Waarom éénmalige toegankelijkheidsaudits in 2026 niet meer genoeg zijn

Digitale toegankelijkheid is jarenlang behandeld als iets dat je “ook nog even” liet controleren vlak voor livegang. Een externe specialist deed een WCAG-audit, het rapport ging naar IT of UX, een deel van de bevindingen werd opgepakt en daarna verdween toegankelijkheid weer naar de achtergrond. Voor veel organisaties was dat niet ideaal, maar het voelde werkbaar.

In 2026 is die aanpak steeds minder houdbaar. WCAG is niet langer alleen een kwaliteitskader voor goede digitale dienstverlening. In de Verenigde Staten verwijst ADA Title II voor web en mobiele apps expliciet naar WCAG 2.1 AA. In Europa is de European Accessibility Act sinds 28 juni 2025 van toepassing op belangrijke producten en diensten, waaronder e-commerce, consumentenbankieren, e-books, communicatiediensten en delen van vervoer. In Nederland ziet de ACM toe op onder meer webwinkels en communicatiediensten.

Voor universiteiten, hogescholen, uitvoeringsorganisaties, gemeenten, zorggerelateerde instellingen en semipublieke dienstverleners betekent dit: een audit is nog steeds nodig, maar niet meer genoeg. Je moet kunnen laten zien dat toegankelijkheid structureel wordt beheerd.

De kern is eenvoudig: digitale diensten worden steeds vaker beoordeeld als volwaardige toegangspoorten tot onderwijs, overheid, zorg, vervoer, werk en commerciële dienstverlening. Als een formulier, login, betaalstap of studentenportaal niet toegankelijk is, is dat geen klein UI-probleem. Het kan betekenen dat iemand niet zelfstandig kan deelnemen.

ADA Title II richt zich op Amerikaanse state and local governments en hun digitale content en apps. De relevante compliance-deadlines liggen op 24 april 2026 voor grotere publieke entiteiten en 26 april 2027 voor kleinere entiteiten en special district governments. Belangrijker dan de datumdiscussie is de technische norm: WCAG 2.1 Level AA is de referentie in de regel. Ook vóór de deadlines blijven bredere ADA-verplichtingen rond effectieve communicatie en gelijke toegang bestaan.

De EAA werkt anders, maar de richting is vergelijkbaar. De wet geldt vanaf 28 juni 2025 voor een reeks producten en diensten in de EU. Denk aan webwinkels, ticketing, bankdiensten, e-books, elektronische communicatiediensten en digitale klantreizen waarin iemand een overeenkomst sluit, betaalt, reserveert of communiceert. ACM ConsuWijzer legt bijvoorbeeld uit dat zoeken, kiezen, bestellen, inloggen en betalen toegankelijk moeten zijn bij webwinkels.

Voor organisaties in Nederland en de EU is de praktische les: toezichthouders kijken vooral naar functionele gebruikersreizen. Een homepage met goede contrastwaarden helpt, maar een ontoegankelijke inschrijving, tentamenaanmelding, betaalpagina of supportflow is veel kritischer.

Het klassieke patroon zie je in veel organisaties. Er komt een grote audit. Het rapport is degelijk, soms zelfs uitstekend. Er staan tientallen of honderden bevindingen in, geordend per WCAG-succescriterium. Daarna begint de echte werkelijkheid: productteams hebben releases, redacties plaatsen nieuwe content, leveranciers leveren componenten aan, ontwikkelaars wisselen van project en een redesign verandert de frontend.

Zes maanden later zijn sommige oorspronkelijke bevindingen opgelost, maar dezelfde type issues verschijnen opnieuw. Een knop zonder toegankelijke naam. Een modal zonder goed focusmanagement. Nieuwe PDF’s zonder structuur. Een formulier met foutmeldingen die niet door schermlezers worden aangekondigd. Niet omdat teams onverschillig zijn, maar omdat toegankelijkheid niet in het proces zit.

Een eenmalige audit geeft je een momentopname. Die momentopname is waardevol als nulmeting, maar hij bewijst niet dat je daarna onder controle blijft. Bij een klacht, intern onderzoek of toezichthoudervraag wil je kunnen laten zien wat je hebt gedaan, wat je prioriteert, welke risico’s bekend zijn en hoe regressies worden opgespoord.

Een moderne audit begint niet met “scan de website”. Hij begint met scope. Welke websites, apps, portalen, formulieren en documenten zijn essentieel? Welke reizen zijn kritisch voor gebruikers? In het onderwijs zijn dat bijvoorbeeld aanmelden, inloggen, rooster bekijken, vakinformatie lezen, tentamenvoorzieningen aanvragen, betalen en contact opnemen met support.

Daarna combineer je automatische scans met handmatige review. Automatische tools zijn goed in veel technische patronen: ontbrekende labels, contrastproblemen, ARIA-fouten, headingstructuur, formulierrelaties en een deel van keyboard issues. Maar ze zien niet alles. Een mens moet toetsenbordgebruik, schermlezergedrag, vergroting, mobiele interactie, begrijpelijkheid en proceslogica beoordelen.

De output moet meer zijn dan een lijst met fouten. Een bruikbaar auditrapport bevat een WCAG-matrix, prioriteiten per gebruikersimpact, voorbeelden uit echte journeys, screenshots of selectors, advies voor componenten, mapping naar EN 301 549 waar relevant en een samenvatting voor bestuur, compliance en productteams.

De audit is de baseline. Daarna heb je een laag nodig die nieuwe problemen zichtbaar maakt. Vergelijk het met security scanning of performance monitoring. Je doet niet één keer per jaar een pentest en verder niets. Je monitort dependencies, releases, afwijkingen en incidenten. Voor toegankelijkheid zou hetzelfde moeten gelden.

Een accessibility monitoring layer kijkt periodiek naar belangrijke pagina’s en journeys. Hij signaleert regressies, bewaakt scores en maakt trends zichtbaar. Dat betekent niet dat software menselijke audits vervangt. Het betekent dat teams sneller zien waar iets stukgaat en niet hoeven te wachten tot de volgende grote audit.

In de praktijk werkt dit vooral goed wanneer monitoring is gekoppeld aan releaseprocessen. Nieuwe componenten worden getest voordat ze breed worden uitgerold. Belangrijke templates worden na elke release opnieuw gecontroleerd. Product owners zien welke issues terugkomen. Compliance krijgt periodieke voortgang in plaats van losse rapporten.

Toegankelijkheid faalt zelden door één persoon. Het faalt meestal door onduidelijk eigenaarschap. IT denkt dat UX het bewaakt. UX denkt dat development het oplost. Development denkt dat compliance prioriteert. Compliance heeft geen zicht op de backlog. Ondertussen publiceert communicatie nieuwe content.

Een volwassen aanpak benoemt eigenaarschap per laag: beleid, design system, codebase, content, inkoop en incidentafhandeling. Niet iedereen hoeft WCAG-specialist te zijn, maar iedereen moet weten wanneer toegankelijkheid relevant is en waar signalen landen.

Bewijsvoering hoeft niet zwaar te beginnen. Een toegankelijkheidsbeleid, een backlog met issues, besluiten over prioriteiten, periodieke rapportages en releasechecks zijn al veel sterker dan een los rapport van vorig jaar. In geval van een klacht kun je dan laten zien dat je redelijk en proportioneel handelt: je kent de risico’s, pakt kritieke journeys eerst op en borgt verbetering in processen.