Hoe AI-agents de accessibility tree van je website kunnen gebruiken

De accessibility tree is een door de browser gemaakte weergave van de semantische structuur van een pagina. Hij bevat rollen en toegankelijke namen voor elementen zoals knoppen en formuliervelden, zodat compatibele agents kunnen herkennen waarmee ze kunnen werken.

Browseragents kunnen de DOM, accessibility tree en screenshots combineren. De tree is vooral nuttig voor snapshot-afhankelijke browseragents; andere agents gebruiken ook visuele context. Hij is één onderdeel van AI agent readiness, en een leesbare tree bewijst op zichzelf geen taaksucces.

Hoe AI agents je website 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:

De accessibility tree werkt als een inhoudsopgave: hij vat samen wat er op de pagina staat en wat je ermee kunt doen. DOM parsing levert een browseragent daarentegen de volledige broncode met duizenden irrelevante nodes.

Wat is de accessibility tree? Een technische uitleg

De accessibility tree is een door de browser gegenereerde vereenvoudigde versie van de DOM. Een browser bouwt bij het renderen van een pagina twee boomstructuren: de DOM voor visuele weergave en de accessibility tree voor assistieve technologie. De accessibility tree laat visuele decoratie, layout-informatie en scripting weg en houdt de semantische kern over.

Elk element in de accessibility tree heeft vier kernattributen:

Een typisch stuk HTML voor een navigatiemenu ziet er zo uit:

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

De accessibility tree bevat geen visuele styling meer: geen klassen, hover-effecten, flex layouts of kleuren. Alleen de elementen die betekenis hebben blijven over: een navigatie-landmark, een afbeelding met naam en drie links. Agents die accessibility snapshots gebruiken krijgen daarmee gestructureerde informatie.

Die 93% tokenreductie verlaagt de API-kosten en versnelt de verwerking, omdat het model minder irrelevante context hoeft te lezen. Hoe ChatGPT en Claude bronnen kiezen om te citeren, lees je in onze andere artikelen.

Welke AI agent-frameworks gebruiken de accessibility tree?

Deze frameworks bieden de accessibility tree direct aan of combineren hem met andere invoer:

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. Andere browseragents kunnen deze informatie aanvullen met DOM-data en screenshots.

Het onderzoek: toegankelijkheid en AI agent-prestaties

De CHI 2026-studie "Is the Web Accessible for Web Agents?" onderzocht hoe accessibility-barrières de prestaties van AI agents beïnvloeden. Dit zijn de slagingspercentages:

Met een standaardweergave slaagden de agents in 78,33% van de taken. Bij alleen toetsenbordnavigatie daalde het slagingspercentage naar 41,67%, en bij een vergrote weergave naar 28,33%.

Accessibility-barrières kunnen dus ook browseragents hinderen die op semantische interactie vertrouwen. Ontbrekende labels, elementen zonder toetsenbordbediening en onduidelijke semantiek verzwakken hun accessibility snapshots, ook wanneer DOM- of screenshotcontext beschikbaar is.

De overlap: WCAG en AI agent readiness

Webtoegankelijkheid (WCAG-conformiteit) en AI agent readiness overlappen, omdat schermlezers en compatibele browseragents dezelfde semantische signalen kunnen gebruiken. De tabel laat per accessibility-practice zien welk WCAG-criterium erbij hoort, wat het een agent oplevert en welk scannercheckpoint het dekt:

Onze IsAgentReady scanner meet een deel van deze signalen in de categorie Content & Semantics. De checkpoints controleren gepubliceerde markup, zoals semantische HTML, koppenstructuur, ARIA-landmarks, alt-tekst, taalattributen en linktekst. Ze voeren geen browseragent uit en meten geen taakbegrip.

De ARIA-controverse: gebruik met voorzichtigheid

ARIA (Accessible Rich Internet Applications) kan de accessibility tree verrijken wanneer HTML alleen niet volstaat. In de accessibility-gemeenschap loopt een debat over overmatig ARIA-gebruik, dat ook voor AI agent readiness telt.

De eerste regel van ARIA luidt, vrij vertaald: "Gebruik geen ARIA als je native HTML kunt gebruiken." De WebAIM Million-analyse laat zien waarom dit ertoe doet:

Pagina's mét ARIA hebben gemiddeld 57 accessibility-fouten, pagina's zonder ARIA 27. Dat is meer dan het dubbele. Meer ARIA betekent dus niet automatisch betere toegankelijkheid, en verkeerd gebruikte ARIA maakt de accessibility tree slechter dan geen ARIA.

OpenAI's eigen documentatie voor web agents beveelt aan om ARIA-attributen toe te voegen. Roselli noemt dat een gevaarlijke oversimplificatie. Dit is de betere aanpak:

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. Denk aan custom widgets, dynamische content en complexe interacties zonder native HTML-equivalent
3. Test met echte schermlezers. Gebruik niet alleen de accessibility tree-inspector in DevTools
4. Gebruik zo weinig ARIA als mogelijk. Elk overbodig ARIA-attribuut is een mogelijke foutbron

De business case: 95% van de top 1 miljoen websites heeft WCAG-fouten

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. Die check vindt alleen de fouten die automatisch te detecteren zijn, dus het werkelijke aantal ligt waarschijnlijk hoger.

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
• Ontbrekende documenttaal (17,1%): agents verwerken content mogelijk in de verkeerde taal

Verbeteringen aan je webtoegankelijkheid versterken de semantische interactie voor compatibele browseragents, maar bewijzen niet dat je site als geheel klaar is voor AI agents. Omdat 94,8% van de top 1 miljoen websites detecteerbare WCAG-fouten heeft, is er op de meeste sites ruimte voor verbetering.

Praktische checklist: verbeter je accessibility tree

Een driedelig actieplan om je accessibility tree te verbeteren, voor gebruikers met een beperking en voor browseragents die snapshots gebruiken:

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

Eén accessibility tree, twee doelgroepen

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.

94,8% van de top 1 miljoen websites heeft detecteerbare WCAG-fouten. 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.

Webtoegankelijkheid is goed voor inclusie. Omdat 51% van al het webverkeer geautomatiseerd is, helpt dezelfde semantische structuur ook browseragents die snapshots gebruiken. Begin bij de snelle verbeteringen en werk toe naar structurele veranderingen. Onze AI agent readiness scanner helpt je 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