Hoe schermlezers een website echt navigeren (en waarom dat uw kijk op verbeteringen verandert)

Veel bevindingen in een toegankelijkheidsrapport („ontbrekende alt-tekst", „kopniveaus springen van h2 naar h4", „knop heeft geen toegankelijke naam") lezen als willekeurig regels volgen, totdat u begrijpt wat een schermlezer eigenlijk met uw pagina doet. Zodra u dat weet, voelen de meeste bevindingen niet meer willekeurig.

De pagina wordt niet van boven naar beneden gelezen als een document

Een ziende bezoeker scant een pagina visueel – de ogen springen meteen naar een grote kop, een opvallende knop, een vertrouwde navigatiebalk, geleid door lay-out en visuele hiërarchie. Een schermlezergebruiker heeft die visuele snelkoppeling niet. In plaats daarvan presenteren schermlezers de pagina als een gestructureerde boom die is opgebouwd uit de onderliggende HTML: koppen, landmarks (zoals „navigatie", „hoofdinhoud", „voettekst"), links, formuliervelden en knoppen, elk met een naam en een rol. Schermlezergebruikers navigeren rechtstreeks door die boom – van kop naar kop, van landmark naar landmark of van link naar link – met speciale sneltoetsen, in plaats van te scrollen en te scannen zoals een ziende bezoeker.

Daarom is de kopstructuur veel belangrijker dan het lijkt. Een ziende gebruiker werpt een blik op een pagina en begrijpt direct: „dat is de belangrijke titel, dat is een subsectie". Een schermlezergebruiker die tussen koppen springt voor een overzicht van een pagina, is volledig afhankelijk van een logische volgorde van uw h1- tot h6-tags – springt u van een h2 direct naar een h4, dan is er visueel niets stuk, maar u hebt wel de kaart verbroken waarop een schermlezergebruiker vertrouwt om de paginastructuur te begrijpen.

De „toegankelijke naam" doet veel werk

Elk interactief element – een knop, een link, een formulierveld – heeft een zogeheten toegankelijke naam nodig: de tekst die een schermlezer voor dat element daadwerkelijk voorleest. Soms is die vanzelfsprekend (een knop met de tekst „Verzenden" heeft „Verzenden" als toegankelijke naam). Maar een knop met alleen een icoon (een vergrootglas voor zoeken, een prullenbak voor verwijderen) heeft helemaal geen zichtbare tekst – heeft hij geen aria-label of vergelijkbaar attribuut, dan leest een schermlezer alleen „knop" voor, zonder enige aanwijzing wat hij doet. Dit is een van de meest voorkomende bevindingen bij echte audits, en het is volledig onzichtbaar als u alleen naar de pagina kijkt, omdat het icoon visueel „vanzelfsprekend" zoeken of verwijderen betekent.

Waarom alt-tekst meer is dan „het beeld beschrijven"

Alt-tekst bestaat juist omdat een schermlezer een afbeelding niet kan interpreteren zoals een ziend mens – hij kan alleen de tekst voorlezen die u als vervanging hebt opgegeven. Goede alt-tekst beschrijft de functie of inhoud van de afbeelding in context, niet een algemeen onderschrift: een puur decoratieve afbeelding hoort lege alt-tekst te hebben (alt=""), zodat een schermlezer hem helemaal overslaat in plaats van iets onbruikbaars als „image1234.jpg" voor te lezen; een productfoto die de enige bron van informatie is over de kleur of het ontwerp van een product, heeft echte, specifieke alt-tekst nodig; een afbeelding die als knop dient (bijvoorbeeld een social-media-icoon dat naar uw Twitter/X-pagina linkt) heeft alt-tekst nodig die de actie beschrijft, niet het icoon („Volg ons op X", niet „vogellogo").

De praktische les

Niets hiervan vereist dat u de technische taal van WCAG uit het hoofd leert. Het vraagt één mentale omslag: vraag uzelf voordat u een bevinding herstelt af: „wat zou een schermlezergebruiker hier daadwerkelijk ervaren, op basis van de structurele informatie in de code, niet van de visuele lay-out?" Het meeste van wat in een rapport verschijnt – kopvolgorde, toegankelijke namen, alt-tekst, formulierlabels – komt terug op diezelfde onderliggende vraag. Bekijk een echte uitsplitsing van de WCAG-criteria per principe, of controleer uw website gratis om te zien wat een scan op uw eigen site daadwerkelijk vindt.