WCAG 2.2 AA-sjekkliste for SaaS-produkter og nettapplikasjoner

En WCAG 2.2 AA-sjekkliste for SaaS: innlogging, skjemaer, dialoger, navigasjon i enkeltsideapper, tabeller, diagrammer, dra og slipp, tidsavbrudd og ACR.

FixReports-redaksjonenOppdatert 26. oktober 20269 min lesing

Et SaaS-produkt har to flater der universell utforming gjelder: markedsføringsnettstedet som selger det, og applikasjonen folk bruker hver dag. Markedsføringsnettstedet feiler på de samme måtene som alle andre nettsteder, med lav kontrast, manglende alt-tekst og skjemaer uten ledetekster. Applikasjonen legger til sine egne problemer: innloggingsflyter som blokkerer passordbehandlere, dialoger som fanger tastaturfokuset, navigasjon i enkeltsideapper som skjermlesere ikke merker, datatabeller og diagrammer uten tekst, dra og slipp uten alternativ, og økter som utløper uten forvarsel. Denne sjekklisten går gjennom WCAG 2.2 nivå AA etter delene i et typisk SaaS-produkt.

Kort oppsummert

WCAG 2.2 ble en W3C-anbefaling i oktober 2023 og la til ni suksesskriterier, seks av dem på nivå A eller AA (W3C (åpnes i en ny fane)).
Accessible Authentication (3.3.8, AA) betyr at en innlogging ikke kan være avhengig av at man husker eller skriver av et passord, med mindre folk kan lime det inn eller bruke en passordbehandler (W3C (åpnes i en ny fane)).
Interaktive klikk- og trykkflater må være minst 24 × 24 CSS-piksler, eller ha nok plass rundt seg (2.5.8, AA) (W3C (åpnes i en ny fane)).
Meldinger som «Lagret» eller «3 resultater» må nå frem til skjermlesere uten at fokuset flyttes (4.1.3, AA) (W3C (åpnes i en ny fane)).
Kunder i næringslivet og offentlig sektor ber ofte om en Accessibility Conformance Report (ACR), som regel skrevet på VPAT-malen fra Information Technology Industry Council (ITI (åpnes i en ny fane)).

Hvorfor betyr universell utforming mer for SaaS enn for et brosjyrenettsted?

Folk bruker et SaaS-produkt i timevis, ofte fordi arbeidsgiveren har valgt det. En barriere på en markedsføringsside koster deg en besøkende; en barriere i produktet kan hindre noen i å gjøre jobben sin. Derfor spør større kunder, universiteter og offentlige virksomheter stadig oftere om universell utforming før de kjøper, og derfor må svaret dekke applikasjonen, ikke bare nettstedet.

Det betyr også noe fordi automatiske tester bare fanger opp en del av problemet. Verktøy som axe-core finner feil i markupen, for eksempel manglende ledetekster og lav kontrast. De kan ikke avgjøre om en dialog sender fokuset tilbake til riktig sted, om dataene i et diagram er tilgjengelige som tekst, eller om en arbeidsflyt kan fullføres med tastatur. En applikasjon trenger både automatiske kontroller og manuell testing.

Hvordan gjør du registrering og innlogging universelt utformet?

Det er i autentiseringen at WCAG 2.2 la til det viktigste nye kravet for SaaS.

Tillat innliming og passordbehandlere (3.3.8, AA). Ikke blokker innliming i passord- eller kodefelt, og bruk autocomplete="username", autocomplete="current-password" og autocomplete="one-time-code", slik at nettlesere og passordbehandlere kan fylle dem ut.
Unngå gåter som eneste vei inn. En CAPTCHA som ber folk skrive av forvrengt tekst eller løse en gåte, er en test av kognitive funksjoner. Tilby et alternativ, og velg helst kontroller som ikke krever noe av brukeren (W3C (åpnes i en ny fane)).
Gi hvert felt en ledetekst (1.3.1 og 3.3.2, A). Bruk en synlig <label> som er knyttet til feltet; plassholdertekst forsvinner når noen skriver, og er ikke en ledetekst.
Beskriv feil i tekst (3.3.1, A), og foreslå rettelser (3.3.3, AA). «Passordet må ha minst 12 tegn» hjelper; en rød ramme alene gjør det ikke.
Ikke spør to ganger (3.3.7, A). Hvis en registrering i flere trinn allerede har spurt etter firmanavn eller adresse, fyller du det ut eller lar folk velge det i stedet for å skrive det inn på nytt.
Hold hjelpen på samme sted (3.2.6, A). Hvis du tilbyr chat, en hjelpelenke eller kontaktinformasjon, plasserer du dem på samme relative sted på hver side i flyten.

Hvilke skjema- og feilmønstre gir flest feil?

Det er i skjemaene de fleste feilene i applikasjoner finnes. WebAIMs undersøkelse fra 2026 av én million forsider fant manglende ledetekster i skjemaer på 51 % av dem (WebAIM (åpnes i en ny fane)), og applikasjoner har langt flere skjemaer enn forsider.

Gi hvert inndatafelt et programmatisk navn, og grupper relaterte kontroller, for eksempel radioknapper, med <fieldset> og <legend>.
Fortell folk om feil der de vil legge merke til dem: flytt fokuset til et feilsammendrag øverst i skjemaet eller til det første ugyldige feltet, og lenk hvert punkt i sammendraget til feltet sitt.
Merk obligatoriske felt med tekst, ikke bare med farge (1.4.1, A).
Ikke send inn skjemaet eller endre kontekst bare fordi noen velger et alternativ (3.2.2, A); vent på en uttrykkelig handling.

Hvordan bør dialoger, menyer og popovere oppføre seg?

Det er i egenutviklede komponenter at støtten for tastatur og skjermleser oftest svikter. WAI-ARIA Authoring Practices Guide beskriver forventet oppførsel for hvert mønster (W3C (åpnes i en ny fane)).

Dialoger: flytt fokuset inn i dialogen når den åpnes, hold Tab inne i den mens den er åpen, lukk den med Escape, og send fokuset tilbake til kontrollen som åpnet den. Bruk det innebygde <dialog>-elementet eller role="dialog" med aria-modal="true" og et navn.
Ingen tastaturfeller (2.1.2, A): det må være mulig å forlate hver komponent med tastaturet.
Synlig fokus (2.4.7, AA) som ikke skjules bak faste topplinjer, cookie-bannere eller chat-widgeter (2.4.11, AA, nytt i 2.2).
Verktøytips og popovere (1.4.13, AA) som folk kan lukke med Escape og holde pekeren over uten at de forsvinner, og som blir værende til de lukkes.
Hurtigtaster med ett tegn (2.1.4, A): hvis et trykk på en bokstavtast utløser en handling, lar du folk slå av hurtigtastene eller endre dem, eller gjør dem aktive bare når den aktuelle komponenten har fokus.

Hvordan håndterer du navigasjon i en enkeltsideapp?

I en enkeltsideapp (single-page app) endres URL-en uten at en ny side lastes inn, så det kan hende at skjermlesere ikke sier fra om at noe har skjedd.

Oppdater dokumenttittelen ved hver ruteendring, slik at hver visning har en beskrivende tittel (2.4.2, A).
Flytt fokuset til hovedoverskriften i den nye visningen, eller kunngjør endringen i en høflig live-region (polite); rammeverk som Next.js har en ruteannonsering (route announcer) for dette.
Hold en logisk fokusrekkefølge (2.4.3, A): etter at et element er slettet, bør fokuset gå til en fornuftig nabo, ikke tilbake til toppen av siden.
Tilby en måte å hoppe over gjentatt navigasjon på (2.4.1, A), for eksempel en hopplenke eller landemerker.

Hvordan gjør du dashbord, datatabeller og diagrammer universelt utformet?

Tabeller: bruk ekte <table>-markup med <th> og scope for overskrifter, og en tabelltekst (caption) (1.3.1, A). Rutenett bygget av <div>-elementer trenger hele ARIA-mønsteret for grid, som er mye vanskeligere å få riktig.
Diagrammer: gi hvert diagram et tekstalternativ som sier hovedpoenget, og tilby dataene som en tabell (1.1.1, A). Ikke bruk bare farge for å skille dataseriene fra hverandre (1.4.1, A); legg til etiketter eller mønstre.
Kontrast: tekst trenger 4.5:1 (1.4.3, AA), og linjer i diagrammer, ikoner og kanter på inndatafelt trenger 3:1 mot bakgrunnen (1.4.11, AA). Sjekk mørk modus for seg. Vår sjekk av fargekontrast tester alle fargepar.
Statusmeldinger (4.1.3, AA): «Lagret», «Opplasting fullført» og antall resultater bør bruke role="status" eller en live-region, slik at skjermlesere hører dem uten å miste plassen sin.

Hva endrer de nye kriteriene i WCAG 2.2 for nettapplikasjoner?

Kriterium	Nivå	Hva det betyr i en app
2.4.11 Focus Not Obscured (Minimum)	AA	Faste verktøylinjer, bannere og chat-widgeter må ikke dekke elementet i fokus helt
2.5.7 Dragging Movements	AA	Alt som gjøres ved å dra, for eksempel å endre rekkefølgen på en kanban-tavle, trenger et alternativ med ett enkelt pekertrykk, for eksempel en meny eller knapper for opp og ned
2.5.8 Target Size (Minimum)	AA	Knapper og lenker er minst 24 × 24 CSS-piksler, eller har så stor avstand at en sirkel på 24 piksler rundt hver av dem ikke overlapper en annen
3.2.6 Consistent Help	A	Hjelpelenker, chat og kontaktinformasjon på samme relative sted på hver side
3.3.7 Redundant Entry	A	Informasjon som allerede er oppgitt i samme prosess, fylles ut automatisk eller kan velges
3.3.8 Accessible Authentication (Minimum)	AA	Innlogging uten å huske eller skrive av noe, med mindre innliming, passordbehandlere eller en annen metode er tillatt

WCAG 2.2 fjernet også 4.1.1 Parsing, som ikke lenger har noen praktisk betydning for universell utforming (W3C (åpnes i en ny fane)).

Hva med tidsavbrudd, layout og zoom?

Tidsavbrudd for økter (2.2.1, A): varsle folk før en økt utløper, og la dem forlenge den med en enkel handling, med mindre tidsgrensen er nødvendig eller lengre enn 20 timer. Å lagre arbeid underveis forhindrer det verste utfallet.
Reflow (1.4.10, AA): innholdet må fungere i en bredde på 320 CSS-piksler (tilsvarer zoom til 400 % på en skjerm som er 1280 piksler bred) uten rulling i to retninger; datatabeller og lignende innhold er unntatt.
Tekstavstand (1.4.12, AA): økt linjehøyde og bokstavavstand skal ikke kutte av tekst, noe beholdere med fast høyde ofte gjør.
Retning (1.3.4, AA): ikke lås appen til stående eller liggende retning med mindre det er nødvendig.

Hva er en ACR, og trenger du en?

En Accessibility Conformance Report (ACR) dokumenterer hvordan et produkt oppfyller hvert kriterium for universell utforming: støtter, støtter delvis eller støtter ikke, med merknader. De fleste skrives på VPAT-malen som Information Technology Industry Council publiserer, og som finnes i utgaver for WCAG, de amerikanske Section 508-standardene og den europeiske standarden EN 301 549 (ITI (åpnes i en ny fane)).

Amerikanske føderale etater må kjøpe universelt utformet teknologi etter Section 508 (Section508.gov (åpnes i en ny fane)), og offentlige organer i EU viser til EN 301 549, så B2B-produkter som selger til slike kunder, blir ofte bedt om en ACR i anskaffelsesprosessen. En ærlig ACR, der kjente mangler er oppført, er mer nyttig for kjøpere enn en som påstår full støtte. Den bør bygge på testing av produktet, også manuell testing; en automatisk skanning alene kan ikke fylle den ut.

Hvis du selger til forbrukere i EU, kan tilgjengelighetsdirektivet (European Accessibility Act) også gjelde for hvordan du selger på nett; vår veiledning om tilgjengelighetsdirektivet forklarer virkeområdet. Dette er ikke juridisk rådgivning.

Hvordan bør et SaaS-team teste universell utforming?

Automatiser det grunnleggende. Kjør axe-core eller en lignende motor i ende-til-ende-testene dine og på markedsføringsnettstedet, og la bygg feile ved nye brudd. Vår gratis test av universell utforming kjører den samme motoren på en hvilken som helst offentlig side.
Test med tastatur. Fullfør hovedarbeidsflytene dine, for eksempel registrering, oppretting av en post og endring av innstillinger, med bare Tab, Shift+Tab, Enter, mellomromstasten, Escape og piltastene.
Test med skjermleser. NVDA på Windows og VoiceOver på macOS og iOS er gratis. Sjekk at navn, roller, tilstander og meldinger blir lest opp.
Zoom og endre størrelse. Sjekk tekstzoom på 200 % og et vindu som er 320 piksler bredt.
Rett i designsystemet. De fleste feil kommer fra felles komponenter; når du retter en knapp eller en dialog én gang, er den rettet overalt.

Ofte stilte spørsmål

Gjelder WCAG for innloggede deler av en nettapplikasjon?

WCAG gjelder for alt nettinnhold, også sider bak innlogging. Om en lov krever at et bestemt produkt oppfyller standarden, avhenger av jurisdiksjonen og kunden, men kjøpere som spør om universell utforming, mener som regel hele produktet.

Kan et overlegg gjøre et SaaS-produkt universelt utformet?

Nei. Overlegg endrer ikke den underliggende koden i egenutviklede komponenter, og det er der feilene i applikasjoner finnes. Vår veiledning om tilgjengelighetsoverlegg omtaler FTCs tiltak mot en ledende leverandør av overlegg.

Hvor mye av WCAG kan automatiske verktøy sjekke?

Bare en del. Automatiske regler finner pålitelig manglende navn, ledetekster og kontrastfeil, men mange kriterier, som meningsfull fokusrekkefølge, nyttig alt-tekst og forståelige feilmeldinger, krever at et menneske vurderer dem.

Hvilken WCAG-versjon bør vi sikte mot?

WCAG 2.2 nivå AA er den gjeldende versjonen. Mange lover og anskaffelsesregler viser fortsatt til WCAG 2.1 AA; når du oppfyller 2.2 AA, oppfyller du også 2.1 AA, bortsett fra det fjernede Parsing-kriteriet.

Må vi oppfylle nivå AAA?

W3C anbefaler ikke å kreve AAA for hele produkter, fordi noe innhold ikke kan oppfylle alle AAA-kriteriene. Nivå AA er det vanlige målet.