Begreber

Tilgængelighedstræ

Se også: a11y tree, accessibility object model, AOM

Den interne datastruktur, som browsere og operativsystemer opbygger fra DOM'en, og som mapper hvert element til en rolle, et navn, en tilstand og relationer — de data, som skærmlæsere og anden hjælpeteknologi faktisk gennemgår.

Tilgængelighedstræet er den operativsystemniveau-datastruktur, som skærmlæsere og anden hjælpeteknologi faktisk forbruger. Når man åbner en side i en browser, opbygger browseren to træer: DOM-træet (det almindelige HTML-hierarki) og tilgængelighedstræet, en parallel struktur afledt af DOM’en, men med tilgængelighedsmetadata.

At forstå tilgængelighedstræet forklarer ca. 80 % af den ellers forvirrende adfærd fra ARIA, skærmlæsere og „hvorfor annoncerer dette ikke?“- fejlfindingssessioner.

Hvad det indeholder

Hver knude i tilgængelighedstræet har:

  • Rolle — hvad elementet er: button, link, heading, navigation, dialog. Fra HTML-elementtypen eller fra eksplicit ARIA role="...".
  • Navn — hvad elementet hedder. Fra labeltekst, alt-attribut, aria-label, aria-labelledby eller beregnet tekstindhold.
  • Beskrivelse — yderligere kontekst. Fra aria-describedby- eller title-attributter.
  • Tilstand — aktuel tilstand: pressed, expanded, checked, busy. Fra HTML-attributter (disabled, required) eller ARIA (aria-pressed, aria-expanded).
  • Egenskaber — relationer og metadata: aria-controls, aria-owns, aria-haspopup.

Skærmlæsere gennemgår dette træ og annoncerer hver knude baseret på disse felter. Tab- og piletastenavigation rutes igennem træet, ikke DOM’en.

Hvorfor rent visuelt indhold forsvinder

En <div onclick="...">styled til at ligne en knap</div> har ingen rolle i tilgængelighedstræet — browseren ser en generisk <div> og registrerer den som role="generic" (effektivt usynlig for hjælpeteknologi). onclick- handleren flyttes ikke ind i tilgængelighedstræet, fordi træet kun afspejler, hvad browseren slutter, at elementet er ud fra dets HTML-rolle.

Det er derfor semantisk HTML er vigtig på det mest grundlæggende niveau: ikke på grund af stil eller konvention, men fordi semantiske HTML-elementer automatisk udfylder tilgængelighedstræet med de rigtige roller. Ikke- semantisk markup skaber et div-suppe-træ, som skærmlæsere ikke kan give mening til.

ARIA’s opgave i træet

ARIA eksisterer specifikt for at udfylde tilgængelighedstræet i de tilfælde, hvor native HTML ikke har et matchende element. role="combobox" fortæller browseren at sætte en combobox-knude i træet for et element, der ellers ville have fremstået som generisk. aria-expanded="true" sætter en tilstandsegenskab på den knude.

ARIA ændrer IKKE DOM’en. Det ændrer, hvad browseren skriver ind i tilgængelighedstræet.

Sådan inspicerer man det

Browser-DevTools eksponerer nu tilgængelighedstræet direkte:

  • Chrome / Edge DevTools — Elements-panelet → Accessibility-fanen (højre kolonne) viser de beregnede tilgængelighedsegenskaber for den valgte knude. „Full-page accessibility tree“-til/fra-knappen (Chrome- flag i nogle versioner) viser træet som en sidebjælke.
  • Firefox DevTools — Accessibility-panelet (ikonet i værktøjslinjen) viser en dedikeret tilgængelighedstræ-visning, svarende til Elements-visningen men gengivet i tilgængelighedstræ-termer.
  • Safari Web Inspector — Audit / Accessibility-fanen giver tilsvarende inspektion.

Når man kan se tilgængelighedstræet, kan man besvare spørgsmålet „hvorfor annoncerer dette ikke?“ empirisk. Svaret er næsten altid: knuden i tilgængelighedstræet har en anden rolle end forventet, eller dens navn er tomt, eller dens tilstand er forkert.

Hvorfor „tilgængelighedstræ“ er en bedre mental model end „ARIA“

Udviklere, der lærer ARIA uden at forstå tilgængelighedstræet, ender med at drysse ARIA-attributter ud i håb om, at skærmlæsere opfanger dem. Udviklere, der forstår tilgængelighedstræet, ved, at ARIA’s opgave er at skrive specifikke felter ind i specifikke træknuder, og at direkte inspektion af træet er hurtigere end at gætte.