Hva er nytt i WCAG 2.2? De 9 nye kriteriene på godt norsk

En tastaturbruker går gjennom kassen din med Tab-tasten. Fokus lander på «Betal nå»-knappen, men et fast cookie-banner ligger oppå den, så brukeren ser ikke hvor fokus er. Etter WCAG 2.1 kunne siden fortsatt bestått. Etter WCAG 2.2 stryker den.

Det er den typen hull oppdateringen til 2.2 tetter. Nedenfor får hvert nye suksesskriterium samme behandling: hva det sier, hvem det hjelper, en rask test og den vanlige løsningen. Vil du ha de fire prinsippene og nivåene samlet på én side, se WCAG 2.2-referansen vår.

Hva er WCAG 2.2?

WCAG 2.2 er gjeldende versjon av Web Content Accessibility Guidelines, W3C-standarden som de fleste lover og kontrakter om tilgjengelighet viser til. Den ble en W3C-anbefaling 5. oktober 2023 (åpnes i en ny fane), ble oppdatert 12. desember 2024 (åpnes i en ny fane) og ble godkjent som ISO/IEC 40500:2025 (åpnes i en ny fane) i oktober 2025.

WCAG består av testbare krav som kalles suksesskriterier, hvert med et nivå: A (minimum), AA (det lovene som regel krever) eller AAA (det strengeste). «Vi trenger WCAG 2.2 AA» betyr alle kriterier på nivå A og AA i versjon 2.2. Spesifikasjonen sier at 2.2 «bygger på og er bakoverkompatibel med WCAG 2.1», så den utvider 2.1 i stedet for å erstatte den.

Hva er endret fra WCAG 2.1 til 2.2?

WCAG 2.2 legger til ni suksesskriterier og fjerner ett. Seks av de nye er på nivå A eller AA og teller dermed mot det vanlige AA-målet: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 og 3.3.8. De tre andre er AAA. Kriteriet som er fjernet, er 4.1.1 Parsing, som W3C nå beskriver som foreldet.

4.1.1 Parsing sjekket feil i koden, for eksempel dupliserte ID-er. WCAG 2 FAQ (åpnes i en ny fane) forklarer at slike problemer nå fanges opp av andre kriterier, som 4.1.2 Navn, rolle, verdi. Men det er en hake: krever en kontrakt fortsatt WCAG 2.0 eller 2.1, kan det hende du «må fortsette å teste og rapportere 4.1.1».

Fokus ikke skjult og fokusutseende: ser tastaturbrukere hvor de er?

Disse kriteriene sørger for at elementet med tastaturfokus er synlig. På nivå AA (2.4.11) må en lenke eller knapp med fokus ikke skjules helt av innhold du har lagt til, som en fast toppmeny, et cookie-banner eller en chatteboble. På AAA får ingenting dekke noen del av den (2.4.12), og fokusrammen må være stor og ha tydelig kontrast (2.4.13).

• Hvem det hjelper: seende som bruker tastatur i stedet for mus, ofte på grunn av en motorisk funksjonsnedsettelse. Ser de ikke fokus, må de gjette.
• Rask test: last inn en lang side med cookie-banner, fast toppmeny og chatwidget synlige samtidig, og trykk Tab mange ganger. Forsvinner fokus helt bak noe, er det brudd på 2.4.11.
• Vanlig løsning: legg til scroll-padding i CSS som tilsvarer høyden på den faste toppmenyen eller bunnfeltet, slik at nettleseren ruller elementer med fokus fri av den. W3C oppgir dette som en tilstrekkelig teknikk (åpnes i en ny fane). Et banner kan også bestå hvis det er modalt og må lukkes først.

Fokusutseende (2.4.13) krever en indikator som er minst like stor som en 2 CSS-piksler tykk ramme rundt komponenten, med en kontrastendring på minst 3:1 mellom tilstanden med og uten fokus. Det er AAA, men en heltrukken ramme på 2 piksler i en kraftig farge holder som regel. Guiden vår om fargekontrast forklarer hvordan du måler 3:1.

Drabevegelser og målstørrelse: kan folk bruke nettstedet uten presis peking?

Disse to kriteriene på nivå AA hjelper dem som synes finmotorisk styring av pekeren er vanskelig. 2.5.7 sier at alt du kan gjøre ved å dra, også må fungere med enkeltklikk eller enkelttrykk. 2.5.8 sier at mål skal være minst 24 × 24 CSS-piksler, eller ha slik avstand at en sirkel på 24 piksler sentrert på hvert mål ikke berører et annet mål.

2.5.7 Drabevegelser

Tenk på en glidebryter for prisintervall i filtrene i en nettbutikk, eller en ønskeliste du sorterer ved å dra. For en som har skjelving eller bruker hodepeker, kan trykk-hold-flytt-slipp være svært vanskelig.

Rask test: fullfør hver dra-oppgave bare med klikk eller trykk. Vanlig løsning: la folk klikke hvor som helst på glidebryterens spor, legg til feltene «min» og «maks» ved siden av, eller legg til knappene «Flytt opp» og «Flytt ned» i sorterbare lister. Tastaturstøtte alene er ikke nok: W3Cs Understanding-dokument (åpnes i en ny fane) sier at tastaturalternativ «ikke automatisk oppfyller dette suksesskriteriet».

2.5.8 Målstørrelse (minimum)

De vanlige feilene er små «×»-knapper i popup-vinduer, tettpakkede sidetall, stjernevurderinger og rader med ikoner for sosiale medier. Å treffe feil er irriterende for alle og en reell barriere for dem med nedsatt finmotorikk.

• Unntak: lenker inne i en setning, mål med en tilsvarende kontroll et annet sted på siden som har riktig størrelse, kontroller som nettleseren gir størrelse og som du ikke har stylet om, og tilfeller der en bestemt størrelse er avgjørende eller lovpålagt.
• Rask test: prøv alle små ikoner og knapper på en mobil; vil du måle et av dem, kan du inspisere det i nettleserens utviklerverktøy.
• Vanlig løsning: legg til padding. Det klikkbare området blir større selv om ikonet ser likt ut. Og se på 24 piksler som et minimum: det eldre AAA-kriteriet 2.5.5 krever 44 × 44.

Konsekvent hjelp og overflødig inntasting: får du folk til å lete eller gjenta seg selv?

Begge er på nivå A. 3.2.6 Konsekvent hjelp sier at hvis hjelp som kontaktinformasjon, chat eller en lenke til ofte stilte spørsmål finnes på flere sider, må den stå i samme rekkefølge i forhold til resten av siden hver gang. 3.3.7 Overflødig inntasting sier at folk ikke skal måtte skrive inn igjen informasjon de allerede har gitt i samme prosess.

Konsekvent hjelp forplikter deg ikke til å tilby hjelp i det hele tatt. Det sier bare at hvis telefonnummeret står i toppfeltet på produktsidene, skal det ikke flytte seg til bunnfeltet i kassen, der folk trenger det mest. Personer med hukommelses- eller oppmerksomhetsvansker har mest nytte av dette. Løsningen er som regel en felles mal, ikke å plassere hjelpen side for side.

Overflødig inntasting gjelder skjemaer i flere steg. Et bestillingsskjema som spør etter e-postadressen i steg 1 og igjen i steg 3, stryker, og det samme gjør en kasse som får deg til å skrive inn en identisk fakturaadresse på nytt. Fyll ut feltet automatisk eller la folk velge det, for eksempel med en avkrysningsboks for «Fakturaadressen er den samme som leveringsadressen». Unntakene: når ny inntasting er nødvendig, kreves av sikkerhetshensyn eller når den tidligere informasjonen ikke lenger er gyldig.

Tilgjengelig autentisering: kan folk logge inn uten en hukommelsestest?

Suksesskriterium 3.3.8 (nivå AA) sier at ingen steg i innloggingen får bygge på en kognitiv funksjonstest, som å huske et passord, skrive av forvrengte tegn eller løse en gåte, med mindre du tilbyr et alternativ eller noe som hjelper. I praksis: la passordbehandlere fylle ut feltene, tillat innliming, og tilby en metode som ikke er avhengig av hukommelsen.

WCAG definerer en kognitiv funksjonstest som «en oppgave som krever at brukeren husker, bearbeider eller skriver av informasjon». Å skrive inn navn, e-postadresse eller telefonnummer teller ikke, fordi det er personlig for deg og likt overalt. Et innloggingssteg består på AA hvis det tilbyr minst ett av disse:

• Et alternativ uten kognitiv test, for eksempel en passnøkkel eller en innloggingslenke på e-post.
• En mekanisme som hjelper, for eksempel støtte for passordbehandlere, eller kopier og lim inn slik at en engangskode ikke må skrives inn på nytt.
• Gjenkjenning av objekter, for eksempel «velg bildene med en sykkel».
• Personlig innhold, som å kjenne igjen et bilde du har lastet opp selv.

AAA-versjonen, 3.3.9, fjerner de to siste valgene, så en bilde-CAPTCHA kan bestå på AA, men ikke på AAA. Typiske feil: passordfelt som blokkerer innliming eller passordbehandlere, felt for engangskoder som slutter å virke når du limer inn, og en tekst-CAPTCHA uten alternativ. Personer med dysleksi eller hukommelsesvansker har mest å vinne, men alle som har blitt låst ute etter en lang dag, kjenner igjen problemet.

Er WCAG 2.2 et lovkrav?

Det avhenger av hvor du er og hvem du er. Lover nevner sjelden en WCAG-versjon direkte, og flere viser fortsatt til WCAG 2.1 AA. Fordi WCAG 2.2 er bakoverkompatibel, oppfyller 2.2 AA også 2.1 AA, bortsett fra det fjernede 4.1.1. Sikter du mot 2.2, dekker du begge. Nevner en kontrakt en versjon, er det kontrakten som gjelder. I Norge krever forskrift om universell utforming av IKT-løsninger (åpnes i en ny fane) at private virksomheter oppfyller WCAG 2.0 nivå A og AA, med unntak av 1.2.3–1.2.5.

• EU: etter EUs tilgjengelighetsdirektiv (EAA) formodes samsvar når du oppfyller den harmoniserte standarden EN 301 549. Ifølge AccessibleEU (åpnes i en ny fane) tar versjon 4.1.1, publisert i september 2026, inn WCAG 2.2, men er ennå ikke den rettslige referansen; til den er kunngjort i EU-tidende, gjelder v3.2.1 (basert på WCAG 2.1 AA). Forklaringen vår av EUs tilgjengelighetsdirektiv går gjennom hvem det gjelder for.
• Storbritannia: myndighetenes veiledning (åpnes i en ny fane) sier at nettsteder og apper i offentlig sektor må oppfylle WCAG 2.2 AA. Veiledningen gjelder offentlige organer, ikke private virksomheter.
• USA: justisdepartementets regel for delstater og lokale myndigheter bruker WCAG 2.1 AA, og fristene ble flyttet i april 2026 (åpnes i en ny fane) til 26. april 2027 og 26. april 2028. For private virksomheter sier departementets veiledning fra 2022 (åpnes i en ny fane) at ADA gjelder for nettstedene deres, men den fastsetter ingen bestemt teknisk standard.

Hva med WCAG 3?

WCAG 3 er et utkast, så ingen kan oppfylle den ennå. W3C publiserte oppdaterte utkast i september 2026 og sier at WCAG 3 ikke ventes å bli en ferdig standard «på noen år til». WCAG 2 vil ikke bli faset ut før flere år etter det, så 2.2 er versjonen du bør jobbe etter nå.

Hvordan sjekker du de nye kriteriene på 15 minutter?

De fleste brudd på de seks kriteriene på nivå A og AA finner du på omtrent 15 minutter med et tastatur, en mobil og din egen innloggingsside. Det erstatter ikke en full revisjon eller testing med personer med funksjonsnedsettelser, men det viser deg hvor du skal begynne, og gir en utvikler en konkret liste å jobbe ut fra.

1. Gå gjennom forsiden, en produktside og kassen med Tab-tasten mens alle bannere vises. Ser du alltid fokus? (2.4.11)
2. Fullfør hver glidebryter eller dra-og-slipp-oppgave bare med klikk eller trykk. (2.5.7)
3. Prøv alle lukkeknapper, sidetall og små ikoner på en mobil. (2.5.8)
4. Sammenlign hvor hjelp og kontaktinformasjon står på tre ulike sidetyper. (3.2.6)
5. Gå gjennom et kjøp eller en bestilling, og noter hvert spørsmål du svarer på to ganger. (3.3.7)
6. Logg inn med en passordbehandler, og lim deretter inn et passord og en engangskode. Har hver CAPTCHA et alternativ? (3.3.8)

For resten av WCAG går guiden vår om hvordan du tester tilgjengeligheten på nettstedet gjennom gratis verktøy og manuelle sjekker, og sjekklisten for tilgjengelige nettsteder gjør vanlige feil om til en oppgaveliste. Det du ikke kan rette ennå, hører hjemme i tilgjengelighetserklæringen din.

Et ord om widgeter, også vår: ingen av disse kriteriene kan oppfylles fra et panel på besøkendes side. En stor peker gjør små mål lettere å treffe, men gjør dem ikke 24 piksler brede, og utheving av fokus flytter ikke et fast banner ut av veien. Alle de nye kriteriene handler om hvordan sidene dine er bygd, så løsningen ligger i malene og koden din.