Hoe AI Agents je Website Zien: De Accessibility Tree Uitgelegd
51% van al het webverkeer is geautomatiseerd (Imperva Bad Bot Report 2025). Bots, crawlers en AI agents vormen inmiddels de meerderheid van je bezoekers. Maar die AI agents zien je website niet zoals jij. Geen kleuren, geen afbeeldingen, geen zorgvuldig ontworpen layouts. Ze navigeren via een verrassend simpele datastructuur die oorspronkelijk voor een heel ander doel werd gebouwd.
Die structuur is de accessibility tree. Een door de browser gegenereerde vereenvoudigde weergave van je pagina die decennialang schermlezers van semantische informatie voorzag. Nu is diezelfde boom de primaire interface waarmee AI agents je website begrijpen en ermee interacteren. De meeste websites zijn er niet op voorbereid.
Hoe AI agents je website daadwerkelijk zien
AI agents die het web browsen hebben drie manieren om een pagina te begrijpen. Elke benadering heeft z'n eigen afwegingen qua kosten, snelheid en begrip:
Visueel (screenshots)
De agent maakt een screenshot en stuurt het als afbeelding naar een LLM. Hoge token-kosten (~1.000+ tokens per screenshot), traag, en moeite met dynamische content. Gebruikt door Anthropic Computer Use en Google Project Mariner.
DOM Parsing
De agent leest de ruwe HTML-broncode. Duizenden nodes vol ruis — inline styles, tracking scripts, decoratieve elementen. Een gemiddelde pagina heeft 15.000+ tokens aan DOM, waarvan het meeste irrelevant is.
Accessibility Tree
De gestripte semantische weergave: alleen rollen, namen, statussen en beschrijvingen. Dezelfde 15.000+ token DOM wordt teruggebracht tot ~200-400 tokens. De meest efficiënte manier voor AI agents om een pagina te begrijpen.
Het verschil is behoorlijk. DOM parsing dwingt een AI agent om duizenden irrelevante nodes te verwerken. De accessibility tree geeft een kant-en-klare samenvatting van wat er op de pagina staat en wat je ermee kunt doen. Vergelijk het met het verschil tussen het lezen van de volledige broncode van een webpagina versus de inhoudsopgave.
Wat is de accessibility tree? Technische Uitleg
De accessibility tree is een door de browser gegenereerde vereenvoudigde versie van de DOM. Elke keer dat een browser een webpagina rendert, bouwt hij twee boomstructuren: de DOM voor visuele weergave, en de accessibility tree voor assistieve technologie. Alle visuele decoratie, layout-informatie en scripting worden eruit gefilterd. Wat overblijft is de semantische kern.
Elk element in de accessibility tree heeft vier kernattributen:
Rol
Wat is dit element? Een knop, link, heading, navigatie, formulierveld? De rol vertelt de agent wat voor type interactie mogelijk is.
Naam
Hoe heet dit element? De zichtbare tekst, een aria-label, of een alt-tekst. De naam vertelt de agent wat het element doet of voorstelt.
Status
Wat is de huidige toestand? Ingeschakeld, uitgeschakeld, aangevinkt, uitgevouwen? De status vertelt de agent wat er nu met het element aan de hand is.
Beschrijving
Aanvullende context via aria-describedby of title-attributen. De beschrijving geeft extra informatie die niet uit de naam alleen blijkt.
Een concreet voorbeeld. Dit is een typisch stuk HTML voor een navigatiemenu:
<nav class="bg-gray-800 shadow-lg p-4 flex items-center justify-between">
<div class="flex items-center space-x-2">
<img src="/logo.svg" class="h-8 w-8" alt="Acme Corp">
<span class="text-white font-bold text-xl">Acme Corp</span>
</div>
<div class="hidden md:flex space-x-6">
<a href="/products" class="text-gray-300 hover:text-white
transition-colors duration-200 font-medium">Producten</a>
<a href="/pricing" class="text-gray-300 hover:text-white
transition-colors duration-200 font-medium">Prijzen</a>
<a href="/contact" class="bg-blue-600 text-white px-4 py-2
rounded-lg hover:bg-blue-700 font-medium">Contact</a>
</div>
</nav>
En dit is wat de accessibility tree ervan maakt:
navigation:
img "Acme Corp"
link "Producten"
link "Prijzen"
link "Contact"
Alle visuele styling is weg. De klassen, hover-effecten, flex layouts, kleuren, compleet verdwenen. Wat overblijft zijn de elementen die betekenis hebben: een navigatie-landmark, een afbeelding met naam, en drie links. Precies de informatie die een AI agent nodig heeft om de pagina te snappen en ermee te werken.
Die 93% tokenreductie heeft directe impact op kosten en snelheid. Minder tokens betekent snellere verwerking, lagere API-kosten en minder kans op hallucinaties omdat het model minder irrelevante context moet doorploegen. Het is ook de reden waarom AI-systemen zoals ChatGPT en Claude de voorkeur geven aan websites met een schone semantische structuur.
Welke AI agent-frameworks gebruiken de accessibility tree?
De accessibility tree is geen theoretisch concept. Het is de standaardbenadering geworden voor de meest gebruikte AI agent-frameworks:
Playwright MCP
Microsoft's officiële MCP-server voor browser-automatisering. Gebruikt browser.accessibility.snapshot() als primaire paginaweergave — de accessibility tree ís de interface.
browser-use
Populair open-source framework (40k+ GitHub-sterren) dat de accessibility tree als standaard representatie gebruikt voor pagina-interacties.
OpenAI Atlas / Operator
OpenAI's web-navigatie-agent gebruikt een hybride van accessibility tree en visuele snapshots. De accessibility tree is de primaire bron; screenshots worden alleen ingezet bij ambiguïteit.
Claude Computer Use
Anthropic's computer use-benadering combineert visuele snapshots met accessibility tree-data voor robuustere navigatie en interactie.
De trend is duidelijk. De accessibility tree is de standaard geworden voor AI agent-website-interactie. Elk framework dat nu wordt gebouwd of bijgewerkt, gebruikt het als primaire of mede-primaire interface. De kwaliteit van je accessibility tree bepaalt direct hoe goed AI agents je website kunnen begrijpen en gebruiken.
Het onderzoek: toegankelijk = betere AI-prestaties
De link tussen webtoegankelijkheid en AI agent-prestaties is niet alleen logisch, het is ook wetenschappelijk onderzocht. De CHI 2026-studie "Is the Web Accessible for Web Agents?" testte systematisch hoe accessibility-barrières de prestaties van AI agents beïnvloeden. De resultaten zijn overtuigend:
Met een standaard visuele interface slagen AI agents in 78,33% van de taken. Dwing ze om alleen via het toetsenbord te navigeren, en het slagingspercentage daalt naar 41,67%. Bij vergrote weergave zakt het naar 28,33%. Dat is bijna twee derde van de taken die falen.
De conclusie is simpel: accessibility-barrières zijn AI agent-barrières. Dezelfde problemen die het web moeilijk maken voor gebruikers met een beperking, ontbrekende labels, niet-toetsenbord-navigeerbare elementen, onduidelijke semantiek, hinderen AI agents net zo goed. De accessibility tree is de brug. Als die brug gebroken is, komen noch assistieve technologie noch AI agents aan de overkant.
De overlap: WCAG en AI agent readiness
De overlap tussen webtoegankelijkheid (WCAG-conformiteit) en AI agent readiness is geen toeval, het is structureel. Accessibility best practices produceren precies de semantische signalen die AI agents nodig hebben. Hier een overzicht van hoe de belangrijkste accessibility-practices bijdragen aan betere AI agent-interactie:
| Accessibility practice | WCAG-criterium | AI agent-voordeel | Scanner checkpoint |
|---|---|---|---|
| Semantische HTML-elementen | WCAG 1.3.1 (Info & Relaties) | Agent begrijpt paginastructuur en elementfuncties | Semantische HTML (3.3) |
| Alt-tekst op afbeeldingen | WCAG 1.1.1 (Niet-tekstuele content) | Agent begrijpt visuele content zonder screenshots | Alt-tekst (3.5) |
| Koppenstructuur (H1-H6) | WCAG 1.3.1, 2.4.6 (Koppen & labels) | Agent navigeert efficiënt door contentstructuur | Koppenstructuur (3.2) |
| ARIA landmarks & labels | WCAG 4.1.2 (Naam, rol, waarde) | Agent identificeert secties en interactieve elementen | ARIA landmarks (3.4) |
| Toetsenbordnavigatie | WCAG 2.1.1 (Toetsenbord) | Agent kan alle elementen bereiken zonder muis | Formulierkwaliteit (4.6) |
| Formulierlabels | WCAG 1.3.1, 3.3.2 (Labels of instructies) | Agent begrijpt invoervelden en kan formulieren invullen | Formulierkwaliteit (4.6), Interactive surfaces (4.8) |
| Beschrijvende linkteksten | WCAG 2.4.4 (Linkdoel) | Agent begrijpt waar links naartoe leiden zonder context | Beschrijvende linkteksten (3.7) |
| Taalattribuut | WCAG 3.1.1 (Taal van pagina) | Agent verwerkt content in de juiste taal | Taalattribuut (3.6) |
Onze IsAgentReady scanner meet veel van deze signalen in de categorie Content & Semantics (categorie 3, 20% weging). De checkpoints voor semantische HTML (3.3), koppenstructuur (3.2), ARIA landmarks (3.4), alt-tekst (3.5), taalattribuut (3.6) en beschrijvende linkteksten (3.7) evalueren direct de kwaliteit van je accessibility tree. En daarmee hoe goed AI agents je site kunnen snappen.
De ARIA-controverse: gebruik met voorzichtigheid
ARIA (Accessible Rich Internet Applications) kan de accessibility tree verrijken wanneer HTML alleen niet volstaat. Maar er is een groeiend debat in de accessibility-gemeenschap over overmatig ARIA-gebruik, en dat debat is direct relevant voor AI agent readiness.
De eerste regel van ARIA is letterlijk: "Gebruik geen ARIA als je native HTML kunt gebruiken." Geen abstracte richtlijn. De WebAIM Million-analyse laat zien waarom:
Pagina's mét ARIA hebben gemiddeld 57 accessibility-fouten. Pagina's zonder ARIA: 27 fouten. Meer dan de helft minder. Meer ARIA betekent niet betere toegankelijkheid. Verkeerd gebruikte ARIA maakt de accessibility tree slechter dan helemaal geen ARIA.
OpenAI's eigen documentatie voor web agents beveelt het toevoegen van ARIA-attributen aan als optimalisatiestrategie. Accessibility-experts zoals Roselli noemen dat een gevaarlijke oversimplificatie. De juiste benadering:
-
Gebruik eerst semantische HTML
— een
<button>heeft geenrole="button"nodig, een<nav>geenrole="navigation" - Voeg ARIA alleen toe wanneer HTML niet volstaat — voor custom widgets, dynamische content en complexe interacties die geen native HTML-equivalent hebben
- Test met echte schermlezers — niet alleen met de accessibility tree-inspector in DevTools
- Minder is meer — elke overbodige ARIA-attribuut is een potentiële foutbron
De business case: 95% van websites faalt
Als de accessibility tree zo belangrijk is voor AI agents, hoe goed doen websites het dan? De cijfers zijn ontnuchterend. Volgens de meest recente WebAIM Million-analyse van de top 1 miljoen websites:
94,8% van de top 1 miljoen websites heeft detecteerbare WCAG-fouten. 5,2% slaagt voor een geautomatiseerde WCAG-conformiteitscheck. En dit zijn alleen de fouten die automatisch gedetecteerd kunnen worden. De werkelijke situatie is waarschijnlijk nog slechter.
De meest voorkomende problemen zijn precies de dingen die de accessibility tree breken voor AI agents:
- Ontbrekende alt-tekst op afbeeldingen (54,5% van pagina's) — AI agents weten niet wat afbeeldingen voorstellen
- Lege links (48,6%) — AI agents kunnen niet bepalen waar links naartoe leiden
- Ontbrekende formulierlabels (45,9%) — AI agents kunnen formulieren niet invullen
- Lage kleurcontrasten (78,0%) — minder relevant voor AI agents, maar symptoom van slechte aandacht voor accessibility
- Ontbrekende documenttaal (17,1%) — AI agents verwerken content mogelijk in de verkeerde taal
Dat is tegelijkertijd een probleem en een enorme kans. Als 94,8% van websites een gebrekkige accessibility tree heeft, geeft het verbeteren van je webtoegankelijkheid je een direct concurrentievoordeel voor AI agent-interactie. Je concurreert niet tegen perfectie. Je concurreert tegen een veld waarin bijna iedereen dezelfde fouten maakt.
Praktische checklist: verbeter je accessibility tree
Een driedelig actieplan om je accessibility tree te verbeteren, en daarmee zowel de toegankelijkheid voor gebruikers met een beperking als de bruikbaarheid voor AI agents:
Niveau 1: Snelle verbeteringen (deze week)
-
Voeg alt-tekst toe aan alle afbeeldingen
— beschrijvend voor content-afbeeldingen, leeg (
alt="") voor decoratieve -
Voeg een
lang-attribuut toe aan je<html>-tag - Gebruik beschrijvende linkteksten — vervang "klik hier" en "lees meer" door tekst die de bestemming beschrijft
-
Label alle formuliervelden
— elk
<input>heeft een bijbehorend<label>nodig - Verwijder lege links en knoppen — elk interactief element moet een toegankelijke naam hebben
Niveau 2: Structurele verbeteringen (deze maand)
-
Gebruik semantische HTML-elementen
—
<nav>,<main>,<article>,<section>,<aside>,<header>,<footer>in plaats van<div>-soep -
Maak een logische koppenstructuur
— één
<h1>, geneste<h2>-<h6>zonder niveaus over te slaan - Zorg voor toetsenbordnavigatie — alle interactieve elementen moeten bereikbaar en bedienbaar zijn via het toetsenbord
-
Gebruik native HTML waar mogelijk
—
<button>in plaats van<div onclick>,<a href>in plaats van<span onclick> -
Groepeer gerelateerde formuliervelden
met
<fieldset>en<legend>
Niveau 3: Geavanceerde optimalisatie (dit kwartaal)
- Audit met schermlezers — test met VoiceOver (macOS/iOS), NVDA of JAWS (Windows) om te ervaren wat AI agents "zien"
- Implementeer ARIA landmarks strategisch — alleen waar native HTML niet volstaat, en test na elke toevoeging
-
Maak dynamische content accessibility-ready
— gebruik
aria-live-regio's voor content die asynchroon wordt bijgewerkt -
Optimaliseer formulieren voor AI agents
— duidelijke labels, logische tabvolgorde, foutmeldingen gekoppeld aan velden via
aria-describedby - Implementeer agentprotocollen — voeg WebMCP toe voor gestructureerde AI agent-interactie, en agents.json om je agent-capabilities te adverteren
- Monitor je AI agent readiness — gebruik tools zoals onze scanner om regelmatig te controleren of je accessibility tree de signalen levert die AI agents nodig hebben
Conclusie: twee vliegen in één klap
De accessibility tree is het onverwachte maar logische scharnierpunt tussen webtoegankelijkheid en AI agent readiness. Door je website toegankelijker te maken, maak je hem tegelijkertijd begrijpelijker voor AI agents. Dezelfde investering bedient zowel gebruikers met een beperking als de groeiende stroom van AI agents die je website bezoeken. Dat komt niet vaak voor in webontwikkeling.
De cijfers spreken voor zich. 94,8% van websites faalt op basale webtoegankelijkheid. Dat is tegelijk 94,8% van websites die een suboptimale interface bieden aan AI agents. De CHI 2026-studie laat zien dat accessibility-barrières direct leiden tot lagere AI agent-prestaties. En de meeste moderne AI agent-frameworks gebruiken de accessibility tree als primaire interface.
Investeren in webtoegankelijkheid is niet alleen de juiste keuze voor inclusie, het is een strategische noodzaak in een wereld waar meer dan de helft van je websiteverkeer geautomatiseerd is. Begin bij de snelle verbeteringen, werk toe naar structurele veranderingen, en gebruik tools zoals onze AI agent readiness scanner om je voortgang te meten.
Bronnen
- Imperva Bad Bot Report 2025 — Jaarlijks rapport over geautomatiseerd webverkeer: 51% van al het internetverkeer is geautomatiseerd
- "Is the Web Accessible for Web Agents?" — CHI 2026 — Wetenschappelijke studie over de impact van accessibility-barrières op AI agent-prestaties
- WebAIM Million — The 2025 Report on the Accessibility of the Top 1,000,000 Home Pages — Jaarlijkse analyse van WCAG-conformiteit: 94,8% faalpercentage
- WAI-ARIA Authoring Practices — W3C — De officiële ARIA-richtlijnen met de "eerste regel van ARIA"
- The Accessibility Tree — MDN Web Docs — Technische documentatie over hoe browsers de accessibility tree bouwen
- Playwright MCP — Microsoft — Documentatie over hoe Playwright MCP de accessibility tree als primaire interface gebruikt
- Adrian Roselli — Accessibility Expert Blog — Kritische analyse van ARIA-overgebruik en AI agent-optimalisatie
- IsAgentReady: Wat is AI Agent Readiness? — Introductie tot AI agent readiness en hoe het samenhangt met webtoegankelijkheid
- IsAgentReady: Wat is WebMCP en waarom je website het nodig heeft
- IsAgentReady: Wat is agents.json — AI agent-mogelijkheden adverteren
- IsAgentReady: The State of AEO — Belangrijkste inzichten uit Vercel's 2026 rapport