# Tjekliste til WCAG 2.2 AA for SaaS-produkter og webapps

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

Opdateret 2026-10-26

Et SaaS-produkt har to flader, hvor tilgængelighed er vigtig: den marketingside, der sælger det, og den applikation, som folk bruger hver dag. Marketingsiden fejler på samme måder som enhver hjemmeside, med lav kontrast, manglende alt-tekst og formularer uden ledetekster. Applikationen tilføjer sine egne problemer: login, der blokerer adgangskodeadministratorer, dialoger, der fanger tastaturfokus, navigation i single-page-apps, som skærmlæsere ikke opdager, datatabeller og diagrammer uden tekst, træk og slip uden alternativ og sessioner, der udløber uden varsel. Denne tjekliste gennemgår WCAG 2.2 niveau AA efter de dele, et typisk SaaS-produkt består af.

**Det vigtigste i korte træk**

- WCAG 2.2 blev en W3C-anbefaling i oktober 2023 og tilføjede ni succeskriterier, heraf seks på niveau A eller AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) betyder, at et login ikke må afhænge af, at man husker eller afskriver en adgangskode, medmindre man kan indsætte den eller bruge en adgangskodeadministrator ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Interaktive mål skal være mindst 24 × 24 CSS-pixels eller have nok plads omkring sig (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Meddelelser som »Gemt« eller »3 resultater« skal nå skærmlæsere, uden at fokus flyttes (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Købere i erhvervslivet og den offentlige sektor beder ofte om en Accessibility Conformance Report, som regel udarbejdet på VPAT-skabelonen fra Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Hvorfor betyder tilgængelighed mere for SaaS end for en brochureside?

Folk bruger et SaaS-produkt i timevis, ofte fordi deres arbejdsgiver har valgt det. En barriere på en marketingside koster en besøgende; en barriere i produktet kan forhindre nogen i at udføre deres arbejde. Derfor spørger større kunder, universiteter og offentlige myndigheder i stigende grad til tilgængelighed, før de køber, og derfor skal svaret omfatte applikationen og ikke kun hjemmesiden.

Det betyder også noget, fordi automatiske tests kun fanger en del af problemet. Værktøjer som axe-core finder fejl i markuppen, for eksempel manglende ledetekster og lav kontrast. De kan ikke afgøre, om en dialog sender fokus tilbage til det rigtige sted, om et diagrams data findes som tekst, eller om et arbejdsforløb kan gennemføres med tastaturet. En applikation har brug for både automatiske tjek og manuelle tests.

## Hvordan gør du oprettelse og login tilgængelige?

Det er ved login, at WCAG 2.2 har tilføjet det vigtigste nye krav for SaaS.

- **Tillad indsætning og adgangskodeadministratorer (3.3.8, AA).** Bloker ikke indsætning i felter til adgangskoder og koder, og brug `autocomplete="username"`, `autocomplete="current-password"` og `autocomplete="one-time-code"`, så browsere og adgangskodeadministratorer kan udfylde dem.
- **Undgå gåder som den eneste vej ind.** En CAPTCHA, der beder folk om at afskrive forvrænget tekst eller løse en gåde, er en test af kognitive funktioner. Tilbyd et alternativ, og foretræk tjek, der ikke kræver noget af brugeren ([W3C](https://www.w3.org/TR/turingtest/)).
- **Giv alle felter en ledetekst (1.3.1 og 3.3.2, A).** Brug et synligt `<label>`, der er knyttet til feltet; pladsholdertekst forsvinder, når man begynder at skrive, og er ikke en ledetekst.
- **Beskriv fejl i tekst (3.3.1, A), og foreslå rettelser (3.3.3, AA).** »Adgangskoden skal have mindst 12 tegn« hjælper; en rød kant alene gør ikke.
- **Spørg ikke to gange (3.3.7, A).** Hvis en oprettelse i flere trin allerede har spurgt om firmanavn eller adresse, så udfyld oplysningerne, eller lad brugeren vælge dem i stedet for at skrive dem igen.
- **Hold hjælpen samme sted (3.2.6, A).** Hvis du tilbyder chat, et hjælpelink eller kontaktoplysninger, så placér dem samme relative sted på hver side i forløbet.

## Hvilke formular- og fejlmønstre giver flest fejl?

Det er i formularer, at de fleste fejl i applikationer findes. WebAIM’s undersøgelse fra 2026 af en million forsider fandt manglende ledetekster i formularer på 51 % af dem ([WebAIM](https://webaim.org/projects/million/)), og applikationer har langt flere formularer end forsider.

- Giv hvert inputfelt et programmatisk navn, og gruppér betjeningselementer, der hører sammen, for eksempel radioknapper, med `<fieldset>` og `<legend>`.
- Fortæl om fejl der, hvor brugeren lægger mærke til dem: flyt fokus til en fejloversigt øverst i formularen eller til det første ugyldige felt, og link hvert punkt i oversigten til sit felt.
- Markér obligatoriske felter i tekst, ikke kun med farve (1.4.1, A).
- Send ikke formularen, og skift ikke kontekst, bare fordi nogen vælger en mulighed (3.2.2, A); vent på en udtrykkelig handling.

## Hvordan skal dialoger, menuer og popovers opføre sig?

Det er i egne komponenter, at understøttelsen af tastatur og skærmlæser oftest bryder sammen. WAI-ARIA Authoring Practices Guide beskriver den forventede adfærd for hvert mønster ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialoger**: flyt fokus ind i dialogen, når den åbner, hold Tab inde i den, mens den er åben, luk den med Escape, og send fokus tilbage til det betjeningselement, der åbnede den. Brug det indbyggede `<dialog>`-element eller `role="dialog"` med `aria-modal="true"` og et navn.
- **Ingen tastaturfælder (2.1.2, A)**: alle komponenter skal kunne forlades med tastaturet.
- **Synligt fokus (2.4.7, AA)**, der ikke er skjult bag fastlåste headere, cookiebannere eller chatwidgets (2.4.11, AA, nyt i 2.2).
- **Værktøjstip og popovers (1.4.13, AA)**, som brugeren kan lukke med Escape, som ikke forsvinder, når man holder musen over dem, og som bliver, indtil de lukkes.
- **Genveje med én tast (2.1.4, A)**: hvis et tryk på en bogstavtast udløser en handling, så lad brugeren slå genvejene fra eller tildele dem igen, eller gør dem kun aktive, når den pågældende komponent har fokus.

## Hvordan håndterer du navigation i en single-page-app?

I en single-page-app ændres URL’en, uden at en side indlæses, så skærmlæsere siger måske ikke, at der er sket noget.

- Opdater dokumentets titel ved hvert ruteskift, så hver visning har en beskrivende titel (2.4.2, A).
- Flyt fokus til den nye visnings hovedoverskrift, eller annoncer skiftet i en høflig live-region; frameworks som Next.js har en route announcer til formålet.
- Hold en logisk fokusrækkefølge (2.4.3, A): når et element er slettet, skal fokus gå til et fornuftigt naboelement, ikke tilbage til toppen af siden.
- Giv mulighed for at springe gentaget navigation over (2.4.1, A), for eksempel med et spring-til-indhold-link eller landmarks.

## Hvordan gør du dashboards, datatabeller og diagrammer tilgængelige?

- **Tabeller**: brug ægte `<table>`-markup med `<th>` og `scope` til overskriftsceller og en tabeltekst (1.3.1, A). Gitre bygget af `<div>`-elementer kræver det fulde ARIA-gittermønster, som er meget sværere at få rigtigt.
- **Diagrammer**: giv hvert diagram et tekstalternativ, der siger hovedpointen, og tilbyd dataene som en tabel (1.1.1, A). Brug ikke kun farve til at adskille dataserier (1.4.1, A); tilføj etiketter eller mønstre.
- **Kontrast**: tekst skal have 4.5:1 (1.4.3, AA), og linjer i diagrammer, ikoner og kanter på inputfelter skal have 3:1 mod deres baggrund (1.4.11, AA). Tjek mørk tilstand for sig. Vores [farvekontrasttjek](/da/color-contrast-checker) tester ethvert farvepar.
- **Statusmeddelelser (4.1.3, AA)**: »Gemt«, »Upload fuldført« og antal resultater skal bruge `role="status"` eller en live-region, så skærmlæserbrugere hører dem uden at miste deres plads.

## Hvad ændrer de nye kriterier i WCAG 2.2 for webapps?

| Kriterium | Niveau | Hvad det betyder i en app |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Fastlåste værktøjslinjer, bannere og chatwidgets må ikke dække det fokuserede element helt |
| 2.5.7 Dragging Movements | AA | Alt, der gøres ved at trække, for eksempel at omarrangere et kanban-board, skal have et alternativ med en enkelt markør, for eksempel en menu eller knapper til op og ned |
| 2.5.8 Target Size (Minimum) | AA | Knapper og links på mindst 24 × 24 CSS-pixels eller med så meget afstand, at en cirkel på 24 pixels omkring hvert mål ikke overlapper et andet |
| 3.2.6 Consistent Help | A | Hjælpelinks, chat og kontaktoplysninger samme relative sted på hver side |
| 3.3.7 Redundant Entry | A | Oplysninger, der allerede er indtastet i samme forløb, udfyldes eller kan vælges |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login uden at huske eller afskrive, medmindre indsætning, adgangskodeadministratorer eller en anden metode er tilladt |

WCAG 2.2 fjernede også 4.1.1 Parsing, som ikke længere har nogen praktisk betydning for tilgængeligheden ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Hvad med timeouts, layout og zoom?

- **Timeout af sessioner (2.2.1, A)**: advar brugeren, før en session udløber, og lad vedkommende forlænge den med en enkel handling, medmindre tidsgrænsen er afgørende eller længere end 20 timer. At gemme igangværende arbejde undgår det værste udfald.
- **Reflow (1.4.10, AA)**: indholdet skal fungere i en bredde på 320 CSS-pixels (svarende til zoom til 400 % på en skærm, der er 1280 pixels bred) uden scrolling i to retninger; datatabeller og lignende indhold er undtaget.
- **Tekstafstand (1.4.12, AA)**: større linjehøjde og bogstavafstand må ikke skære tekst af, hvilket containere med fast højde ofte gør.
- **Visningsretning (1.3.4, AA)**: lås ikke appen til stående eller liggende format, medmindre det er afgørende.

## Hvad er en ACR, og har du brug for en?

En Accessibility Conformance Report (ACR) dokumenterer, hvordan et produkt opfylder hvert tilgængelighedskriterium: understøttes, understøttes delvist eller understøttes ikke, med bemærkninger. De fleste udarbejdes på VPAT-skabelonen fra Information Technology Industry Council, som findes i udgaver for WCAG, de amerikanske Section 508-standarder og den europæiske standard EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Amerikanske føderale myndigheder skal købe tilgængelig teknologi efter Section 508 ([Section508.gov](https://www.section508.gov/)), og offentlige myndigheder i EU henviser til EN 301 549, så B2B-produkter, der sælger til disse kunder, bliver ofte bedt om en ACR under indkøbet. En ærlig ACR, hvor kendte mangler er opført, er mere nyttig for købere end en, der påstår fuld understøttelse. Den bør bygge på test af produktet, også manuel test; en automatisk scanning alene kan ikke udfylde den.

Hvis du sælger til forbrugere i EU, kan European Accessibility Act også gælde for, hvordan du sælger online; vores [guide til EAA](/da/blog/european-accessibility-act-online-stores) forklarer, hvad den omfatter. Dette er ikke juridisk rådgivning.

## Hvordan bør et SaaS-team teste tilgængelighed?

1. **Automatisér det grundlæggende.** Kør axe-core eller en lignende motor i dine end-to-end-tests og på marketingsiden, og lad builds fejle ved nye overtrædelser. Vores [gratis tilgængelighedstjek](/da/website-accessibility-checker) kører den samme motor på enhver offentlig side.
2. **Test med tastaturet.** Gennemfør dine vigtigste arbejdsforløb, for eksempel oprettelse, at lave en ny post og at ændre indstillinger, kun med Tab, Shift+Tab, Enter, mellemrumstasten, Escape og piletasterne.
3. **Test med en skærmlæser.** NVDA på Windows og VoiceOver på macOS og iOS er gratis. Tjek, at navne, roller, tilstande og meddelelser bliver læst op.
4. **Zoom og skift vinduesstørrelse.** Tjek tekstzoom på 200 % og et vindue på 320 pixels i bredden.
5. **Ret fejlene i designsystemet.** De fleste fejl kommer fra fælles komponenter; når du retter en knap eller en dialog én gang, er den rettet overalt.

## Ofte stillede spørgsmål

### Gælder WCAG for de dele af en webapp, der kræver login?

WCAG gælder for alt webindhold, også sider bag et login. Om en lov kræver, at et bestemt produkt opfylder WCAG, afhænger af jurisdiktionen og kunden, men købere, der spørger til tilgængelighed, mener som regel hele produktet.

### Kan et overlay gøre et SaaS-produkt tilgængeligt?

Nej. Overlays ændrer ikke den underliggende kode i egne komponenter, og det er netop der, applikationers fejl findes. Vores guide om [tilgængelighedsoverlays](/da/blog/accessibility-overlays-ftc-order) beskriver FTC’s indgreb over for en førende leverandør af overlays.

### Hvor meget af WCAG kan automatiske værktøjer tjekke?

Kun en del. Automatiske regler finder pålideligt manglende navne, ledetekster og kontrastfejl, men mange kriterier, for eksempel en meningsfuld fokusrækkefølge, brugbar alt-tekst og forståelige fejlmeddelelser, kræver, at et menneske vurderer dem.

### Hvilken WCAG-version bør vi gå efter?

WCAG 2.2 niveau AA er den aktuelle version. Mange love og indkøbsregler henviser stadig til WCAG 2.1 AA; opfylder man 2.2 AA, opfylder man også 2.1 AA, bortset fra det fjernede kriterium Parsing.

### Skal vi opfylde niveau AAA?

W3C anbefaler ikke at kræve AAA for hele produkter, fordi noget indhold ikke kan opfylde alle AAA-kriterier. Niveau AA er det sædvanlige mål.

## Kilder

- 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/)