WCAG közérthetően: weboldal-akadálymentességi követelmények

A WCAG a webes akadálymentesség nemzetközi követelményrendszere. Abban segít, hogy egy weboldal tartalmait és funkcióit olyan felhasználók is elérjék, akik például képernyőolvasót használnak, nem tudnak egeret kezelni, nehezebben látnak bizonyos színeket, vagy más módon férnek hozzá a digitális tartalmakhoz.

A gyakorlatban ez többek között azt jelenti, hogy az oldal billentyűzettel is kezelhető, a szövegek megfelelő kontrasztúak, a képek szükség esetén értelmes alternatív szöveget kapnak, az űrlapok egyértelműen használhatók, az interaktív elemek pedig segítő technológiák számára is értelmezhetők.

A WCAG 2-es szabványcsalád legújabb változata a WCAG 2.2, amelyet a W3C 2023. október 5-én tett W3C Recommendation státuszú webszabvánnyá. A W3C új vagy frissített akadálymentesítési munkáknál ezt a verziót javasolja kiindulási alapként. A megfelelőség azonban nem egy akadálymentességi plugin telepítését vagy egy automatikus ellenőrzőben elért jó pontszámot jelenti. A WCAG konkrét, tesztelhető sikerkritériumokat tartalmaz, amelyek a tartalmat, a felületet és a működést egyaránt érintik.

Mi az a WCAG, és miért van rá szükség?

A WCAG a Web Content Accessibility Guidelines rövidítése. A W3C Web Accessibility Initiative keretében fejlesztett szabvány közös követelményrendszert ad a webes tartalmak akadálymentesítéséhez. Az akadálymentességet nem érdemes kizárólag a vak vagy gyengénlátó felhasználók szempontjából nézni. A weboldalak használhatóságát látási, hallási, mozgási és kognitív adottságok egyaránt befolyásolhatják. Van, aki képernyőolvasóval böngészik. Más csak billentyűzetet tud használni. Valaki nagyítja a tartalmat, mert kis méretben nehezen olvassa, más pedig bizonyos színkombinációkat nem tud megfelelően megkülönböztetni.

A kérdés minden esetben ugyanaz: hozzáférhető-e az információ és működtethető-e az oldal akkor is, ha valaki nem pontosan úgy használja, ahogy azt a tervező alapértelmezettnek gondolta?

WCAG 2.0, 2.1 és 2.2 – melyiket kell nézni?

A WCAG 2.0, 2.1 és 2.2 egymásra épülő szabványverziók. A későbbi változatok új követelményekkel egészítették ki az előzőeket. A WCAG 2.2 kilenc új sikerkritériumot adott a 2.1-hez képest, miközben a korábbi 4.1.1 Parsing kritériumot elavultként eltávolította. Új fejlesztésnél vagy akadálymentesítési projektben ezért célszerű a WCAG 2.2-t használni, kivéve, ha valamilyen szerződéses vagy jogi előírás más verziót határoz meg.

A WCAG négy alapelve közérthetően

A WCAG követelményei négy alapelv köré szerveződnek: a webes tartalomnak érzékelhetőnek, működtethetőnek, érthetőnek és robusztusnak kell lennie. Angolul ezek a Perceivable, Operable, Understandable és Robust kifejezések, amelyekből a POUR rövidítés származik. Ezek elsőre elvont fogalmaknak tűnhetnek, weboldalon azonban nagyon konkrét követelményeket jelentenek.

1. Érzékelhető – az információhoz hozzá kell tudni férni

Ha egy információ lényeges, azt nem szabad kizárólag olyan formában közölni, amelyhez bizonyos felhasználók nem férnek hozzá. Egy információt hordozó képhez például szükség lehet szöveges alternatívára, amelyet a képernyőolvasó fel tud olvasni. Videónál feliratokra lehet szükség. A szöveg és a háttér között megfelelő kontrasztot kell biztosítani. Ugyanez vonatkozik arra is, amikor egy állapotot csak színnel jelzünk. Ha egy űrlapon a hibás mezőt kizárólag piros keret mutatja, a felhasználónak ebből kellene kitalálnia, mi történt. Sokkal használhatóbb megoldás, ha a vizuális jelzés mellett szöveges hibaüzenet is megjelenik.

Az akadálymentesítés tehát sokszor nem egy teljesen eltérő felületet jelent. Inkább azt, hogy ugyanaz az információ többféle módon is hozzáférhető legyen.

2. Működtethető – az oldal használata se jelentsen akadályt

Egy oldal nem attól használható, hogy minden információ látható rajta. A funkciókat is el kell tudni érni. Erre jó próba, ha félretesszük az egeret, és csak billentyűzettel próbáljuk végigjárni az oldalt. Elérhető a menü? Meg lehet nyomni a gombokat? Kitölthető az űrlap? Bezárható egy felugró ablak? Látszik, éppen melyik elemen van a fókusz? Gyakori hiba, hogy egy egyedi lenyíló menü vagy más interaktív elem egérrel tökéletesen működik, billentyűzettel viszont nem érhető el. A funkció ilyenkor technikailag létezik, de nem minden felhasználó számára. A WCAG 2.2 ezen a területen új sikerkritériumokat is bevezetett, például a fókusz kitakarásával, a húzó mozdulatok alternatíváival és bizonyos interaktív célterületek minimális méretével kapcsolatban.

3. Érthető – a tartalom és a működés legyen kiszámítható

Egy technikailag működő oldal még lehet indokolatlanul nehéz. Az űrlapmezőknek egyértelmű elnevezés kell. A hibaüzenetből ki kell derülnie, mit kell javítani. A navigáció működjön következetesen, és ugyanaz a művelet ne viselkedjen teljesen másképp az oldal különböző részein. A „Hiba történt” üzenet például kevés információt ad. Sokkal többet segít, ha a rendszer azt is jelzi, hogy például az e-mail-cím formátuma hibás. A WCAG 2.2 ezen a területen többek között az ismételt adatbevitel csökkentésével és a következetesen elérhető segítséggel is foglalkozik.

4. Robusztus – a segítő technológiáknak is érteniük kell az oldalt

Ez a rész technikaibb, de az alapja egyszerű. Egy elem ne csak kinézetében legyen gomb. A böngészőnek és a segítő technológiának is fel kell ismernie, hogy gomb, mi a neve, és milyen állapotban van. Ebben nagy szerepe van a szemantikus HTML-nek és az interaktív komponensek megfelelő megvalósításának. Az ARIA-attribútumok bizonyos esetekben kiegészíthetik a hiányzó akadálymentességi információkat, de nem attól lesz jó egy felület, hogy minél több ARIA kerül a kódba. Sok helyzetben a megfelelő natív HTML-elem a legegyszerűbb és legmegbízhatóbb megoldás.

Mit jelent a WCAG A, AA és AAA szint?

A WCAG három megfelelőségi szintet használ: A, AA és AAA. Ezek egymásra épülnek. Nem érdemes úgy gondolni rájuk, hogy az A „kicsit akadálymentes”, a AAA pedig „teljesen akadálymentes”. Mindegyik szint konkrét sikerkritériumokat jelöl.

A szint

Az A szint tartalmazza az alapvető követelményeket. A megfelelőséghez minden alkalmazandó A szintű sikerkritériumot teljesíteni kell. Nem lehet ezek közül csak a könnyebbeket kiválasztani, majd az oldalt A szintűnek nevezni.

AA szint

AA megfelelőséghez az A és AA szint összes alkalmazandó sikerkritériumát teljesíteni kell. Az AA tehát nem külön követelménycsomag az A helyett, hanem arra épül rá. Sok akadálymentesítési projektben az AA jelenik meg célszintként, de azt, hogy egy adott szervezetnek jogilag vagy szerződés szerint milyen megfelelőségi szintet kell elérnie, külön kell vizsgálni.

AAA szint

AAA megfelelőséghez az A, AA és AAA szint kritériumait egyaránt teljesíteni kell. A W3C nem javasolja általános követelményként a teljes webhelyek AAA szintű megfelelőségét, mert bizonyos tartalomtípusoknál nem feltétlenül teljesíthető minden AAA kritérium.

Mit kell teljesítenie a gyakorlatban egy WCAG-nak megfelelő weboldalnak?

A teljes szabvány ennél jóval részletesebb, de egy tipikus weboldalnál bizonyos területek rendszeresen előkerülnek.

Szövegek, címsorok és tartalmi struktúra

Attól, hogy egy oldal vizuálisan rendezettnek látszik, még nem biztos, hogy a tartalmi struktúrája technikailag is rendben van. Egy nagy, félkövér szöveg például nem válik automatikusan címsorrá. A megfelelő HTML-címsoroknak úgy kell felépülniük, hogy a tartalom logikája vizuális megjelenítés nélkül is követhető maradjon. A linkeknél hasonló szempont érvényesül. Ha egy oldalon sok „Tovább” link szerepel, a környezetből kiragadva nehezebb eldönteni, melyik hová vezet.

Képek és alternatív szövegek

Nem minden képhez kell hosszú alt szöveg. Az alternatív szöveg szerepe attól függ, mire szolgál a kép. Egy információt közvetítő képnek olyan alternatíva kell, amely átadja a lényegi tartalmat. Egy kizárólag dekorációs célt szolgáló kép más kezelést igényelhet. Az alt attribútum nem SEO-kulcsszavak tárolására való. Ha egy kép fontos információt közöl, annak a leírásból a felhasználó számára is ki kell derülnie. A helyes kérdés tehát nem az, hogy „ki van-e töltve az alt mező?”, hanem az, hogy aki nem látja a képet, hozzájut-e a szükséges információhoz.

Színek és kontraszt

A túl gyenge kontraszt az egyik leggyakoribb és legegyszerűbben felismerhető probléma. Világosszürke szöveg fehér háttéren látványterven visszafogottnak tűnhet, használat közben azonban nehezen olvasható. A kontraszt nem csak a folyó szöveget érinti. Gombok, mezőhatárok, állapotjelzések és más vizuális elemek esetében is lehetnek követelmények. Információt pedig nem célszerű kizárólag színre bízni. Ha egy grafikon kategóriái csak eltérő színekkel különböznek egymástól, bizonyos felhasználók számára nehezebbé válhat az értelmezés.

Billentyűzetes navigáció

Egy weboldal alapvető interaktív funkcióinak billentyűzettel is használhatónak kell lenniük, ahol az adott WCAG-kritérium ezt megköveteli. Különösen érdemes ellenőrizni a navigációt, a lenyíló menüket, a linkeket, a gombokat, a modális ablakokat, az űrlapokat, valamint az egyedi keresőket és szűrőket. Nem elég, ha a Tab billentyű technikailag végiglépked az oldalon. A navigációnak használhatónak és követhetőnek kell maradnia.

A fókusznak láthatónak kell lennie

A billentyűzettel navigáló felhasználónak tudnia kell, melyik elem aktív éppen. Ezért problémás, ha a design kedvéért egyszerűen eltávolítják a fókuszjelölést, és nem kap megfelelő alternatívát. Az is gond, ha a fókuszban lévő elem ugyan technikailag aktív, de egy ragadós fejléc, cookie-panel vagy más lebegó elem eltakarja. A WCAG 2.2 külön sikerkritériumokat vezetett be a fókusz kitakarásával kapcsolatban.

Űrlapok és hibaüzenetek

Egy akadálymentes űrlap nem egyszerűen nagyobb mezőkből áll. A felhasználónak tudnia kell, mit vár el tőle az adott mező. Ehhez megfelelő címkézésre van szükség, hiba esetén pedig annak is egyértelműnek kell lennie, mi történt és hol kell javítani. Ha például az e-mail-cím hibás, kevés segítséget jelent, ha a rendszer csak pirosra színezi a mezőt. Jobb megoldás, ha közli, hogy az e-mail-cím formátuma nem megfelelő, és egyértelműen azonosítja az érintett mezőt. Az ilyen megoldások ráadásul nem csak az akadálymentességet javítják. Általában minden felhasználó számára egyszerűbbé teszik az űrlap használatát.

Gombok, linkek és más interaktív elemek

Egy kattintható elem funkciójának érthetőnek kell lennie, és megfelelően azonosítható névre van szüksége. A túl kicsi célterületek szintén gondot okozhatnak. A WCAG 2.2 AA szinten új Target Size (Minimum) sikerkritériumot vezetett be, amely meghatározott kivételekkel minimumkövetelményt ír elő bizonyos interaktív célterületekre. Mobilon ennek különösen gyakorlati jelentősége van. Egymás mellé zsúfolt apró ikonokat nem minden felhasználó tud pontosan megérinteni.

Videók és hanganyagok

A multimédiás tartalmaknál a konkrét követelmények a tartalom típusától és a megcélzott megfelelőségi szinttől is függenek. Videóknál például feliratokra és más alternatívákra lehet szükség. Az alapelv ugyanaz: a lényeges információ ne legyen hozzáférhetetlen azért, mert kizárólag egyetlen érzékelési módon jelenik meg.

Bejelentkezés és azonosítás

A WCAG 2.2 az akadálymentes hitelesítés területével is bővült. Az AA szintű Accessible Authentication (Minimum) kritérium célja, hogy a hitelesítési folyamat ne követeljen meg szükségtelenül olyan kognitív funkciótesztet, amelyhez nincs megfelelő alternatíva vagy segítség. A bejelentkezés akadálymentessége tehát nem merül ki abban, hogy megfelelő méretű-e a jelszómező. A teljes folyamatnak használhatónak kell lennie.

Melyek a leggyakoribb WCAG-hibák egy weboldalon?

Sok probléma hétköznapi és elsőre nem is feltétlenül feltűnő. Hiányzik a lényegi képek megfelelő alternatív szövege. Túl gyenge a kontraszt. A menü egér nélkül nem használható. Billentyűzetes navigációnál eltűnik a fókusz. Az űrlapmező nincs megfelelően címkézve. A hibaüzenet nem mondja meg, mit kell kijavítani. A vizuálisan címsornak látszó szövegek mögött nincs logikus HTML-struktúra.

Összetettebb oldalakon gyakran az egyedi komponenseknél jelennek meg hibák. Egy saját fejlesztésű legördülő lista például egérrel tökéletesen működhet, miközben képernyőolvasóval vagy billentyűzetről alig használható. Éppen ezért kevés csak vizuálisan végignézni az oldalt.

Elég egy automatikus WCAG-ellenőrző?

Nem. Az automatizált tesztek hasznosak, de csak a vizsgálat egy részét tudják elvégezni. A W3C megfelelőségi útmutatója is abból indul ki, hogy bizonyos sikerkritériumok ellenőrzéséhez automatizált vizsgálat és emberi értékelés kombinációjára lehet szükség.

Egy eszköz például észreveheti, hogy egy képről hiányzik az alt attribútum. Azt már jóval nehezebb automatikusan eldönteni, hogy a megadott szöveg valóban megfelelően írja-e le a kép funkcióját vagy tartalmát. Ugyanez igaz a címsorokra vagy az összetettebb felhasználói folyamatokra. A rendszer képes megmutatni a technikai struktúrát, de annak szakmai értékeléséhez emberi döntés kell. Egy hibamentes automatikus teszt ezért önmagában nem bizonyítja a WCAG-megfelelőséget.

Hogyan történik egy weboldal WCAG-ellenőrzése?

Automatikus vizsgálattal gyorsan megtalálhatók bizonyos hibák

Az automatizált eszközök jó első szűrőt jelentenek. Gyorsan észrevehetnek bizonyos kódolási, kontraszt-, címkézési vagy strukturális problémákat. Nagyobb webhelyeknél különösen hasznosak, mert sok oldalt lehet velük rendszeresen átvizsgálni. A találatokat azonban értékelni kell, és attól, hogy az eszköz nem jelez hibát, még maradhatnak akadályok.

Manuálisan is végig kell próbálni a működést

A billentyűzetes használat az egyik legegyszerűbb manuális próba. Végig lehet menni a fő navigáción, megnyitni a menüket, kitölteni az űrlapokat, használni a felugró ablakokat és végrehajtani a fontos feladatokat. Így gyorsan kiderülhet, ha valahol eltűnik a fókusz, hibás a fókuszsorrend, vagy egy komponensből nem lehet billentyűzettel kilépni.

Segítő technológiákkal is tesztelni kell

A képernyőolvasó más típusú problémákat hozhat felszínre. Lehet például egy gomb vizuálisan teljesen egyértelmű, miközben a képernyőolvasó csak annyit közöl róla, hogy „gomb”, a funkciója pedig nem derül ki. A megfelelő teszteléshez természetesen azt is tudni kell, hogyan használják ténylegesen az adott segítő technológiát.

Nem csak oldalakat, teljes folyamatokat is vizsgálni kell

Egy webáruházban kevés, ha a termékoldal akadálymentes, de a fizetési folyamat nem hajtható végre. A WCAG megfelelőségi modellje szerint, ha több oldal együtt alkot egy teljes folyamatot, akkor a folyamat minden érintett oldalának meg kell felelnie a megcélzott szinten. A W3C erre példaként egy online vásárlási folyamatot is említ a termékválasztástól a checkoutig. Egy audit során ezért nem elég néhány statikus oldalt ellenőrizni. A valódi felhasználói feladatokat is végig kell vinni.

Mikor érdemes foglalkozni a WCAG-gal egy weboldal készítése során?

Lehetőleg már a tervezésnél. Ha csak a fejlesztés végén derül ki, hogy a színpaletta kontrasztja nem megfelelő, bizonyos komponensek billentyűzettel nem használhatók, vagy az űrlapok címkézése hibás, a javítás jóval több munkával járhat.

Az akadálymentesség több szakmai területet egyszerre érint. A designernek számolnia kell a kontraszttal, a fókuszállapotokkal és az interakciók vizuális jelzésével. A UX-tervezőnek a folyamatok érthetőségére és kezelhetőségére kell figyelnie. A fejlesztő feladata többek között a szemantikus struktúra, a billentyűzetes működés és az egyedi komponensek megfelelő megvalósítása. A tartalomkészítőnek pedig a címsorokra, linkekre és alternatív szövegekre is gondolnia kell. Az akadálymentességet sokkal nehezebb jól megoldani, ha csak a kész weboldalra próbálják utólag ráépíteni.

Meglévő weboldal is akadálymentesíthető?

Igen. Attól, hogy egy jelenlegi weboldal nem teljesíti az elvárt WCAG-szintet, még nem feltétlenül kell teljesen új oldalt készíteni. Először azt kell megvizsgálni, milyen típusú hibákról van szó, és mennyire mélyen épülnek be a rendszerbe.

Mikor elég célzott javítás?

Ha a technikai alap megfelelő, és a hibák jól körülhatárolhatók, sok minden javítható a meglévő oldalon. Módosíthatók a kontrasztok, kialakíthatók megfelelő fókuszállapotok, javíthatók az űrlapok, pótolhatók vagy pontosíthatók az alternatív szövegek, rendezhető a címsorstruktúra, és akadálymentesebbé tehetők az egyes komponensek. Ilyenkor nincs feltétlenül szükség teljes redesignra.

Mikor kell komolyabban hozzányúlni a rendszerhez?

Más a helyzet, ha az alapvető komponensek sorozatosan akadályokat hoznak létre. Ha a navigáció technikai felépítése rossz, az egyedi felületi elemek nagy része billentyűzettel használhatatlan, a HTML-struktúra következetlen, vagy maga a komponensrendszer nehezíti a javítást, a kisebb módosítások könnyen komolyabb átalakítássá nőnek. Ilyenkor már ugyanazt kell mérlegelni, mint más weboldal-továbbfejlesztéseknél: érdemes-e tovább építeni a jelenlegi alapra, vagy gazdaságosabb egyes részeket újratervezni.

WCAG és jogszabályi megfelelés ugyanazt jelenti?

Nem. A WCAG technikai akadálymentességi követelményrendszer. Sikerkritériumokon keresztül írja le, hogyan vizsgálható a digitális tartalom hozzáférhetősége. Az viszont, hogy egy adott vállalkozásra, szervezetre, szolgáltatásra vagy weboldalra milyen jogi kötelezettségek vonatkoznak, külön kérdés.

Abból tehát, hogy létezik WCAG 2.2 vagy meghatározható egy adott megfelelőségi szint, nem következik automatikusan ugyanaz a kötelezettség minden weboldal számára. Konkrét jogi megfelelőség megállapításakor az adott szervezetre és szolgáltatásra vonatkozó aktuális szabályozást külön kell ellenőrizni. A WCAG-audit és a jogi megfelelőség vizsgálata kapcsolódik egymáshoz, de nem ugyanaz.

Gyakori kérdések a WCAG-ról

Mi az a WCAG?

A WCAG a Web Content Accessibility Guidelines rövidítése. Nemzetközi webes akadálymentességi szabvány, amely tesztelhető sikerkritériumokon keresztül határozza meg az akadálymentességi követelményeket.

Mi a jelenlegi WCAG-verzió?

A WCAG 2-es szabványcsalád legújabb változata a WCAG 2.2. A W3C 2023. október 5-én publikálta Recommendation webszabványként, és új akadálymentesítési munkáknál ezt javasolja használni.

Mi a különbség a WCAG A, AA és AAA között?

A három szint egymásra épül. Egy adott szint teljesítéséhez az adott és az alatta lévő szintek összes alkalmazandó sikerkritériumát teljesíteni kell. AA esetében tehát az A és AA, AAA esetében az A, AA és AAA követelmények számítanak.

Mit jelent a WCAG AA megfelelőség?

Azt, hogy az összes alkalmazandó A és AA szintű sikerkritérium, valamint a WCAG egyéb megfelelőségi követelményei is teljesülnek. Nem elég a követelmények egy tetszőlegesen kiválasztott részének megfelelni.

Kötelező minden weboldalnak megfelelnie a WCAG-nak?

Erre nincs minden weboldalra érvényes egyszerű igen vagy nem válasz. A jogi kötelezettség függhet többek között az adott szervezettől, szolgáltatástól és az alkalmazandó szabályozástól. Konkrét esetben az aktuális jogi követelményeket külön kell ellenőrizni.

Elég egy automatikus WCAG checker?

Nem. Az automatikus teszt jó kiindulópont, de emberi értékelésre is szükség van. Bizonyos problémákról – például egy alternatív szöveg megfelelőségéről vagy egy összetett felhasználói folyamat használhatóságáról – automatizált eszköz önmagában nem tud megbízhatóan dönteni.

Egy WordPress-weboldal lehet WCAG-nak megfelelő?

Igen. A CMS önmagában nem határozza meg a megfelelőséget. A sablon, a bővítmények, az egyedi komponensek, a tartalom és a konkrét fejlesztési megvalósítás együtt számít.

Az akadálymentes weboldal rosszabbul néz ki?

Nem. A megfelelő kontraszt, a látható fókusz, az érthető navigáció vagy a kellően nagy interaktív elemek tervezési követelmények, nem pedig egy adott vizuális stílus előírásai.

Hogyan érdemes elindulni a WCAG-megfelelőség felé?

Meglévő weboldalnál nem célszerű találomra alt szövegeket írni vagy rögtön akadálymentességi bővítményt telepíteni. Először fel kell mérni az aktuális állapotot. Automatikus ellenőrzéssel gyorsan kiszűrhetők bizonyos technikai hibák, ezt pedig manuális vizsgálattal kell kiegészíteni a fontos oldalakon, komponenseken és felhasználói folyamatokon.

A talált problémákat ezután súlyosság, gyakoriság és javítási igény szerint lehet rendezni. A javítás érintheti a designt, a tartalmat és a fejlesztést is, majd újra tesztelni kell az eredményt. A WCAG-megfelelőség teljes oldalakra vonatkozik: egy problémás oldalrészt nem lehet egyszerűen kihagyni a megfelelőségi állításból. Ha pedig több oldal együtt alkot egy teljes folyamatot – például egy online vásárlást –, a folyamat minden érintett oldalának meg kell felelnie a megcélzott szinten.

A WCAG tehát nem egy automatikus teszt pontszáma és nem egy utólag bekapcsolható „akadálymentes mód”. A tartalomnak, a felületnek és a működésnek együtt kell teljesítenie az adott megfelelőségi szint követelményeit.