Přístupnost webů se mění. Šest nových pravidel WCAG 2.2 míří do evropské normy

Když mi zpráva o změnách okolo norem přístupnosti přistála v pravidelném přehledu novinek z webařiny, zbystřil jsem. Dokola opakuju, že tvorba webů už není ta bezstarostná zábava jako před lety. Weby musí splňovat množství legislativních požadavků a přístupnost do této množiny také spadá. Ale je to v tomto případě samozřejmě dobře, všcihni chceme, aby se weby dobře používaly.

WCAG 2.2 není úplná novinka. W3C jej vydalo už v říjnu 2023. Evropská legislativa a harmonizované normy se ale pohybují podstatně pomaleji. Teprve teď se tedy požadavky WCAG 2.2 dostávají přímo do evropské normy.

Image

Neznamená to ovšem, že od září musíme všechny weby okamžitě předělávat. Nová verze EN 301 549 k datu vydání tohoto článku není harmonizovanou normou citovanou v Úředním věstníku Evropské unie. Prokazování shody se směrnicí o přístupnosti webových stránek veřejného sektoru se tedy stále opírá o EN 301 549 v3.2.1 a WCAG 2.1.

Přesto je vhodné se s novou normou seznámit. Docela přesně ukazuje, co budeme u nových webů řešit čím dál častěji.

WCAG (Web Content Accessibility Guidelines) je soubor mezinárodních doporučení pro přístupnost webového obsahu, který vydává konsorcium W3C. Popisuje, jak vytvářet weby a aplikace tak, aby je mohli používat také lidé se zrakovým, sluchovým, pohybovým nebo kognitivním omezením. Pravidla jsou rozdělena do tří úrovní – A, AA a AAA. V praxi se nejčastěji setkáte s požadavkem na úroveň AA.

WCAG a EN 301 549 nejsou totéž

WCAG samo o sobě není evropský zákon, je to praktická sada pravidel, podle kterých lze kontrolovat web. Evropská norma EN 301 549 má ale podstatně širší záběr. Netýká se totiž pouze webových stránek. Řeší také software, mobilní aplikace, dokumenty, hardware nebo například komunikační služby. 

Část požadavků EN 301 549 proto ve WCAG vůbec nenajdeme. Už předchozí verze například obsahovala vlastní pravidla pro titulky, přepis audia, komunikaci v reálném čase nebo zachování informací o přístupnosti při převodu obsahu.

Pro běžnou práci na webu je ale vztah poměrně jednoduchý. Velká část webových požadavků EN 301 549 vychází právě z WCAG. Dosavadní harmonizovaná verze pracuje s WCAG 2.1, nová v4.1.1 přechází na WCAG 2.2.

Šest nových pravidel, která se týkají běžných webů

WCAG 2.2 přidává proti WCAG 2.1 celkem devět kritérií úspěšnosti. Tři z nich jsou ale na úrovni AAA. Pokud se bavíme o obvyklém cíli WCAG 2.2 AA, přibývá šest požadavků na úrovních A a AA.

Nejde přitom o nějaké exotické situace pro speciální weby. Na několik z nich lze narazit na prakticky každém e-shopu, klientské zóně nebo složitějším formuláři.

Focus nesmí zmizet pod sticky hlavičkou

Nové kritérium 2.4.11 Focus Not Obscured (Minimum) požaduje, aby prvek, který získá focus při ovládání klávesnicí, nebyl kompletně zakryt jiným obsahem vytvořeným webem.

Typický problém? Sticky hlavička nebo lišta přilepená ke spodnímu okraji obrazovky.

Představte si, že procházíte formulář pomocí klávesy Tab. Prohlížeč posune stránku na další políčko, jenže to skončí schované právě pod fixní hlavičkou. Technicky focus existuje, uživatel jej ale nevidí.

WCAG 2.1 vyžadovalo viditelný focus. WCAG 2.2 jde v tomto případě o krok dál a řeší také situaci, kdy je správně vytvořený focus překryt jiným prvkem stránky. Na úrovni AA stačí, aby nebyl zakryt celý. Přísnější požadavek na jeho úplnou viditelnost existuje až na úrovni AAA.

Tipuju, že toto bude problém na řadě webů. Stačí se podívat, jak dnes fungují všechny možné cookies lišty, marketingové popupy, výzvy k odběru newsletteru a podobně. Sám si nejsem jist, jestli toto mám na všech webech splněno beze zbytku.

Drag & drop nesmí být jediná možnost

Kritérium 2.5.7 Dragging Movements míří na ovládací prvky vyžadující tažení myší nebo prstem. 

Pokud například aplikace umožňuje přesouvat položky seznamu pouze pomocí drag & drop, musí nabídnout také způsob, jak stejné operace dosáhnout bez tažení. Mohou to být například tlačítka pro posun nahoru a dolů.

Důležitý detail je, že nestačí říct: „Ale klávesnicí to funguje.“ WCAG zde řeší samostatně možnost ovládání pomocí jednoduchého kliknutí nebo ťapnutí. Rozhraní tedy může být přístupné z klávesnice a přesto toto kritérium nesplnit.

Tohle mi přijde zajímavé hlavně u různých administračních rozhraní, konfigurátorů nebo aplikací, kde se drag & drop používá docela přirozeně.

Příklad: pokud znáte Drupal, u všech drag’n’drop položek v adminu je možnost přepnout místo přetahování myší na nastavení vah jednotlivých řádků pomocí číselného údaje.

Malé ikonky začínají být větší problém

Další praktickou změnou je 2.5.8 Target Size (Minimum). Aktivní plocha ovládacího prvku by měla mít alespoň 24 × 24 CSS pixelů.

Není to ale absolutní pravidlo. WCAG obsahuje několik výjimek. Menší prvek může vyhovět například tehdy, pokud má kolem sebe dostatek prostoru, aby nehrozilo nechtěné kliknutí na sousední ovládací prvek. Výjimku mají také odkazy přímo uvnitř běžného textu.

Prakticky bych se tedy podíval například na:

• malé ikonky pro zavření dialogu,
• ovládání carouselů,
• ikonky editace a mazání položek těsně vedle sebe,
• malé checkboxy bez dostatečně velké klikací plochy,
• drobné ovládací prvky v tabulkách.

Nejde jen o uživatele s motorickým omezením. Kdo někdy zkoušel na telefonu trefit malý křížek nebo tři tečky vedle jiného tlačítka, asi chápe smysl tohoto pravidla i bez znalosti WCAG.

Nápověda by neměla cestovat po webu

Kritérium 3.2.6 Consistent Help požaduje konzistentní umístění mechanismů pomoci, pokud se objevují na více stránkách webu.

Může jít například o telefonní číslo, kontakt, odkaz na nápovědu nebo chatbot. Jestliže se podobný prvek opakuje napříč webem, neměl by být na jedné stránce v hlavičce, na druhé někde uprostřed a na třetí na konci patičky.

Neznamená to, že každý web musí mít chatbot nebo nápovědu. Kritérium řeší konzistenci v případě, že podobnou pomoc už nabízíte.

Praxe? Napadá mě hned několik designů z posledního roku, kdy jsem něco podobného jejich autorům připomínkoval.

Jednou zadané údaje po uživateli znovu nechtějte

3.3.7 Redundant Entry se týká vícekrokových procesů.

Pokud už uživatel během jednoho procesu nějakou informaci zadal a web ji potřebuje znovu, neměl by ji muset znovu opisovat. Web ji má předvyplnit nebo nabídnout možnost ji vybrat.

Typický příklad vidím v objednávkovém procesu. Pokud už zákazník vyplnil své jméno a adresu, nemá příliš smysl nutit jej o dva kroky později zadávat stejné údaje znovu.

Existují samozřejmě výjimky. Opětovné zadání může být nutné z bezpečnostních důvodů, informace už nemusí být platná nebo její nové zadání může být podstatou daného kroku.

Přístupnost prostě není jen správný aria-label a dostatečný kontrast. Část problémů vzniká už při návrhu samotného procesu.

Přihlašování nesmí být test paměti

Hodně zajímavé je také 3.3.8 Accessible Authentication (Minimum).

WCAG 2.2 nechce, aby přihlášení vyžadovalo řešení úkolu založeného na kognitivních schopnostech bez dostupné pomoci nebo alternativy. Jako příklad W3C uvádí nutnost zapamatovat si heslo nebo přepisovat jednorázový kód.

To neznamená konec hesel. Pokud formulář umožňuje použití správce hesel, požadavek lze splnit právě tímto mechanismem. Podobně by web neměl svévolně zakazovat vložení obsahu ze schránky, protože možnost copy & paste může uživateli pomoci například při práci s jednorázovým kódem.

Tohle pravidlo bych měl na paměti u různých rádoby bezpečnostních vylepšení, která komplikují práci správcům hesel nebo blokují vložení hesla či ověřovacího kódu. Z pohledu autora aplikace mohou působit bezpečněji, z pohledu přístupnosti mohou vytvořit úplně nový problém.

Osobně vždy teču z nejrůznějších přihlašovacích formulářů, u kterých jejich autoři vymysleli „unikátní“ bezpečnostní mechanismus…

Jedno staré pravidlo naopak zmizelo

WCAG 2.2 přidává nová pravidla, ale něco také ubírá. Kritérium 4.1.1 Parsing, které známe z WCAG 2.0 a 2.1, bylo označeno za zastaralé a odstraněno.

Původně řešilo například správné párování HTML značek, unikátní ID nebo další syntaktické problémy, které mohly komplikovat práci asistivním technologiím.

Vývoj webových technologií ale tento požadavek postupně překonal. Moderní prohlížeče a asistivní technologie pracují s chybami HTML podstatně předvídatelněji a problémy, které mají skutečný dopad na přístupnost komponent, pokrývají jiná kritéria, zejména 4.1.2 Name, Role, Value.

WCAG 2.2 proto 4.1.1 považuje za zastaralé.

WCAG 2.2 ano, ale právně ještě chvíli WCAG 2.1

Vydání EN 301 549 v4.1.1 samo o sobě nemění zákonné povinnosti. Aby nová norma získala význam harmonizované normy, musí být její reference zveřejněna v Úředním věstníku Evropské unie. Evropská komise výslovně upozorňuje, že nová verze WCAG nebo EN 301 549 automaticky nemění povinnosti vyplývající ze směrnice WAD.

V září 2026 tedy máme trochu zvláštní mezistav:

nová evropská norma už počítá s WCAG 2.2, ale právním referenčním bodem je zatím stále předchozí harmonizovaná EN 301 549 v3.2.1 založená na WCAG 2.1.

U nového webu bych asi kontroloval rovnou WCAG 2.2 AA. Rozdíl není dramatický a šest nových požadavků jsou většinou věci, které mají praktický dopad na použitelnost webu bez ohledu na to, kdy se nová norma objeví v Úředním věstníku.

Postřeh z praxe: V reálu jsem zatím nepotkal klienta, který by toto řešil do detailu. Málokdo je edukovaný nad rámec toho, aby chtěl něco více, než vyžaduje jen nezbytný soulad s legislativou a tím, co je kontrolní orgán schopen identifikovat. Tzn. focusy, kontrasty barev, základní ovládání klávesnicí…

Přístupnost se posouvá od HTML k použitelnosti

Úpravy přístupnosti po auditech pro mě zatím většinou znamenaly doplnit příslušný aria atribut a upravit barvy. To se s WCAG 2.2 mění.

Viditelný focus pod sticky hlavičkou, velikost klikacích prvků, alternativa k drag & drop, opakované vyplňování údajů nebo použitelné přihlášení jsou spíš otázkou návrhu rozhraní a celého procesu. Vývojář je může opravit, ale ideální je myslet na ně dřív, než dostane hotový design.

Nová EN 301 549 zatím nepřináší okamžitou revoluci. Spíš potvrzuje směr, který WCAG ukazuje už několik let. Až se v4.1.1 stane harmonizovanou normou, nebude už WCAG 2.2 jen doporučením, na které je dobré se připravit.