Přístupné chybové zprávy: když formuláře blokují uživatele

Okamžik, kdy se formulář rozbije

Představte si to: nevidomý uživatel vyplní objednávkový formulář, odešle jej a od své čtečky obrazovky neuslyší nic užitečného. Žádné oznámení. Žádné vysvětlení. Stránka vizuálně červeně označila pět validačních chyb, ale uživatel o tom nemá ani tušení. Odešle formulář znovu. A znovu. Nakonec odejde.

Není to okrajový scénář. Nepřístupné zpracování chyb je jednou z nejčastějších překážek, které při skutečných auditech nacházíme, a frustruje uživatele v tu nejhorší možnou chvíli — když se snaží dokončit transakci nebo odeslat něco důležitého.

Dobrou zprávou je, že náprava spočívá především v tom, vědět, jak vypadá „dobré“ řešení. Selhání se téměř vždy opakují v několika stejných vzorech.

Proč jsou chybové zprávy pro uživatele asistivních technologií obtížné

Vidící uživatelé myši si validačních chyb obvykle všimnou okamžitě — červený rámeček, výstražná ikona, text objevující se pod polem. Ale uživatelé, kteří se spoléhají na čtečky obrazovky, ovládání klávesnicí nebo hlasové ovládání, mají zásadně odlišnou zkušenost.

Když je formulář odeslán a objeví se chyby:

Uživatelé čteček obrazovky nemusí slyšet vůbec nic, pokud se fokus nepřesune na chybu nebo ji neoznámí živá oblast (live region)
Uživatelé klávesnice potřebují mít možnost dostat se ke každé chybové zprávě z klávesnice a pochopit, ke kterému poli patří
Uživatelé hlasového ovládání potřebují oslovit pole viditelným a přesným popiskem — pokud je popisek chybný nebo chybí, jsou v koncích

Nic z toho se neděje automaticky. Musíte to vybudovat.

Kritéria WCAG, která se zde uplatňují

Zpracování chyb přímo pokrývají čtyři kritéria úspěšnosti standardu WCAG 2.2:

3.3.1 Identifikace chyb (úroveň A) — Pokud je chyba zjištěna automaticky, chybná položka musí být identifikována a popsána uživateli textem. Chyby nesmíte sdělovat pouze barvou.

3.3.2 Popisky nebo pokyny (úroveň A) — Pole vyžadující konkrétní formát musí tento požadavek zřetelně sdělit před zadáváním nebo během něj, ne až po neúspěšném odeslání.

3.3.3 Návrh opravy chyby (úroveň AA) — Pokud je chyba zjištěna a jsou známy návrhy na opravu, poskytněte je. „Neplatné datum“ nestačí. „Zadejte datum ve formátu DD/MM/RRRR“ ano.

3.3.4 Předcházení chybám (úroveň AA) — U odeslání se závažnými důsledky (finanční transakce, právní ujednání) dejte uživatelům možnost zkontrolovat, opravit a potvrdit údaje dřív, než se akce stane nevratnou.

Existuje také kritérium 4.1.3 Stavové zprávy (úroveň AA), které pokrývá dynamicky vkládané zprávy, jež nezískávají fokus — ty musí být asistivní technologií oznámeny pomocí role="status" nebo role="alert".

Co přístupná chybová zpráva skutečně potřebuje

Správné chybové zprávy vyžadují pozornost ve čtyřech samostatných vrstvách:

1. Programové propojení

Každá chybová zpráva musí být svázána se svým polem pomocí aria-describedby. To čtečkám obrazovky říká, aby text chyby oznámily, když pole získá fokus.

<!-- 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>

Atribut aria-invalid="true" signalizuje, že pole je aktuálně neplatné, což většina čteček obrazovky oznámí, když na něj dopadne fokus.

2. Správa fokusu po odeslání

Když je formulář odeslán a obsahuje chyby, fokus se musí přesunout někam, kde je to užitečné. Dva nejběžnější vzory:

Přesunout fokus na souhrn chyb v horní části formuláře, který vyjmenovává všechny chyby s odkazy na příslušná pole
Přesunout fokus na první chybné pole

Pokud fokus zůstane na tlačítku odeslání nebo nikde, uživatelé čteček obrazovky musí chyby objevit sami procházením formuláře — pokud vůbec vědí, že nějaké existují.

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

3. Oznamování dynamických chyb pomocí živých oblastí

U chyb, které se objevují během psaní (validace v reálném čase přímo u pole), použijte živé oblasti ARIA, aby byla zpráva oznámena, aniž by se musel přesouvat fokus.

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

Použijte role="alert" / aria-live="assertive" pro chyby vyžadující okamžitou pozornost. Použijte role="status" / aria-live="polite" pro méně naléhavou zpětnou vazbu, která počká, až se uživatel odmlčí.

4. Samotná chybová zpráva

Na jazyce záleží. Přístupné chybové zprávy jsou:

Konkrétní: říkají, co je špatně, ne jen že je něco špatně
Návodné: říkají uživateli přesně, co má udělat pro opravu
Zdvořilé: vyhýbají se obviňujícím formulacím jako „zadali jste neplatnou hodnotu“

Nepřístupné	Přístupné
„Neplatný vstup“	„E-mailová adresa musí obsahovat znak @, např. jmeno@priklad.cz“
„Chyba“	„Datum musí být ve formátu DD/MM/RRRR“
„Povinné pole“	„Celé jméno je povinné“
„Neplatné heslo“	„Heslo musí mít alespoň 8 znaků a obsahovat jednu číslici“

Vzory pro různé chybové scénáře

Chyby přímo u pole

Nejběžnější vzor. Chybová zpráva se zobrazí přímo pod příslušným polem. Funguje dobře u jednoduchých formulářů. Aby byla správně oznámena, vyžaduje aria-describedby a aria-invalid.

Souhrnné chybové bannery

U dlouhých formulářů s více chybami umístěte nahoru souhrn, který vyjmenovává všechny problémy jako odkazy vedoucí k příslušným polím. Po neúspěšném odeslání sem přesuňte fokus. Tento vzor používá GOV.UK a je široce doporučován pro složité formuláře.

Toast notifikace

Krátkodobé zprávy objevující se na okraji obrazovky patří k nejméně přístupným běžně používaným vzorům. Zmizí dřív, než se k nim uživatelé čteček obrazovky dostanou, často nejsou vůbec oznámeny a nenabízejí žádnou cestu k nápravě. Nepoužívejte toasty pro chyby. Pokud je přesto používáte, doplňte je trvalým chybovým stavem přímo ve formuláři.

Systémové chyby

Když se něco pokazí na straně serveru, řekněte uživateli srozumitelným jazykem, co se stalo a co může udělat dál. „Něco se pokazilo“ bez dalšího vedení nechává uživatele bezradné.

<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>

Kontrolní seznam pro testování

Po implementaci zpracování chyb ověřte následující ručně — automatizované nástroje většinu z toho nezachytí:

Odeslání prázdného povinného formuláře přesune fokus na souhrn chyb nebo na první chybné pole
Každá chybová zpráva je propojena se svým polem pomocí aria-describedby
Chybná pole mají aria-invalid="true"
Chybové zprávy jsou oznámeny, když fokus dopadne na dotčené pole
Validace v reálném čase používá živé oblasti
Chybové zprávy používají konkrétní, návodný jazyk — ne jen „neplatné“
Barva není jediným způsobem indikace chyb (vedle červené je ikona nebo textový popisek)
K chybě se lze dostat tabulátorem z klávesnice
Pořadí fokusu po odeslání je logické a nepřeskakuje nepředvídatelně
Toast zprávy jsou doplněny trvalým chybovým stavem

Proč automatizované nástroje většinu z toho minou

Automatizovaný skener dokáže zkontrolovat, zda aria-describedby ukazuje na existující prvek a zda je přítomen aria-invalid. Nedokáže zkontrolovat, zda se fokus po odeslání přesouvá správně, zda je text chyby přesný, nebo zda toast notifikace nezmizí dřív, než ji lze přečíst. Naše ruční audity přístupnosti zahrnují testování formulářů se skutečnými asistivními technologiemi — jediný spolehlivý způsob, jak ověřit, že zpracování chyb skutečně funguje od začátku do konce.

Pokud si nejste jisti, jak jsou na tom vaše formuláře, spusťte bezplatný sken, který nejprve odhalí automaticky zjistitelné problémy, a pokračujte odtud.