Hogyan tedd weboldalad WCAG 2.2-kompatibilissé

Weboldalad WCAG 2.2-kompatibilissé tétele folyamat, nem egyszeri javítás. A megfelelőség egy ismételhető munkafolyamat eredménye: értsd meg a szabványt, mérd fel, hol állsz, javítsd a megfelelő dolgokat a megfelelő sorrendben, validáld valódi segítő technológiával és valódi felhasználókkal, dokumentáld az eredményt, és akadályozd meg a visszaesését. Ez az útmutató ezt a munkafolyamatot konkrét, lépésről lépésre haladó útitervvé alakítja, amelyet a csapatod már ma elkezdhet használni — anélkül, hogy akadálymentesítési „overlay” megoldásokhoz folyamodna, amelyek elfedik a problémákat a DOM-ban, ahelyett, hogy megoldanák azokat, és amelyeket ismételten említettek perekben.

1. lépés: Értsd meg, mit követel valójában a WCAG 2.2

Mielőtt bármit auditálnál, tisztázd a célt. A Web Content Accessibility Guidelines négy alapelv köré szerveződik, amelyeket a POUR mozaikszó foglal össze:

• Érzékelhető (Perceivable) — a felhasználóknak képesnek kell lenniük a tartalom érzékelésére. Ide tartoznak a képek szöveges alternatívái, a média feliratai és átiratai, valamint a megfelelő színkontraszt.
• Működtethető (Operable) — minden funkciónak működnie kell egér nélkül. A teljes billentyűzetes működtethetőség, a látható fókuszjelzők és a billentyűzetcsapdák hiánya alapvető követelmények.
• Érthető (Understandable) — a tartalomnak és a viselkedésnek kiszámíthatónak kell lennie. Ide tartoznak a világos címkék, a következetes navigáció, a hasznos hibaüzenetek és az olvasható nyelv.
• Robusztus (Robust) — a jelölésnek a jelenlegi és jövőbeli segítő technológia által értelmezhetőnek kell lennie, ami a gyakorlatban érvényes HTML-t, valamint az ARIA-nevek, -szerepek és -értékek helyes használatát jelenti.

Minden alapelv tesztelhető sikerkritériumokra bomlik, és minden kritériumhoz egy megfelelőségi szint van rendelve: A (alapvető), AA (a legtöbb szervezet által megcélzott jogi és gyakorlati alapszint) és AAA (kiterjesztett). Amikor az emberek „WCAG 2.2 AA”-ról beszélnek, akkor minden A és AA szintű sikerkritérium teljesítésére gondolnak. A WCAG 2.2 kilenc új kritériumot ad a 2.1-hez képest — köztük a Focus Not Obscured, Dragging Movements, Target Size (Minimum) és Accessible Authentication kritériumokat —, amelyek többsége javítja a billentyűzetet használó, gyengénlátó és mozgáskorlátozott felhasználók élményét.

Segít tudni, miért ez a cél. Az AA-megfelelőségre hivatkoznak azok a törvények és előírások, amelyek a legvalószínűbben vonatkoznak rád: olvass utána a WCAG-megfelelőségnek mint műszaki szabványnak, majd nézd meg, hogyan kapcsolódik az Európai Akadálymentesítési Irányelvhez, az ADA törvényhez a magán- és állami amerikai szervezetek esetében, valamint a Section 508 előíráshoz az amerikai szövetségi ügynökségek és beszállítóik esetében. Ha útközben megakaszt a terminológia, tartsd nyitva az akadálymentességi szószedetet egy lapon.

Két további fogalom alakít minden őszinte megfelelőségi állítást. Az első a megfelelőség hatóköre: a WCAG-megfelelőség teljes oldalakra vonatkozik, nem elszigetelt komponensekre, és teljes folyamatokra (pl. egy teljes fizetési folyamatra) — nem állíthatod, hogy egy oldal megfelelő, ha egy lépés egy többlépéses feladatban kudarcot vall. A második az akadálymentesítést támogató technológia: csak olyan funkcióhasználati módokra támaszkodhatsz, amelyeket a felhasználóid segítő technológiája ténylegesen támogat. A gyakorlatban ez azt jelenti, hogy aktuális képernyőolvasókkal és böngészőkkel kell tesztelni, ahelyett, hogy feltételeznénk, hogy az érvényes jelölés önmagában garantálja a használható eredményt. Tartsd mindkettőt szem előtt, amikor az alábbi lépésekben kijelölöd a munkád hatókörét; ezek határozzák meg, mit jelenthetsz ki védhetően elértnek.

2. lépés: Futtass automatikus alapszkennelést

Nem javíthatod azt, amit nem tudsz megmérni, ezért állíts fel egy kiindulási alapot. Az automatikus tesztelés gyors, ismételhető, és kiváló a legtöbb oldalt sújtó nagy mennyiségű, mechanikus hibák elkapásában: hiányzó alternatív szöveg, alacsony színkontraszt, üres linkek és gombok, címkézetlen űrlapmezők, hiányzó dokumentumnyelv és duplikált azonosítók.

A nyílt forráskódú axe-core motorra épülő eszközök — köztük a QualiBooth akadálymentesség-szkennelő szoftvere — percek alatt prioritizált problémalistát készítenek. Ha csak egy gyors képet szeretnél arról, hol állsz, kezdd néhány kulcsfontosságú oldal ingyenes akadálymentességi szkennelésével.

Néhány szabály, hogy az alapfelmérésed őszinte maradjon:

1. Reprezentatív sablonokat szkennelj, ne a teljes oldaladat. Teszteld a kezdőlapot, egy tartalom-/cikksablont, egy termék- vagy kategóriaoldalt, egy űrlapot (regisztráció, fizetés, kapcsolat) és bármilyen bejelentkezést igénylő irányítópultot. Egy sablon javítása általában több száz oldalt javít.
2. Valódi állapotokat tesztelj, ne csak a kezdeti betöltést. Nyiss meg menüket, bonts ki harmonikákat, indíts el modálisokat, és küldj be űrlapokat hibákkal. Sok jogsértés csak interaktív állapotokban jelenik meg.
3. Rögzítsd a számokat. Rögzítsd a problémák számát súlyosság és sikerkritérium szerint. Ez az előtte/utána viszonyítási alapod és a javítási teendőlistád alapja.

Légy őszinte a korlátokkal kapcsolatban: az automatikus eszközök megbízhatóan csak a WCAG-problémák 30–40 %-át észlelik. A tiszta automatikus szkennelés szükséges, de soha nem elegendő egy valódi megfelelőségi állításhoz.

3. lépés: Egészítsd ki az automatizálást kézi audittal

A fennmaradó 60–70 % WCAG-kritérium emberi ítélőképességet igényel. Vajon ez az alternatív szöveg valóban közvetíti a kép jelentését, vagy csak pixeleket ír le? Logikus-e az olvasási és fókuszsorrend? Megmondják-e a hibaüzenetek a felhasználónak, hogyan álljon helyre? Helyesen jelentik-e be az egyedi legördülő menüt, és el tudod-e érni és működtetni csak billentyűzettel? Egyetlen motor sem tud ezekre megbízhatóan válaszolni.

Egy strukturált kézi audit jellemzően lefedi:

• Csak billentyűzetes működtetés — tabulátorral járd be minden interaktív elemet; igazold a látható fókuszjelzőt, a logikus sorrendet, a csapdák hiányát, és azt, hogy mindent, amit egérrel megtehetsz, anélkül is megtehetsz.
• Szemantikai szerkezet — címsorok értelmes hierarchiában, tájékozódási pontok, listaként jelölt listák és megfelelő fejlécekkel ellátott táblázatok.
• Űrlapok — programozott címkék, csoportosított mezők, a kötelező mezők egyértelmű jelzése, és az általuk leírt beviteli mezőkhöz kötött hibaüzenetek.
• Dinamikus tartalom — modálisok, amelyek helyesen csapdázzák és állítják vissza a fókuszt, élő régiók, amelyek bejelentik a frissítéseket, és ARIA, amelyet csak ott használnak, ahol a natív HTML nem boldogul.
• Tartalomminőség — értelmes linkszöveg, megfelelő kontraszt valós kontextusban, és olyan tartalom, amely nem támaszkodik kizárólag színre vagy formára.

A kézi akadálymentességi auditok útmutatónk végigvezet a teljes módszertanon, a kerülendő gyakori akadálymentességi problémák pedig egy gyors ellenőrzőlista azokról a hibákról, amelyeket az auditorok a leggyakrabban találnak. Ha inkább elvégeztetnéd, a QualiBooth akadálymentességi tanácsadó csapata szakértői kézi auditokat végez a WCAG 2.2 AA kritériumai alapján.

4. lépés: Priorizálj és javíts

Egy hosszú jogsértéslista nyomasztó, amíg nem sorrendezed. Triázsolj a felhasználói hatás és a kiterjedés kombinálásával:

1. Először a blokkolók. Bármi, ami lehetetlenné tesz egy feladatot egy felhasználói csoport számára — billentyűzetcsapdák, hozzáférhetetlen fizetés, címkézetlen bejelentkezési űrlap — a lista tetejére kerül, függetlenül attól, hány előfordulás létezik.
2. Aztán a gyakori, oldalszintű problémák. Egy kontraszt- vagy fókuszprobléma a fejlécedben, láblécedben vagy designrendszer-komponensedben minden oldalon megsokszorozódik. Egyszeri javítása hozza a legnagyobb megtérülést.
3. Aztán az oldalspecifikus és tartalmi problémák. Egy-egy hiányzó alternatív szöveg, egy rosszul címkézett vezérlőelem vagy egy egyszeri címsorhézag.

Amikor javítasz, a forrást javítsd, ne a tünetet. Részesítsd előnyben a natív HTML-elemeket az ARIA-val foltozott <div>-ekkel szemben; javítsd a designrendszer-komponenst ahelyett, hogy minden oldalt javítanál, amely használja; és a sablonokban és megosztott komponensekben kezeld a gyökérokokat, hogy a javítás skálázódjon. Minden köteg után szkennelj újra, hogy lásd a számok csökkenését, és elkerüld a regressziók bevezetését. Ez egyben a megfelelő pillanat arra is, hogy az akadálymentességet beépítsd a designtokenjeidbe — állíts be alapértelmezésként kontrasztbiztos színeket, minimum 24×24 px célméretet és látható fókuszstílusokat, hogy az új munka megfelelően induljon.

Néhány javítási minta elég gyakran ismétlődik ahhoz, hogy kifejezetten kiemeljük:

• Használd a platformot. A natív <button>, <a href>, <input>, <select> és <dialog> ingyen érkezik billentyűzetviselkedéssel, fókuszkezeléssel és helyes akadálymentes névvel. Az ARIA-hoz csak valós hézagok kitöltéséhez nyúlj — és ne feledd az ARIA első szabályát: ne használj ARIA-t, ha egy natív elem megteszi.
• Nevezd el a dolgokat programozottan. Minden vezérlőelemnek akadálymentes névre van szüksége egy <label>-ből, aria-label-ből vagy aria-labelledby-ból — nem csak a közeli vizuális szövegből. A csak ikonos gombok a leggyakoribb vétkesek.
• Kezeld a fókuszt szándékosan. Amikor egy modális megnyílik, mozgasd bele a fókuszt, csapdázd, amíg nyitva van, és bezáráskor add vissza az indítóelemnek. Amikor a tartalom navigáció nélkül frissül, használj élő régiót, hogy a képernyőolvasó-felhasználók hallják, mi változott.
• Ne kódolj jelentést kizárólag színbe vagy formába. Párosítsd a színt szöveggel, ikonokkal vagy mintázatokkal, hogy az információ megmaradjon a színvak és gyengénlátó felhasználók számára.

Kövesd nyomon a javítást a megszokott feladatkövető rendszeredben, sikerkritérium szerint címkézve, hogy az akadálymentességi munka minden más mellett látható legyen, ahelyett, hogy egy különálló, elavuló táblázatban élne.

5. lépés: Tesztelj segítő technológiával és fogyatékossággal élő emberekkel

A megfelelőség végső soron arról szól, hogy valódi emberek tudják-e használni az oldaladat. Itt két validációs réteg számít, és ezek nem felcserélhetők.

Képernyőolvasós tesztelés. Ellenőrizd a javításaidat azzal a segítő technológiával szemben, amelyet az emberek valóban használnak: NVDA vagy JAWS Chrome/Firefox böngészővel Windowson, és VoiceOver Safarival macOS-en és iOS-en. Figyeld a pontos neveket, a helyes szerepeket, a bejelentett állapotváltozásokat és az értelmes olvasási sorrendet. A képernyőolvasós kiértékelés profi átvilágítást nyújt a főbb kombinációkon, ha a csapatodnak hiányzik a tapasztalata.

Használhatósági tesztelés fogyatékossággal élő felhasználókkal. Minden sikerkritérium teljesítése a padló, nem a plafon — egy oldal lehet műszakilag megfelelő, mégis frusztráló a használata. A legmegbízhatóbb jelzés a fogyatékossággal élő emberek által végzett auditokból származik, akik saját segítő technológiájukkal és szokásaikkal tesztelnek, és olyan akadályokat tárnak fel, amelyeket az ellenőrzőlisták nem vesznek észre. Ez a különbség a szabvány betűjének teljesítése és a valódi digitális akadálymentesség nyújtása között.

6. lépés: Dokumentáld a megfelelőséget (nyilatkozat és VPAT/ACR)

Miután elvégezted a javítást és a validálást, rögzítsd az eredményt. A dokumentáció az, ami a „megpróbáltuk”-ot védhető és kommunikálható állítássá alakítja.

• Akadálymentességi nyilatkozat. Egy nyilvános oldal, amely megadja a megfelelőségi célodat (pl. WCAG 2.2 AA), leírja, mit tettél, felsorol minden ismert korlátozást, és módot ad a felhasználóknak a problémák jelentésére. Sok előírás, köztük az EAA, elvár egyet.
• VPAT / Akadálymentességi Megfelelőségi Jelentés. A kitöltött Voluntary Product Accessibility Template ACR-ré válik — a standard dokumentummá, amelyet a beszerzési csapatok és a vállalati vásárlók bizonyítékként kérnek. A mi az a VPAT/ACR útmutatónk elmagyarázza a dokumentumot, a VPAT-jelentések szolgáltatás pedig pontos, audittal alátámasztott jelentést készít, amelyet átadhatsz az ügyfeleknek és a jogi csapatoknak.

Ezeket a valódi auditeredményeidből származó bizonyítékok alapján írd meg, ne vágyak alapján. Egy olyan VPAT, amely túlbecsüli a megfelelőséget, kötelezettség, nem eszköz.

7. lépés: Tartsd fenn a megfelelőséget az idő múlásával

Az akadálymentesség abban a pillanatban visszaesik, amint az oldal megváltozik — egy új komponens, egy újratervezett űrlap, egy harmadik féltől származó widget vagy egy tartalmi szerkesztés csendben újra bevezethet akadályokat. A megfelelőség egy állapot, amelyet fenntartasz, nem egy mérföldkő, amelyet egyszer teljesítesz.

Építsd be az akadálymentességet a szoftvered életciklusába:

1. Tolj balra. Adj hozzá automatikus ellenőrzéseket a pipeline-odhoz a CI/CD akadálymentességi integrációval, hogy a jogsértéseket a pull requestek során elkapd, mielőtt élesednének — a lehető legolcsóbb helyen a javításukhoz.
2. Monitorozd a produkciót. Ütemezz ismétlődő akadálymentességi auditokat, hogy elkapd a regressziókat és a tartalmi sodródást, amelyeket a kiadás előtti ellenőrzések nem látnak.
3. Erősítsd meg a csapatodat. Lásd el a designereket, fejlesztőket és tartalomszerzőket egy akadálymentességi eszköztárral és közös szabványokkal, hogy az akadálymentesség mindenki alapértelmezett beállítása legyen, ne egy szakember utólagos gondolata.
4. Irányíts nagy léptékben. Nagy vagy többoldalas szervezetek számára egy olyan platform, mint az Agora, központosítja a nyomon követést, a jelentéskészítést és a javítást a csapatok között.

Hibák, amelyek kisiklatják a megfelelőségi erőfeszítéseket

Az elakadó csapatok ezt általában kiszámítható okokból teszik. Figyelj ezekre:

• Kizárólag az automatizálásban bízni. Egy zöld automatikus jelentés a kritériumoknak csak harmadát fedi le. Megfelelőség bizonyítékaként kezelni a leggyakoribb — és jogilag a legkockázatosabb — hiba.
• Overlay vásárlása. Az overlay-ek és „akadálymentességi widgetek” azonnali megfelelőséget ígérnek olyan JavaScript befecskendezésével, amely felülírja az oldalt. Nem javítják a mögöttes kódot, gyakran zavarják a felhasználók saját segítő technológiáját, és egyre több panaszban említik őket. Ezek a kockázathoz, nem a megfelelőséghez vezető rövidítések.
• Oldalak javítása rendszerek helyett. Egyedi oldalak javítása a designrendszer törött állapotában hagyása mellett azt jelenti, hogy minden új oldal újra bevezeti ugyanazokat a hibákat. Először a megosztott komponenseket és sablonokat javítsd.
• Egyszeri projektként kezelni. CI/CD-ellenőrzések és ismétlődő auditok nélkül egy megfelelő oldal néhány kiadási cikluson belül kisodródik a megfelelőségből.
• A valódi felhasználók kihagyása. A műszaki megfelelőség használhatósági tesztelés nélkül még mindig azt eredményezheti, hogy a fogyatékossággal élő felhasználók nem tudják elvégezni az alapvető feladatokat.

Ezek elkerülése megakadályozza, hogy a befektetésed elszivárogjon abban a pillanatban, amikor a projekt „élesedik”.

Mindezt összerakva

A WCAG 2.2 AA felé vezető reális út így néz ki: tanuld meg a POUR alapelveket és az AA célt, futtass egy automatikus alapszkennelést, egészítsd ki egy kézi audittal, javíts hatás és kiterjedés szerint, validálj képernyőolvasókkal és fogyatékossággal élő felhasználókkal, dokumentáld a megfelelőségedet egy nyilatkozatban és egy VPAT-ban, majd tartsd egészségesen CI/CD-ellenőrzésekkel és ismétlődő auditokkal. Minden lépés az előzőre épül — és semmi sem függ egy overlay-től, amely elfedi a valódi kódot.

Kezdd kicsiben, és építs lendületet: szkennelj néhány sablont ezen a héten, javítsd a designrendszered kontraszt- és fókuszstílusait, és tegyél egy automatikus ellenőrzést a pipeline-odba. Innen a fenti útiterv elvisz a hátralévő úton. Amikor készen állsz a gyorsításra, fedezd fel az árazásunkat, kérj egy demót, vagy beszélj egy szakértővel a stackedre szabott javítási tervről.