Jak zajistit soulad webu s WCAG 2.2

Zajistit soulad vašeho webu s WCAG 2.2 je proces, nikoli jednorázová oprava. Soulad je výsledkem opakovatelného postupu: porozumějte standardu, změřte, kde se nacházíte, opravte správné věci ve správném pořadí, ověřte je se skutečnou asistivní technologií a skutečnými uživateli, zdokumentujte výsledek a zabraňte jeho regresi. Tento průvodce mění tento postup v konkrétní, krok za krokem popsanou cestovní mapu, kterou váš tým může začít používat ještě dnes — aniž byste se uchylovali k „overlay” řešením přístupnosti, která spíše maskují problémy v DOM, než aby je opravovala, a která byla opakovaně zmiňována v soudních sporech.

Krok 1: Pochopte, co WCAG 2.2 ve skutečnosti vyžaduje

Než cokoli auditujete, ujasněte si cíl. Web Content Accessibility Guidelines jsou uspořádány kolem čtyř principů, shrnutých akronymem POUR:

Vnímatelný (Perceivable) — uživatelé musí být schopni obsah vnímat. Sem patří textové alternativy k obrázkům, titulky a přepisy médií a dostatečný barevný kontrast.
Ovladatelný (Operable) — každá funkce musí fungovat bez myši. Plná ovladatelnost klávesnicí, viditelné indikátory zaměření a absence pastí klávesnice jsou základní požadavky.
Srozumitelný (Understandable) — obsah a chování musí být předvídatelné. Sem patří jasné popisky, konzistentní navigace, užitečné chybové zprávy a čitelný jazyk.
Robustní (Robust) — kód musí být analyzovatelný současnou i budoucí asistivní technologií, což v praxi znamená validní HTML a správné použití názvů, rolí a hodnot ARIA.

Každý princip se dělí na testovatelná kritéria úspěchu a každému kritériu je přiřazena úroveň shody: A (zásadní), AA (právní a praktická základní úroveň, na kterou cílí většina organizací) a AAA (rozšířená). Když lidé říkají „WCAG 2.2 AA”, myslí tím splnění každého kritéria úspěchu úrovně A a úrovně AA. WCAG 2.2 přidává oproti verzi 2.1 devět nových kritérií — včetně Focus Not Obscured, Dragging Movements, Target Size (Minimum) a Accessible Authentication — z nichž většina zlepšuje zážitek uživatelů využívajících klávesnici, se slabým zrakem a s motorickým postižením.

Pomáhá vědět, proč je toto cílem. Na shodu úrovně AA odkazují zákony a předpisy, které se vás nejpravděpodobněji týkají: přečtěte si o souladu s WCAG jako technickém standardu a poté se podívejte, jak se mapuje na Evropský akt o přístupnosti, ADA pro soukromé a veřejné subjekty v USA a Section 508 pro federální agentury USA a jejich dodavatele. Pokud vás cestou zaskočí terminologie, mějte otevřený náš slovník přístupnosti v záložce.

Každé poctivé tvrzení o shodě utvářejí ještě dva další koncepty. Prvním je rozsah shody: shoda s WCAG se vztahuje na celé stránky, nikoli na izolované komponenty, a na kompletní procesy (např. celý nákupní proces) — nemůžete tvrdit, že stránka je v souladu, pokud selže jeden krok ve vícekrokovém úkolu. Druhým je technologie podporující přístupnost: smíte se spoléhat pouze na takové způsoby použití funkce, které jsou skutečně podporovány asistivní technologií, kterou vaši uživatelé mají. V praxi to znamená testovat se současnými čtečkami obrazovky a prohlížeči, namísto předpokladu, že samotný validní kód zaručuje použitelný výsledek. Mějte oba na paměti při vymezování rozsahu práce v krocích níže; určují, co můžete obhajitelně prohlásit za dosažené.

Krok 2: Spusťte automatizovaný výchozí sken

Nemůžete opravit to, co nemůžete změřit, takže si stanovte výchozí úroveň. Automatizované testování je rychlé, opakovatelné a vynikající v zachycování objemných, mechanických chyb, které sužují většinu webů: chybějící alternativní text, nízký barevný kontrast, prázdné odkazy a tlačítka, neoznačená pole formulářů, chybějící jazyk dokumentu a duplicitní ID.

Nástroje postavené na open-source enginu axe-core — včetně softwaru pro skenování přístupnosti od QualiBooth — vytvoří během několika minut prioritizovaný seznam problémů. Pokud chcete jen rychlý přehled o tom, kde se nacházíte, začněte bezplatným skenem přístupnosti několika klíčových stránek.

Několik pravidel, aby vaše výchozí měření zůstalo poctivé:

Skenujte reprezentativní šablony, nikoli celý web. Otestujte domovskou stránku, šablonu obsahu/článku, stránku produktu nebo kategorie, formulář (registrace, pokladna, kontakt) a jakoukoli přihlašovanou nástěnku. Oprava jedné šablony obvykle opraví stovky stránek.
Testujte skutečné stavy, nejen prvotní načtení. Otevřete menu, rozbalte akordeony, spusťte modální okna a odešlete formuláře s chybami. Mnoho porušení se objeví pouze v interaktivních stavech.
Zaznamenejte čísla. Zachyťte počty problémů podle závažnosti a podle kritéria úspěchu. To je vaše srovnání před/po a základ vašeho seznamu nápravy.

Buďte upřímní ohledně limitů: automatizované nástroje spolehlivě detekují pouze 30–40 % problémů WCAG. Čistý automatizovaný sken je nezbytný, ale nikdy nestačí pro skutečné tvrzení o shodě.

Krok 3: Doplňte automatizaci manuálním auditem

Zbývajících 60–70 % kritérií WCAG vyžaduje lidský úsudek. Vyjadřuje tento alternativní text skutečně význam obrázku, nebo jen popisuje pixely? Je pořadí čtení a zaměření logické? Říkají chybové zprávy uživateli, jak se zotavit? Je vlastní rozbalovací nabídka oznámena správně a můžete ji dosáhnout a ovládat pouze klávesnicí? Žádný engine na tyto otázky nemůže spolehlivě odpovědět.

Strukturovaný manuální audit obvykle pokrývá:

Ovládání pouze klávesnicí — projděte tabulátorem každý interaktivní prvek; potvrďte viditelný indikátor zaměření, logické pořadí, absenci pastí a to, že vše, co lze udělat myší, lze udělat i bez ní.
Sémantická struktura — nadpisy ve smysluplné hierarchii, orientační body, seznamy označené jako seznamy a tabulky se správnými záhlavími.
Formuláře — programové popisky, seskupená pole, jasné označení povinných polí a chybové zprávy svázané se vstupy, které popisují.
Dynamický obsah — modální okna, která správně zachytávají a obnovují zaměření, živé oblasti, které oznamují aktualizace, a ARIA použité pouze tam, kde nativní HTML nestačí.
Kvalita obsahu — smysluplný text odkazů, dostatečný kontrast ve skutečných kontextech a obsah, který se nespoléhá pouze na barvu nebo tvar.

Náš průvodce manuálními audity přístupnosti provádí celou metodikou a běžné problémy přístupnosti, kterým se vyhnout je rychlý kontrolní seznam chyb, které auditoři nacházejí nejčastěji. Pokud byste to raději nechali udělat za sebe, tým konzultací v oblasti přístupnosti od QualiBooth provádí odborné manuální audity proti kritériím WCAG 2.2 AA.

Krok 4: Stanovte priority a proveďte nápravu

Dlouhý seznam porušení je zahlcující, dokud jej neseřadíte. Třiďte kombinací dopadu na uživatele a dosahu:

Nejprve blokátory. Cokoli, co znemožňuje úkol pro skupinu uživatelů — pasti klávesnice, nepřístupná pokladna, neoznačený přihlašovací formulář — jde na vrchol bez ohledu na to, kolik výskytů existuje.
Poté časté, celosíťové problémy. Problém s kontrastem nebo zaměřením ve vaší hlavičce, patičce nebo komponentě návrhového systému se násobí na každé stránce. Jeho jednorázová oprava přináší největší návratnost.
Poté problémy specifické pro stránku a obsah. Jednotlivý chybějící alternativní text, jeden špatně označený ovládací prvek nebo ojedinělá mezera v nadpisech.

Při nápravě opravujte zdroj, nikoli příznak. Upřednostňujte nativní HTML prvky před <div> prvky záplatovanými pomocí ARIA; opravte komponentu návrhového systému namísto každé stránky, která ji používá; a řešte hlavní příčiny v šablonách a sdílených komponentech, aby se oprava škálovala. Po každé dávce znovu skenujte, abyste viděli pokles počtů a vyhnuli se zavádění regresí. Toto je také správná chvíle zabudovat přístupnost do vašich návrhových tokenů — nastavte jako výchozí kontrastně bezpečné barvy, minimální velikost cíle 24×24 px a viditelné styly zaměření, aby nová práce začínala v souladu.

Několik vzorů nápravy se opakuje dostatečně často, aby si zasloužily výslovnou zmínku:

Využijte platformu. Nativní <button>, <a href>, <input>, <select> a <dialog> přicházejí s chováním klávesnice, správou zaměření a správným přístupným názvem zdarma. Po ARIA sáhněte jen k zaplnění skutečných mezer — a pamatujte na první pravidlo ARIA: nepoužívejte ARIA, pokud postačí nativní prvek.
Pojmenovávejte věci programově. Každý ovládací prvek potřebuje přístupný název z <label>, aria-label nebo aria-labelledby — nikoli pouze blízký vizuální text. Tlačítka pouze s ikonou jsou nejčastějším provinilcem.
Spravujte zaměření záměrně. Když se otevře modální okno, přesuňte do něj zaměření, podržte jej, dokud je otevřené, a po zavření jej vraťte na spouštěč. Když se obsah aktualizuje bez navigace, použijte živou oblast, aby uživatelé čteček obrazovky slyšeli, co se změnilo.
Nekódujte význam pouze barvou nebo tvarem. Spárujte barvu s textem, ikonami nebo vzory, aby informace přežila pro barvoslepé a slabozraké uživatele.

Sledujte nápravu ve svém běžném nástroji pro sledování úkolů, označenou podle kritéria úspěchu, aby práce na přístupnosti byla viditelná vedle všeho ostatního, místo aby žila v oddělené tabulce, která zastarává.

Krok 5: Testujte s asistivní technologií a lidmi s postižením

Shoda je v konečném důsledku o tom, zda skuteční lidé mohou váš web používat. Zde záleží na dvou vrstvách ověření a ty nejsou vzájemně zaměnitelné.

Testování se čtečkou obrazovky. Ověřte své opravy proti asistivní technologii, kterou lidé skutečně používají: NVDA nebo JAWS s Chrome/Firefox na Windows a VoiceOver se Safari na macOS a iOS. Naslouchejte přesným názvům, správným rolím, oznámeným změnám stavu a rozumnému pořadí čtení. Vyhodnocení se čtečkou obrazovky vám poskytne profesionální průchod napříč hlavními kombinacemi, pokud vašemu týmu chybí zkušenosti.

Testování použitelnosti s uživateli s postižením. Splnění každého kritéria úspěchu je podlaha, nikoli strop — web může být technicky v souladu a přesto frustrující k používání. Nejspolehlivější signál pochází z auditů provedených lidmi s postižením, kteří testují s vlastní asistivní technologií a zvyklostmi a odhalují bariéry, které kontrolní seznamy přehlédnou. To je rozdíl mezi splněním litery standardu a poskytnutím skutečné digitální přístupnosti.

Krok 6: Zdokumentujte shodu (prohlášení a VPAT/ACR)

Jakmile provedete nápravu a ověření, zachyťte výsledek. Dokumentace je to, co mění „pokusili jsme se” v obhajitelné a sdělitelné tvrzení.

Prohlášení o přístupnosti. Veřejná stránka, která uvádí váš cíl shody (např. WCAG 2.2 AA), popisuje, co jste udělali, vypisuje veškerá známá omezení a dává uživatelům způsob, jak nahlásit problémy. Mnoho předpisů, včetně EAA, jej očekává.
VPAT / Zpráva o shodě přístupnosti. Vyplněná Voluntary Product Accessibility Template se stává ACR — standardním dokumentem, který nákupní týmy a firemní kupující požadují jako důkaz. Náš průvodce co je VPAT/ACR vysvětluje tento dokument a služba VPAT zprávy vytvoří přesnou, auditem podloženou zprávu, kterou můžete předat zákazníkům a právním týmům.

Pište je proti důkazům ze svých skutečných výsledků auditu, nikoli z přání. VPAT, který přeceňuje shodu, je závazkem, nikoli aktivem.

Krok 7: Udržujte soulad v čase

Přístupnost regreduje ve chvíli, kdy se web změní — nová komponenta, přepracovaný formulář, widget třetí strany nebo úprava obsahu mohou tiše znovu zavést bariéry. Shoda je stav, který udržujete, nikoli milník, který jednou projdete.

Zabudujte přístupnost do životního cyklu vašeho softwaru:

Posuňte se doleva. Přidejte automatizované kontroly do své pipeline pomocí integrace přístupnosti CI/CD, aby byla porušení zachycena u pull requestů, než se dostanou do produkce — na nejlevnějším možném místě k jejich opravě.
Monitorujte produkci. Naplánujte opakované audity přístupnosti, abyste zachytili regrese a posun obsahu, které předvydáním provedené kontroly neuvidí.
Posilte svůj tým. Vybavte designéry, vývojáře a autory obsahu sadou nástrojů pro přístupnost a sdílenými standardy, aby přístupnost byla výchozím nastavením pro každého, nikoli dodatečnou myšlenkou specialisty.
Řiďte ve velkém měřítku. Pro velké nebo vícewebové organizace platforma jako Agora centralizuje sledování, reportování a nápravu napříč týmy.

Chyby, které maří úsilí o soulad

Týmy, které uváznou, tak obvykle činí z předvídatelných důvodů. Dávejte pozor na tyto:

Spoléhání pouze na automatizaci. Zelená automatizovaná zpráva pokrývá pouze třetinu kritérií. Považovat ji za důkaz shody je jediná nejčastější — a právně nejrizikovější — chyba.
Nákup overlay. Overlaye a „widgety přístupnosti” slibují okamžitý soulad vstříknutím JavaScriptu, který přepíše stránku. Neopravují podkladový kód, často zasahují do vlastní asistivní technologie uživatelů a byly zmíněny v rostoucím počtu stížností. Jsou zkratkou k riziku, nikoli ke shodě.
Oprava stránek namísto systémů. Náprava jednotlivých stránek při ponechání rozbitého návrhového systému znamená, že každá nová stránka znovu zavádí stejné vady. Opravte nejprve sdílené komponenty a šablony.
Považovat to za jednorázový projekt. Bez CI/CD kontrol a opakovaných auditů se web v souladu během několika vydávacích cyklů ze shody vychýlí.
Vynechání skutečných uživatelů. Technická shoda bez testování použitelnosti může i tak ponechat uživatele s postižením neschopnými dokončit klíčové úkoly.

Vyhnutí se těmto chybám zabrání tomu, aby vaše investice unikla ve chvíli, kdy se projekt „vydá”.

Spojení všeho dohromady

Realistická cesta k WCAG 2.2 AA vypadá takto: naučte se principy POUR a cíl AA, spusťte automatizovaný výchozí sken, přidejte manuální audit, proveďte nápravu podle dopadu a dosahu, ověřte se čtečkami obrazovky a uživateli s postižením, zdokumentujte svou shodu v prohlášení a VPAT a poté ji udržujte zdravou pomocí CI/CD kontrol a opakovaných auditů. Každý krok navazuje na předchozí — a nic z toho nezávisí na overlay, který zakrývá skutečný kód.

Začněte v malém a budujte tempo: tento týden naskenujte hrstku šablon, opravte styly kontrastu a zaměření vašeho návrhového systému a vložte jednu automatizovanou kontrolu do své pipeline. Odtud vás výše uvedená cestovní mapa dovede po zbytek cesty. Až budete připraveni zrychlit, prozkoumejte naše ceny, vyžádejte si demo nebo si promluvte s odborníkem o nápravném plánu přizpůsobeném vašemu technologickému stacku.