Toegankelijkheidsboom

De toegankelijkheidsboom is de datastructuur op besturingssysteemniveau die schermlezers en andere hulptechnologie daadwerkelijk verwerken. Wanneer een pagina in een browser wordt geopend, bouwt de browser twee bomen: de DOM-boom (de gewone HTML-hiërarchie) en de toegankelijkheidsboom, een parallelle structuur afgeleid van de DOM maar met toegankelijkheidsmetadata.

Inzicht in de toegankelijkheidsboom verklaart ruwweg 80% van het anderszins verwarrende gedrag van ARIA, schermlezers en foutopsporingssessies van het type “waarom wordt dit niet aangekondigd?”.

Inhoud

Elk knooppunt in de toegankelijkheidsboom heeft:

• Rol — wat het element is: button, link, heading, navigation, dialog. Afgeleid van het HTML-elementtype of van een expliciete ARIA role="...".
• Naam — hoe het element heet. Afgeleid van labeltekst, alt-attribuut, aria-label, aria-labelledby of berekende tekstinhoud.
• Beschrijving — aanvullende context. Afgeleid van aria-describedby of title-attributen.
• Toestand — huidige toestand: ingedrukt, uitgevouwen, aangevinkt, bezig. Afgeleid van HTML-attributen (disabled, required) of ARIA (aria-pressed, aria-expanded).
• Eigenschappen — relaties en metadata: aria-controls, aria-owns, aria-haspopup.

Schermlezers doorlopen deze boom en kondigen elk knooppunt aan op basis van deze velden. Tab- en pijltoetsnavigatie verloopt via de boom, niet via de DOM.

Waarom puur visuele inhoud verdwijnt

Een <div onclick="..."> die eruitziet als een knop heeft geen rol in de toegankelijkheidsboom — de browser ziet een generieke <div> en registreert deze als role="generic" (effectief onzichtbaar voor hulptechnologie). De onclick-handler verschijnt niet in de toegankelijkheidsboom, omdat de toegankelijkheidsboom alleen weergeeft wat de browser afleidt dat het element is op basis van zijn HTML-rol.

Dit is waarom semantische HTML op het meest fundamentele niveau telt: niet vanwege stijl of conventie, maar omdat semantische HTML-elementen de toegankelijkheidsboom automatisch vullen met de juiste rollen. Niet-semantische opmaak creëert een div-soup-boom die schermlezers niet kunnen interpreteren.

De rol van ARIA in de boom

ARIA bestaat specifiek om de toegankelijkheidsboom te vullen in gevallen waar native HTML geen overeenkomend element heeft. role="combobox" vertelt de browser een combobox-knooppunt in de boom te plaatsen voor een element dat anders als generiek zou zijn verschenen. aria-expanded="true" stelt een toestandseigenschap op dat knooppunt in.

ARIA verandert de DOM NIET. Het verandert wat de browser in de toegankelijkheidsboom schrijft.

Inspectie

Browser-DevTools stellen de toegankelijkheidsboom nu direct beschikbaar:

• Chrome / Edge DevTools — Elementenpaneel → tabblad Toegankelijkheid (rechterkolom) toont de berekende toegankelijkheidseigenschappen voor het geselecteerde knooppunt. De schakelaar “Volledige toegankelijkheidsboom” (Chrome-vlag in sommige versies) geeft de boom als zijbalk weer.
• Firefox DevTools — het Toegankelijkheidspaneel (pictogram in de werkbalk) toont een toegewijde toegankelijkheidsboomboom, vergelijkbaar met de Elementenweergave maar weergegeven in termen van de toegankelijkheidsboom.
• Safari Web Inspector — tabblad Audit / Toegankelijkheid biedt vergelijkbare inspectiemogelijkheden.

Wanneer de toegankelijkheidsboom zichtbaar is, kan de vraag “waarom wordt dit niet aangekondigd?” empirisch worden beantwoord. Het antwoord is bijna altijd: het knooppunt in de toegankelijkheidsboom heeft een andere rol dan verwacht, of de naam is leeg, of de toestand is onjuist.

Waarom “toegankelijkheidsboom” een beter mentaal model is dan “ARIA”

Ontwikkelaars die ARIA leren zonder de toegankelijkheidsboom te begrijpen, eindigen met het strooien van ARIA-attributen in de hoop dat schermlezers ze oppikken. Ontwikkelaars die de toegankelijkheidsboom begrijpen, weten dat de taak van ARIA het schrijven van specifieke velden naar specifieke knooppunten in de boom is, en dat directe inspectie van de boom sneller is dan gissen.