Hopp til hovedinnhold
Tilbake til bloggen
Veiledning

WCAG 2.2 AA: standarden du faktisk må følge

Nivå AA er terskelen norsk regelverk peker på, og den EU-direktivet bygger videre på. Her er en praktisk gjennomgang: hva som kreves, hva som er nytt i 2.2, og hvordan et realistisk løp ser ut.

Alnet12 min lesetid

WCAG 2.2 AA er ikke én oppgave, men rundt femti suksesskriterier fordelt på fire prinsipper. Det høres uoverkommelig ut. I praksis er det håndterbart, fordi kriteriene i stor grad treffer de samme komponentene: navigasjonen, skjemaene, mediene og fargene.

Hva som er nytt i 2.2

Versjon 2.2 ble publisert i oktober 2023 og legger til ni suksesskriterier. De viktigste for de fleste nettsteder er disse:

  • Fokus ikke skjult

    Elementet som har fokus, skal ikke dekkes helt av sticky headere, chat-bobler eller cookie-bannere.

  • Størrelse på klikkflate

    Interaktive mål bør være minst 24 × 24 CSS-piksler, med mindre det finnes tilstrekkelig avstand rundt.

  • Konsistent hjelp

    Hjelpefunksjoner som kontaktlenke eller chat skal ligge samme sted på tvers av sider.

  • Enkel autentisering

    Innlogging skal ikke kreve at brukeren husker eller gjengir noe uten alternativ – lim inn i passordfelt må fungere.

De fire prinsippene, oversatt til oppgaver

PrinsippTypiske oppgaverHvor de løses
Mulig å oppfatteAlt-tekst, teksting, kontrast, reflow ved 320 pxDesign og innhold
Mulig å betjeneTastatur, fokusrekkefølge, hopp-til-innhold, klikkflaterFrontend
ForståeligLedetekster, feilhåndtering, konsistent navigasjon, språkInnhold og frontend
RobustGyldig markup, riktig bruk av roller og tilstanderFrontend

Et realistisk løp mot AA

  1. Uke 1: nullpunktAutomatisk skanning av alle maler, manuell gjennomgang av de fem viktigste sidene, og en skjermlesertest av hovedflyten.
  2. Uke 2: prioriteringHvert avvik får alvorlighetsgrad, omfang og estimat. Alt som blokkerer en kjøps- eller søknadsflyt havner øverst.
  3. Uke 3–6: rettingKomponentbaserte fikser først – de treffer flest sider per innsats. Deretter sidespesifikke avvik.
  4. Uke 7: verifiseringNy gjennomgang med tastatur og skjermleser, samt regresjonstest av det som er rettet.
  5. Uke 8: dokumentasjonTilgjengelighetserklæring, intern rutine for nytt innhold, og automatiske tester i byggeprosessen.

Slik dokumenterer du etterlevelse

En tilgjengelighetserklæring skal være ærlig. Den er ikke et markedsføringsdokument, men en oversikt over status. Den bør inneholde:

  • Hvilken standard og hvilket nivå løsningen er vurdert mot
  • Hvilke deler som ikke oppfyller kravene, og hvorfor
  • Når avvikene planlegges rettet
  • Hvordan brukere kan melde fra om problemer, og hvor raskt de får svar
  • Dato for siste vurdering og hvem som utførte den

Slik holder du nivået

  1. Legg tilgjengelighet i akseptansekriterieneEn oppgave er ikke ferdig før den er testet med tastatur.
  2. Automatiser i CIaxe-core i byggeprosessen stopper regresjoner før de når produksjon.
  3. Lær opp redaktøreneDe fleste nye avvik oppstår i innhold, ikke i kode. Alt-tekst og overskriftsnivå er redaktøransvar.
  4. Test på nytt hvert halvårNy funksjonalitet, nye tredjepartsskript og nye nettleserversjoner endrer bildet.
  • #WCAG 2.2
  • #Nivå AA
  • #Etterlevelse
  • #Prosess