Ga naar inhoud

Hoe AI Agents je Website Zien: De Accessibility Tree Uitgelegd

12 min leestijd
Bart Waardenburg

Bart Waardenburg

AI Agent Readiness Expert & Oprichter

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.

GEMIDDELDE DOM-GROOTTE
15.000+
ACCESSIBILITY TREE-GROOTTE
~200-400
TOKENREDUCTIE
0
KOSTEN PER INTERACTIE
~97%↓

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:

SLAGINGSPERCENTAGE STANDAARD
0
SLAGINGSPERCENTAGE ALLEEN-TOETSENBORD
0
SLAGINGSPERCENTAGE VERGROOT
0

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:

FOUTEN MET ARIA AANWEZIG
0
FOUTEN ZONDER ARIA
0

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:

  1. Gebruik eerst semantische HTML — een <button> heeft geen role="button" nodig, een <nav> geen role="navigation"
  2. Voeg ARIA alleen toe wanneer HTML niet volstaat — voor custom widgets, dynamische content en complexe interacties die geen native HTML-equivalent hebben
  3. Test met echte schermlezers — niet alleen met de accessibility tree-inspector in DevTools
  4. 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:

WEBSITES MET WCAG-FOUTEN
0
WEBSITES ZONDER WCAG-FOUTEN
0

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

Klaar om te checken?

SCAN JE WEBSITE

Ontvang je AI-agentgereedheidscore met bruikbare aanbevelingen over 5 categorieën.

  • Gratis directe scan met lettercijfer
  • 5 categorieën, 47 checkpoints
  • Codevoorbeelden bij elke aanbeveling

GERELATEERDE ARTIKELEN

Lees verder over AI-agentgereedheid en weboptimalisatie.

Vercel's agent-browser: Waarom een CLI MCP Verslaat voor Browser Automation
10 min leestijd

Vercel's agent-browser: Waarom een CLI MCP Verslaat voor Browser Automation

Vercel's agent-browser behaalde 22.000 GitHub-sterren in twee maanden. Het is een CLI, geen MCP-server, en de data laat zien waarom: 94% minder tokens, 3,5x snellere uitvoering, 100% slagingspercentage. We ontleden hoe het werkt, waarom het de accessibility tree gebruikt, en wat de 'less is more'-bevinding betekent voor je website.

ai-agents web-standards accessibility
Playwright: Van Testrunner naar AI Agent-Interface
11 min leestijd

Playwright: Van Testrunner naar AI Agent-Interface

Playwright haalde Cypress in, toen bracht Microsoft Playwright MCP uit — waarmee dezelfde tool de standaard browser-runtime voor AI agents werd. We ontleden waarom het data-testid vs getByRole debat nu bepaalt of agents je site kunnen gebruiken, het test-accessibility-agent vliegwiel, en wat dit betekent voor frontend-teams.

ai-agents web-standards accessibility
Wat is agents.json? AI Agent-mogelijkheden op je website adverteren
10 min leestijd

Wat is agents.json? AI Agent-mogelijkheden op je website adverteren

agents.json is de opkomende tegenhanger van robots.txt - een machine-leesbaar bestand dat AI-agents vertelt wat je website kan. We behandelen de Wildcard-specificatie, vergelijken het met A2A, MCP en OpenAPI, en laten stap voor stap zien hoe je het implementeert.

ai-agents web-standards agent-protocols

ONTDEK MEER

De meeste websites scoren onder de 45. Ontdek waar jij staat.

RANGLIJST
BEKIJK HOE ANDEREN SCOREN

RANGLIJST

Bekijk AI-gereedheidsscores van gescande websites.
VERGELIJKEN
VERGELIJKEN

VERGELIJKEN

Vergelijk twee websites zij-aan-zij over alle 5 categorieën en 47 checkpoints.
OVER ONS
HOE WIJ METEN

OVER ONS

Lees meer over onze scoringsmethodologie met 5 categorieën.