Prístupná štruktúra dokumentu a webu - formuláre

Formuláre sú bežnou súčasťou webov aj mobilných aplikácií. Či už ide o jednoduchý prihlasovací formulár na odber newslettera, alebo zložitý a komplikovaný na podanie daňového priznania či nákup v e-shope. Ako na formuláre, ktoré nebudú klásť prekážku nikomu?

Viackrokový formulár

Ak máme na webe alebo v aplikácii dlhšie formuláre povedzme nákupný košík alebo registračný formulár, prípadne dlhé dotazníky, pre lepšiu prehľadnosť ich rozdeľme do viacerých krokov či podstránok. Zabezpečíme tým prehľadnosť. Samozrejme, je potrebné to starostlivo zvážiť a ak máme možnosť, tak aj otestovať v A-B testoch.

Pokiaľ sa rozhodneme pre delenie, jednotlivé kroky vyznačíme prístupným spôsobom. Používatelia tak nebudú frustrovaní a budú presne vedieť, v akej fáze sa nachádzajú.

Pri vyznačovaní sa nespoliehame, prirodzene, iba na farbu. Ak chceme dať každému vedieť, kde sa nachádza, použijeme napríklad číselné označenie (krok 3 zo 4) alebo percentá (50 % hotovo). Aby aj používateľ screen readera presne vedel, ktorý krok je aktuálny, používame atribút aria-current=“step“ alebo aria-current=“page“.

Prístupnosť z klávesnice

V súčasnosti sa čoraz častejšie stáva, že začiarkavacie polia, prepínače a tlačidlá sú dostupné iba na kliknutie myšou. To spôsobuje problémy celému spektru používateľov, ktorí myš z rôznych dôvodov používať nemôžu.

V prvom rade sú to ľudia so znevýhodnením – nevidiaci, ktorí na kurzor myši logicky nevidia, používatelia s poruchou jemnej motoriky, s postihnutím rúk, ale aj tí, ktorí majú práve zlomenú ruku, alebo sa im myš pokazila.

Preto je nevyhnutné, aby každý interaktívny prvok bol prístupný aj ovládnuteľný z klávesnice. Najjednoduchším spôsobom, ako to dosiahnuť, je používať natívne HTML 5 elementy.

Prístupnosť z klávesnice si môžeme overiť aj sami tak, že si skúsime prejsť celý web klávesom Tab. Ak sú všetky prvky fokusovateľné (vrátane formulárov), tak je všetko v poriadku.

Prístupnosť z klávesnice je aj jedným zo základných kritérií normy WCAG 2.1, konkrétne 2.1: Keyboard accessible – level A.

Identifikácia účelu vstupu

Do editačných polí vo formulároch zadávame rôzne typy údajov – meno, e-mail, telefónne číslo. Každý údaj si vyžaduje iný druh vstupu (napríklad v e-mailovej adrese nemôže chýbať @ – zavináč). Každý takýto účel je vhodné vo formulári špecifikovať.

Editačnému poľu, do ktorého používateľ zapisuje e-mailovú adresu, priradíme typ e-mail (<input type=“e-mail“>), pole s telefónnym číslom zasa typ telefón (<type=“tel“>) a textové polia budú mať typ text (<input type=“text“>).

Načo je to dobré? Eliminujeme tak chyby pri zadávaní údajov.

Na toto sa vzťahuje WCAG kritérium 1.3.5 Identify Input Purpose – level AA.

Označovanie prvkov formulára

Najprv je potrebné zdôrazniť, že každý prvok musí mať označenie (popis, label). Existuje však niekoľko krokov, aby sme zabezpečili, že aj pre ľudí so zdravotným znevýhodnením sa nebudú správať formuláre tak, ako by žiadny popis nemali.

Najvhodnejšie je umiestniť popis editačného poľa nad alebo doľava od neho. Nie doprava, ani nadol, pretože je to vo všeobecnosti mätúce.

Ak je popis pod editačným poľom a ešte s ním ani nie je zviazaný, nevidiaci človek môže byť zmätený z toho, ktorý popis ku ktorému poľu patrí.

Pre používateľov, ktorí používajú lupu (zoom), umiestnenie popisov doprava od poľa znamená, že najprv uvidia pole bez popisu. Aby popis našli, musia posúvať web vo vodorovnom smere, čo je nepohodlné a náročné na zrak aj koncentráciu.

Editačné polia (aj ostatné prvky formulára) musia byť zviazané s ich menovkou. Identifikátor v <input> nastavíme tak, aby zodpovedal atribútu for <label>. <input> je najlepšie nevkladať do <label>, pretože niektoré asistenčné technológie to nepodporujú. Zabezpečíme tým, že keď sa používateľ screen readera bude pohybovať po formulárových prvkoch, vypočuje si zároveň s typom prvku aj jeho popis. Bude tak vedieť, aký údaj má do ktorého editačného poľa zapísať. Screen reader mu tiež oznámi, akú voľbu si vyberá pomocou toho ktorého prepínača, alebo čo začiarkne výberom príslušného check boxu. V zoznamových rámikoch (select boxoch) bude vedieť, k čomu sa ich možnosti vzťahujú.

Používame nápovedy pod prvkami formulára, nie placeholder. Placeholder totiž zmizne po zadaní informácií do poľa, čo sťažuje používateľovi zapamätať si nápovedu alebo popis a vykonať prípadnú opravu. Pre niektorých používateľov môže byť tiež úplne neprístupný, pretože placeholder nie je široko podporovaný v rámci asistenčných technológií a nezobrazuje sa v starších webových prehliadačoch. Predvolená farba placeholdera je svetlošedá, čo znamená, že má nízky farebný kontrast oproti väčšine farieb pozadia.

Nápovedu môžeme cez atribút aria-describedby zviazať priamo s prvkom formulára, čím znovu pomôžeme nevidiacim používateľom vyhnúť sa chybám pri vypĺňaní formulára.

Príklad použitia aria-describedby

Používateľ čítača obrazovky v tomto príklade počuje nasledujúce informácie o inputoch:
Telefónne číslo editačné Použite medzinárodný tvar (+421xxxyyyzzz).
Email: editačné E-mail musí obsahovať zavináč.

V kóde to vyzerá nasledovne:


<form>
    <div>
     <label for="phone">Telefónne číslo</label>
     <input type="tel" id="phone" aria-describedby="phoneHint">
      <small id="phoneHint">Použite medzinárodný tvar (+421xxxyyyzzz)</small>
    </div>
    <div>
     <label for="email">E-mail</label>
    <input type="email" id="email" aria-describedby="emailHint">
     <small id="emailHint">E-mail musí obsahovať zavináč</small>
    </div>
</form>

Zvýraznenie vstupov pri fokusovaní, chyby vo formulári

Je potrebné zreteľne zvýrazniť prvky nielen formulára pri fokusovaní. Zabezpečíme, aby zvolená farba zvýraznenia fokusu bola dostatočne kontrastná oproti pozadiu inputu. Je to užitočné pre používateľov, ktorí používajú iba klávesnicu. (WCAG 2.4.7 Focus Visible – úroveň AA).

Všetci robíme chyby. Pri ich identifikácii vo formulároch sa nespoliehame iba na farbu, ale použijeme stručnú a jasnú textovú alternatívu na popis chyby.

Aby aj používatelia screen readerov zachytili, že v poli urobili chybu, využívame atribút aria-invalid=“true“. Ak chceme priradiť popis chyby k príslušným poliam formulára, použijeme zasa aria-describedby. (WCAG 3.3.1: Error identification – úroveň A, 3.3.3: Error Suggestion – úroveň AA, 1.4.1: Use of Color – level A).

Identifikácia povinných polí

Ak vyznačujeme vo formulári povinné polia, pre väčšinu používateľov je zrozumiteľný znak * vedľa popisku. Avšak stretli sme sa už aj s alternatívou, kedy hviezdička označovala nepovinné polia. Preto ak používame nejaký takýto identifikátor, je vhodné používateľom vysvetliť, čo ním budeme označovať.

Screen reader je schopný pri pohybe po formulárových prvkoch oznámiť svojmu používateľovi, či je pole povinné alebo nie. Je však k nemu potrebné priradiť atribút aria-required=“true“. (WCAG 1.3.1: Info and Relationships – level A, 3.3.2: Labels or Instructions – level A)

Príklad jednoduchého prístupného formulára

Samozrejme, je to len základný kód bez CSS a bez Jawascriptu. Prakticky je to len ukážka toho, ako by mal vyzerať formulár, ktorý bude pre používateľov screen readerov a klávesnice úplne prístupný.

Takto to vyzerá v kóde:


<form>
   <fieldset>
    <legend>Osobné údaje</legend>
    <div>
     <label for="fname">Meno:</label>
     <input type="text" id="fname" name="fname" aria-required="true">
    </div>
    <div>
     <label for="lname">Priezvisko:</label>
     <input type="text" id="lname" name="lname">
    </div>
    <div>
     <label for="tel">Telefónne číslo:</label>
     <input type="tel" id="tel" aria-describedby="phoneHint">
      <small id="phoneHint">Použite medzinárodný tvar (+421XXXYYYZZZ)</small>
    </div>
    <div>
     <label for="email">E-mail:</label>
     <input type="email" id="email" aria-required="true" aria-describedby="emailHint">
      <small id="emailHint">E-mail musí obsahovať zavináč (@)</small>
    </div>
   </fieldset>
   <button type="submit">Odoslať</button>
</form>

Záver

Prístupné formuláre nemusia byť žiadnym strašiakom. Stačí dodržať niekoľko jednoduchých krokov a budú pohodlne vyplniteľné pre všetkých zamestnancov, zákazníkov, klientov, pacientov, respondentov, voličov daňovníkov a tak ďalej.

To všetko totiž ľudia so znevýhodnením sú.

A keď prirátame všetkých ľudí so situačným znevýhodnením, je to len o dôvod viac, prečo sa prístupnosťou ako takou zaoberať.

Chcete sa o tejto téme dozvedieť viac? Prezrite si celú kategóriu Prístupnosť.

Alebo vás rada uvidím na školeniach: