Accessibility-audit för React-appar: WCAG 2.2, axe-core och screen readers

Tillgänglighet behandlas ofta som något man lägger till sist, om det blir tid över. Det är fel av två skäl: det är en rättighetsfråga och i många fall ett lagkrav, och det är dramatiskt mycket dyrare att laga i efterhand än att bygga rätt. För svenska bolag skärps dessutom kraven, bland annat genom tillgänglighetsdirektivet. Den här guiden går igenom hur du faktiskt granskar och förbättrar tillgängligheten i en React-app - och varför verktygen bara tar dig halvvägs.

WCAG 2.2 i korthet

WCAG är standarden, och dess principer är enklare än lagtexten antyder: innehåll ska vara möjligt att uppfatta, gränssnitt ska gå att hantera, information ska vara begriplig, och allt ska fungera robust med olika hjälpmedel. Version 2.2 lägger till krav som tydligare fokusmarkering och att inte kräva precisa muspekningar. Nivå AA är det de flesta krav landar på, och en rimlig målnivå. Att tolka kraven konkret för just er app är en del av det jag gör inom webbutveckling.

axe-core fångar hälften - automatisera den hälften

Automatiska verktyg som axe-core är utmärkta på att fånga maskinläsbara fel: bilder utan alt-text, för svag färgkontrast, fält utan etiketter, felaktig HTML-struktur. Och de bör automatiseras - kör axe i er testsvit och i CI så att nya tillgänglighetsfel fångas direkt, precis som vilken annan bugg som helst. Det är billig, kontinuerlig kvalitet.

Men var ärlig om gränsen: automatiska verktyg fångar bara ungefär hälften av de verkliga problemen. De kan se att en knapp saknar etikett, men inte om etiketten är begriplig. De kan inte bedöma om tangentbordsnavigeringen är logisk eller om en skärmläsare faktiskt kan förstå sidan. Den andra hälften kräver människor.

Testa med tangentbord - det enklaste verkliga testet

Det mest avslöjande testet kräver inga verktyg alls: lägg undan musen och försök använda hela appen med bara tangentbordet. Kan du nå allt? Är ordningen logisk? Ser du tydligt var fokus är? Fastnar du i en meny du inte kommer ur? Den här övningen tar tio minuter och avslöjar fler verkliga problem än någon automatisk skanning. För användare som inte kan använda mus är det här hela deras upplevelse.

Testa med en skärmläsare

Nästa steg är att faktiskt lyssna på appen med en skärmläsare. Det är ovant första gången, men det är det enda sättet att förstå hur en blind användare upplever sidan. Läses knapparna upp begripligt? Annonseras det när innehåll uppdateras dynamiskt? Är formulärfel kopplade till rätt fält? Mycket som ser perfekt ut visuellt är obegripligt för en skärmläsare, och det upptäcker du bara genom att höra det.

Vanliga React-specifika fallgropar

React-appar har sina egna återkommande problem. Klickbara div:ar istället för riktiga knappar, vilket gör dem osynliga för tangentbord. Modaler som inte fångar fokus eller inte går att stänga med Escape. Dynamiska uppdateringar som sker tyst utan att meddelas. Och egna komponenter som ser ut som en select men inte beter sig som en för hjälpmedel. Använd riktiga HTML-element så långt det går - de är tillgängliga från början, till skillnad från det du bygger själv.

Bygg in det, granska löpande

Det billigaste sättet att vara tillgänglig är att bygga rätt från start och fånga regressioner löpande - axe i CI plus regelbundna manuella genomgångar av tangentbord och skärmläsare. En engångsaudit är bra, men tillgänglighet förfaller om den inte bevakas. Hur ett sådant löpande arbetssätt ser ut visar jag i kundcase.

Relaterat

Vill du ta det vidare?

Jag granskar och förbättrar tillgängligheten i React-appar - automatiserade kontroller plus den manuella granskning som verktygen inte klarar. Boka ett samtal så går vi igenom var ni står.

Vanliga frågor

Räcker axe-core för att göra vår app tillgänglig?

Nej. Automatiska verktyg som axe-core fångar ungefär hälften av de verkliga problemen - maskinläsbara fel som saknad alt-text, svag kontrast och fält utan etiketter. De kan inte bedöma om navigeringen är logisk eller om en skärmläsare förstår sidan. Den andra hälften kräver manuell testning med tangentbord och skärmläsare.

Vad är det enklaste tillgänglighetstestet vi kan göra?

Lägg undan musen och använd hela appen med bara tangentbordet. Kontrollera att du når allt, att ordningen är logisk, att fokus syns tydligt och att du inte fastnar i menyer. Övningen tar tio minuter och avslöjar fler verkliga problem än någon automatisk skanning.

Vilka tillgänglighetsfel är vanligast i React-appar?

Klickbara div:ar istället för riktiga knappar, modaler som inte fångar fokus eller inte stängs med Escape, dynamiska uppdateringar som sker tyst utan att meddelas, och egna komponenter som ser ut som standardelement men inte beter sig som dem för hjälpmedel. Använd riktiga HTML-element så långt det går.