Miksi saavutettavuus ja suostumus nyt limittyvät

GDPR edellyttää, että suostumus voidaan saada jokaiselta käyttäjältä, ei vain niiltä, jotka voivat nähdä bannerin ja klikata sitä. Euroopan tietosuojaneuvosto on selventänyt, että jos rekisteröity ei voi merkityksellisesti olla vuorovaikutuksessa suostumuskäyttöliittymän kanssa — vamman vuoksi, jota sivusto ei ole huomioinut — suostumusta ei ole saatu pätevästi. Tämä tarkoittaa, että evästeitä ei olisi koskaan pitänyt ladata.

Saavutettavuuden puolella Euroopan saavutettavuuslaki (EAA), joka on saatettu kansalliseksi laiksi kaikissa EU:n jäsenvaltioissa, tekee WCAG 2.1 AA:sta vähimmäisvaatimuksen yksityisen sektorin verkkosivustoille ja sovelluksille, jotka tarjoavat kuluttajapalveluja. Seuraamusjärjestelmä vaihtelee maittain, mutta tyypillisesti se vaihtelee 50 000 ja 500 000 euron välillä rikkomusta kohden, ja lisäksi markkinoilta poistamismääräyksiä jatkuvasta noudattamatta jättämisestä.

WCAG:n perusvaatimukset evästebannereille

Näppäimistöllä operointi

Jokainen bannerin ohjauselementti — Hyväksy, Hylkää, Hallitse asetuksia, sulje — on oltava saavutettavissa ja käytettävissä pelkällä näppäimistöllä. Käyttäjien pitäisi pystyä liikkumaan Tab-näppäimellä painikkeissa loogisessa järjestyksessä ja aktivoimaan ne Enter- tai Space-näppäimellä. Fokuksen on oltava näkyvä vähintään 3:1-kontrastisuhteella taustaa vasten.

Fokuksen ansaitseminen modaalisissa bannereissa

Jos banneri estää vuorovaikutuksen muun sivun kanssa, näppäimistön fokuksen on oltava loukkuun bannerin sisällä, kunnes käyttäjä tekee valinnan. Käyttäjien ei pitäisi pystyä liikkumaan Tab-näppäimellä bannerin ulkopuolelle vierittääkseen alla olevaa sivua. Kun fokus oli loukkuun ja banneri sulkeutuu, fokuksen pitäisi palata elementtiin, joka käynnisti bannerin, tai järkevään oletukseen.

Ruudunlukijan ilmoitukset

Banneri on ilmoitettava valintaikkunana, jolla on saavutettava nimi ja rooli. Käytä `role="dialog"` tai `role="alertdialog"` `aria-labelledby`:lla osoittaen bannerin otsikkoon ja `aria-describedby`:lla osoittaen selittävään tekstiin.

Värikontrasti

Tekstin on täytettävä 4,5:1-kontrasti taustaa vasten; suurella tekstillä (18 pistettä+ tai 14 pistettä lihavoitu) tarvitaan 3:1. Painikkeen tekstillä, kuvakkeilla ja fokusindikaattoreilla on kaikilla omat kontrastin vähimmäisvaatimuksensa. Vaaleanharmaa "Hylkää"-painike valkoisella taustalla on yleinen WCAG-virhe, jonka näemme tarkastuksissa.

Pelkästään värivihjeiden välttäminen

Älä luota pelkästään väriin Hyväksy- ja Hylkää-painikkeiden erottamiseen. Käytä erillisiä nimikkeitä, kuvakkeita tai muotoja, jotta värisokeat käyttäjät voivat erottaa painikkeet toisistaan.

Tummat kuviot ja saavutettavuus

WCAG 2.2 esittelee uusia kriteerejä, jotka kohdistuvat suoraan tummiin kuvioihin — erityisesti suostumuksen osalta:

• 3.3.8 Saavutettava todennus — kieltää kognitiiviset pulmat suostumuksen esteenä.
• 3.3.7 Tarpeeton syöttö — käyttäjien ei pitäisi joutua syöttämään tietoja uudelleen vain peruuttaakseen suostumuksen.
• 2.4.11 Fokus ei peitettynä — banneri itsessään ei saa peittää taustalla olevien elementtien fokusindikaattoria.
• 2.5.7 Vetämisliikkeet — jos banneri käyttää vedä-hyväksy-vuorovaikutusta, yksiosoittiminen vaihtoehto on oltava.

RTL ja kansainvälistyminen

Saavutettavuus ulottuu oikealta vasemmalle -kieliin (arabia, heprea, persia, urdu) ja ruudunlukijan ääntämiseen:

• Aseta `dir="rtl"` banneriin, kun asiakirjan kieli on RTL, jotta painikkeiden järjestys ja fokuksen kulku vastaavat lukusuuntaa.
• Käytä oikeita `lang`-attribuutteja käännetylle bannerin kopiolla, jotta ruudunlukijat lausuvat sanat oikealla fonetiikalla.
• Peilaa ikonografia — nuolet ja edistymispalkit pitäisi kääntää RTL-kielillä.

Bannerin testaaminen WCAG-vaatimustenmukaisuuden osalta

Älä luota yhteen työkaluun. Yhdistä automaattinen skannaus todellisella apuvälinetestauksella:

• axe DevTools tai Lighthouse — havaitsee automaattisesti noin 30–40 % WCAG-virheistä.
• NVDA tai JAWS Windowsilla, VoiceOver Mac/iOS:lla, TalkBack Androidilla — testaa todellisilla ruudunlukijoilla. Voidaanko banneri ilmoittaa, navigoida ja sulkea vain ruudunlukijaa käyttämällä?
• Pelkkä näppäimistönavigointi — irrota hiiri. Jos et voi Hyväksyä, Hylätä ja hallita asetuksia, näppäimistökäyttäjätkään eivät voi.
• Värisokeuden simulaatio — Chrome DevTools sisältää sisäänrakennetut näkökykysimulaattorit. Tarkista, että Hyväksy ja Hylkää ovat erotettavissa toisistaan protanopian, deuteranopian ja tritanopian yhteydessä.
• Zoomaus 400 %:iin — WCAG edellyttää, että sisältö pysyy käytettävänä 400 %:n zoomauksen yhteydessä ilman vaakasuoraa vieritystä. Kiinteässä asennossa olevat bännerit epäonnistuvat usein tässä testissä.

Yleisiä saavutettavuusvirheitä, joita näemme

• Hylkää piilotettu hammasrataskuvakkeen taakse — tumma kuvio sekä saavutettavuusvirhe (kuvakepainikkeella ei ole saavutettavaa nimeä).
• Fokus ei koskaan saavuta banneria — bännerit, jotka varastavat visuaalista huomiota mutta jätetään Tab-järjestyksestä pois.
• Modaali-banneri ilman fokusansaa — käyttäjät voivat liikkua Tab-näppäimellä taustasivulle, kun banneri väittää estävänsä vuorovaikutuksen.
• Asetusmuutoksissa ei ole `aria-live`-attribuuttia — ruudunlukijakäyttäjät eivät kuule vahvistusta, että heidän valintansa tallennettiin.
• Käännetyt bännerit ilman `lang`-attribuuttia — ruudunlukijat lausuvat espanjankielisen tekstin englannin fonetiikalla.

Miten FlexyConsent tarjoaa saavutettavuuden