Testguide

Automatiserte verktøy fanger opp ca. 30–50 % av tilgjengelighetsproblemer. Resten krever at du tester manuelt – med tastatur, skjermleser og sunt skjønn. Denne guiden gir deg en konkret sjekkliste du kan bruke underveis i utviklingen.

Tips: Du trenger ikke kjøre alt på én gang. Gjør tastaturtest og kontrastsjekk til en vane hver gang du bygger noe nytt. Kjør skjermlesertest før lansering.

Uu-tilsynet publiserer tilsynsrapporter som viser vanlige feil. Disse gir nyttig kontekst for hva tilsynet faktisk ser etter.

Mange brukere er avhengige av tastatur – blant annet personer med nedsatt motorikk og brukere av skjermlesere. Test med Tab-tasten og sjekk:

• Snarveilenke: Finnes det en «hopp til hovedinnhold»-lenke øverst på siden?
• Fokusmarkering: Er det alltid tydelig hvor fokus er?
• Logisk rekkefølge: Følger tab-rekkefølgen den visuelle layouten?
• Interaktive elementer: Kommer du til alle lenker, knapper og skjemafelt? Fungerer de med Enter og mellomrom?
• Modaler og ekspanderbare felt: Flyttes fokus inn i modalen når den åpnes? Kan du lukke den med Escape?

Brukere med moderat nedsatt syn bruker ofte nettleserens zoomfunksjon. Test slik:

• Zoom til 200 % og deretter 400 % (Ctrl/Cmd + og −). Sjekk at alt innhold og funksjonalitet er tilgjengelig.
• Endre vindusbredden gradvis fra fullskjerm til smalest mulig. Fungerer layout, rekkefølge og gruppering i hele spekteret?
• Test på mobil at du kan forstørre innholdet.

• Er lenker i løpende tekst markert med mer enn bare farge (for eksempel understreking)?
• Mål kontrasten mellom tekst og bakgrunn. Minimumskravet er 4.5:1 for vanlig tekst og 3:1 for stor tekst og grafiske elementer.
• Test med simulert fargeblindhet – bruk Chrome DevTools (Rendering → Emulate vision deficiencies) eller Funkify.

Bruk gjerne vår kontrastsjekker for en rask test.

Overskrifter gir struktur og gjør det mulig for skjermleserbrukere å navigere raskt mellom seksjoner.

• Har alle seksjoner beskrivende overskrifter?
• Er overskriftene kodet med riktige nivåer (<h1> til <h6>) uten å hoppe over nivåer?
• Bruk nettleserens utviklerverktøy eller en tilleggsmodul som HeadingsMap for å sjekke overskriftshierarkiet.

• Er lenkene visuelt tydelige – med understreking eller annen markering utover farge?
• Gir lenketeksten mening alene, uten kontekst? (Unngå «klikk her» og «les mer».)
• Åpnes lenker i ny fane bare når det er forventet? Gi i så fall tydelig indikasjon.

• Har meningsbærende bilder en beskrivende alt-tekst?
• Har dekorative bilder et tomt alt-attributt (alt="")?
• Formidler alt-teksten bildets funksjon i kontekst, ikke bare hva som er synlig?

Les mer om alt-tekst-valg fra W3C.

• Har alle skjemafelt en synlig og kodet ledetekst (<label>)?
• Er feilmeldinger tydelige og forklarer hva som er galt og hvordan brukeren kan rette det?
• Får skjermleserbrukere beskjed om obligatoriske felt og valideringsfeil?

Test med en skjermleser for å oppleve løsningen slik mange brukere gjør:

• macOS/iOS: VoiceOver (innebygd – aktiver med Cmd+F5 på Mac)
• Windows: NVDA (gratis) eller den innebygde Narrator
• Android: TalkBack (innebygd)

Sjekk at:

• Alt innhold leses opp i en logisk rekkefølge
• Interaktive elementer annonseres med riktig rolle (knapp, lenke, avkrysningsboks)
• Dynamisk innhold (varsler, oppdateringer) annonseres med aria-live

Automatiserte tester fanger opp ca. 30–50 % av tilgjengelighetsproblemer. Bruk dem som et første lag:

• axe DevTools – nettleserutvidelse for Chrome og Firefox
• Lighthouse – innebygd i Chrome DevTools under «Accessibility»
• jest-axe – for automatiserte tester i Jest
• Wave – nettleserutvidelse fra WebAIM
• W3C-validator – for å sjekke HTML-kode

Husk: Automatiserte verktøy kan verifisere at en alt-tekst finnes, men ikke at den er god. Manuell testing er alltid nødvendig i tillegg.