Tillgänglighetsträd

Tillgänglighetsträdet är den datastruktur på operativsystemnivå som skärmläsare och annan hjälpmedelsteknik faktiskt konsumerar. När du öppnar en sida i en webbläsare bygger webbläsaren två träd: DOM-trädet (den vanliga HTML-hierarkin) och tillgänglighetsträdet, en parallell struktur härledd från DOM:en men med tillgänglighetsmetadata.

Att förstå tillgänglighetsträdet förklarar ungefär 80 % av ARIA:s, skärmläsares och “varför tillkännager det inte det här?”-felsökningssessionernas annars förbryllande beteende.

Vad det innehåller

Varje nod i tillgänglighetsträdet har:

• Roll — vad elementet är: knapp, länk, rubrik, navigering, dialog. Från HTML-elementtypen eller från explicit ARIA role="...".
• Namn — vad elementet kallas. Från etikettext, alt-attribut, aria-label, aria-labelledby eller beräknat textinnehåll.
• Beskrivning — ytterligare kontext. Från aria-describedby eller title-attribut.
• Tillstånd — aktuellt tillstånd: tryckt, expanderat, markerat, pågående. Från HTML-attribut (disabled, required) eller ARIA (aria-pressed, aria-expanded).
• Egenskaper — relationer och metadata: aria-controls, aria-owns, aria-haspopup.

Skärmläsare traverserar detta träd och tillkännager varje nod utifrån dessa fält. Tabb- och pilnavigering sker genom trädet, inte DOM:en.

Varför rent visuellt innehåll försvinner

En <div onclick="...">formaterad att se ut som en knapp</div> har ingen roll i tillgänglighetsträdet — webbläsaren ser en generisk <div> och registrerar den som role="generic" (i praktiken osynlig för hjälpmedelsteknik). onclick-hanteraren hamnar inte i tillgänglighetsträdet eftersom trädet bara återspeglar vad webbläsaren härleder att elementet är utifrån dess HTML-roll.

Det är därför semantisk HTML spelar roll på den mest grundläggande nivån: inte på grund av stil eller konvention, utan för att semantiska HTML-element automatiskt fyller tillgänglighetsträdet med rätt roller. Icke-semantisk uppmärkning skapar ett div-soppa-träd som skärmläsare inte kan förstå sig på.

ARIA:s uppgift i trädet

ARIA finns specifikt för att fylla tillgänglighetsträdet i fall där inbyggd HTML saknar ett matchande element. role="combobox" talar om för webbläsaren att placera en combobox-nod i trädet för ett element som annars hade framstått som generiskt. aria-expanded="true" sätter en tillståndsegenskap på den noden.

ARIA ändrar INTE DOM:en. Det ändrar vad webbläsaren skriver in i tillgänglighetsträdet.

Hur man inspekterar det

Webbläsarens DevTools exponerar nu tillgänglighetsträdet direkt:

• Chrome / Edge DevTools — panelen Elementer → fliken Tillgänglighet (högerkolumn) visar de beräknade tillgänglighetsegenskaperna för den valda noden. Växlaren “Fullsidans tillgänglighetsträd” (Chrome-flagga i vissa versioner) visar trädet som en sidopanel.
• Firefox DevTools — Tillgänglighetspanelen (ikon i verktygsfältet) visar en dedikerad vy av tillgänglighetsträdet, liknande elementvyn men renderad i tillgänglighetsträds-termer.
• Safari Web Inspector — fliken Granskning / Tillgänglighet ger jämförbar inspektion.

När du kan se tillgänglighetsträdet kan du empiriskt besvara frågan “varför tillkännager det inte det här?”. Svaret är nästan alltid: noden i tillgänglighetsträdet har en annan roll än du trodde, eller så är dess namn tomt, eller så är dess tillstånd fel.

Varför “tillgänglighetsträd” är en bättre mental modell än “ARIA”

Ingenjörer som lär sig ARIA utan att förstå tillgänglighetsträdet strör ARIA-attribut i hopp om att skärmläsare ska plocka upp dem. Ingenjörer som förstår tillgänglighetsträdet vet att ARIA:s uppgift är att skriva specifika fält till specifika trädnoder, och att inspektera trädet direkt är snabbare än att gissa.