Website toegankelijkheid audit met AI (Skill): van WCAG-risico naar fixlijst

Toegankelijkheid wordt in veel teams pas serieus bekeken als de website al live is. De campagne loopt, het formulier verzamelt leads, en dan vraagt iemand waarom een bezoeker met toetsenbordnavigatie vastloopt. Op dat moment voelt een audit groot, juridisch en technisch. Een marketeer ziet vooral de landingspagina. Een designer ziet componenten. Een developer ziet templates. De eigenaar ziet een lijst met losse klachten zonder duidelijke volgorde.

Deze KREATE skill maakt dat eerste uur veel bruikbaarder. Niet door te beloven dat AI je website "WCAG-proof" maakt, maar door rommelige pagina-input om te zetten in een geprioriteerde werkvoorraad: wat is waarschijnlijk kritiek, welk WCAG-criterium raakt het, waarom is het een probleem voor echte gebruikers, en welke fix kun je aan een maker of developer geven?

De focus ligt op Nederlandse ondernemers, marketeers, designers en makers die niet willen wachten tot er budget is voor een volledige audit, maar wel vandaag betere beslissingen willen nemen. Je gebruikt de skill als eerste triage. Daarna bepaal je wat automatisch te verbeteren is, wat in design of code thuishoort, en welke onderdelen nog door een toegankelijkheidsspecialist of gebruikers met hulpmiddelen gecontroleerd moeten worden.

Waarom toegankelijkheid vaak te laat wordt gecontroleerd

Website toegankelijkheid klinkt voor veel teams als iets dat aan het einde van het project hoort. Eerst moet de propositie staan. Dan de copy. Dan de pixel-perfecte pagina. Dan conversie. Pas daarna komt de vraag of iemand met een screenreader, slecht zicht, beperkte motoriek of alleen een toetsenbord dezelfde flow kan gebruiken.

Dat is precies waar het misgaat. Toegankelijkheid is geen laklaag over een afgeronde pagina. Het zit in keuzes die je al vroeg maakt: de volgorde van koppen, de tekst op knoppen, het contrast van je merkpalet, labels bij formulieren, foutmeldingen, focus states, alt-teksten, interactieve elementen en de structuur van je HTML. Als die keuzes eenmaal over meerdere templates verspreid zijn, wordt repareren duurder en trager.

De officiële WCAG 2.2-aanbeveling van W3C ordent toegankelijkheid onder vier principes: waarneembaar, bedienbaar, begrijpelijk en robuust. Dat klinkt abstract, maar de dagelijkse vertaling is concreet. Kan iemand de inhoud waarnemen zonder kleur alleen? Kan iemand door het formulier zonder muis? Is de linktekst duidelijk? Geeft de interface aan waar de focus zit? Zijn foutmeldingen te begrijpen?

Een eerste AI-audit helpt omdat hij die losse signalen bij elkaar brengt. Niet als eindvonnis, maar als gestructureerde start. In plaats van "we moeten ooit iets met toegankelijkheid" krijg je: "deze drie dingen blokkeren waarschijnlijk gebruikers, deze vijf dingen zijn verbeteringen, en dit is de volgorde waarin we ze aanpakken."

Wat deze KREATE AI skill oplost

De KREATE skill voor website toegankelijkheid audit AI is ontworpen voor een praktische workflow. Je voert een URL, HTML-fragment of paginabeschrijving in. De skill laat een LLM kijken naar bekende risicogebieden, zoals ontbrekende alt-tekst, zwakke koppenstructuur, onduidelijke linkteksten, formulieren zonder labels, contrastsignalen, ARIA-misbruik, focusproblemen en leesbaarheid. Daarna vraagt de skill om een rapport dat niet alleen problemen noemt, maar ze ook bruikbaar maakt voor actie.

Een goede output bestaat niet uit tien algemene adviezen. Een goede output zegt bijvoorbeeld: dit formulier lijkt geen expliciet label te hebben, dit raakt WCAG 3.3.2 Labels or Instructions, dit is lastig voor screenreadergebruikers, en dit is een mogelijke HTML-aanpassing. Of: deze call-to-action gebruikt alleen kleur om urgentie te tonen, waardoor iemand met kleurwaarnemingsproblemen het verschil kan missen.

De skill is bedoeld voor Claude Code, Codex, Gemini, OpenCode, ChatGPT en andere LLMs. Je kunt hem gebruiken in een codebase-context, in een losse chat of als onderdeel van een reviewproces. Het belangrijkste is dat je de output niet behandelt als certificaat. Je behandelt hem als startpunt voor een fixlijst.

Probeer eerst de gratis tool

KREATE heeft voor deze pipeline-test ook een publieke tool gemaakt: Website Toegankelijkheid Audit AI. Gebruik die om de eerste stap te ervaren. Je kunt een URL of HTML invoeren, een WCAG-niveau kiezen en een geprioriteerd Nederlandstalig rapport laten maken.

De tool is handig voor een snelle eerste check. De volledige skill is breder inzetbaar: je kunt hem combineren met codecontext, designnotities, componentdocumentatie, CMS-output of een backlog met bekende problemen. Zo groeit de audit van "wat ziet AI op deze pagina?" naar "welke verbeteringen moeten wij als team plannen?"

Wat AI wel en niet kan beoordelen bij WCAG

AI is sterk in patroonherkenning, samenvatten, prioriteren en het vertalen van technische signalen naar gewone taal. Dat past goed bij een eerste toegankelijkheidsronde. Een LLM kan zien dat een pagina waarschijnlijk geen logische headingvolgorde heeft, dat linkteksten als "klik hier" weinig betekenis geven, of dat een formulierlabel ontbreekt in de aangeleverde HTML.

Maar WCAG-conformiteit is meer dan tekstuele analyse. W3C/WAI zegt in zijn evaluatie-overzicht dat tools kunnen helpen, maar dat geen tool alleen kan bepalen of een site aan toegankelijkheidsstandaarden voldoet; deskundige menselijke evaluatie blijft nodig. Dat is een belangrijke grens. AI kan risico's vinden en uitleggen, maar niet alle interactie, hulpmiddelen, gebruikerscontext en edge cases betrouwbaar testen.

Daarom werkt deze skill het best met drie labels in je hoofd: "waarschijnlijk probleem", "te verifieren" en "actie klaar". Een ontbrekend label in HTML is vaak actie klaar. Een contrastprobleem op basis van een beschrijving is te verifieren met een contrasttool of designwaarde. Een complexe keyboard-trap in een JavaScript-component vraagt echte interactietest.

De Nederlandse uitleg van WCAG 2.2-richtlijnen op WCAG.nl is nuttig om termen te vertalen naar begrijpelijke taal voor Nederlandse teams. Zo wordt contrast niet alleen "kleur", maar een meetbare verhouding. En "bedienbaar" betekent niet alleen dat iets klikbaar is, maar dat iemand er ook zonder muis doorheen kan.

Hoe de workflow werkt

De workflow bestaat uit zes stappen. Je hoeft ze niet zwaar te maken; het doel is juist dat je snel van ruwe pagina naar bruikbare prioriteiten gaat.

1. Kies de pagina of flow. Begin niet met je hele website. Kies een landingspagina, checkout, intakeformulier, productpagina of blogtemplate.
2. Verzamel input. Gebruik een URL, geplakte HTML, relevante componentnotities, screenshotsamenvatting of een korte beschrijving van de flow.
3. Kies het WCAG-niveau. Voor veel teams is AA de praktische standaard om mee te starten. A is basaler, AAA is strenger en niet altijd voor alle content haalbaar.
4. Laat de skill risico's clusteren. Vraag niet alleen om fouten, maar om categorie, ernst, WCAG-criterium, impact en fixsuggestie.
5. Controleer de output. Markeer wat direct klopt, wat met een tool getest moet worden, en wat menselijke evaluatie vraagt.
6. Zet om naar werk. Maak tickets of taken met concrete acceptatie: label toegevoegd, focus state zichtbaar, linktekst herschreven, contrastwaarde aangepast.

Hier zit de echte winst. Een losse checklist geeft vaak alleen "check alt text". De skill dwingt de vraag af: welke afbeelding mist alt-tekst, is die afbeelding informatief of decoratief, wat zou een goede alt-tekst zijn, en wie moet dit aanpassen?

Stap voor stap: van URL naar prioriteitenlijst

Stel: je hebt een landingspagina voor een gratis tool. De pagina heeft een hero, een formulier, drie featureblokken en een FAQ. Je wilt weten waar de grootste toegankelijkheidsrisico's zitten voordat Dex media, Selma SEO/GEO of Sanne Publish ermee verdergaat.

Je begint met de URL of HTML. Daarna vraag je de skill om de pagina te beoordelen op WCAG AA, met extra aandacht voor formulieren, knoppen, linkteksten en koppenstructuur. Een sterke prompt geeft de skill ook de context: dit is een Nederlandse marketingpagina, het doel is conversie naar een tool of community, en de output moet geschikt zijn voor makers die actie moeten nemen.

De eerste output is meestal een lijst met bevindingen. Die lijst moet je niet klakkeloos overnemen. Je leest hem als reviewer. Als de skill zegt dat een knoptekst onduidelijk is, kijk je naar de echte knop. Als de skill zegt dat er mogelijk contrastproblemen zijn, test je de kleurwaarden. Als de skill een ARIA-fix voorstelt, controleer je of semantische HTML niet eenvoudiger en robuuster is.

Daarna maak je de prioriteitenlijst. Kritieke issues zijn dingen die iemand echt blokkeren: een formulier zonder bruikbaar label, een keyboard-flow die vastloopt, een knop zonder toegankelijke naam, of foutmeldingen die niet gekoppeld zijn aan velden. Waarschuwingen zijn verbeteringen die waarschijnlijk impact hebben, maar meer context vragen. Info-items zijn onderhoudskansen, zoals betere headingdiscipline of consistentere linkteksten.

Zo wordt toegankelijkheid onderdeel van de normale productieworkflow. Niet als schuldgevoel aan het eind, maar als kwaliteitsronde voordat content, design en development te ver uit elkaar lopen.

Voorbeeld zonder de volledige skill weg te geven

Een publieke voorbeeldvraag kan er zo uitzien:

Analyseer deze pagina als eerste toegankelijkheidscheck.
Gebruik WCAG 2.2 AA als referentie.
Geef per bevinding: ernst, categorie, mogelijk WCAG-criterium,
impact voor gebruikers en een concrete fixsuggestie.
Markeer wat nog handmatig geverifieerd moet worden.

Dat is niet de volledige KREATE skill. De echte skill bevat meer sturing op rol, outputstructuur, prioritering, safeguards, voorbeeldformaten en vervolgacties. Maar zelfs dit korte voorbeeld laat zien wat belangrijk is: vraag niet om een vage score, vraag om werkbare beslisinformatie.

Een matige AI-output zegt: "Verbeter de alt-teksten." Een bruikbare output zegt: "De hero-afbeelding lijkt informatief omdat hij het productresultaat toont. Als de HTML geen alt-tekst bevat, mist een screenreadergebruiker context. Voeg een korte alt-tekst toe die het resultaat beschrijft, of markeer de afbeelding als decoratief als dezelfde informatie al in tekst staat."

Dat verschil bepaalt of je team iets met de audit kan. Toegankelijkheid wordt pas beter als de output vertaald is naar keuzes in tekst, design en code.

Tabel: losse checklist versus AI-audit workflow

Veelgemaakte fouten

1. Alleen op een score sturen

Een score voelt overzichtelijk, maar kan misleiden. Een pagina met een nette score kan nog steeds een formulier hebben dat voor een groep gebruikers niet bruikbaar is. Kijk liever naar blokkades, impact en bewijs.

2. AI-fixes zonder controle overnemen

AI kan goede suggesties doen, maar ook te veel ARIA toevoegen of een oplossing voorstellen die niet past bij je component. Semantische HTML is vaak beter dan een ingewikkelde ARIA-reparatie. Laat een developer technische fixes beoordelen.

3. Contrast beschrijven zonder waarden te testen

Een LLM kan op basis van tekst of CSS vermoeden dat contrast zwak is. Voor een echte beslissing heb je kleurwaarden en een contrastmeting nodig. Gebruik AI om de plek te vinden, niet als enige meetinstrument.

4. Alleen de homepage controleren

De grootste toegankelijkheidsproblemen zitten vaak in flows: formulieren, checkout, filters, modals, accountschermen en foutmeldingen. Kies pagina's waar een gebruiker echt iets moet doen.

5. Geen eigenaar aan fixes koppelen

Een audit zonder eigenaar verdwijnt. Zet bij elke bevinding wie moet handelen: copy, design, development, contentbeheer of product owner. Maak de fix klein genoeg om af te ronden.

Hoe je dit in een KREATE-productieflow gebruikt

Voor KREATE-content werkt deze skill goed als brug tussen blog, tool en community. De blog legt de denkwijze uit. De publieke tool laat lezers een eerste scan uitvoeren. De volledige skill in Skool helpt makers om dezelfde workflow in hun eigen LLM-omgeving te draaien.

In een contentpipeline kan de stap er zo uitzien: voordat een nieuwe toolpagina of blogtemplate naar QA gaat, draait iemand een eerste AI-audit. De output wordt niet gepubliceerd, maar toegevoegd aan de interne checklist. Dex kan media-altteksten scherper maken. Selma kan letten op duidelijke linkankers en structured content. Vera kan pre-publish QA doen met bekende risico's in beeld. Sanne publiceert pas als de afgesproken QA-gates gehaald zijn.

Gebruik dezelfde aanpak naast andere productieflows, zoals de AI-workflow voor klantintake, zodat accessibility-checks niet los van intake, content en QA blijven hangen.

Zo blijft de conversiepath logisch. De lezer krijgt praktische waarde in de blog, ervaart de tool, en kan daarna de volledige skill ophalen in de community. KREATE bouwt geen losse contentstukken, maar een herhaalbare manier om AI-skills, tools en kwaliteitscontrole aan elkaar te koppelen.

Download de volledige skill

Als je alleen een snelle scan wilt, gebruik dan de publieke Website Toegankelijkheid Audit AI. Als je de workflow wilt opnemen in je eigen proces, met betere instructies, vaste output en ruimte voor code- of designcontext, download dan de volledige KREATE skill.

FAQ

Is een website toegankelijkheid audit met AI genoeg voor WCAG-compliance?

Nee. Gebruik AI als eerste triage en fixvoorbereiding. Voor formele WCAG-claims, juridische zekerheid of complexe applicaties heb je deskundige menselijke evaluatie en waar nodig gebruikerstests nodig.

Welk WCAG-niveau moet ik kiezen?

Voor veel websites is WCAG AA het praktische startpunt. Niveau A bevat basiscriteria, AA is strenger en vaak de relevante richtlijn voor professionele websites, en AAA gaat verder maar is niet altijd haalbaar of verplicht voor alle content.

Kan ik de skill gebruiken zonder codebase?

Ja. Je kunt werken met een URL, HTML-fragment, componentbeschrijving of paginabeschrijving. Met codecontext wordt de output vaak concreter, maar een eerste audit kan ook zonder volledige repository.

Welke problemen vindt AI het best?

AI is vooral nuttig bij tekstuele en structurele signalen: headinglogica, linkteksten, formulierlabels, alt-tekstkeuzes, uitleg van impact en het clusteren van bevindingen. Interactieproblemen, exacte contrastwaarden en hulpmiddelgedrag moet je aanvullend testen.

Mag ik de AI-output direct aan een developer geven?

Ja, maar geef hem als concept-fixlijst. Laat technische oplossingen controleren, vooral bij ARIA, JavaScript-componenten, focusgedrag en formulieren. De beste output is een startpunt voor tickets, niet het laatste oordeel.