Formulář s validací – Jak na přístupnost
V tomto díle našeho seriálu o přístupnosti si popíšeme jedno z doporučených 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ář
Přístupnosti webových formulářů se obecněji a podrobněji věnujeme v tomto článku. Shrňme si ale pro jistotu ještě jednou základní požadavky:
-
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 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 nebo symbolem, například chybná pole vykřičníkem a pojmenování povinných polí 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 , neboť oproti svázání pomocí atributu
aria-labelledbyumož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ěřeno fokusem klávesnice, by mělo být vizuálně zvýrazněno. Toho lze docílit použitím pseudotřídy
:focusa nastavením CSS vlastnostioutline.
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-describedbypopsané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
