Formulář s validací - Jak na přístupnost
V tomto díle našeho seriálu o přístupnosti si popíšeme základní obecné požadavky na webové formuláře. Zejména se ale blíže zaměříme na jedno z přístupných řešení implementace validace webových formulářů a ukážeme si, jak už je u těchto našich článků zvykem, jak takové funkční řešení může vypadat v praxi.
Základní obecné požadavky na formulář
- Povinná pole formuláře by měla mít nastavena atribut aria-required="true". To je informace pro odečítače obrazovky, aby při zaměření pole fokusem klávesnice uživateli oznámily, že pole je povinné.
- Chybná pole by měla mít pomocí JavaScriptu nastavena atribut aria-invalid="true" v závislosti na tom, jestli je pole chybně vyplněno nebo ne. Podobně i zde tento atribut způsobuje, že stav platnosti pole bude uživateli odečítače ohlášen při zaměření tohoto pole fokusem klávesnice.
- Chybná i povinná pole by neměla být vyznačena jen pomocí barvy, ale také ikonkou například vykřičníku respektive hvězdičkou, aby tato informace byla přístupná i pro barvoslepé uživatele.
- Pokud možno, tak pro svázání polí s jejich pojmenováním používejte raději element <label for="id-svazaneho-pole">, neboť oproti svázání pomocí atributu aria-labelledby umožníte, že dané pole bude možné aktivovat vedle kliknutí na toto pole také kliknutím na jeho pojmenování. To se hodí především u zaškrtávacích polí, na které se myší hůře trefuje.
- U polí pro vyplnění hesla je dobré uvést požadavky na heslo ještě před jeho chybným zadáním. Tyto požadavky by pak měly být svázány s příslušným polem pro zadání hesla pomocí atributu aria-describedby. To zajistí, že požadavky na heslo budou přečteny odečítačem v momentě přesunutí fokusu klávesnice na dané pole.
- Vedle polí pro vyplnění hesla je dobré přidat ještě řádně pojmenované zaškrtávací pole, které když zaškrtnete, tak se zadané heslo odkryje, aby uživatel měl kontrolu, že heslo zadal správně.
- Pole, které je zrovna zaměřené fokusem klávesnice, by mělo být vizuálně zvýrazněno. Toho lze docílit použitím pseudotřídy :focus a nastavením CSS vlastnosti outline.
Možné přístupné způsoby validace formulářů
Při realizaci přístupné validace webového formuláře se nejčastěji setkáváme s těmito dvěma způsoby chování:
- Chybové hlášky o špatně zadaných formulářových polích se zobrazí a jsou přečteny odečítačem obrazovky už v momentě přesunutí fokusu klávesnice mimo chybné pole. Výhodou tohoto přístupu je, že se o chybě dozvíme hned. Nevýhodou je skutečnost, že takovou validaci není úplně triviální správně a přístupně implementovat a také to, že případné hlášení o chybě při každém přesunu fokusu mimo pole může být pro uživatele otravné nebo matoucí.
- Chybové hlášky se zobrazují hromadně až po pokusu o odeslání formuláře. Výhodou je poměrná jednoduchost implementace a přehlednost pro uživatele, nevýhodou je pro uživatele nutnost projít celým formulářem až k tlačítku pro jeho odeslání, aby se o případných chybách dozvěděl. Na toto řešení se blíže zaměříme dále v tomto článku.
Popis přístupného řešení validace formuláře
Aby byla validace webového formuláře dobře přístupná, měla by splňovat následující kritéria:
- Chybové hlášky by měly být s příslušným chybně zadaným polem svázány přes atribut aria-describedby. To zaručí, že v momentě přesunutí fokusu klávesnice na chybné pole budou patřičné hlášky odečítačem přečteny.
- Při pokusu o odeslání formuláře proběhne validace všech jeho polí najednou a v případě, že je některé z polí chybně vyplněno, se fokus přesune na první takové chybné pole, což díky atributu aria-describedby popsaném v předchozím bodu zároveň způsobí přečtení první patřičné chybové hlášky odečítačem.
- Po úspěšném odeslání formuláře by se uživatel odečítače o této skutečnosti měl dozvědět. To zajistíme nejlépe tak, že hlášku o úspěchu zobrazíme v elementu s atributem aria-live="assertive".
Funkční ukázka
Zdrojový kód ke stažení
Související kritéria úspěšnosti WCAG
Výše popsaná implementace formuláře s validací splňuje především následující kritéria úspěšnosti Pokynů pro zpřístupnění webového obsahu WCAG (Web Content Accessibility Guidelines):
- 1.3.1: Info and Relationships.
- 2.1.1: Keyboard.
- 2.1.2: No Keyboard Trap.
- 2.1.3: Keyboard (No Exception).
- 2.4.6: Headings and Labels.
- 2.4.7: Focus Visible.
- 2.5.3: Label in Name.
- 3.3.1: Error Identification.
- 3.3.3: Error Suggestion.
- 3.3.2: Labels or Instructions.
- 4.1.2: Name, Role, Value.
Autor: Adam Samec
- Log in to post comments