Accessibility score 100% - Digitale toegankelijkheid

Hoe wij onze website 100% WCAG AA-compliant hebben gemaakt met digitale toegankelijkheid

Europese toegankelijkheidswet (European Accessibility Act) en e-commerce

In 2025 wordt de European Accessibility Act (EAA) ingevoerd. Deze wet digitale toegankelijkheid verplicht e-commerce bedrijven zoals webshops om te voldoen aan de toegankelijkheidsrichtlijnen (WCAG 2.2). Wat de gevolgen zullen zijn voor deze bedrijven is op dit moment nog niet bekend, maar de kans is zeer groot dat er op termijn boetes uitgedeeld gaan worden aan bedrijven die hun digitale toegankelijkheid niet op orde hebben.

Onze klanten en de verplichtingen van WCAG 2.2

Aangezien het bouwen van webshops één van onze belangrijkste bezigheden is, krijgen onze eigen klanten ook te maken met deze nieuwe wetgeving. Om deze en toekomstige e-commerce partners goed van dienst te kunnen zijn bij het toegankelijk maken van hun webshop of website, hebben we onszelf volledig ondergedompeld in de wereld der accessibility en, als eerste stap in de goede richting, onze eigen site volledig binnenstebuiten gekeerd en aangepast. In deze blog post lees je wat we hebben gedaan om 100% toegankelijk te worden en wat Digital KISS voor jouw e-commerce platform kan betekenen op het gebied van toegankelijkheid.

Wat is website toegankelijkheid (accessibility)?

Voor we inzoomen op het toegankelijk maken van onze eigen website is het belangrijk om te begrijpen wat er wordt bedoeld met accessibility.

Zoals het voor iemand in een rolstoel belangrijk is ook gewoon een supermarkt of een willekeurige winkel in de winkelstraat te kunnen bezoeken, moet iemand met bijvoorbeeld een visuele, fysieke of neurologische functiebeperking ook jouw website kunnen gebruiken en iets kunnen afrekenen in jouw webshop. In de woorden van de Web Content Accessibility Guidelines (WCAG): een website moet voor iedereen waarneembaar, bruikbaar, begrijpelijk en robuust zijn.

Hiervoor zal deze persoon misschien gebruik maken van screen reader software die de content van de website voorleest, of alleen het toetsenbord gebruiken om door de site heen te navigeren. Een ander zal alle bewegende of knipperende elementen op je site willen uitzetten omdat deze zorgen voor misselijkheid of een epileptische aanval en weer iemand anders zal het kleurencontrast willen aanpassen vanwege een oogafwijking.

Voor al deze mensen – en dan hebben we het over meer dan een kwart van de Europese volwassen bevolking – zijn de meeste e-commerce platformen niet goed toegankelijk. Veel van de benodigde functionaliteiten zitten niet standaard in een website ingebakken, ontwikkelaars vergeten deze te implementeren of erger: ze overrulen deze functionaliteiten met hun styling omdat zij zelf vooral oog hebben voor hoe een site er voor de meeste bezoekers uitziet en functioneert.

We moeten toegeven: ook wij van Digital KISS hebben tot nu toe weinig rekening gehouden met eindgebruikers met een functiebeperking, dus let’s stop talking the talk and let’s walk the walk!

Wat houden de WCAG-richtlijnen in?

Voor we onze eigen website onder een kritisch toegankelijkheidsvergrootglas konden leggen, moesten we zelf natuurlijk ook wel weten hoe en wat. In de eerdergenoemde Web Content Accessibility Guidelines (WCAG), geschreven en onderhouden door de werkgroep Web Accessibility Initiative (WAI) van het World Wide Web Consortium (W3C), staat precies uitgewerkt wat de richtlijnen precies inhouden, wat de succescriteria zijn en, niet onbelangrijk, welke technieken we tot onze beschikking hebben om ontoegankelijke onderdelen op een pagina toegankelijk te maken voor mensen met een beperking.

In totaal zijn er op dit moment 87 verschillende succescriteria gedefinieerd en bestaan sommige van deze criteria ook weer uit verschillende aandachtspunten, dus dat leverde genoeg huiswerk op. Gelukkig is het ene succescriterium het andere niet. Er wordt namelijk onderscheid gemaakt tussen level A-, AA- en AAA-criteria, waarbij A staat voor het laagste, meest essentiële niveau en AAA voor het hoogste niveau wat je qua toegankelijkheid kunt nastreven. De European Accessibility Act schrijft voor dat (middel)grote e-commerce bedrijven toegankelijkheidsniveau AA moeten hebben, dus over de meest strenge criteria hoefden we ons voor nu niet te buigen.

Er bleven echter genoeg criteria over waar bij het testen van onze website wel op gelet moest worden, zoals:

  • Klopt de koppenstructuur binnen de pagina’s? De koppen zijn de dikgedrukte, grote titels bovenaan de pagina, aan het begin van elke sectie binnen een pagina en alle sub-secties die daar weer onder vallen, enzovoorts... (Google vindt het ook belangrijk dat de koppenstructuur op orde is, dus het was sowieso de moeite om die eens kritisch tegen het licht te houden)
  • Zijn alle interactieve onderdelen zoals knoppen, links en formuliervelden ook te bereiken en te herkennen als je gebruikmaakt van screen reader software of de tabtoets op je keyboard?
  • Als een blind of slechtziend iemand langs een belangrijke afbeelding (foto, infographic, etc.) komt, wordt er dan voorgelezen wat er op deze afbeelding staat?
  • Is het mogelijk om bewegende onderdelen te pauzeren of helemaal te stoppen?

Onze checklist voor website toegankelijkheid (WCAG 2.2)

Om systematisch te werk te kunnen gaan met alle WCAG 2.2 A- en AA-criteria hebben we deze in een checklist gegoten. Deze checklist diende als uitgangspunt voor de interne audit die we bij onszelf zouden afnemen en die ons een duidelijk beeld zou moeten geven van de punten die op onze eigen website verbeterd moesten worden.

Accessibility testen: devtools en andere hulpmiddelen

Voor het testen hadden we een aantal hulpmiddelen voor handen. Webdevelopers maken bij het ontwikkelen van een site doorgaans veel gebruik van devtools: een programmaatje dat is ingebouwd in browsers zoals Chrome, Firefox of Safari. Met devtools kan een developer onder andere de HTML-code (HyperText Markup Language: de fundamentele opmaaktaal waarmee een website is gebouwd) inspecteren die de browser gebruikt om een site te tonen. Deze code geeft op het geoefende blote oog al veel prijs over hoe (on)toegankelijk een website is, dus bij het doorlopen van de checklist stond devtools bijna permanent open.

Daarnaast kun je in devtools speciale plugins aan het werk zetten die een site scannen op bijvoorbeeld het juiste gebruik van heading tags (de eerdergenoemde koppen van een pagina), het kleurgebruik (of er genoeg contrast is tussen de achtergrondkleur en de kleur van de letters) en of interactieve onderdelen goed bereikbaar zijn.

Voor gebruikers die om wat voor reden dan ook niet met een muis kunnen navigeren, hebben we getest of de site met de tabtoets op het toetsenbord goed te bezoeken is. Daarbij is het belangrijk dat het zichtbaar is welk element op dat moment tab focus heeft. Vaak is dit te herkennen aan een ring in een afwijkende kleur die om het element heen verschijnt. Ook is de volgorde van belang: ‘tabben’ moet in een logische volgorde gebeuren, van links naar rechts en van boven naar beneden. En er mogen uiteraard geen interactieve elementen overgeslagen worden.

Blinden en slechtzienden gebruiken doorgaans een hulpmiddel dat de content van een website voorleest. Met VoiceOver, het programma wat op een Apple computer hiervoor de standaard is, hebben we zelf de proef op de som genomen. Het vergde wat oefening om VoiceOver onder de knie te krijgen, maar leerde ons uiteindelijk een hoop over mogelijke verbeterpunten.

Last but not least hebben we onze website ook getest op zijn bewegende en knipperende onderdelen omdat deze, zoals eerder vermeld, bij bezoekers kunnen zorgen voor misselijkheid of een epileptische aanval.

Score van 100% accessibility

Resultaten van onze accessibility audit en verbeterpunten

De uitkomsten van ons testonderzoek hadden we grotendeels al zien aankomen. We lieten eerder al doorschemeren dat we zelf weinig oog hadden voor bezoekers met een functiebeperking, en dat blijkt ook wel uit de ingevulde checklist. Onze website werkt voor de grootste groep gebruikers – zij die gebruik maken van hun ogen en een muis om te navigeren - helemaal prima. Voor andere bezoekers is het echter een stuk moeilijker om op een prettige manier de website te gebruiken. Eén van de gebruikte devtools plugins, Lighthouse, onderschrijft deze conclusie: we krijgen een gemiddelde accessibility-score van 85%. Klinkt hartstikke goed, maar het zijn juist die laatste 15% die voor bepaalde bezoekers de drempel vormen om een website te kunnen gebruiken.

Hieronder een aantal bevindingen:

  • Onze koppenstructuur leek regelrecht uit een spaghettiwestern te zijn gerukt: iedere pagina had wel zijn sheriff (een H1, oftewel heading level 1: de top dog onder de koppen), maar daaronder was het een wetteloze schietkraam vol outlaws die zich hadden vermomd als brave gezagsgetrouwe burgers. Om niet helemaal te verdwalen in deze vergezochte metafoor: de conclusie was dat onze koppenstructuur wel iets meer… structuur kon gebruiken.
  • Iets anders dat opviel was iets dat juist niét opviel. Aan elementen die via de tabtoets focus kregen was namelijk bijna nergens te zien dat zij daadwerkelijk focus hadden. De ring in een afwijkende kleur ontbrak bijna overal, en waar deze wel aanwezig was, werd deze om onverklaarbare redenen in het lichtlila getoond. Verder was het vooral gissen welk element op dat moment focus had.
  • Als je onze website via de homepage bezoekt, word je oog direct naar een verspringende, eindeloos variërende koptekst getrokken. Als je vervolgens naar beneden scrolt, beginnen er elementen weg te draaien, verspringt de pagina van licht naar donker en weer terug en komen er teksten en foto’s en vlakken inschuiven… Allemaal supervet, tenzij al die bewegingen en knipperende tekst een epileptische aanval of misselijkheid bij je veroorzaken. Hoewel dergelijke animaties grotendeels onder level AAA van de WCAG 2.2 vallen, hebben we de site hier wel op gecontroleerd. Iets dat zo’n impact heeft op een gebruikers fysieke toestand, is wat ons betreft niet te negeren.

Deze en vele andere kleine en grote punten leverden een waslijst van verbetermogelijkheden op waarmee we vervolgens aan de slag konden.

Formulieren met user error handling

De verbeteringen die onze website WCAG AA-compliant maken

In een paar dagen tijd hebben we met chirurgische precisie alle verbeterpunten aan onze website doorgevoerd, waarbij de ene aanpassing makkelijker of sneller te implementeren was dan de andere.

Zo kostte het verbeteren van de toegankelijkheid van onze contactformulieren best wat extra aandacht: om deze ook voor blinden en slechtzienden goed bruikbaar te maken, moesten deze bijna volledig opnieuw gebouwd worden. Als je nu in formulier een fout maakt, word je in al dan niet gesproken tekst gewezen op de velden die je bent vergeten in te vullen en kun je via een directe link naar zo’n veld toe. Ook moest er aangepast worden hoe de gebruiker feedback krijgt na het versturen van een formulier. Waar we eerder werkten met een simpele pop-up die na een paar seconden weer verdween, wordt deze feedback nu permanent getoond en door screen reader software voorgelezen.

Een andere vereiste is dat er een mechanisme beschikbaar is om blokken content die op meerdere webpagina's worden herhaald te omzeilen, ook wel bekend als een skip-to-content-link. Die hadden we uiteraard nog niet, dus die hebben we toegevoegd. Als je nu met de tabtoets door de site gaat, is de eerste link waar je op komt zo’n skip-to-content-link. Deze brengt je direct naar de hoofdinhoud van een pagina, in plaats van dat je iedere keer het volledige navigatiemenu bovenaan de pagina moet doorklikken.

De tabtoetsgebruikende bezoeker kan sowieso opgelucht ademhalen, want alle focusbare elementen zoals knoppen en links beschikken nu over dezelfde, duidelijk zichtbare focus-ring, dus verdwalen is zo goed als geen optie meer.

Verder zijn alle bewegende, knipperende en van kleur veranderende onderdelen door de gebruiker uit te zetten. Dit gebeurt door in de systeeminstellingen van zijn device verminderde beweging in te schakelen. De site zal dan automatisch overschakelen naar stilstaande versies, zonder verlies van content.

Ook het kleurgebruik van knoppen en tekst vroeg om onze aandacht: de contrast-ratio van de witte tekst op de gekleurde knoppen en de gekleurde tekst op de witte achtergrond was te laag. Deze kleur dan maar aanpassen zorgde echter voor een dilemma: het ging hier om één van onze brand colors, een kleur die bepalend is voor Digital KISS als merk en die we online en in ons drukwerk overal gebruiken. De oplossing bleek een compromis: gebruikers die in hun systeeminstellingen verhoogd contrast hebben ingeschakeld, krijgen een donkerdere versie van deze kleur te zien. Alle andere gebruikers zien de originele kleur.

Zonder verhoogd contrast ingeschakeld rolt er bij Lighthouse een accessibility-score van 96% uit, maar mét deze optie ingeschakeld is onze website inmiddels 100% accessible!

Jouw website WCAG AA compliant maken

Met alle opgedane kennis en vaardigheden in onze achterzak is het voor Digital KISS inmiddels een koud kunstje om ook jouw website of webshop naar een hoger toegankelijkheidsniveau te tillen. Want zeg nou zelf: op een boete zit je als bedrijf niet te wachten. Buiten dat moet dat kwart van de Europese bevolking met een beperking toch ook gewoon de producten in jouw webshop op een bevredigende manier kunnen afrekenen, en jouw website bezoeken zonder dat het frustraties oplevert?

Benieuwd geworden naar wat Digital KISS precies voor de toegankelijkheid van jouw platform kan betekenen? Neem dan contact met ons op voor advies op maat.

Wil je een laten ontwikkelen? Plan een informeel gesprek met ons in!