Přístupná validace formulářů a chybové hlášky

V pokladně a registračních formulářích e-shopy ztrácejí zákazníky a práce s chybami je místo, kde formuláře nejčastěji selhávají u lidí se čtečkou obrazovky, lupou nebo klávesnicí. Pravidlo je jednoduché: řekněte, co je špatně, textem, u pole, a postarejte se, aby to asistivní technologie ohlásila. Stránka je součástí série přístupné vzory UI.

Související kritéria WCAG

• 3.3.1 Identifikace chyb (A): „položka s chybou je identifikována a chyba je uživateli popsána textem“. W3C dodává, že barvu lze použít, ale jen navíc k textu.
• 3.3.3 Návrh opravy chyby (AA): pokud se chyba zjistí automaticky a oprava je známá, navrhněte ji, pokud by to neohrozilo bezpečnost nebo účel obsahu. „E-mail není platný“ splňuje 3.3.1; „Zadejte e-mailovou adresu ve tvaru [email protected]“ splňuje i 3.3.3.
• 3.3.2 Popisky nebo instrukce (A): předem řekněte, co je povinné a v jakém formátu.
• 4.1.3 Stavové zprávy (AA): vlastní příklad W3C je text „5 chyb na stránce“ přidaný do formuláře bez přesunu fokusu, který se musí oznámit. Zpráva, která dostane fokus, je změna kontextu, nikoli stavová zpráva.
• 3.3.4 Prevence chyb (právní, finanční, datové) (AA): objednávky musí jít vrátit, před odesláním zkontrolovat nebo potvrdit.
• 1.4.1 Použití barvy (A), 1.4.3 Kontrast (minimální) (AA): červený text na bílé musí stále dosáhnout poměru 4,5:1.
• 3.3.7 Opakované zadávání (A): po chybě nenuťte uživatele zadávat znovu údaje, které už uvedl.

Příklad kódu

<form novalidate>
  <div id="error-summary" tabindex="-1" aria-labelledby="error-summary-title" hidden>
    <h2 id="error-summary-title">2 chyby ve formuláři</h2>
    <ul>
      <li><a href="#email">E-mail: zadejte adresu ve tvaru [email protected]</a></li>
      <li><a href="#postcode">PSČ: zadejte ho ve tvaru 110 00</a></li>
    </ul>
  </div>

  <label for="email">E-mail</label>
  <input id="email" type="email" autocomplete="email"
         aria-invalid="true" aria-describedby="email-error">
  <p id="email-error" class="error">
    <span aria-hidden="true">⚠</span> Zadejte adresu ve tvaru [email protected]
  </p>

  <label for="postcode">PSČ <span class="hint" id="postcode-hint">(například 110 00)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Zadejte PSČ ve tvaru 110 00</p>

  <button type="submit">Pokračovat k platbě</button>
</form>

Jak to funguje:

• Text u pole. Každá zpráva je viditelný text propojený přes aria-describedby, takže se čte spolu s polem. aria-invalid="true" označí pole jako neplatné; je to technika W3C ARIA21 „Using aria-invalid to Indicate An Error Field“.
• Souhrn chyb po odeslání. Nahoře zobrazte souhrn s odkazy na pole a přesuňte na něj fokus (má tabindex="-1", aby fokus mohl dostat), nebo přesuňte fokus na první neplatné pole. Pokud fokus nepřesouváte, oznamte chyby živou oblastí; to je technika W3C ARIA19 „Using ARIA role=alert or Live Regions to Identify Errors“. Nedělejte obojí, jinak se zpráva přečte dvakrát.
• Průběžná validace při psaní má být střídmá: ověřujte, když uživatel pole opustí, ne při každém stisku klávesy, a chybu odstraňte, jakmile je opravená.
• Zachovejte data. Po neúspěšném odeslání nechte vše, co uživatel zadal.
• Nativní validace prohlížeče (required, type="email") funguje také, ale její zprávy a vzhled se liší podle prohlížeče a jazyka; mnoho e-shopů používá novalidate a vlastní zprávy v jazyce stránky.

Klávesnice a chování fokusu

Časté chyby v e-shopech

• Jen červené ohraničení neplatného pole, nebo červená hvězdička bez textu.
• Chyby jako toast nahoře na obrazovce, který po třech sekundách zmizí a nikdy se neoznámí.
• Obecné zprávy („Neplatný vstup“, „Chyba“) bez nápovědy, jaký formát se očekává.
• Placeholder jako jediný popisek a nápověda formátu, který zmizí, jakmile uživatel začne psát.
• Zprávy nepropojené s poli, takže uživatelé čteček slyší popisek a nic víc.
• Tlačítko odeslání zakázané, dokud není formulář platný, což problém skrývá místo toho, aby ho vysvětlilo; viz neaktivní tlačítka.
• Iframy platebních poskytovatelů s vlastními nepopsanými poli a chybami jen v angličtině v lokalizovaném obchodě.
• Formulář se po chybě na serveru vymaže, včetně doručovací adresy.

Co najde automatizovaná kontrola a co ruční testování

Všechna jsou kartami v naší knihovně pravidel. Automatická kontrola vidí formulář v jeho počátečním stavu; neodesílá ho. Testujte ručně: odešlete prázdné i chybné hodnoty a ověřte, že je každá chyba popsaná textem, propojená s polem, oznámená čtečkou obrazovky a čitelná při zvětšení na 200 %. S rozšířením prohlížeče můžete automatická pravidla spustit znovu, když jsou chyby na obrazovce. Postup najdete v článku jak testovat WCAG.

Spusťte bezplatnou kontrolu jedné stránky na pokladně nebo kontaktní stránce. Je to automatizovaná kontrola, nikoli úplný audit.

Časté otázky

Co WCAG vyžaduje u chyb formulářů?

Kritérium 3.3.1 Identifikace chyb (A): pole s chybou je identifikováno a chyba je popsána textem. Kritérium 3.3.3 Návrh opravy chyby (AA): pokud je oprava známá, navrhněte ji. Kritérium 4.1.3 Stavové zprávy (AA): zprávy, které se objeví bez přesunu fokusu, asistivní technologie oznámí.

Stačí k označení chyby červené ohraničení?

Ne. W3C uvádí, že barvu lze použít navíc, ale chyba musí být identifikována i textem. Samotné červené ohraničení selže u lidí, kteří barvy nerozlišují, i u uživatelů čteček obrazovky.

Jak propojit chybovou zprávu s polem?

Dejte zprávě id, odkažte na ni z pole přes aria-describedby a na poli nastavte aria-invalid="true" (technika W3C ARIA21). Čtečka obrazovky pak přečte popisek, neplatný stav i zprávu.

Má se fokus přesunout na první chybu?

Po odeslání je běžný a spolehlivý postup přesunout fokus na souhrn chyb nebo na první neplatné pole. Pokud se fokus nepřesune, musí být zpráva typu „3 chyby ve formuláři“ stavovou zprávou, aby se oznámila.

Dokáže automatizovaná kontrola otestovat chyby formuláře?

Zkontroluje formulář v počátečním stavu: popisky, hodnoty autocomplete, platné odkazy ARIA a kontrast. Formuláře neodesílá, takže zda se chyby objeví, jsou popsané textem a jsou oznámené, je nutné otestovat ručně.

Zdroje

• W3C, Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• W3C, Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html
• W3C, Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html