Přejít k navigační liště

Zdroják » Webdesign » WCAG 2.0 – Srozumitelnost a pomoc při zadávání dat

WCAG 2.0 – Srozumitelnost a pomoc při zadávání dat

Články Webdesign

V dnešním dílu seriálu o WCAG 2.0 dokončíme povídání o třetím principu, který je zaměřen na srozumitelnost webové stránky. Podíváme se na třetí pravidlo tohoto principu, které se zabývá vším, co souvisí s pomocí uživatelům při zadávání dat.

Každý občas udělá chybu. Pro uživatele se zdravotním postižením může být bezchybné zadání údajů a vyplnění formuláře dokonce problematičtější než u běžných uživatelů. Důvodem může být například

  • nedostatek na straně asistivní technologie, kdy kvůli neporozumění syntetickému hlasu uživatel zadá špatný údaj,

  • špatně nebo nepřístupně vytvořený formulář, v němž nejsou vůbec či nedostatečně (například pouze barvou) vyznačeny povinné položky. 

Z těchto důvodů může pak být pro handicapované uživatele i obtížné zjistit, že udělali při zadávání dat chybu, kde se chyba nachází a jak ji opravit.

Cílem Pravidla 3.3 je proto minimalizovat počet vážných či nevratných chyb, zajistit, aby na všechny chyby byl uživatel upozorněn, a v neposlední řadě mu byla poskytnuta nápověda, aby věděl, jak chyby, které udělal, může opravit.

Pravidlo 3.3 Pomoc při zadávání: Pomozte uživatelům vyvarovat se chyb nebo chyby opravit.

Pravidlo 3.3 obsahuje šest kritérií úspěšnosti, my se opět budeme zabývat pouze těmi s nejvyšší a střední prioritou.

3.3.1 Identifikace chyby (Úroveň A)

Jestliže je při zadávání automaticky zjištěna chyba, je chybná položka označena a chyba je uživateli popsána ve formě textu.

Smyslem tohoto kritéria úspěšnosti je zajistit, aby uživatel v případě, kdy je zjištěna chyba při zadávání, byl na tuto chybu upozorněn. Chybová hláška by měla být co možná nejvíce popisná a výstižná. Například opětovné zobrazení formuláře po jeho neúspěšném odeslání a pouhé zvýraznění chybně vyplněných polí nemusí být pro některé uživatele dostatečné a nezjistí z něj, že formulář nebyl správně vyplněn. Tento způsob upozornění je nevhodný například pro uživatele screenreaderů, kteří se o chybě dozví teprve, když při opětovném procházení formuláře narazí na první upozornění na chybu. Navíc mohou formulář považovat za nefunkční a znovu jej nevyplňovat, protože může nastat situace, kdy na upozornění na chybu vůbec nenarazí – obzvlášť, pokud se chyba vyskytuje v některém z posledních formulářových prvků.

Ideálním řešením je proto na chybu či chyby při zadávání dat upozornit nejen u jednotlivých formulářových prvků, ale i co nejblíže začátku opětovně zobrazeného formuláře, aby uživatel věděl, proč se mu formulář zobrazil znovu. Pokud je tato informace promítnuta i do titulku stránky či nadpisu formuláře, je to ještě lepší, protože se tuto informaci dozví, aniž by musel procházet obsah stránky. Kromě textového popisu chyby je samozřejmě možné (a v mnoha případech i žádoucí) upozornit na chybu i barevným odlišením, vhodným obrázkem, atp.

3.3.2 Popisky nebo pokyny (Úroveň A)

Je-li vyžadován vstup uživatele, má uživatel k dispozici popisky nebo pokyny.

Aby uživatel měl zadávání dat co nejvíce usnadněno, je vhodné mu poskytnout jednoduché instrukce a nápovědu, jakým způsobem má data zadávat. Nevidomí uživatelé potřebují bezpečně vědět, jaké informace mají do jednotlivých polí zadávat, jednoduché informace vizuálně spojené s formulářovými prvky pak mohou pomoci těm, kteří mají poruchy učení a soustředění či těm, kteří používají softwarovou lupu.

Smyslem tohoto kritéria úspěšnosti není uživatele zahltit spoustou neužitečných informací, ale poskytnout mu jich tak akorát. Příliš mnoho informací může být pro uživatele stejná  překážka, jako když zcela chybí či jejich příliš málo.

Co tedy můžeme pro uživatele v tomto ohledu udělat?

  • Popisky formulářových prvků korektně přiřadit pomocí značky label a vazebních atributů for a id odpovídajícím formulářovým prvkům tak, aby byly přečteny screenreadery vždy, když formulářový prvek získá focus.
  • Popisky formulářových prvků umístit dostatečně blízko odpovídajícím formulářovým prvkům tak, aby uživatelé softwarových lup mohli snadno poznat, který popisek patří ke konkrétnímu prvku.
  • K jednotlivým editačním polím doplnit nápovědné texty s příklady dat, které má uživatel zadat.
  • Jednoznačně identifikovat povinné položky tak, aby uživatel, který ovládá web pouze z klávesnice, nemusel formulář po jeho odeslání a zobrazení nekompletně vyplněného formuláře znovu procházet a doplňovat chybějící informace.

Pěkně zpracované nápovědné texty jsou například u registračního formuláře Založení nového uživatele Seznam účtu, Nápověda se zobrazí vždy až ve chvíli, kdy formulářový prvek získá focus, a je bez problémů čitelná i screenreadery při procházení formuláře kurzorovými šipkami. Pokud jej uživatel screenreaderu prochází tabulátorem, nápověda mu čtena není, což ale nemusí být na závadu. Protože pokud uživatel formulář vyplňuje poněkolikáté, neprochází jej již kurzorovými šipkami, ale tabulátorem, a v takovém případě by jej nápověda u každé položky spíše zdržovala, než mu pomáhala.

3.3.3 Návrhy pro opravení chyby (Úroveň AA)

Je-li při zadávání automaticky zjištěna chyba a jsou známy návrhy na její opravení, jsou návrhy prezentovány uživateli. Výjimku tvoří případ, kdy je takový postup v rozporu s bezpečností nebo účelem obsahu. 

Kritérium úspěšnosti 3.1.1 se zabývá upozorňováním na chyby – pokud už nastanou. Řada uživatelů ale může mít i v případě, kdy budou na chybu upozorněni, problém ji opravit, protože nebudou vědět jak.

Ukažme si několik příkladů, jak uživateli při opravování chyb pomoci.

  • Dodatečná nápověda pro opravu chyby. Na stránku s výsledky neúspěšně odeslaného formuláře doplníme kromě informace o chybě i příklad správného vyplnění editačního pole, které uživatel vyplnil chybně.

  • Výběr z  nabízených možností. Při chybném zadání údajů je vhodné – pokud to s charakter vstupních dat umožňuje – usnadnit uživateli opravu údajů výběrem z několika možností. Pokud totiž uživatel nevěděl napoprvé, v jaké podobě má informace zadat, je dost pravděpodobné, že by to nevěděl ani napodruhé. Výběr z několika možností mu zadání dat výrazně usnadní.

3.3.4 Předcházení chybám – právní, finanční, data (Úroveň AA)

Pro webové stránky, z nichž vyplývají právní důsledky, stránky, umožňující provádět finanční transakce, stránky umožňující modifikaci nebo mazání uživatelských dat uložených v systémech pro uchovávání dat nebo pro stránky, pomocí nichž se odesílají odpovědi na testové otázky, platí alespoň jeden z následujících bo­dů:

  • Zrušitelnost: Akce uživatele lze vrátit zpět.
  • Kontrola dat: Data zadaná uživatelem jsou zkontrolována na chyby a uživatel má možnost chyby opravit.
  • Potvrzení: Je dostupný mechanismus umožňující zkontrolování, potvrzení a opravení informací před dokončením zadávání.

Cílem tohoto kritéria úspěšnosti je pomoci uživatelům vyhnout se problémům, které vzniknou jako výsledek činností, jež nelze vrátit zpět. Příklady takových činností mohou být například koupě letenky, kterou již nelze vrátit, či nákup akcií na burze. Pokud uživatel udělá chybu v datu, na které si letenku koupí, nemůže už letenku vrátit a letenka je mu k ničemu. Stejně tak pokud udělá chybu v počtu akcií, nakoupí více či méně akcií, než chtěl. Oba tyto příklady ukazují typ transakcí, které musí proběhnout okamžitě, nelze je vrátit zpět a případné chyby se mohou uživateli pěkně prodražit. Stejně tak může být velký problém, pokud uživatel neúmyslně přepíše či smaže data v databázi, která budou později potřeba – například údaje v profilu na webu cestovní kanceláře, od níž si uživatel koupil zájezd a cestovní kancelář údaje z profilu používá pro další komunikaci s uživatelem.

Nabídnutí možnosti vrátit akci před odesláním zpět a opravit chybu dává uživateli možnost vyvarovat se těchto chyb.

Příkladem vhodného řešení může být například zobrazení stránky s daty s výzvou k jejich potvrzení a také možností zadané údaje opravit.

Jak je z výše uvedeného textu zřejmé, i toto pravidlo má přesah nad rámec požadavků na přístupnost webu pro uživatele s handicapem a formulář, vytvořený v souladu s požadavky tohoto pravidla, jistě ocení každý uživatel. A to je pro dnešek vše. Náš seriál o WCAG 2.0 se pomalu blíží do finále. Příště se podíváme na poslední princip a pravidlo této metodiky přístupnosti a tím náš seriál zakončíme.

Komentáře

Subscribe
Upozornit na
guest
0 Komentářů
Inline Feedbacks
View all comments

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.