WCAG és webes akadálymentesítés

WCAG és webes akadálymentesítés: mit jelent, kire vonatkozik, és hogyan teszteld a weboldalad?

A WCAG a webes akadálymentesség nemzetközileg használt műszaki szabványa. Abban segít, hogy egy weboldal tartalma és kezelőfelülete látási, hallási, mozgásszervi vagy kognitív akadályozottság mellett is használható legyen. A legtöbb szervezet számára az AA szint a reális cél, de egy automatikus teszt jó pontszáma önmagában még nem igazolja a megfelelést.

Valószínűleg kétféle helyzet egyikében találtál rá erre a témára. Vagy kaptál egy feladatot, hogy „a weboldalnak WCAG-kompatibilisnek kell lennie”, és most próbálod megfejteni, ez pontosan mit jelent. Vagy weboldalakat készítesz, és szeretnéd még az átadás előtt megtalálni azokat a hibákat, amelyek miatt az oldal egyes látogatóknak nehezen vagy egyáltalán nem használható.

A téma elsőre szabványok, betűszavak és sikerkritériumok sűrűjének tűnik. A gyakorlatban sokkal emberibb kérdésekről van szó. El tudja-e olvasni a képernyőolvasó a menüpontot? Végig lehet-e menni az űrlapon egér nélkül? Észrevehető-e, melyik elem van fókuszban? Megérthető-e a hibaüzenet akkor is, ha valaki nem érzékeli a piros színt?

Mit jelent a webes akadálymentesség?

A webes akadálymentesség azt jelenti, hogy a weboldalakat, webalkalmazásokat és digitális tartalmakat a lehető legtöbb ember képes érzékelni, megérteni és kezelni. Ide tartoznak a vak és gyengénlátó, a siket és nagyothalló, a mozgásszervi, beszéd-, kognitív vagy neurológiai fogyatékossággal élő felhasználók igényei is.

Az akadálymentes megoldások sokszor más helyzetekben is segítenek. A videó felirata jól jön zajos környezetben, az erős kontraszt napsütésben, a billentyűzetes kezelés pedig törött egér vagy ideiglenes kézsérülés esetén. Az idősebb látogatók csökkenő látása, kézügyessége vagy koncentrációja ugyancsak olyan igényeket hozhat elő, amelyekre egy átgondolt felület jobban reagál.

A cél egy közösen használható, befogadó weboldal. Egy külön „akadálymentes verzió” fenntartása könnyen oda vezet, hogy a két oldal tartalma és funkciói eltérnek, a másodlagos változat pedig lemarad a frissítésekben. A jó irány általában az, hogy maga az elsődleges weboldal legyen hozzáférhető.

Mi a WAI, a WCAG és a WAI-ARIA?

A hasonló rövidítések könnyen összemosódnak, pedig más szerepük van.

A WAI, vagyis Web Accessibility Initiative a World Wide Web Consortium, röviden W3C akadálymentességgel foglalkozó kezdeményezése. Szabványokat, oktatóanyagokat, értelmezési segédleteket és tesztelési módszereket készít a hozzáférhető webhez.

A WCAG a Web Content Accessibility Guidelines rövidítése. Ez a webes tartalmak akadálymentességi követelményeit rendezi egységes rendszerbe. A szabvány nem azt írja elő, hogy minden gomb kék legyen, vagy hogy egy konkrét keretrendszert használj. Ellenőrizhető sikerkritériumokat ad, amelyekhez többféle technikai megoldás vezethet.

A WAI-ARIA a dinamikus webes komponensek szerepét, állapotát és kapcsolatait segít átadni a kisegítő technológiáknak. Hasznos lehet például egy egyedi tabpanel, lenyíló menü vagy modális ablak esetén. Az ARIA viszont nem javít meg automatikusan egy rosszul felépített komponenst. Ha van megfelelő natív HTML-elem, rendszerint az a biztosabb kiindulópont.

A WCAG négy alapelve

A WCAG 2.2 összesen 13 irányelvet rendez négy alapelv alá. Az angol kezdőbetűkből a POUR mozaikszó áll össze: Perceivable, Operable, Understandable, Robust.

Alapelv	Mit jelent a gyakorlatban?	Tipikus példa
Észlelhető	Az információ többféle érzékelési mód mellett is hozzáférhető.	A tartalmi képnek értelmes szöveges alternatívája van, a videóhoz felirat tartozik.
Működtethető	A felület különböző beviteli módokkal is kezelhető.	A menü, az űrlap és a modális ablak billentyűzettel is használható.
Érthető	A tartalom és a működés kiszámítható, a hibák javíthatók.	Az űrlap egyértelműen megnevezi a hibás mezőt és a javítás módját.
Robusztus	A kódot a böngészők és a kisegítő technológiák megbízhatóan értelmezik.	A vezérlőknek helyes szemantikájuk, nevük, szerepük és állapotuk van.

Ez a felosztás segít abban, hogy ne szűkítsd le az akadálymentességet a színkontrasztra és az alt attribútumokra. Egy oldal lehet vizuálisan jól olvasható, miközben a billentyűzetes fókusz elakad egy felugró ablakban. Egy technikailag szabályos űrlap is nehezen használható, ha a hibaüzenetei értelmezhetetlenek.

Mit jelent az A, AA és AAA szint?

A WCAG három megfelelőségi szintet használ. Ezek egymásra épülnek: az AA szinthez az összes A és AA, az AAA szinthez pedig az összes A, AA és AAA sikerkritériumot teljesíteni kell.

Szint	Jelentése	Gyakorlati értelmezés
A	A legalacsonyabb megfelelőségi szint.	Alapvető akadályokat szüntet meg, de önmagában sok esetben kevés egy széles körben használható oldalhoz.
AA	Tartalmazza az A és az AA követelményeket.	Ez a leggyakoribb szervezeti cél, és számos szabályozási környezet is ehhez közeli követelményrendszert használ.
AAA	Tartalmazza mindhárom szint követelményeit.	Magasabb szintű elvárásokat ad, amelyek közül érdemes a relevánsakat akkor is alkalmazni, ha a teljes oldal nem céloz AAA megfelelést.

Az AAA szinttel kapcsolatban gyakori félreértés, hogy ezt a „látássérülteknek készített oldalak” számára találták ki. Az AAA nem egy felhasználói csoport külön szabványa. Többféle fogyatékossághoz kapcsolódó emelt követelményeket tartalmaz. Maga a WCAG sem ajánlja, hogy teljes webhelyekre általános szabályként kötelező legyen a teljes AAA megfelelés, mert bizonyos tartalmaknál minden AAA sikerkritérium teljesítése nem lehetséges.

Ettől még az AAA követelményeit érdemes átnézni. Egy egészségügyi, oktatási vagy kifejezetten sérülékeny felhasználókat kiszolgáló felületnél több magasabb szintű megoldás is indokolt lehet. A megfelelőségi cél és a valódi felhasználói igény két külön kérdés.

Melyik WCAG-verziót érdemes használni?

A W3C jelenlegi stabil ajánlása a WCAG 2.2, amelyet 2023 októberében tettek közzé W3C-ajánlásként. A 2.2 a korábbi 2.0 és 2.1 követelményeire épül, és kilenc új sikerkritériumot adott hozzá. Ezek többek között a látható és kitakarásmentes fókuszt, a húzó mozdulat alternatíváját, a célterületek minimális méretét, a következetes segítséget és a hozzáférhető hitelesítést érintik.

Új fejlesztésnél jó műszaki cél a WCAG 2.2 AA. A W3C is a legfrissebb verzió használatát ösztönzi, és a WCAG 2.2-t visszafelé kompatibilisnek tekinti a korábbi 2.x verziókkal. A 4.1.1 Parsing sikerkritérium a 2.2-ben elavulttá vált és kikerült a követelmények közül.

A jogi megfelelésnél ennél árnyaltabb a kép. Az Európai Unióban a közszférabeli szervezetek weboldalaira és mobilalkalmazásaira vonatkozó Web Accessibility Directive műszaki hátterét a harmonizált EN 301 549 v3.2.1 szabvány adja, amely erősen a WCAG 2.1-re támaszkodik, de azon kívüli követelményeket is tartalmaz. Az Európai Bizottság szabványosítási összefoglalója külön felhívja rá a figyelmet, hogy egy új WCAG-verzió nem válik automatikusan jogi követelménnyé.

A 2025. június 28-tól alkalmazandó European Accessibility Act bizonyos piaci termékeket és fogyasztói szolgáltatásokat is érint, például az e-kereskedelmet, a lakossági banki szolgáltatásokat, az e-könyveket, az elektronikus hírközlést és a személyszállítás egyes digitális elemeit. Ebből nem következik minden magánweboldal azonos kötelezettsége. A pontos hatály függhet a szolgáltatástól, a szervezet méretétől, a tartalomtól, a nemzeti átültetéstől és az esetleges kivételektől.

Ha a megfelelés jogi okból fontos, előbb tisztázd, melyik szabályozás vonatkozik rád. A WCAG 2.2 AA remek fejlesztési alap, a jogi megfelelőség igazolásához viszont az alkalmazandó jogszabályt, a harmonizált szabványt és a dokumentációs kötelezettségeket együtt kell nézni. Ez a cikk technikai tájékoztató, jogi véleményt nem helyettesít.

Milyen hibák tesznek nehezen használhatóvá egy weboldalt?

Az akadálymentességi hibák egy része apró kódhibának látszik, a felhasználó számára mégis teljes folyamatokat zárhat el.

Hiba	Mi történik miatta?	Kiknek okozhat különösen nagy akadályt?
Hiányzó vagy rossz képleírás	A képernyőolvasó nem tudja átadni a kép információját, vagy értelmetlen fájlnevet olvas fel.	Vak és gyengénlátó felhasználók
Gyenge színkontraszt	A szöveg, ikon vagy fókuszjelző beleolvad a háttérbe.	Gyengénlátó, színlátási zavarral élő és idősebb felhasználók
Hibás címsorstruktúra	A tartalom szerkezete nehezen áttekinthető, a címsorok közötti navigáció félrevezető.	Képernyőolvasót használók, kognitív akadályozottsággal élők
Billentyűzettel nem elérhető elem	Egér nélkül nem nyitható meg a menü, nem aktiválható a gomb vagy nem zárható be a modális ablak.	Mozgásszervi akadályozottsággal élők, képernyőolvasót használók
Láthatatlan vagy rosszul kezelt fókusz	A felhasználó nem tudja, hol jár az oldalon, esetleg csapdába kerül egy komponensben.	Billentyűzettel navigálók
Címke nélküli űrlapmező	A mező célja a vizuális elrendezésből látszik, a segítő technológia számára viszont nem derül ki.	Vak és gyengénlátó felhasználók, hangvezérlést használók
Csak színnel jelzett hiba	A piros keret önmagában nem mondja meg, melyik mező hibás és miért.	Színlátási zavarral élők, képernyőolvasót használók
Felirat nélküli videó	A beszédhang információja nem érhető el szövegesen.	Siket és nagyothalló felhasználók, zajos környezetben videózók
Nagyításkor széteső oldal	A tartalom vízszintesen görgetendővé, takarttá vagy használhatatlanná válik.	Gyengénlátó és nagyítást használó felhasználók

A hiba súlyosságát ne csak a darabszám alapján ítéld meg. Egyetlen, billentyűzettel nem aktiválható „Fizetés” gomb fontosabb lehet húsz kisebb strukturális figyelmeztetésnél, mert az egész vásárlást megakadályozza.

Miért nem elég egy automatikus accessibility-pontszám?

Az automatikus eszközök gyorsan megtalálják a programból ellenőrizhető hibák egy részét. Képesek jelezni például a hiányzó alt attribútumot, az elégtelen kontrasztot, az érvénytelen ARIA-tulajdonságot vagy a címke nélküli űrlapmezőt. Abban is sokat segítenek, hogy a hibát összekössék az érintett HTML-elemmel és WCAG-sikerkritériummal.

Egyetlen eszköz sem képes önállóan eldönteni, hogy a weboldal akadálymentes-e. Ezt a W3C is egyértelműen leírja az értékelési útmutatóiban. A gép felismeri, hogy egy képhez tartozik szöveges alternatíva, de a szöveg értelmességét sok esetben embernek kell megítélnie. Ugyanez igaz a fókuszsorrend logikájára, a hibaüzenetek érthetőségére, a videófelirat pontosságára vagy egy teljes ügyintézési folyamat használhatóságára.

Egy jó vizsgálat ezért több rétegből áll:

1. automatikus ellenőrzés több, egymást részben kiegészítő eszközzel;
2. billentyűzetes bejárás Tab, Shift+Tab, Enter, Space és Escape használatával;
3. nagyítás, reflow, kontraszt és mozgó tartalmak ellenőrzése;
4. képernyőolvasós próba legalább a fontos oldaltípusokon és folyamatokon;
5. összetettebb vagy nagy kockázatú szolgáltatásnál szakértői audit és fogyatékossággal élő felhasználókkal végzett teszt.

Az automatikus riport hibakeresési kiindulópont, nem tanúsítvány. A 100-as Lighthouse-pontszám is csak azt mutatja, hogy az adott futásban pontozott auditok teljesültek.

Ha magyar nyelvű háttéranyagot keresel, a kormányzati Web akadálymentesítési kisokos videókkal és letölthető leiratokkal vezeti végig a témát a WCAG alapjaitól a gépi és manuális ellenőrzésen át az űrlapokig, menükig és vizuális követelményekig.

Online accessibility-tesztelő eszközök

Az online ellenőrzők előnye, hogy telepítés nélkül kipróbálhatók. Beírod a nyilvános oldal URL-jét, vársz néhány másodpercet, és kapsz egy listát a talált hibákról. Gyors első állapotfelmérésre kifejezetten hasznosak.

Arra figyelj, hogy az eszköz jellemzően csak a megadott oldal aktuális, kívülről elérhető állapotát látja. Egy belépés mögötti felületet, megnyitásra váró menüt, validációs hibaállapotot vagy többlépéses folyamatot nem biztos, hogy vizsgálni tud. Bizalmas fejlesztői oldal URL-jét pedig ne add át olyan külső szolgáltatásnak, amelynek adatkezelését nem ellenőrizted.

PageSpeed Insights

A PageSpeed Insights sok weboldal-tulajdonos számára a legegyszerűbb belépő. A háttérben Lighthouse-auditot futtat, és a teljesítmény mellett a „Kisegítő lehetőségek” kategóriában accessibility-pontszámot, sikeres ellenőrzéseket, hibákat és manuálisan vizsgálandó tételeket is mutat.

Kezdésnek azért jó, mert nincs szükség telepítésre, a riport közérthető, és a fejlesztő rögtön tovább tud menni az érintett elemek felé. A pontszám súlyozott átlag, ezért két azonos hibaszámú oldal eredménye eltérhet. A manuális ellenőrzések nem részei a pontszámnak.

AccessibilityChecker.org

Az AccessibilityChecker.org ingyenes vizsgálata látványos összképet ad, majd elkülöníti a kritikus hibákat, a sikeres ellenőrzéseket, a kötelező manuális vizsgálatokat és a nem releváns szabályokat. Egy issue megnyitásakor megmutathatja a problémás elemet, a kapcsolódó kódrészletet és a javítás irányát.

Ez a felosztás kezdőként is jól értelmezhető, mert látszik belőle, mennyi mindenben kell emberi döntés. A szolgáltatás megfelelőségi címkéit és kockázati értékelését kezeld a saját rendszerén belüli jelzésként, ne független jogi tanúsítványként.

Skynet Technologies accessibility checker

A Skynet Technologies ingyenes ellenőrzője kategóriákra bontja a vizsgálatot, és külön jelzi a sikeres, sikertelen, nem alkalmazható vagy manuális ellenőrzést igénylő tételeket. Hasznos kiegészítése, hogy egyes hibák mellett megmutatja az érintett felhasználói csoportokat, például a gyengénlátó, színlátási zavarral vagy diszlexiával élő embereket és az idősebb látogatókat.

Ez közelebb viszi a riportot a valódi felhasználói hatáshoz. A részletes nézet viszont nem minden esetben vezet olyan pontosan kódszintig, mint egy fejlesztői böngészőbővítmény, ezért a javításhoz érdemes mellé axe DevTools vagy WAVE vizsgálatot is futtatni.

QualiBooth

A QualiBooth ingyenes URL-vizsgálata egyszerű összesítést ad a kockázatról, a pontszámról és a talált hibákról. A részletes riportot PDF-ben is elkérheted e-mailben, ami akkor kényelmes, ha a feladatokat később adod át vagy nem akarsz a webes felületről egyenként másolni.

A PDF jó munkadokumentum lehet, a vizsgálat korlátai viszont ugyanazok, mint más automatikus ellenőrzőknél. A riport elkészülte nem jelent teljes WCAG-auditot.

WebYes accessibility checker

A WebYes accessibility checker a hibákat és az ellenőrzőlistát külön nézetben mutatja. Az „All issues” alatt a javítandó elemekre koncentrálhatsz, a „Checklist” pedig azt is láthatóvá teszi, hogy az eszköz mit vizsgált meg és mely ellenőrzéseken ment át az oldal.

A hibák kódszintig lenyithatók és vágólapra másolhatók, ezért akkor praktikus, ha a riportból rögtön fejlesztési feladatot készítesz. A manuális ellenőrzések arányát itt is érdemes külön figyelni.

Chrome-bővítmények accessibility-teszteléshez

A böngészőbővítmények ott látják az oldalt, ahol te is. Emiatt helyi fejlesztői környezetben, belépés mögötti felületen és egy megnyitott dinamikus állapotban is használhatók. Fejlesztés közben általában gyorsabb velük a javítás, mert a problémás elem és a forráskód egy helyen vizsgálható.

axe DevTools

Az axe DevTools a Deque axe-core motorjára épülő bővítmény. Telepítés után nyisd meg a Chrome fejlesztői eszközeit az Inspect paranccsal, válaszd az axe DevTools fület, majd indítsd el az oldal vizsgálatát.

Az ingyenes verzió oldalankénti automatikus ellenőrzést ad. A hibáknál megkapod az érintett elemet, a súlyosságot, a probléma magyarázatát és a javítást segítő részleteket. Fejlesztőként ez az egyik leghasznosabb első eszköz, mert a riport közel marad a DOM-hoz és a kódhoz.

WAVE Evaluation Tool

A WAVE Evaluation Tool a WebAIM eszköze. A böngésző ikonjára kattintva oldalsávot nyit, és közvetlenül a weboldalon helyezi el a hibákat, figyelmeztetéseket, strukturális elemeket és ARIA-jelöléseket mutató ikonokat.

A WAVE legnagyobb erőssége a vizuális kontextus. Gyorsan meglátod, hogy egy hiányzó címke, üres link vagy címsorprobléma hol jelenik meg az oldalon. A Structure, Order és Contrast nézet a dokumentumszerkezet, a navigációs sorrend és a kontraszt emberi értékelésében is segít. A bővítmény helyben, a böngészőben végzi az elemzést, ezért intranetes vagy jelszóval védett oldalaknál is használható.

Silktide Accessibility Checker

A Silktide Accessibility Checker telepítés után egy kis ikonnal jelenik meg a böngésző eszköztárában. Erre kattintva az oldal jobb szélén nyílik meg a lebegő panel, miközben maga a vizsgált weboldal is látható marad.

A kezdőnézetből elérhető az automatikus accessibility checker, a kontrasztvizsgálat, az alt szövegek áttekintése, a képernyőolvasó-szimulátor, a fókuszsorrend, a landmarkok, a linkek és a címsorok ellenőrzése. Külön nézet segít a látássérülés, a színlátási zavar és a diszlexia lehetséges hatásainak szemléltetésében is. A bővítmény hivatalos leírása szerint több mint 200 ellenőrzést kínál, és a WCAG 2.0, 2.1, valamint 2.2 verzióit is támogatja.

A Silktide egyik erőssége az érthető hibamagyarázat. A tesztoldalon például olyan ismétlődő alt szövegeket is jelzett, amelyeket a többi kipróbált eszköz nem emelt ki. Ez előfordulhat akkor, ha egy cikk kiemelt képe és a közvetlenül mellette lévő, azonos helyre mutató cím ugyanazt a szöveget adja át a képernyőolvasónak. A felhasználó ilyenkor egymás után kétszer hallhatja ugyanazt a címet.

Ebből nem következik, hogy egy kiemelt kép alt szövege soha nem egyezhet meg a cikk címével. A helyes megoldás a kép szerepétől és a környező kódtól függ. Ha a kép csak megismétli a közeli szöveget, a W3C alt szövegekhez készített döntési fája alapján gyakran az üres alt="" a jobb választás. Ha a fotó önálló információt hordoz, rövid, a kép jelentését átadó leírásra van szükség. A Silktide jelzése éppen azért hasznos, mert ráirányítja a figyelmet erre a manuálisan eldöntendő különbségre.

A képernyőolvasó- és látásszimulációs nézetek jó tanulási segítséget adnak, de nem helyettesítik a valódi kisegítő technológiával és érintett felhasználókkal végzett tesztelést. Az automatikus ellenőrzés eredményeit itt is a konkrét oldal és felhasználói folyamat összefüggésében kell értelmezni.

A11y Quick Check

Az A11y Quick Check kézi ellenőrzést támogató, könnyen kezelhető bővítmény. A felugró panelen kiválaszthatod, hogy többek között a címsorokat, képek alternatív szövegét, listákat, landmarkokat, táblázatokat, formokat, ARIA-tulajdonságokat vagy célterületeket szeretnéd megjelölni.

A checkboxos működés gyors tanulóeszközzé is teszi. A hosszú, általános audit helyett célzottan nézheted meg például a címsorstruktúrát vagy az interaktív elemek hozzáférhető nevét. Az eredmények között lehetnek téves pozitív jelzések, ezért a megjelölt elemeket mindig értelmezd.

Parancssoros accessibility-tesztelés

Ha rendszeresen készítesz weboldalakat, a manuálisan megnyitott riportok mellett érdemes parancssoros, vagyis CLI-teszteket is használni. Ezek ismételhetők, fájlba menthetők, és később beilleszthetők a CI-folyamatba, hogy egy új fejlesztés ismert hibákat ne engedjen vissza.

Pa11y: jó elsődleges WCAG CLI

A Pa11y egyszerűen futtatható egy URL-en, alapértelmezett célja pedig a WCAG 2 AA szint. Két beépített ellenőrző motort támogat: az axe-core-t és a HTML_CodeSniffert. Együtt futtatva részben eltérő szabályértelmezést kapsz, ami szélesebb automatikus hibafeltárást adhat.

Telepítés nélkül, npx használatával:

npx pa11y@latest "https://pelda.hu/" \
  --standard WCAG2AA \
  --runner axe \
  --runner htmlcs

JSON-riport mentéséhez:

npx pa11y@latest "https://pelda.hu/" \
  --standard WCAG2AA \
  --runner axe \
  --runner htmlcs \
  --reporter json > pa11y-report.json

A riportban megjelenhet a hibaüzenet, a szabálykód, a problémás HTML-részlet és az elem CSS-szelektora. A Pa11y műveletsorokat is tud futtatni, így előkészíthető vele egy menü, modális ablak vagy űrlaphiba vizsgálandó állapota. Több URL, sitemap és CI-küszöb kezeléséhez a Pa11y CI ad kényelmesebb keretet.

Lighthouse CLI: látványos HTML-riporthoz

A Lighthouse parancssorból is futtatható, és külön HTML-jelentést készíthet csak az accessibility kategóriáról:

npx lighthouse@latest "https://pelda.hu/" \
  --only-categories=accessibility \
  --output=html \
  --output-path=./lighthouse-accessibility.html

Ez ugyanannak a tesztcsaládnak a fejlesztőbarát változata, amellyel a PageSpeed Insightsban és a Chrome DevToolsban találkozol. A riport megosztható és archiválható, de a 100-as eredmény itt sem igazol teljes WCAG-megfelelést.

Milyen más CLI-eszközök jöhetnek szóba?

Eszköz	Mire jó?	Mikor választanám?
axe CLI	Közvetlen axe-core eredményeket ad.	Ha kifejezetten az axe motort akarod futtatni, és vállalod a böngésződriver beállítását.
Pa11y CI	URL-listát, sitemapet és CI-folyamatot kezel.	Ha több oldalt vizsgálsz minden buildnél.
webhint	Accessibility mellett HTML-, kompatibilitási, biztonsági és best-practice ellenőrzéseket ad.	Ha általános webminőségi auditot szeretnél.
IBM Equal Access	Saját szabálymotorral és tesztautomatizálási integrációkkal dolgozik.	Ha egy második motor véleményét építenéd be Playwright-, Puppeteer- vagy Selenium-tesztekbe.
QualWeb	ACT Rules és WCAG techniques alapú értékelést, valamint EARL-riportot is támogat.	Ha szabványközeli keresztellenőrzésre vagy géppel feldolgozható jelentésre van szükséged.

Nem sok haszna van öt, nagyrészt axe-alapú eszközt egymás mellé telepíteni. Többet nyersz egy jól megválasztott automatikus párossal és következetes manuális tesztekkel.

Mit tud az MCP az akadálymentességi tesztelésben?

Az MCP, vagyis Model Context Protocol lehetővé teszi, hogy egy AI-asszisztens külső eszközöket használjon. Böngészős MCP-vel az AI meg tudja nyitni az oldalt, kezelheti a cookie-ablakot, előkészíthet egy dinamikus állapotot, billentyűket nyomhat le, auditot indíthat és segíthet a riportból javítási feladatokat készíteni.

Az MCP egy vezérlési réteg, nem önálló WCAG-módszertan. Az eredmény minőségét az alatta futó Lighthouse-, axe- vagy más szabálymotor, a megadott feladat és az emberi ellenőrzés együtt határozza meg.

Chrome DevTools MCP

A Chrome DevTools MCP hivatalos Google-projekt, amely Chrome-ot ad a kódoló agent kezébe. A lighthouse_audit eszköze accessibility-, SEO-, best-practice és agentic browsing riportot készít. Navigation módban újratölti és vizsgálja az oldalt, snapshot módban pedig az aktuális állapotot elemzi. Ez utóbbi akkor hasznos, ha előbb megnyitottál egy menüt vagy modális ablakot.

A take_snapshot az accessibility tree alapján szöveges képet ad a felület elemeiről, a press_key pedig billentyűzetes interakciókat tesz lehetővé. Ezek jó támpontot adnak a fókusz, a hozzáférhető nevek és a dinamikus működés vizsgálatához, de továbbra sem helyettesítik a tapasztalt képernyőolvasó-felhasználó értékelését.

Codexhez a szerver így adható hozzá:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

A használati statisztikák küldése alapértelmezetten engedélyezett. Ha ezt ki szeretnéd kapcsolni:

codex mcp add chrome-devtools -- \
  npx chrome-devtools-mcp@latest \
  --no-usage-statistics

Az MCP hozzáfér a vezérelt böngészőben megjelenő tartalomhoz. Érzékeny adatoknál használj elkülönített böngészőprofilt, és csak olyan jogosultságot adj, amely tényleg szükséges a vizsgálathoz.

Playwright MCP

A Microsoft Playwright MCP strukturált accessibility snapshot alapján képes navigálni, kattintani, gépelni, képernyőképet készíteni és billentyűket kezelni. Jól használható a Tab-sorrend, a modális fókuszkezelés, az űrlaphibák vagy egy többlépéses folyamat előkészítésére.

Az accessibility snapshot önmagában nem axe- vagy WCAG-audit. Ha automatikus szabályellenőrzést is akarsz, kapcsolj a Playwright-tesztekhez @axe-core/playwright csomagot, vagy futtass külön Pa11y- vagy Lighthouse-vizsgálatot.

Dedikált és kereskedelmi MCP-k

Az A11y MCP közösségi projekt, amely axe-core és Puppeteer segítségével URL-t vagy HTML-t vizsgál. Kifejezetten accessibility-feladatra készült, de kisebb közösség tartja karban, ezért éles folyamatba építés előtt nézd meg az aktuális kiadást, a jogosultságokat és az adatkezelést.

Léteznek külön Lighthouse-wrapper MCP-k is, de a Chrome DevTools MCP mellett nagy az átfedésük. A Deque kereskedelmi Axe MCP megoldása pedig akkor lehet érdekes, ha a szervezet már az Axe DevTools ökoszisztémáját használja, és az előfizetéses, támogatott integráció fontosabb a nyílt forrású összeállításnál.

Egy használható tesztelési folyamat

Egy teljes webhelyet ne egyetlen URL alapján ítélj meg. Válassz reprezentatív mintát: kezdőlapot, lista- vagy kategóriaoldalt, részletes tartalmi oldalt, kapcsolatfelvételi vagy regisztrációs űrlapot, keresőt, belépést és a legfontosabb üzleti folyamatot. Webshopnál ilyen a kosár és a fizetés is.

Ezután haladj rétegenként:

1. Futtass PageSpeed Insights vagy Lighthouse ellenőrzést a gyors állapotképhez.
2. Nézd át ugyanazt az oldalt axe DevTools, WAVE vagy Silktide segítségével, és javítsd a biztosan reprodukálható kódhibákat.
3. Futtass Pa11y-t a fontos sablonokra, majd mentsd a riportot, hogy később összehasonlítható legyen.
4. Járd be billentyűzettel a teljes folyamatot. Figyeld a fókusz láthatóságát, sorrendjét, a modális ablakokat, a menüket és a hibaállapotokat.
5. Ellenőrizd nagyítással, keskeny viewporton, mozgáscsökkentett beállítással és legalább egy képernyőolvasóval.
6. A hibajegybe írd bele az érintett elemet, a felhasználói hatást, a WCAG-sikerkritériumot, a reprodukció lépéseit és az elfogadási feltételt.
7. Javítás után ugyanabban az állapotban tesztelj újra, és az automatizálható regressziókat építsd be a CI-folyamatba.

Az én gyakorlati alapcsomagom egy online Lighthouse-vizsgálatból, axe DevToolsból, WAVE-ből vagy Silktide-ból, Pa11y CLI-ből és célzott manuális tesztekből állna. AI-val támogatott munkánál ehhez jöhet a Chrome DevTools MCP, amely segít az állapotok előkészítésében és a riportok feldolgozásában.

A webes akadálymentesség akkor működik jól, ha nem az átadás előtti utolsó auditként kerül elő. Már a komponensek tervezésénél, a szövegírásnál és a fejlesztés közben olcsóbb javítani a hibákat. A legfontosabb váltás az, hogy a pontszám helyett a felhasználói feladatot nézd: el tudja-e végezni az ember azt, amiért az oldalra érkezett?

GYIK

Mi a különbség a WAI és a WCAG között?

A WAI a W3C webes akadálymentességgel foglalkozó kezdeményezése. A WCAG az általa fejlesztett, webes tartalmakra vonatkozó akadálymentességi szabvány. A WAI emellett oktatóanyagokat, tesztelési útmutatókat és más technikai specifikációkat is készít.

Melyik WCAG-szintet érdemes megcélozni?

A legtöbb általános weboldalnál a WCAG 2.2 AA jó műszaki cél. Ehhez az összes A és AA sikerkritériumot teljesíteni kell. Jogi kötelezettségnél külön ellenőrizd az alkalmazandó szabályozást és harmonizált szabványt.

Elég a 100-as Lighthouse accessibility-pontszám?

Nem. A 100-as pontszám csak a Lighthouse által automatikusan pontozott ellenőrzések eredményét mutatja az adott oldalállapotban. A manuális vizsgálatot igénylő követelmények, a teljes felhasználói folyamat és több tartalmi minőségi kérdés kimarad belőle.

Egy accessibility plugin vagy overlay akadálymentessé teszi az oldalt?

Egy segédplugin adhat hasznos funkciókat, de nem javítja ki megbízhatóan a tartalom, a HTML-szemantika, a billentyűzetes működés és a dinamikus komponensek összes hibáját. A tartós megoldás a forráskód, a dizájn, a tartalom és a szerkesztési folyamat javítása, majd ezek tesztelése.

Milyen gyakran kell újratesztelni a weboldalt?

Minden jelentősebb sablon-, komponens- vagy funkcióváltozás után érdemes célzottan tesztelni. A legfontosabb automatikus ellenőrzések fussanak a fejlesztési folyamatban is, időszakosan pedig végezz szélesebb manuális felülvizsgálatot a reprezentatív oldalakon és folyamatokon.

Szójegyzék

• Accessibility / a11y – Digitális akadálymentesség. Az „a11y” rövidítésben az „a” és az „y” között 11 betű található.
• Assistive technology – Kisegítő technológia, például képernyőolvasó, képernyőnagyító, Braille-kijelző, kapcsolóvezérlés vagy hangvezérlés.
• Accessibility tree – A böngésző által előállított szemantikai struktúra, amelyből a kisegítő technológiák megismerhetik az elemek szerepét, nevét, állapotát és kapcsolatait.
• ARIA – Accessible Rich Internet Applications. HTML-attribútumok rendszere, amely főleg egyedi, dinamikus komponensek szemantikájának átadását segíti.
• CI, continuous integration – Olyan automatizált fejlesztési folyamat, amelyben a módosításokhoz build, teszt és más minőség-ellenőrzés futhat.
• Conformance – Egy meghatározott WCAG-verzió és megfelelőségi szint összes vonatkozó követelményének teljesítése a megadott oldalon vagy oldalkörön.
• Focus – Az az elem, amely jelenleg billentyűzetes vagy más beviteli műveletet fogad. A fókusznak láthatónak és logikusan mozgathatónak kell lennie.
• MCP, Model Context Protocol – Olyan kapcsolódási szabvány, amelyen keresztül egy AI-asszisztens külső eszközöket és adatforrásokat használhat.
• Reflow – A tartalom átrendeződése szűk viewporton vagy nagyításkor úgy, hogy olvasható és kezelhető maradjon.
• Screen reader – Képernyőolvasó szoftver, amely beszéddel vagy Braille-kimenettel adja át a felület tartalmát és szemantikáját.
• WCAG – Web Content Accessibility Guidelines, a webes tartalmak akadálymentességi követelményeit leíró nemzetközi szabvány.