Is een WCAG-audit de juiste eerste stap?
Geplaats in categorie: BlogGeschreven door
Nooit geen reden voor roze lippenstift
Is een WCAG-audit de juiste eerste stap?
Veel organisaties die serieus werk willen maken van digitale toegankelijkheid, denken dat een toegankelijkheidsaudit of WCAG-audit het enige logische startpunt is. Het is overzichtelijk, het heeft een kop en een staart, en na afloop ligt er een officieel rapport over de toegankelijkheid van de website of app op tafel. Maar als we kijken naar wat er nodig is om een organisatie écht digitaal toegankelijk te maken, is diezelfde audit soms een moeizame start voor je team.
In de praktijk zien we vaak dat een audit wordt ingezet als het beginpunt, terwijl het eigenlijk het slotstuk zou moeten zijn van een groter proces om digitale toegankelijkheid te implementeren.
De audit als instrument (en de verplichte verklaring)
Wat is een onderzoek naar toegankelijkheid eigenlijk? In de kern is het een gestructureerde evaluatie waarbij een expert je platform langs de meetlat van de WCAG-richtlijnen legt. Bij zo’n onderzoek volgen we de WCAG-evaluatiemethode (WCAG-EM). Dit is de wereldwijde standaard op het gebied van digitale toegankelijkheid. In Europa vormt EN 301 549 hierbij het juridische kader: deze norm verwijst naar de WCAG. Momenteel is WCAG 2.2 niveau AA de geldende meetlat.
Sinds de komst van de European Accessibility Act (EAA) is een toegankelijkheidsverklaring voor veel commerciële partijen en e-commercediensten verplicht geworden. In die verklaring moet je eerlijk aangeven in hoeverre je platform voldoet aan de eisen en welke concrete maatregelen je neemt om gebreken op te lossen.
Om die verklaring inhoudelijk te vullen, heb je onderzoek nodig. Maar dat betekent niet automatisch dat je een volledig, officieel WCAG-EM auditrapport van 80 pagina’s nodig hebt om te starten. Je hebt substantie nodig voor je verklaring, maar een zware audit is vaak niet het juiste instrument om verandering binnen je team te realiseren.
Waarom een rapport alleen niet werkt
De gedachte is vaak: “We laten een consultant 50 criteria afvinken, die levert een PDF op en dan weten we wat we moeten fixen.” Maar wat er dan gebeurt, is dat je een technisch en droog document over de schutting gooit bij je designers, developers en content creators.
De moed zakt ze vaak in de schoenen. Niemand wordt enthousiast van een lijst met honderden foutmeldingen zonder context. Een audit constateert fouten achteraf, maar draagt de benodigde kennis niet op een positieve manier over. Toegankelijkheid is een ambacht dat je moet embedden in je dagelijkse workflow, geen invuloefening die je één keer per jaar doet.
Daar komt nog iets bij: zolang toegankelijkheid geen onderdeel is van het dagelijkse proces, ontstaat vrijwel altijd regressie. Oude fouten keren terug, nieuwe features introduceren nieuwe barrières, en het volgende rapport ziet er weer grotendeels hetzelfde uit als het vorige. De audit meet, maar verandert niets aan het systeem dat de fouten veroorzaakt.
Werken vanuit een framework
Door onze ervaring met zowel grote als middelgrote ontwikkelteams zien we dat er effectievere manieren zijn om toegankelijkheid structureel te verbeteren dan starten met een losse audit.
Ons consultancy framework is gebaseerd op de Planning & Managing Web Accessibility gids van de W3C, vertaald naar een pragmatisch model dat aansluit op hoe teams daadwerkelijk werken.
Wat hier het verschil maakt, is onze achtergrond: we ontwerpen en bouwen al ruim twintig jaar complexe digitale platformen, waarvan de laatste tien jaar standaard digitaal toegankelijk. We spreken de taal van designers en developers en weten hoe toegankelijkheid in de praktijk werkt binnen agile omgevingen.
Onze route bestaat uit vier fases:
- Inzicht: Hier gaat het over richting. Wat is het risico? Wat is de ambitie? Wat speelt er intern? Een korte quickscan is hier vaak voldoende om de grootste blokkades zichtbaar te maken. Dit levert meteen genoeg inhoud op voor een eerste toegankelijkheidsverklaring.
- Plannen: In deze fase worden afspraken gemaakt. Rollen, verantwoordelijkheden, prioriteiten, kennisgaten. Toegankelijkheid wordt gekoppeld aan bestaande processen in plaats van ernaast gezet.
- Actie: Hier gebeurt het echte werk. Teams bouwen en verbeteren zelf, met begeleiding. Processen worden aangepast. Ontwikkelaars leren toegankelijke patronen. Designers leren betere keuzes maken. Redactie leert schrijven voor echte mensen. De kennis verschuift van extern naar intern. Als klap op de vuurpijl voeren we een volledige WCAG-EM audit uit om het succes aan te kunnen tonen.
- Borgen: Toegankelijkheid vraagt, net als security of performance, om onderhoud. Door periodieke scans, hercontroles en meebewegen met nieuwe wetgeving blijft het niveau stabiel, ook wanneer teams wisselen, systemen veranderen of de organisatie groeit.
Focus op resultaat
Een audit is een meetinstrument. Super handig, maar meer is het niet. Het vertelt hoe het ervoor staat, maar niet hoe je structureel beter wordt. Mijn advies: begin niet met het auditen van het verleden, maar met het bouwen aan de toekomst. Duurzame toegankelijkheid ontstaat pas wanneer teams begrijpen waarom iets niet werkt, weten hoe ze het zelf goed kunnen bouwen en verantwoordelijkheid voelen voor de kwaliteit.
Of zoals het in de praktijk vaak voelt: toegankelijkheid is pas echt geregeld wanneer je er niet steeds meer expliciet over hoeft na te denken, omdat het onderdeel is geworden van hoe je ontwerpt, ontwikkelt en publiceert.
Dat bereik je niet met één dik rapport, maar met goed ingerichte processen, gedeelde kennis en begeleiding die aansluit op de realiteit van het team. Nieuwsgierig wat voor jouw organisatie past? We helpen je graag.
Alles weten over accessibility?
In ons handboek ‘Bouwen aan een digitaal toegankelijke organisatie’ lees je exact wat je nodig hebt om klaar te zijn voor de European Accessibility Act.
Ook interessant
Geschreven door
Nooit geen reden voor roze lippenstift