Website toegankelijk maken

Ik gebruik de beschikbare tools, en AI is daar één van. Duizend pagina's nakijken op contrast doet een machine nou eenmaal sneller en beter dan ik.

Maar geen van die tools, inclusief AI, weet waaróm iets op je pagina staat. Een LLM als ChatGPT of Claude kan inmiddels bijvoorbeeld prima beschrijven wat er op een foto te zien is. Alleen vraagt diezelfde foto om een andere alt-tekst als het een link is, als het een grafiek samenvat, of als het puur versiering is. Dat is context die een mens controleert.

Dus doorloop ik je pagina's daarnaast met alleen een toetsenbord, en luister ik wat een screenreader ervan maakt. Waar je mij voor inhuurt is niet het aanzetten van een tool. Het is weten welke oplossing bij welk probleem hoort, die uitvoeren, en met de hand vaststellen dat het klopt.

Zo'n ding heet ook wel een accessibility widget of een accessibility overlay. Die legt een laagje over je site heen; de code eronder verandert niet. Voor mensen die een screenreader gebruiken pakt dat vaak slechter uit, want de widget gaat de strijd aan met de software die ze al hebben. En de wet kijkt naar je website, niet naar het knopje ervoor. Een widget kan hooguit wat kleuren bijstellen. Structuur, formulieren en focus moeten in de code. Daar begin ik dus.

Geen officiële term, maar je hoort hem veel. Wat er meestal mee bedoeld wordt: voldoet de site aan WCAG 2.1 AA, het niveau waar de wet naar verwijst.

Er is geen knop die het aanzet, en geen stempel die de wet van je vraagt. Een keurmerk bestaat wel, het waarmerk drempelvrij.nl, maar dat is vrijwillig. Wat de wet wel wil is dat je kunt uitleggen hoe je site ervoor staat, onderbouwd met een toegankelijkheids­onderzoek. Vraagt iemand of je site wcag proof is, dan vraagt hij eigenlijk of je het kunt aantonen.

Omdat het iets anders is. Een toegankelijkheids­onderzoek volgt de WCAG-EM-methode: een vastgestelde steekproef van pagina's, alle vijftig succescriteria van niveau A en AA, per criterium onderbouwd met bewijs, in een rapport dat een toegankelijkheids­verklaring kan dragen. Dat is veel werk, en dat werk lever ik niet.

Ik kijk naar de code. Axe en AI halen eruit wat meetbaar is, en daarnaast loop ik met de hand na hoe je koppenstructuur in elkaar zit, of je links en tabellen kloppen, wat een screenreader ervan maakt, en of alles met het toetsenbord te bedienen is: tabvolgorde, focus, roving tabindex.

Wat ik dus niet doe: je teksten beoordelen, je video's op ondertiteling nakijken, of je pdf's langslopen. Die punten komen wel op de werklijst te staan, met wie ze het beste oppakt erbij.

De € 750 gaat van de prijs van het oplossen af. Laat je mij het werk doen, dan heeft de doorlichting je uiteindelijk niets gekost. Een onderzoek wordt nergens van afgetrokken.

En je hebt niet altijd een onderzoek nodig. Dat is er vooral voor de toegankelijkheids­verklaring die overheden moeten publiceren. Speelt dat bij jou niet, dan is dit gewoon het hele traject.

Moet je die verklaring wél publiceren, dan is de volgorde de vraag. Staat je site er waarschijnlijk redelijk voor? Laat dan eerst het onderzoek doen: je krijgt het document en de bevindingen in één keer, en met die lijst kun je direct bij mij terecht. Weet je al dat er veel mis is, dan werkt die volgorde tegen je. Een onderzoek meet, het repareert niets. Je betaalt dan om te horen wat je al vermoedde, daarna om het te laten oplossen, en vaak nog een derde keer voor een hertest. Eerst repareren en dan één keer laten onderzoeken scheelt je een ronde.

Ja, als er concrete bevindingen in staan: welk succescriterium, en waar op de site. Dan heb ik de werklijst al. Ik lees het rapport door, zet er uren bij, en je krijgt een offerte voor het oplossen. Staat er alleen dat de formulieren niet toegankelijk zijn, zonder aan te wijzen welke en waarom, dan moet ik het alsnog uitzoeken.

Nee. Die publiceer je zelf, over je eigen website (wat erin staat en wat de statussen betekenen), en hij hoort te steunen op een onderzoek volgens de WCAG-EM-methode. Dat onderzoek doe ik niet, en daar wil je ook liever iemand voor die niet zelf de code heeft geschreven. Wat ik lever is het werk dat eraan voorafgaat: de punten opgelost, zodat zo'n onderzoek straks weinig meer te vinden heeft.

Ja. Het systeem bepaalt dit niet. Toegankelijkheid zit in de HTML die je bezoeker uiteindelijk krijgt, en die komt uit je thema, je templates, je plugins of je componenten. WordPress, Laravel, Symfony, Drupal, Statamic: het werk is hetzelfde. Draait je site op WordPress en heb je daar ook iets op maat nodig? Dat doe ik ook: WordPress maatwerk.

Ook maatwerk React-componenten pak ik aan, en daar zit vaak juist het probleem. Een zelfgebouwde dropdown, modal of tab-set werkt met de muis prima, en met een toetsenbord niet. Zulke componenten vallen buiten het bereik van de meeste toegankelijkheids­bureaus.

Waar we tegen een grens lopen is code waar je zelf niet bij kunt, zoals een gesloten plugin van iemand anders. Dat zeg ik dan meteen.

Nee, dat is eerder regel dan uitzondering. Ik werk in de code die er ligt, ook als ik hem niet heb geschreven. Wel heb ik toegang nodig tot de repository of een omgeving waar ik veilig kan werken. Mijn wijzigingen lever ik zo aan dat jouw bureau ze kan nakijken en zelf kan uitrollen. Willen zij het liever helemaal zelf doen? Ook goed. Dan doe ik de doorlichting en pakken zij de lijst op.