Tillgänglighet på riktigt: det skanningsverktyget inte hittar

En tillgänglighetsrapport från ett skanningsverktyg ser ofta bra ut. Siffran längst upp är grön och listan med fel får plats på en sida. Lägg sedan undan musen och försök köpa något med bara tangentbordet. Det är inte ovanligt att det tar stopp redan i steg två.

Det är ingen motsägelse. Verktyget mätte det som går att mäta automatiskt, och gjorde det bra. Men det är bara en del av jobbet.

Vad ett automatiskt test kan avgöra

Maskinen är bra på regler med facit: har bilden ett alt-attribut, har fältet en etikett, räcker kontrasten mellan text och bakgrund. Det är värdefullt, det tar sekunder och det ska ligga i bygget så att det körs vid varje ändring.

Men mycket i WCAG handlar om sammanhang, och sammanhang kan maskinen inte bedöma. Den ser att alt-texten finns, men inte om den hjälper den som inte ser bilden. Den ser att sidan går att tabba igenom, men inte om ordningen är begriplig. Automatiska tester hittar en del av felen. Resten kräver att någon faktiskt använder gränssnittet.

Fyra vanliga fel

• Fokus som inte syns. Någon har tagit bort webbläsarens fokusmarkering för att den var ful, och aldrig ersatt den. För den som navigerar med tangentbord är det ungefär som att stänga av muspekaren.
• Dialoger som inte släpper taget. Modalen öppnas, men fokus ligger kvar bakom den. Användaren tabbar runt på en sida som inte syns, och Esc gör ingenting.
• Fel som bara markeras med färg. Fältet blir rött vid fel. En skärmläsare läser upp exakt samma sak som innan, och den som inte uppfattar rött ser bara ett formulär som vägrar skickas.
• Knappar utan namn. En ikonknapp utan text läses upp som ”knapp”. Tre sådana i rad, och användaren får gissa vilken som var ”ta bort”.

Knappen utan namn brukar verktyget hitta. De andra tre får du leta efter själv, med tangentbord, skärmläsare och egna ögon.

Testa själv på tio minuter

Du kan själv ta reda på ungefär var du står. Lägg undan musen och gå igenom det viktigaste flödet på din sajt, till exempel köpet, inloggningen eller ansökan:

1. Tabba från toppen av sidan till knappen som slutför. Kom du fram?
2. Såg du var fokus låg hela vägen, utan att leta?
3. Öppna en dialog. Hamnade fokus i den, och kom du ut med Esc?
4. Skicka formuläret med ett fel i. Fick du veta i text vilket fält som var fel?
5. Zooma till 200 procent. Försvann något, eller fick du vågrät scroll?

Fastnar du på någon av de fem har du hittat ett fel som drabbar fler än du tror. Tangentbordet används inte bara av den som har skärmläsare. Det används av den som brutit handleden, sitter med en trasig styrplatta eller helt enkelt jobbar snabbare utan mus.

Kör de automatiska testerna vid varje ändring. Men tabba igenom flödet själv innan du litar på siffran.

WCAG 2.2 flyttade kraven närmare gränssnittet

Nästan alla nya kriterier i 2.2 handlar om frontend, inte om innehåll. Knappen eller fältet som har fokus får inte döljas helt bakom till exempel ett klistrat sidhuvud. Det som styrs med dragrörelser ska gå att göra på annat sätt. Klickytor har fått ett minimikrav på storlek. Och inloggningen får inte bygga på att användaren minns eller skriver av något, om det inte finns ett alternativ. Låt lösenordshanteraren fylla i lösenordet, och titta sedan på de andra stegen: en kod från ett sms som inte går att klistra in är samma sorts problem. Varje kriterium har undantag, så läs det exakta kravet innan du bockar av.

Lagkraven lutar sig mot den europeiska standarden EN 301 549. Version 3.2.1 pekade på WCAG 2.1 nivå AA. Version 4.1.1, som ETSI publicerade i september 2026, pekar på WCAG 2.2 nivå AA. Att standarden är publicerad är inte samma sak som att den gäller juridiskt. Det sker först när EU hänvisar till den i sin officiella tidning, vilket väntas senare i år. Men riktningen är inte längre en gissning. Bygger du nytt är det billigare att sikta på 2.2 direkt än att göra om samma komponenter senare.

Rätta i komponenten, inte på sidan

Det här avgör om jobbet håller över tid. En granskningsrapport listar felen per sida, men felen sitter sällan på sidan. Samma knapp, samma fält och samma dialog återkommer på varje sida som använder dem, och rapporten räknar dem varje gång.

Rätta i komponenten. Då får varje sida som använder den samma rättning, och nästa sida som byggs med den får det rätt från början. Rättar du sida för sida kommer samma fel tillbaka så fort någon bygger något nytt.

• Lägg en synlig fokusmarkering i grunden, och gör den svår att råka ta bort.
• Låt dialogen ta hand om fokus: fånga det när den öppnas, lämna tillbaka det när den stängs.
• Skriv i text vad som är fel och koppla meddelandet till fältet. Färg räcker inte.
• Kräv ett tillgängligt namn på ikonknappar, och låt komponentbiblioteket säga ifrån när det saknas.

Vad lagen kräver, kort

Offentlig sektor har sedan 2019 omfattats av lagen om tillgänglighet till digital offentlig service. Sedan den 28 juni 2025 gäller dessutom lagen om vissa produkters och tjänsters tillgänglighet, som bygger på EU:s tillgänglighetsdirektiv. Den omfattar vissa produkter och tjänster, bland annat e-handel, banktjänster för konsumenter och delar av persontransporter. Det finns undantag, bland annat för mikroföretag som tillhandahåller tjänster. Ta reda på om du omfattas innan du gör något annat, och ta hjälp av någon som arbetar med det juridiska om du är osäker.

Omfattas du räcker det inte att uppfylla kraven. Du ska också kunna beskriva hur tjänsten uppfyller dem. Där är en automatisk siffra som svagast: den säger vad verktyget kunde mäta, inte vad en användare kan göra.

Vi går igenom gränssnitt mot grundkraven i WCAG och rättar felen i komponenterna. Så går en granskning till. Omfattas tjänsten av lagen gäller kraven även när du erbjuder den i en app. Läs om hur du väljer plattform för mobilen.