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. Browseragents kunnen de DOM, accessibility tree en screenshots combineren, met verschillende afwegingen voor structuur, visuele context en tokengebruik.
De accessibility tree is een belangrijke gestructureerde representatie voor browseragents en assistieve technologie. Begrijpen hoe deze werkt, welke frameworks hem aanbieden en waar DOM- of screenshotcontext aanvult, is een belangrijk onderdeel van AI agent readiness.
Hoe AI agents je website daadwerkelijk zien
Browseragents kunnen drie representaties gebruiken om een pagina te begrijpen en combineren die vaak. Elke benadering heeft 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
Een compacte semantische weergave met rollen, namen, statussen en beschrijvingen. Dezelfde 15.000+ token DOM wordt teruggebracht tot ~200-400 tokens. Een efficiënt gestructureerd signaal voor compatibele browseragents.
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. Dat is waardevolle gestructureerde informatie voor agents die accessibility snapshots gebruiken.
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.
Accessibility snapshots zijn een veelgebruikte gestructureerde interface in frameworks zoals Playwright MCP en agent-browser. De kwaliteit van je accessibility tree beïnvloedt hun semantische interacties direct. Andere browseragents kunnen deze informatie aanvullen met DOM-data en screenshots.
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 kunnen ook browseragents hinderen die op semantische interactie vertrouwen. Ontbrekende labels, niet-toetsenbord-navigeerbare elementen en onduidelijke semantiek verzwakken hun accessibility snapshots, ook wanneer DOM- of screenshotcontext beschikbaar is.
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 verzwakken de accessibility tree voor snapshot-afhankelijke browseragents:
- Ontbrekende alt-tekst op afbeeldingen (54,5% van pagina's): snapshot-afhankelijke browseragents kunnen afbeeldingen niet semantisch duiden
- Lege links (48,6%): compatibele browseragents missen een toegankelijke naam waarmee ze de bestemming kunnen bepalen
- Ontbrekende formulierlabels (45,9%): snapshot-afhankelijke browseragents missen de veldnaam die betrouwbare formulierinteractie ondersteunt
- 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). Daarmee test je de accessibility-weergave die snapshot-afhankelijke browseragents ook kunnen gebruiken, niet iedere agentrepresentatie
- 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 bruikbare semantische signalen levert aan compatibele browseragents
Conclusie: twee vliegen in één klap
De accessibility tree is een belangrijk raakvlak tussen webtoegankelijkheid en browser-agentinteractie. Toegankelijkheidsverbeteringen versterken semantische interactie voor compatibele browseragents zonder de algemene AI agent readiness te bewijzen. Andere agents kunnen daarnaast de DOM, screenshots en andere signalen gebruiken.
De cijfers spreken voor zich. 94,8% van websites faalt op basale webtoegankelijkheid. Dat betekent ook zwakkere semantische signalen voor browseragents die accessibility snapshots gebruiken. De CHI 2026-studie laat zien dat accessibility-barrières kunnen leiden tot lagere AI agent-prestaties. DOM- en screenshotcontext nemen het belang van goede semantiek niet weg.
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 accessibility snapshots 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