# WCAG 2.2 AA-checklista för SaaS-produkter och webbappar

<https://www.fixreports.com/sv/blog/wcag-2-2-checklist-saas-web-apps>

Uppdaterad 2026-10-26

En SaaS-produkt har två ytor där tillgänglighet spelar roll: marknadsföringssajten som säljer den och applikationen som människor använder varje dag. Marknadsföringssajten brister på samma sätt som vilken webbplats som helst, med låg kontrast, saknad alt-text och formulär utan etiketter. Applikationen lägger till egna problem: inloggningar som blockerar lösenordshanterare, dialogrutor som fångar tangentbordsfokus, navigering i en ensidesapplikation som skärmläsare inte märker, datatabeller och diagram utan text, dra och släpp utan alternativ och sessioner som går ut utan förvarning. Den här checklistan går igenom WCAG 2.2 nivå AA utifrån delarna i en typisk SaaS-produkt.

**Det viktigaste i korthet**

- WCAG 2.2 blev en W3C-rekommendation i oktober 2023 och lade till nio framgångskriterier, varav sex på nivå A eller AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) innebär att en inloggning inte får förutsätta att man minns eller skriver av ett lösenord, om man inte kan klistra in det eller använda en lösenordshanterare ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Interaktiva mål måste vara minst 24 × 24 CSS-pixlar, eller ha tillräckligt med utrymme runt sig (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Meddelanden som ”Sparat” eller ”3 resultat” måste nå skärmläsare utan att fokus flyttas (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Företagskunder och offentliga köpare ber ofta om en tillgänglighetsrapport (Accessibility Conformance Report, ACR), som oftast skrivs i VPAT-mallen från Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Varför spelar tillgänglighet större roll för SaaS än för en broschyrsajt?

Människor använder en SaaS-produkt i timmar, ofta för att deras arbetsgivare har valt den. Ett hinder på en marknadsföringssida kostar dig en besökare; ett hinder i produkten kan hindra någon från att göra sitt jobb. Därför frågar större kunder, universitet och offentliga organisationer allt oftare om tillgänglighet innan de köper, och därför behöver svaret omfatta applikationen, inte bara webbplatsen.

Det spelar också roll eftersom automatiska tester bara fångar en del av problemet. Verktyg som axe-core hittar fel i koden, till exempel saknade etiketter och låg kontrast. De kan inte avgöra om en dialogruta återför fokus till rätt plats, om ett diagrams data finns tillgängliga som text eller om ett arbetsflöde kan slutföras med tangentbordet. En applikation behöver både automatiska kontroller och manuell testning.

## Hur gör du registrering och inloggning tillgängliga?

Det är för inloggning som WCAG 2.2 lade till det viktigaste nya kravet för SaaS.

- **Tillåt inklistring och lösenordshanterare (3.3.8, AA).** Blockera inte inklistring i fält för lösenord eller koder, och använd `autocomplete="username"`, `autocomplete="current-password"` och `autocomplete="one-time-code"` så att webbläsare och lösenordshanterare kan fylla i dem.
- **Undvik pussel som enda väg in.** En CAPTCHA som ber människor skriva av förvrängd text eller lösa ett pussel är ett test av kognitiv funktion. Erbjud ett alternativ och välj hellre kontroller som inte kräver någon åtgärd av användaren ([W3C](https://www.w3.org/TR/turingtest/)).
- **Ge varje fält en etikett (1.3.1 och 3.3.2, A).** Använd en synlig `<label>` som är kopplad till fältet; platshållartext försvinner när någon skriver och är ingen etikett.
- **Beskriv fel i text (3.3.1, A) och föreslå rättelser (3.3.3, AA).** ”Lösenordet måste ha minst 12 tecken” hjälper; enbart en röd ram gör det inte.
- **Fråga inte två gånger (3.3.7, A).** Om en registrering i flera steg redan har frågat efter företagsnamn eller adress, fyll i dem eller låt användaren välja dem i stället för att skriva in dem igen.
- **Håll hjälpen på samma plats (3.2.6, A).** Om du erbjuder chatt, en hjälplänk eller kontaktuppgifter, placera dem på samma relativa plats på varje sida i flödet.

## Vilka formulär- och felmönster orsakar flest fel?

Det är i formulären de flesta fel i applikationer finns. WebAIM:s undersökning 2026 av en miljon startsidor hittade saknade formuläretiketter på 51 % av dem ([WebAIM](https://webaim.org/projects/million/)), och applikationer har mycket fler formulär än startsidor.

- Ge varje fält ett programmatiskt namn, och gruppera relaterade kontroller, som radioknappar, med `<fieldset>` och `<legend>`.
- Berätta om fel där de märks: flytta fokus till en felsammanfattning överst i formuläret, eller till det första ogiltiga fältet, och länka varje punkt i sammanfattningen till sitt fält.
- Markera obligatoriska fält med text, inte bara med färg (1.4.1, A).
- Skicka inte formuläret och byt inte kontext bara för att någon väljer ett alternativ (3.2.2, A); vänta på en uttrycklig åtgärd.

## Hur ska dialogrutor, menyer och popover-rutor bete sig?

Det är i anpassade komponenter som stödet för tangentbord och skärmläsare oftast går sönder. WAI-ARIA Authoring Practices Guide beskriver det förväntade beteendet för varje mönster ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialogrutor**: flytta fokus in i dialogrutan när den öppnas, håll Tab inom den medan den är öppen, stäng den med Escape och återför fokus till kontrollen som öppnade den. Använd det inbyggda elementet `<dialog>` eller `role="dialog"` med `aria-modal="true"` och ett namn.
- **Inga tangentbordsfällor (2.1.2, A)**: det måste gå att lämna varje komponent med tangentbordet.
- **Synligt fokus (2.4.7, AA)** som inte döljs bakom fasta sidhuvuden, cookiebanners eller chattwidgetar (2.4.11, AA, nytt i 2.2).
- **Verktygstips och popover-rutor (1.4.13, AA)** som går att stänga med Escape, som går att hovra över utan att de försvinner och som ligger kvar tills de stängs.
- **Kortkommandon med ett enda tecken (2.1.4, A)**: om ett tryck på en bokstavstangent utlöser en åtgärd, låt användarna stänga av eller ändra kortkommandona, eller gör dem aktiva bara när den aktuella komponenten har fokus.

## Hur hanterar du navigering i en ensidesapplikation?

I en ensidesapplikation (SPA) ändras URL:en utan att sidan laddas om, så skärmläsare kanske inte meddelar att något har hänt.

- Uppdatera dokumentets titel vid varje vägbyte, så att varje vy har en beskrivande titel (2.4.2, A).
- Flytta fokus till den nya vyns huvudrubrik, eller meddela ändringen i en artig live-region (polite live region); ramverk som Next.js har en inbyggd vägannonserare (route announcer) för detta.
- Behåll en logisk fokusordning (2.4.3, A): när ett objekt raderas bör fokus hamna på ett rimligt grannelement, inte överst på sidan.
- Erbjud ett sätt att hoppa förbi upprepad navigering (2.4.1, A), till exempel en hopplänk eller landmärken.

## Hur gör du instrumentpaneler, datatabeller och diagram tillgängliga?

- **Tabeller**: använd riktig `<table>`-kod med `<th>` och `scope` för rubriker, och en tabellrubrik (1.3.1, A). Rutnät byggda av `<div>`-element behöver hela ARIA-mönstret för grid, som är mycket svårare att få rätt.
- **Diagram**: ge varje diagram ett textalternativ som anger huvudbudskapet, och erbjud data som en tabell (1.1.1, A). Förlita dig inte enbart på färg för att skilja dataserier åt (1.4.1, A); lägg till etiketter eller mönster.
- **Kontrast**: text behöver 4.5:1 (1.4.3, AA), och linjer i diagram, ikoner och fältkanter behöver 3:1 mot bakgrunden (1.4.11, AA). Kontrollera mörkt läge separat. Vår [kontroll av färgkontrast](/sv/color-contrast-checker) testar valfritt färgpar.
- **Statusmeddelanden (4.1.3, AA)**: ”Sparat”, ”Uppladdningen är klar” och antal resultat bör använda `role="status"` eller en live-region, så att skärmläsare läser upp dem utan att användaren tappar bort var hen är.

## Vad ändrar de nya kriterierna i WCAG 2.2 för webbappar?

| Kriterium | Nivå | Vad det innebär i en app |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Fasta verktygsfält, banners och chattwidgetar får inte helt dölja elementet med fokus |
| 2.5.7 Dragging Movements | AA | Allt som görs genom att dra, till exempel att ändra ordning på en kanbantavla, behöver ett alternativ med en enda pekare, till exempel en meny eller knappar för upp och ned |
| 2.5.8 Target Size (Minimum) | AA | Knappar och länkar är minst 24 × 24 CSS-pixlar, eller placerade så att en cirkel på 24 pixlar runt var och en inte överlappar någon annan |
| 3.2.6 Consistent Help | A | Hjälplänkar, chatt och kontaktuppgifter på samma relativa plats på varje sida |
| 3.3.7 Redundant Entry | A | Uppgifter som redan angetts i samma process fylls i automatiskt eller går att välja |
| 3.3.8 Accessible Authentication (Minimum) | AA | Inloggning utan att memorera eller skriva av, om inte inklistring, lösenordshanterare eller en annan metod tillåts |

WCAG 2.2 tog också bort 4.1.1 Parsing, som inte längre har någon praktisk betydelse för tillgängligheten ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Hur är det med tidsgränser, layout och zoom?

- **Tidsgränser för sessioner (2.2.1, A)**: varna användarna innan en session går ut och låt dem förlänga den med en enkel åtgärd, om inte tidsgränsen är nödvändig eller längre än 20 timmar. Att spara påbörjat arbete förhindrar det värsta utfallet.
- **Omflödning (1.4.10, AA)**: innehållet måste fungera vid 320 CSS-pixlars bredd (motsvarande zoom till 400 % på en skärm som är 1280 pixlar bred) utan rullning i två riktningar; datatabeller och liknande innehåll är undantagna.
- **Textavstånd (1.4.12, AA)**: större radhöjd och teckenavstånd ska inte klippa av text, vilket behållare med fast höjd ofta gör.
- **Orientering (1.3.4, AA)**: lås inte appen i stående eller liggande läge om det inte är nödvändigt.

## Vad är en ACR, och behöver du en?

En tillgänglighetsrapport (Accessibility Conformance Report, ACR) dokumenterar hur en produkt uppfyller varje tillgänglighetskriterium: stöds, stöds delvis eller stöds inte, med kommentarer. De flesta skrivs i VPAT-mallen som publiceras av Information Technology Industry Council, med utgåvor för WCAG, de amerikanska Section 508-standarderna och den europeiska standarden EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Amerikanska federala myndigheter måste köpa tillgänglig teknik enligt Section 508 ([Section508.gov](https://www.section508.gov/)), och offentliga organ i EU hänvisar till EN 301 549, så B2B-produkter som säljs till sådana kunder får ofta frågan om en ACR vid upphandlingen. En ärlig ACR där kända brister redovisas är mer användbar för köparna än en som påstår fullt stöd. Den bör bygga på tester av produkten, inklusive manuella tester; en automatisk skanning räcker inte för att fylla i den.

Om du säljer till konsumenter i EU kan tillgänglighetsdirektivet också gälla hur du säljer online; vår [guide till tillgänglighetsdirektivet](/sv/blog/european-accessibility-act-online-stores) förklarar dess räckvidd. Det här är inte juridisk rådgivning.

## Hur bör ett SaaS-team testa tillgänglighet?

1. **Automatisera grunderna.** Kör axe-core eller en liknande motor i dina end-to-end-tester och på marknadsföringssajten, och låt byggen misslyckas vid nya överträdelser. Vårt [kostnadsfria tillgänglighetstest](/sv/website-accessibility-checker) kör samma motor på valfri offentlig sida.
2. **Testa med tangentbordet.** Gå igenom dina viktigaste arbetsflöden, som registrering, att skapa en post och att ändra inställningar, med bara Tab, Skift+Tab, Enter, mellanslag, Escape och piltangenterna.
3. **Testa med en skärmläsare.** NVDA i Windows och VoiceOver i macOS och iOS är gratis. Kontrollera att namn, roller, tillstånd och meddelanden läses upp.
4. **Zooma och ändra storlek.** Kontrollera 200 % textzoom och ett fönster som är 320 pixlar brett.
5. **Åtgärda i designsystemet.** De flesta fel kommer från gemensamma komponenter; om du åtgärdar en knapp eller dialogruta en gång åtgärdas den överallt.

## Vanliga frågor

### Gäller WCAG för de inloggade delarna av en webbapp?

WCAG gäller för allt webbinnehåll, även sidor bakom en inloggning. Om en lag kräver att en viss produkt uppfyller riktlinjerna beror på jurisdiktion och kund, men köpare som frågar om tillgänglighet menar oftast hela produkten.

### Kan en overlay göra en SaaS-produkt tillgänglig?

Nej. Overlays ändrar inte den underliggande koden i anpassade komponenter, och det är där felen i applikationer finns. Vår guide om [tillgänglighetsoverlays](/sv/blog/accessibility-overlays-ftc-order) beskriver FTC:s åtgärder mot en ledande leverantör av overlays.

### Hur stor del av WCAG kan automatiska verktyg kontrollera?

Bara en del. Automatiska regler hittar tillförlitligt saknade namn, etiketter och kontrastfel, men många kriterier, som meningsfull fokusordning, användbar alt-text och begripliga felmeddelanden, kräver en människas bedömning.

### Vilken WCAG-version bör vi sikta på?

WCAG 2.2 nivå AA är den aktuella versionen. Många lagar och upphandlingsregler hänvisar fortfarande till WCAG 2.1 AA; den som uppfyller 2.2 AA uppfyller också 2.1 AA, bortsett från det borttagna kriteriet Parsing.

### Måste vi uppfylla nivå AAA?

W3C rekommenderar inte att man kräver AAA för hela produkter, eftersom visst innehåll inte kan uppfylla alla AAA-kriterier. Nivå AA är det vanliga målet.

## Källor

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)