Tillgänglighetsträdet: så läser skärmläsaren din sida
En knapp har rätt text på skärmen. En skärmläsare läser ändå fel namn, eller ingenting alls. Skillnaden mellan hur något ser ut och hur det faktiskt exponeras för en skärmläsare ligger i ett steg de flesta utvecklare aldrig tittat på: tillgänglighetsträdet.
Vad tillgänglighetsträdet faktiskt är
När webbläsaren laddar en sida bygger den flera modeller av innehållet. HTML blir DOM-trädet, CSS blir CSSOM. Webbläsaren kombinerar de två och bygger ytterligare två träd. Layoutträdet visas på skärmen, tillgänglighetsträdet görs tillgängligt för skärmläsare och annan assisterande teknik.
TetraLogicals Craig Abbott beskriver processen i en genomgång publicerad 22 september. Webbläsaren går igenom varje element och avgör om det har betydelse i sammanhanget. Har det det, skapas en nod i trädet. Har det inte det, ignoreras det helt, i Abbotts egna ord: "creates a reference node for it, or ignores it completely." Varje nod i trädet får tre centrala egenskaper: namn, roll och tillstånd/värde. Om de tre låter bekanta är det för att de är exakt det som krävs av WCAG 4.1.2 Name, Role, Value.
Samma komponent, två olika bilder
Ta en vanlig kryssruta med en kopplad <label>. I HTML-koden ser man två separata element som hänger ihop via for- och id-attribut, en type, ett checked. För att räkna ut vad en skärmläsare kommer säga måste man själv koppla ihop alla delarna i huvudet.
I tillgänglighetsträdet är samma komponent en enda nod: en kryssruta med namnet "Accept terms and conditions", markerad som fokuserbar. Namn, roll, giltighet, fokuserbarhet och ikryssat läge ligger färdigberäknade i samma nod, klara att läsa av. TetraLogical: "instead of two elements, 14 classes and a generated ID to sift through, we just have to look at a single node."
Så hittar du det i din egen webbläsare
Både Chrome och Firefox har inbyggda verktyg för det här. I Chrome öppnar du devtools, letar upp fliken "Accessibility" bredvid "Styles" och "Computed", och slår på togglen "show accessibility tree". I Firefox hittar du en egen Accessibility-panel under webbutvecklarverktygen, med inbyggda kontroller för saknade namn och kontrastfel.
Trädet visar noderna i samma ordning som en skärmläsare faktiskt läser upp dem, vilket inte alltid är samma ordning som i DOM:en eller på skärmen. Väljer du en nod ser du dess beräknade namn, roll och tillstånd direkt i panelen.
Inte bara för skärmläsare
Tillgänglighetsträdet driver mer än skärmläsare. Röststyrning, till exempel Windows Voice Access, använder samma träd för att hitta rätt kontroll när du säger "klicka på Fortsätt". Webbläsartillägg och automatiserade testverktyg gör detsamma, via operativsystemens egna tillgänglighets-API:er (AX API på Mac, UI Automation på Windows, AT-SPI på Linux).
Vad det betyder för era komponenter
Bygger ni med <slot>, skuggträd (shadow DOM) eller egna webbkomponenter är det precis här saker brukar gå fel. Vi skrev nyligen om samma mönster i vår genomgång av Safari 27.0:s 32 tillgänglighetsfixar. Namn och roller som ser rätt ut i koden kan ändå landa fel i trädet. Orsaken är hur webbläsaren tolkar aria-labelledby och aria-owns mot slottat innehåll.
TetraLogicals egna råd, samlade till fem punkter:
- Kontrollera att namn, roll och tillstånd stämmer för varje element.
- Kontrollera läsordningen, den kan skilja sig från den visuella ordningen.
- Kontrollera att inget viktigt döljs av misstag.
- Kontrollera att inget dekorativt exponeras av misstag.
- Luta er på semantisk HTML i stället för att mikrostyra trädet med ARIA-attribut.
Vill ni ha hjälp att verifiera att era komponenter exponerar rätt namn och roll? Boka en tillgänglighetsanalys.
Karin Holm Grundare, Holm Digital AB