Webové formuláře – Jak na přístupnost

Tento článek je dalším příspěvkem do série našich textů věnujících se přístupnosti především webových stránek a aplikací. Tentokrát se podíváme na zoubek webovým formulářům, neboť i zde dochází k častým prohřeškům proti přístupnosti.

Popisky formulářových polí

Základním požadavkem na přístupnost formulářů je zajištění, aby každé formulářové pole bylo stručně, jasně a výstižně pojmenováno a aby tento popisek byl správně značen ve zdrojovém kódu jedním z následujících způsobů:

Pomocí atributu for na elementu <label>, kde hodnota atributu for odkazuje prostřednictvím id na popisované formulářové pole. Tento způsob je doporučen, neboť v tomto případě je možné formulářové pole aktivovat nejen kliknutím myši na samotné pole, ale také na jeho svázaný popisek v podobě elementu <label>.
Pomocí atributu aria-labelledby nastaveném na daném formulářovém poli, kdy tento atribut odkazuje prostřednictvím id na element pojmenovávající dané pole.
Pomocí atributu aria-label nastaveném rovněž na daném formulářovém poli v případě, že nechcete vizuálně zobrazovat popisek formulářového pole. Hodnota atributu aria-label je přímo popisek daného pole.

Delší popisy polí a chybové hlášky

Potřebujete-li uvést nějaký delší popis formulářového pole, např. instrukci, jaká hodnota pole je vyžadována, tak doporučujeme odkázat se na každý takový element s delším popisem pomocí atributu aria-describedby nastaveném na daném formulářovém poli. To způsobí, že tento popis bude odečítačem obrazovky přečten po přesunutí fokusu na dané pole, avšak až jako poslední informace. Stejným způsobem doporučujeme se přes atribut aria-describedby odkazovat také na elementy s chybovými hláškami pro dané pole. Příklad tohoto řešení lze nalézt v článku věnovaném validaci formulářů.

Při použití atributu aria-describedby nebo také aria-labelledby ale mějte na paměti, že text odkazovaného elementu bude odečítačem obrazovky přečten i v případě, že tento element je skryt například přes CSS vlastnost display: none;, nebo přes atribut aria-hidden="true". Pokud tedy takový element odečítačem číst nechcete, tak na něj přes atribut aria-describedby nebo aria-labelledby neodkazujte. V praxi tak například při zobrazování nebo skrývání chybových hlášek nestačí jen měnit jejich zobrazování přes CSS vlastnost display: none;, ale je nutné také přidávat nebo odebírat id odkazovaného elementu v atributu aria-describedby, případně odkazovaný element do stránky vůbec nevkládat.

Značení povinných polí

Přístupné značení povinných formulářových polí spočívá v následujícím:

Neindikovat povinné pole jen pomocí barvy, např. červenou barvou. Přítomnost pouze barevného odlišení může totiž představovat problém pro barvoslepé uživatele.
Doporučeným vizuálním odlišením povinných polí je pomocí hvězdičky za popiskem povinného pole. Na začátku formuláře by pak měla být informace, že povinná pole jsou značena hvězdičkou.
Povinné pole by mělo být signalizováno také asistivním technologiím jedním z následujících způsobů:
- Pomocí atributu aria-required="true", který pouze říká asistivním technologiím, jako jsou odečítače obrazovky, že jde o povinné pole.
- Povinné pole lze indikovat také HTML atributem required, jež se chová stejně jako atribut aria-required="true", avšak navíc oproti němu způsobuje to, že přítomnost atributu required na formulářovém poli a nevyplnění hodnoty tohoto pole neumožní odeslání formuláře. Kromě toho webové prohlížeče při pokusu o odeslání formuláře za těchto okolností přesunou fokus do daného povinného pole a odečítače typicky současně samovolně ohlásí, že pole má být vyplněno. Jinými slovy, atribut aria-required="true" má stejně jako ostatní ARIA atributy dopad jen na asistivní technologie, kdežto atribut required ovlivňuje funkcionalitu stránky jako takové pro všechny uživatele.

Další atributy polí

Atribut `placeholder`

Elementy <input> určitých typů a element <textarea> mohou mít nastaven atribut placeholder čili zástupný text, který se zobrazuje ve formulářovém poli za předpokladu, že do pole není vepsána žádná hodnota. Z hlediska přístupnosti je silně doporučeno, aby tento text nesuploval pojmenování daného pole, ale aby jen uváděl příklad jeho možné hodnoty. Problém totiž je, že hodnota atributu placeholder přestane být viditelná a ani nemusí být čtena odečítačem, jakmile uživatel do pole zapíše hodnotu. Vyplní-li tedy uživatel celý formulář s nějakou chybou a je následně při pokusu o jeho odeslání veden k tomu, aby opravil pole s určitou hodnotou atributu placeholder, tak nalezení takového pole může být bez smazání vyplněných hodnot polí nemožné.

Atribut `type`

Elementy <input> mohou mít nastaven atribut type, který především určuje, jaké hodnoty lze do pole zapsat. Dalším pro přístupnost důležitým chováním je však i to, že tento atribut může na dotykových mobilních zařízeních určovat, jaká virtuální klávesnice se při aktivaci takového pole uživateli zobrazí. Atribut type="email" tedy může způsobit zobrazení klávesnice, která umožňuje snadné vepsání zavináče, atribut type="number" zase může zobrazit klávesnici umožňující zadání pouze číselné hodnoty a podobně. Pokud tedy hodnota vašeho pole odpovídá nějakému z podporovaných typů, tak je doporučeno tento atribut type patřičně nastavit.

Atribut `autocomplete`

Atribut autocomplete nastavený na polích <input>, <textarea> či <select> určuje, zda může prohlížeč automaticky vyplnit dané pole na základě uživatelem dříve vyplněných polí se stejným účelem. Vyplní-li uživatel například <input> pole s atributem autocomplete="given-name" na jedné stránce čili s atributem indikujícím, že vyplňuje křestní jméno, může prohlížeč na stejné nebo i jiné stránce automaticky za uživatele vyplnit pole se stejným atributem totožnou hodnotou křestního jména, jakou již dříve zadal na první stránce. Takové automatické vyplňování polí může znatelně usnadnit zadávání dat do formulářů zejména uživatelům s pohybovým či kognitivním postižením. Informativní stránky standardu WCAG pro pochopení kritéria úspěšnosti 1.3.5 – Identify Input Purpose navíc zmiňují výhodu používání atributu autocomplete i v tom, že prohlížeč nebo asistivní technologie může takto identifikovaná pole opatřit navíc i symbolem či ikonou představující účel daného pole, například u pole pro datum narození zobrazit narozeninový dort, a tím tak usnadnit porozumění účelu pole uživatelům s kognitivním postižením.

Seskupování polí

Skládá-li se formulář z více sekcí formulářových polí, které spolu nějak souvisí, typicky např. rozdělení na fakturační a doručovací adresu, tak by tyto sekce měly být seskupeny jedním z následujících způsobů:

Pomocí elementu <fieldset> obalit danou skupinu polí a jako prvního potomka do elementu <fieldset> umístit element <legend> obsahující název této skupiny polí.
Skupinu polí obalit do elementu <div>, nastavit mu atribut role="group" a pojmenovat pomocí atributu aria-label nebo aria-labelledby.

Jestliže jsou skupiny polí takto správně značeny, tak odečítač obrazovky při procházení formuláře pomocí klávesnice ohlásí vstup do nebo konec dané skupiny včetně oznámení jejího názvu.

Skupiny přepínačů

Typickým případem, kdy by formulářové prvky měly být v kódu seskupeny a pojmenovány, je seskupování přepínačů, tedy souvisejících elementů <input type="radio">. V tomto případě je doporučeno jedno z následujícího:

Seskupit přepínače pomocí elementu <fieldset> a pojmenovat pomocí <legend> stejně, jako bylo popsáno výše.
Více však doporučujeme obalit přepínače raději do elementu <div> s atributem role="radiogroup" a pojmenovat pomocí atributu aria-label nebo aria-labelledby.

Členění rozsáhlých formulářů pomocí nadpisů

Dobrou praxí v případě rozsáhlých formulářů, podobně jako u seskupování jejich prvků popsaného výše, je členit formulářové prvky navíc ještě pomocí nadpisů, tedy pomocí sémantických elementů typicky <h2> až <h6>. Přítomnost těchto nadpisů umožní jednodušší orientaci a navigaci uživatele ve formuláři, neboť odečítače obrazovky disponují funkcí skákání po nadpisech, takže při potřebě přesunout se o delší úsek nahoru nebo dolů ve formuláři uživatel nemusí mnohokrát přesouvat fokus klávesnice tabulátorem nebo přes Shift + tabulátor.

Pořadí prvků ve formuláři

Autor formuláře by měl počítat s tím, že uživatel odečítače obrazovky prochází obsah formuláře sekvenčně v pořadí, v jakém jsou jeho prvky uvedeny ve zdrojovém kódu. Proto doporučujeme dbát zejména na následující:

Tlačítko pro odeslání formuláře by se mělo nacházet na jeho samotném konci.
Veškeré souhlasy, typicky zaškrtávací pole pro potvrzení obchodních podmínek nebo pro potvrzení zpracování osobních údajů, by se měla nacházet před, nikoliv za tlačítkem pro odeslání formuláře.

Požadavky na dynamické formuláře

Na dnešních interaktivních webech je častým jevem, že při volbě nějakého formulářového pole, např. při změně přepínače, se v závislosti na jeho hodnotě dynamicky pomocí JavaScriptu načte další obsah formuláře. Takové chování je z hlediska přístupnosti v pořádku, avšak jen za předpokladu, že obsah, který se takto posléze dynamicky načítá, se v kódu změní až za polem formuláře, jež tuto dynamickou změnu obsahu způsobil a jež má fokus klávesnice. Čili mění se obsah, který uživatel odečítače obrazovky při sekvenčním procházení formuláře shora dolů teprve navštíví, nikoliv obsah, který již navštívil. Jinými slovy, je třeba zaručit, že uživateli odečítače neunikne žádný důležitý obsah.

Automatická změna fokusu

Dalším občas se vyskytujícím chováním dynamických formulářů je automatické přesouvání fokusu klávesnice při změně hodnoty nějakého formulářového pole. Příkladem je situace, kdy bezprostředně po volbě platební metody pomocí přepínače se fokus automaticky přesune do pole pro zadání čísla platební karty. Jiným takovým příkladem je automatické přesouvání fokusu z jednoho čtyřčíslí platební karty do druhého po vepsání čtvrté číslice. Za předpokladu, že uživatel není na takové chování předem upozorněn, jsou oba tyto příklady automatického přesouvání fokusu považovány za takzvanou změnu kontextu, která může zmást především uživatele odečítačů, a je tedy, striktně řečeno, považována za prohřešek proti přístupnosti.

Validace formuláře

Mezi důležité aspekty přístupnosti formulářů patří zajištění, aby při chybném vyplnění formulářových údajů byl uživatel přístupnou formou srozuměn s veškerými nastalými chybami, bylo mu sděleno, jak je opravit, a co nejvíc mu usnadněno provést opravu. Touto problematikou se zabývá článek Formulář s validací, jehož součástí je i funkční ukázka vzorového formuláře se správně zajištěnou validací.

Související kritéria úspěšnosti standardu WCAG

Výše uvedená doporučení vycházejí jednak z dobré praxe, jednak z následujících takzvaných kritérií úspěšnosti webového standardu WCAG 2.2:

Autor: Adam Samec

Štítky

přístupnost

Jak na přístupnost