Waarom een 100% toegankelijkheidsscore je website niet automatisch toegankelijk maakt

Alt-teksten zijn niet altijd bruikbaar

Automatische tools controleren of afbeeldingen een alt-attribuut hebben, maar ze beoordelen niet of de alternatieve tekst daadwerkelijk beschrijft wat er op de afbeelding staat.

Voorbeeld

Je hebt een afbeelding van een goudvis met alt="foto123”. De tool keurt dit goed, want het alt-attribuut is aanwezig. Inhoudelijk klopt dit echter niet. De tekst zegt niets over wat op de afbeelding te zien is. Dit is juist het doel van de alternatieve tekst: beschrijven wat de afbeelding weergeeft. Tools controleren alleen de aanwezigheid van een alternatieve tekst, niet de inhoudelijke betekenis ervan.

Koppenstructuur: juiste code, verwarrend voor mensen

Testtools kunnen controleren of er koppen zijn, maar niet of de structuur logisch is.

Voorbeeld 1

Een pagina begint met <h3> gevolgd door een <h1>, dan een <h5>. Een tool keurt dit goed, maar voor screenreader-gebruikers is het verwarrend. De hiërarchie ontbreekt, wat het moeilijk maakt om de structuur te begrijpen. Een goede koppenstructuur is als de inhoudsopgave van je website. Tools zien alleen de hoofdstukken, niet of ze op volgorde staan.

Voorbeeld 2

Een ander voorbeeld: het ontbreken van koppen. Met enkel een CSS kan een <div> vormgegeven worden als kop. Een als kop vormgegeven <div> wordt door tools niet als kop herkend, omdat er semantisch geen sprake is van een kop.

Links en knoppen: zichtbaar, maar niet duidelijk

Zolang een link of knop klikbaar is, beschouwen automatische tools die als 'toegankelijk'. Maar ze beoordelen niet of de tekst begrijpelijk is.

Voorbeeld

“Lees meer”, “klik hier”, “bekijk dit”. Zonder visuele context weet een screenreader-gebruiker niet waar deze links naartoe gaan of wat de knop precies doet. Lees meer, maar waarover? Klik hier, maar waar is “hier" als je niks kunt zien? Bekijk dit, maar wat ga je dan bekijken? Automatische testen kunnen de context van een link of knop niet begrijpen, daar is menselijk inzicht voor nodig.

Formulieren: visueel gelabeld, technisch niet

Een veld met een zichtbaar label zoals “Naam” lijkt prima, maar als dat label niet goed gekoppeld is via het for-attribuut, weet een screenreader niet bij welk veld het label hoort.

Voorbeeld

<label>Naam:</label>
<input type="text">

Visueel ziet dit er goed uit. Er is een tekstje “naam” met daaronder een invoerveld waar je je naam in kunt vullen. Voor screenreader gebruikers is echter niet duidelijk dat “naam” hoort bij het invoerveld eronder, omdat het label technisch niet met een for="id" is verbonden met het invoerveld. Automatische tools kunnen deze mismatch missen.

Toetsenbordnavigatie: technisch bereikbaar, praktisch frustrerend

Lighthouse toetst of je met het toetsenbord kunt navigeren, maar niet of dit logisch en bruikbaar is.

Voorbeeld 1

Bij het openen van een website opent er een cookie pop-up. Een toetsenbordgebruiker navigeert door elementen binnen de pop-up. Bij het laatste item verdwijnt de focus naar de standaardpagina, achter de pop-up. De pop-up is niet sluitbaar met de ESC toets. Hierdoor is de website onbruikbaar, omdat de pop-up in het zicht blijft staan.

Voorbeeld 2

De tabvolgorde is onlogisch. De focus springt van boven naar beneden, weer terug naar boven, van rechts naar links. De focus gaat alle kanten op. De visuele en technische volgorde sluiten niet op elkaar aan. Automatische tools ‘voelen’ deze verwarring niet, gebruikers wel.

Conclusie

Automatische testtools zijn een waardevolle eerste stap, maar missen wat echt telt: de menselijke ervaring. De testtools kunnen inhoud, betekenis en gebruikservaring (nog) niet beoordelen. Echte toegankelijkheid bereik je alleen door te testen met mensen: met een toetsenbord, met een screenreader, met gebruikers met een beperking of gewoon met een kritische blik.