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.

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 značením povinných polí je pomocí hvězdičky za popiskem povinného pole. Na začátku nebo konci formuláře by pak měla být informace, že povinná pole jsou značena hvězdičkou.

• Povinné pole by rovněž mělo mít nastaveno atribut aria-required="true" a signalizovat tak povinnost pole asistenčním technologiím, jako jsou odečítače obrazovky.

• Povinné pole lze indikovat také HTML atributem required, jehož chování se od atributu aria-required="true" liší v tom, že přítomnost atributu required na formulářovém poli a nevyplnění hodnoty tohoto pole neumožní odeslání formuláře. Navíc 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 asistenční technologie, kdežto atribut required ovlivňuje funkcionalitu stránky jako takové pro všechny uživatele.

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:

• 1.3.1 – Info and Relationships.

• 1.4.1 – Use of Color.

• 2.4.6 – Headings and Labels.

• 3.2.2 – On Input.

• 3.3.2 – Labels or Instructions.

• 4.1.2 – Name, Role, Value.

Autor: Adam Samec