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. 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.

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.

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:

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 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:

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 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

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, 65 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

Nadat Playwright Cypress inhaalde, bracht Microsoft Playwright MCP uit als een belangrijke browserautomatiseringsoptie voor compatibele agents. We leggen uit hoe getByRole en accessibility snapshots bruikbare roles en names aanbieden zonder volledige agentnavigatie of taaksucces te garanderen.

ai-agents web-standards accessibility
Het Responsive Design Moment voor AI Agents
11 min leestijd

Het Responsive Design Moment voor AI Agents

Het web maakt dezelfde verschuiving door als bij mobiel. Eerst aparte m.dot-sites, toen responsive convergentie. AI agent readiness volgt dezelfde boog: aparte agent-API's vandaag, één adaptieve contentlaag morgen. We volgen de parallellen, de data, en wat er na convergentie komt: de persoonlijke LLM-laag.

ai-agents web-standards getting-started

ONTDEK MEER

De meeste websites scoren onder het gemiddelde. 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 op alle 5 gewogen categorieën.
OVER ONS
HOE WIJ METEN

OVER ONS

Lees meer over onze scoringsmethodologie met 5 categorieën.