Miért fedik át egymást az akadálymentesítés és a hozzájárulás?

A GDPR megköveteli, hogy a hozzájárulás minden felhasználótól megszerezhető legyen, nemcsak azoktól, akik látnak és rá tudnak kattintani egy bannerre. Az Európai Adatvédelmi Testület tisztázta, hogy ha egy érintett nem tud érdemben interakcióba lépni a hozzájárulási felülettel — fogyatékossága miatt, amelyet az oldal nem vett figyelembe — a hozzájárulás nem érvényes. Ez azt jelenti, hogy a cookie-kat egyáltalán nem lett volna szabad betölteni.

Az akadálymentesítés oldalán az Európai Akadálymentesítési Törvény (EAA), amelyet az EU tagállamok nemzeti jogukba ültettek át, a WCAG 2.1 AA szintet teszi minimummá a fogyasztói szolgáltatásokat nyújtó magánszektor weboldalai és alkalmazásai számára. A szankciók országa szerint változnak, de jellemzően jogsértésenként 50 000 és 500 000 euró között mozognak, és tartós nem-megfelelés esetén piaci kivonási határozattal is járhatnak.

A cookie-bannerekre vonatkozó alapvető WCAG-követelmények

Billentyűzettel való kezelhetőség

Minden banner-vezérlőnek — Elfogadás, Elutasítás, Beállítások kezelése, bezárás — kizárólag billentyűzettel elérhetőnek és működtethetőnek kell lennie. A felhasználóknak logikus sorrendben kell tudniuk Tab-billentyűvel navigálni a gombok között, és Enter vagy Space billentyűvel aktiválni azokat. A fókusznak láthatónak kell lennie, legalább 3:1 kontrasztarányban a háttérrel szemben.

Fókuszcsapda a modális bannerekben

Ha a banner blokkolja az oldal többi részével való interakciót, a billentyűzetfókuszt a banneren belül kell tartani, amíg a felhasználó döntést nem hoz. A felhasználóknak ne legyen lehetőségük Tab-bal kilépni a bannerből és görgeti az alatta lévő oldalt. Ha a fókuszt bezárták és a banner bezárul, a fókusznak vissza kell térnie a bannert kiváltó elemre vagy egy ésszerű alapértelmezetthez.

Képernyőolvasói bejelentések

A bannert párbeszédablakként kell bejelenteni, hozzáférhető névvel és szereppel. Használja a `role="dialog"` vagy `role="alertdialog"` attribútumot `aria-labelledby` hivatkozással a banner fejlécére és `aria-describedby` hivatkozással a magyarázó szövegre.

Színkontraszt

A törzsszövegnek 4,5:1 kontrasztot kell elérnie a háttérrel szemben; a nagy szövegnek (18pt+ vagy 14pt félkövér) 3:1 szükséges. A gombszöveg, az ikonok és a fókuszjelzők mind saját kontrasztminimumokkal rendelkeznek. Egy világosszürke „Elutasítás" gomb fehér háttéren az auditok során gyakran látott WCAG-hiba.

Nem csak szín alapú jelzések

Ne hagyatkozzon kizárólag a színre az Elfogadás és Elutasítás megkülönböztetéséhez. Használjon eltérő feliratokat, ikonokat vagy alakzatokat, hogy a színvak felhasználók is megkülönböztethessék a gombokat.

Sötét minták és akadálymentesítés

A WCAG 2.2 új kritériumokat vezet be, amelyek közvetlenül a sötét mintákat célozzák — különösen releváns a hozzájárulás szempontjából:

• 3.3.8 Akadálymentes hitelesítés — tiltja a kognitív rejtvényeket hozzájárulási akadályként.
• 3.3.7 Redundáns bevitel — a felhasználóknak ne kelljen újra megadni adatokat csak a hozzájárulás visszavonásához.
• 2.4.11 Fókusz nem takart — maga a banner ne takarja el a mögötte lévő elemek fókuszjelzőjét.
• 2.5.7 Húzós mozgások — ha a banner húzással elfogadható interakciót alkalmaz, egymutatos alternatívának kell létezni.

RTL és internacionalizáció

Az akadálymentesítés kiterjed a jobbról balra írt nyelvekre (arab, héber, perzsa, urdu) és a képernyőolvasó kiejtésre:

• Állítsa be a `dir="rtl"` attribútumot a banneren, ha a dokumentum nyelve RTL, hogy a gombok sorrendje és a fókuszáramlás megfeleljen az olvasási iránynak.
• Használjon megfelelő `lang` attribútumokat a lefordított banner szövegein, hogy a képernyőolvasók a helyes fonetikával ejtsék a szavakat.
• Tükrözze az ikonográfiát — a sávok, nyilak és folyamatjelzők RTL területi beállításoknál tükröződjenek.

Banner tesztelése WCAG-megfelelőség szempontjából

Ne hagyatkozzon egyetlen eszközre. Kombinálja az automatizált ellenőrzést valódi segédtechnológiai teszteléssel:

• axe DevTools vagy Lighthouse — automatikusan a WCAG-hibák kb. 30-40%-át fogja meg.
• NVDA vagy JAWS Windows rendszeren, VoiceOver Mac/iOS rendszeren, TalkBack Android rendszeren — tesztelje valódi képernyőolvasókkal. A bannert be lehet-e jelenteni, navigálni és bezárni kizárólag a képernyőolvasó segítségével?
• Csak billentyűzetes navigáció — húzza ki az egeret. Ha nem tud Elfogadni, Elutasítani és beállításokat kezelni, billentyűzetes felhasználók sem tudnak.
• Színvakság-szimuláció — a Chrome DevTools beépített látáshiány-szimulátorokat tartalmaz. Ellenőrizze, hogy az Elfogadás és Elutasítás megkülönböztethető-e protanopia, deuteranopia és tritanopia esetén.
• 400%-os nagyítás — a WCAG megköveteli, hogy a tartalom 400%-os nagyításnál is használható maradjon vízszintes görgetés nélkül. A rögzített pozíciójú bannerek gyakran megbuknak ezen a teszten.

Gyakran látott akadálymentesítési hibák

• Elutasítás egy fogaskerék ikon mögé rejtve — sötét minta és akadálymentesítési hiba egyszerre (az ikonon nincs hozzáférhető név).
• A fókusz soha nem éri el a bannert — bannerek, amelyek vizuális figyelmet vonzanak, de kimaradnak a Tab-sorrendből.
• Modális banner fókuszcsapda nélkül — a felhasználók Tab-bal a háttéroldalt érhetik el, miközben a banner állítólag blokkolja az interakciót.
• Nincs `aria-live` a beállítások változásainál — a képernyőolvasó-felhasználók nem hallják a megerősítést, hogy döntésük elmentésre került.
• Lefordított bannerek `lang` attribútum nélkül — a képernyőolvasók angol fonetikával ejtik a spanyol szövegeket.

Hogyan biztosítja a FlexyConsent az akadálymentesítést?