Matrisen för skärmläsare:
Varför varje kombination av hjälpmedel ger en annan bild

När en tillgänglighetsgranskning visar att en webbplats ”fungerar med skärmläsare” är det påståendet nästan meningslöst utan ytterligare förtydliganden. Skärmläsare är inte en enhetlig kategori av programvara – det är komplexa applikationer som var och en implementerar sin egen tolkning av de tillgänglighets-API:er som tillhandahålls av operativsystemen, och lägger den tolkningen på webbläsarens eget tillgänglighetsträd, vilket i sig varierar avsevärt mellan olika leverantörer.

Resultatet blir en mångfacetterad samling tolkningar. En role="dialog" attributet på ett modalt element läses upp på olika sätt i JAWS 2024 med Chrome jämfört med NVDA 2024.1 med Firefox 124 och VoiceOver på macOS Sonoma med Safari 17. Det handlar inte om obetydliga skillnader i formuleringarna – de kan avgöra om en användare förstår att hen befinner sig i en modal dialogruta som låser fokus, eller om hen inte hör någonting alls.

The three-layer stack — operating system accessibility API → → screen reader engine — means that any change at any layer can produce an entirely different user experience. Browsers update their accessibility tree implementations. Screen readers update their virtual buffer strategies. OS APIs evolve. The combination testing requirement isn’t bureaucratic box-ticking; it’s a technical necessity rooted in genuine architectural divergence.

Marknaden för hjälpmedel har konsoliderats kring ett fåtal dominerande verktyg, men vart och ett av dem har unika arkitektoniska egenskaper, användargrupper och webbläsarkompatibilitet. Att förstå dessa är en förutsättning för en välgrundad prioritering av testerna.

I följande matris redovisas beteendet för vanliga ARIA-mönster och HTML-semantik hos de viktigaste kombinationerna av hjälpmedel och webbläsare. Resultaten baseras på tester som genomförts med versioner som är representativa för produktionsmiljön per första kvartalet 2025.

Förklaring: Godkänd = meddelandet var korrekt och fullständigt. Delvis godkänd = meddelandet saknade information eller var felaktigt. Underkänd = inget meddelande, felaktigt meddelande eller navigeringen fungerade inte.

Att förstå varför kombinationer skiljer sig åt – inte bara att de gör det – är avgörande för att kunna skriva kod som är robust över hela matrisen. Skillnaderna kan delas in i flera arkitektoniska kategorier.

Internet Explorer 11 upphörde att stödjas den 15 juni 2022. Microsoft tillhandahåller inte längre säkerhetsuppdateringar eller teknisk support, och Freedom Scientifics JAWS 2024 har inte officiellt stöd för IE 11. WCAG 2.2 – publicerad i oktober 2023 – innehåller framgångskriterier som 2.4.11 Fokus får inte skymmas som är beroende av CSS- och renderingsfunktioner som IE 11 inte kan stödja. JAWS+IE är inte en giltig målkombination för arbete med WCAG 2.2 AA-efterlevnad.

Med detta sagt kan team som underhåller äldre kodbaser från före 2022, eller som ger support i låsta företagsmiljöer där migreringen från IE till Edge ännu inte är klar, behöva förstå hur denna kombination har fungerat tidigare. Kombinationen JAWS/IE använde Microsoft Active Accessibility (MSAA) – ett äldre API-lager med betydligt begränsat stöd för ARIA jämfört med gränssnitten IAccessible2 (IA2) och UI Automation (UIA) som moderna webbläsare tillhandahåller. Många ARIA 1.1-mönster fungerade felaktigt eller gav inget ljud alls under MSAA.

Om ni tillhör de få företag som har en skriftlig, avtalsenlig skyldighet att stödja IE 11, ska ni betrakta den som ett kompletterande mål med ett eget, separat testförlopp – inte som en del av ett program för efterlevnad av WCAG 2.2. Den moderna kombinationen för företag är JAWS + Edge (Chromium), som använder UIA och har utmärkt stöd för ARIA.

Apples strategi för tillgänglighet skiljer sig i grunden från Microsofts. Medan JAWS och NVDA skapar en fullständig virtuell representation av dokumentet och låter användarna navigera i den representationen oberoende av fokus, arbetar VoiceOver mer direkt med det renderade tillgänglighetsträdet och ofta med det faktiska tangentbordsfokuset.

Detta innebär att mönster som fungerar genom att osynligt styra fokus – fokusförflyttningar som sker som svar på ARIA-attribut snarare än på användarinteraktion – kan störa VoiceOver på sätt som verkar oförklarliga tills man förstår skillnaden i arkitekturen. VoiceOver- användare på macOS navigerar med en separat VoiceOver-markör, men relationen mellan VoiceOver-markörens position och tangentbordsfokus är mer tätt kopplad än i JAWS:s Virtual PC Cursor-modell.

Använd denna kalkylator för att uppskatta vilken testinsats som krävs för din produkt, utifrån egenskaperna hos din användarbas, efterlevnadskrav och tillgängliga kombinationer av hjälpmedel.

Inget team har obegränsade testresurser. Målet med en täckningsstrategi är att maximera sannolikheten för att upptäcka verkliga fel som påverkar riktiga användare, inom ramen för de begränsningar som gäller för tid och verktyg. Riskviktning – att fördela testinsatserna i proportion till påverkan på användarna och arkitektoniska risker – är det professionella tillvägagångssättet.

Effektiv kombinationstestning innebär inte bara att köra samma manuella testskript i flera olika verktyg. Varje automatiserat testverktyg har unika tangentbordskommandon, navigeringsmodeller och inställningar för utskriftens detaljnivå. Ett professionellt arbetsflöde tar hänsyn till dessa skillnader och ger reproducerbara, jämförbara resultat.

Följande checklista motsvarar direkt WCAG 2.2 AA:s framgångskriterier, vilka främst valideras genom tester med skärmläsare. Varje punkt måste uppfylla kraven i alla P1-kombinationer innan en funktion anses uppfylla WCAG 2.2 AA.

Testning med skärmläsare är inte bara en punkt på en checklista för tillgänglighet. Det är en kvalitetssäkringsmetod som, när den utförs korrekt för rätt kombinationer, avslöjar fel i gränssnittet som påverkar alla användare – inte bara personer med funktionsnedsättning. Fel i fokushanteringen, dynamiskt innehåll som inte uppdateras och tillstånd som inte kommuniceras programmatiskt är brister i användbarheten som råkar upptäckas genom hjälpmedelsteknikens lins.

Den rättsliga situationen stärker det tekniska argumentet. EU:s direktiv om webbtillgänglighet, de reviderade amerikanska Section 508-standarderna, de brittiska tillgänglighetsföreskrifterna för offentliga organ och en växande våg av ADA-tvister inom den privata sektorn pekar alla mot WCAG 2.2 AA som grundläggande förväntning. Risken för rättstvister är högst där inga dokumenterade tester har genomförts – och att testa en enda kombination är ofta otillräckligt bevis på ett ärligt försök att uppfylla kraven.

På AIOPSGROUP samarbetar vi med organisationer inom finanssektorn, offentlig sektor, detaljhandeln och företagsprogramvarubranschen för att ta fram program för tillgänglighetstestning som är både noggranna och hållbara. Med noggranna menar vi att vi täcker rätt kombinationer för rätt användargrupper. Med hållbara menar vi att vi integrerar tillgänglighetstestning i CI/CD-pipelines, utbildar utvecklingsteam och skapar dynamiska testmatriser som växer i takt med produkten.

Om ert team utvecklar eller underhåller en digital produkt som riktar sig till någon del av allmänheten, handlar det inte om huruvida ni ska genomföra testning med flera olika kombinationer av skärmläsare, utan om hur ni gör det på ett effektivt sätt och i stor skala. Vi kan hjälpa er med båda delarna.