Amikor a hibaüzenetek kizárják a felhasználókat

A pillanat, amikor az űrlap elakad

Képzelje el: egy vak felhasználó kitölt egy fizetési űrlapot, elküldi, és semmi hasznosat nem hall a képernyőolvasójától. Nincs bejelentés. Nincs magyarázat. Az oldal vizuálisan öt érvényesítési hibát jelölt meg pirossal, de a felhasználónak fogalma sincs róla. Újra megnyomja a küldés gombot. Aztán megint. Végül elhagyja az oldalt.

Ez nem szélsőséges forgatókönyv. Az akadálymentesség nélküli hibakezelés az egyik leggyakoribb akadály, amellyel valódi auditok során találkozunk, és olyan, amely a lehető legrosszabb pillanatban frusztrálja a felhasználókat — amikor tranzakciót próbálnak lebonyolítani vagy valami fontosat beküldeni.

A jó hír, hogy a javítás nagyrészt azon múlik, hogy tudjuk, hogyan néz ki a „jó”. A hibák szinte mindig ugyanaz a néhány minta.

Miért nehezek a hibaüzenetek a kisegítő technológiák felhasználóinak

A látó, egeret használó felhasználók általában azonnal észreveszik az érvényesítési hibákat — a piros keretet, a figyelmeztető ikont, a mező alatt megjelenő szöveget. De a képernyőolvasóra, billentyűzetes navigációra vagy hangvezérlésre támaszkodó felhasználók alapvetően más élménnyel szembesülnek.

Amikor egy űrlapot elküldenek, és hibák jelennek meg:

A képernyőolvasót használók lehet, hogy semmit sem hallanak, hacsak a fókusz nem kerül a hibára, vagy egy élő régió be nem jelenti azt
A billentyűzetet használóknak el kell tudniuk érni minden hibaüzenetet billentyűzetről, és meg kell érteniük, melyik mezőhöz tartozik
A hangvezérlést használóknak látható, pontos címkével kell megszólítaniuk a mezőket — ha a címke hibás vagy hiányzik, elakadnak

Mindez nem történik meg automatikusan. Meg kell építeni.

A vonatkozó WCAG-követelmények

A WCAG 2.2 négy teljesítési feltétele foglalkozik közvetlenül a hibakezeléssel:

3.3.1 Hiba azonosítása (A szint) — Ha egy hibát automatikusan észlel a rendszer, a hibás elemet azonosítani és szövegesen le kell írni a felhasználó számára. A hibákat nem lehet kizárólag színnel jelezni.

3.3.2 Címkék vagy utasítások (A szint) — Azoknál a mezőknél, amelyek meghatározott formátumot igényelnek, ezt a követelményt a bevitel előtt vagy közben kell egyértelművé tenni, nem csak a sikertelen beküldés után.

3.3.3 Hibajavítási javaslat (AA szint) — Ha a rendszer hibát észlel, és ismertek a javítási javaslatok, azokat meg kell adni. Az „Érvénytelen dátum” nem elég. Az „Adja meg a dátumot NN/HH/ÉÉÉÉ formátumban” igen.

3.3.4 Hibamegelőzés (AA szint) — Következményekkel járó beküldéseknél (pénzügyi tranzakciók, jogi megállapodások) adjon lehetőséget a felhasználóknak az áttekintésre, javításra és megerősítésre, mielőtt a művelet véglegessé válik.

Ezenkívül létezik a 4.1.3 Állapotüzenetek (AA szint), amely a dinamikusan beszúrt, fókuszt nem kapó üzenetekre vonatkozik — ezeket a kisegítő technológiáknak be kell jelenteniük role="status" vagy role="alert" használatával.

Mire van valójában szüksége egy akadálymentes hibaüzenetnek

A hibaüzenetek helyes megvalósítása négy különálló rétegre való odafigyelést igényel:

1. A programozott kapcsolat

Minden hibaüzenetet a mezőjéhez kell kötni aria-describedby attribútummal. Ez utasítja a képernyőolvasókat, hogy olvassák fel a hibaszöveget, amikor a mező fókuszt kap.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Az aria-invalid="true" attribútum azt jelzi, hogy a mező jelenleg érvénytelen, amit a legtöbb képernyőolvasó bejelent, amikor a fókusz rákerül.

2. Fókuszkezelés beküldés után

Amikor egy űrlapot beküldenek, és hibák vannak, a fókusznak valamilyen hasznos helyre kell kerülnie. A két leggyakoribb minta:

A fókusz áthelyezése az űrlap tetején lévő hibaösszefoglalóra, amely az összes hibát felsorolja az érintett mezőkre mutató linkekkel
A fókusz áthelyezése az első hibás mezőre

Ha a fókusz a küldés gombon marad, vagy sehová sem kerül, a képernyőolvasót használóknak maguknak kell felfedezniük a hibákat az űrlapon végignavigálva — ha egyáltalán tudnak a hibák létezéséről.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Élő régiós bejelentések dinamikus hibákhoz

A gépelés közben megjelenő hibáknál (beviteli mező melletti valós idejű érvényesítés) használjon ARIA élő régiókat, hogy az üzenet a fókusz áthelyezése nélkül is felolvasásra kerüljön.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Használjon role="alert" / aria-live="assertive" beállítást az azonnali figyelmet igénylő hibákhoz. Használjon role="status" / aria-live="polite" beállítást a kevésbé sürgős visszajelzésekhez, amelyek megvárhatják, amíg a felhasználó szünetet tart.

4. Maga a hibaüzenet

A megfogalmazás számít. Az akadálymentes hibaüzenetek:

Konkrétak: megmondják, mi a hiba, nem csak azt, hogy valami hibás
Cselekvésre ösztönzők: pontosan megmondják a felhasználónak, mit tegyen a javításhoz
Udvariasak: kerülik a hibáztató nyelvezetet, mint például „érvénytelen értéket adott meg”

Nem akadálymentes	Akadálymentes
„Érvénytelen bevitel”	„Az e-mail-címnek tartalmaznia kell @ jelet, pl. nev@pelda.hu”
„Hiba”	„A dátumot NN/HH/ÉÉÉÉ formátumban kell megadni”
„Kötelező mező”	„A teljes név megadása kötelező”
„Érvénytelen jelszó”	„A jelszónak legalább 8 karakterből kell állnia, és tartalmaznia kell egy számot”

Minták különböző hibaforgatókönyvekhez

Mező melletti hibák

A leggyakoribb minta. A hibaüzenet közvetlenül a hozzá tartozó mező alatt jelenik meg. Egyszerű űrlapoknál jól működik. A helyes felolvasáshoz aria-describedby és aria-invalid attribútumot igényel.

Hibaösszefoglaló sávok

Hosszú, több hibát tartalmazó űrlapoknál helyezzen összefoglalót az űrlap tetejére, amely az összes problémát linkekként sorolja fel, és ezek az érintett mezőhöz ugranak. Sikertelen beküldés után ide helyezze a fókuszt. Ezt a mintát használja a GOV.UK, és összetett űrlapokhoz széles körben ajánlott.

Toast értesítések

A képernyő szélén megjelenő, rövid életű üzenetek a leggyakrabban használt minták közül a legkevésbé akadálymentesek közé tartoznak. Eltűnnek, mielőtt a képernyőolvasót használók elérnék őket, gyakran egyáltalán nem kerülnek bejelentésre, és nem kínálnak helyreállítási útvonalat. Kerülje a toastok használatát hibákhoz. Ha mégis használja őket, párosítsa őket az űrlapon megjelenő tartós hibaállapottal.

Rendszerhibák

Ha valami elromlik a szerveroldalon, közölje a felhasználóval közérthető nyelven, mi történt, és mit tehet ezután. A „Valami hiba történt” további útmutatás nélkül magára hagyja a felhasználót.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

A tesztelési ellenőrzőlista

A hibakezelés megvalósítása után ellenőrizze manuálisan a következőket — az automatizált eszközök a legtöbbjüket nem fogják kiszűrni:

Üres kötelező űrlap beküldésekor a fókusz a hibaösszefoglalóra vagy az első hibás mezőre kerül
Minden hibaüzenet aria-describedby attribútummal kapcsolódik a mezőjéhez
A hibás mezők aria-invalid="true" attribútummal rendelkeznek
A hibaüzenetek felolvasásra kerülnek, amikor a fókusz az érintett mezőre kerül
A valós idejű érvényesítés élő régiókat használ
A hibaüzenetek konkrét, cselekvésre ösztönző nyelvezetet használnak — nem csak annyit, hogy „érvénytelen”
Nem a szín az egyetlen módja a hibák jelzésének (ikon vagy szöveges címke a piros mellett)
A hiba elérhető tabulátorral a billentyűzetről
A beküldés utáni fókuszsorrend logikus, és nem ugrál kiszámíthatatlanul
A toast üzenetek tartós hibaállapottal vannak párosítva

Miért nem veszik észre az automatizált eszközök ennek nagy részét

Egy automatizált ellenőrző meg tudja vizsgálni, hogy az aria-describedby létező elemre mutat-e, és hogy jelen van-e az aria-invalid. Azt viszont nem tudja ellenőrizni, hogy a fókusz helyesen mozog-e a beküldés után, hogy a hibaszöveg pontos-e, vagy hogy egy toast értesítés eltűnik-e, mielőtt elolvasható lenne. Manuális akadálymentességi auditjaink valódi kisegítő technológiákkal végzett, űrlapspecifikus tesztelést is tartalmaznak — ez az egyetlen megbízható módja annak ellenőrzésére, hogy a hibakezelés valóban működik-e elejétől a végéig.

Ha nem biztos benne, hol tartanak az űrlapjai, indítson ingyenes ellenőrzést, hogy először az automatizálható problémák kerüljenek felszínre, és onnan folytassa.