Test tilgjengeligheten på nettstedet: gratis verktøy og sjekker

Her er en historie vi hører ofte. Noen kjører Lighthouse, får en grønn 100 for tilgjengelighet og går videre. En uke senere skriver en kunde at hun ikke fikk betalt, fordi kortskjemaet ikke kan nås med tastatur. Begge deler er sant. Den automatiske testen besto, og nettstedet sviktet likevel en ekte person.

Denne guiden viser hvordan du tester ordentlig med et lite budsjett: hvilke gratis verktøy du bør kjøre, en manuell rutine på 15 minutter, en første runde med skjermleser og når det lønner seg å betale for en revisjon.

Kan et automatisk testverktøy fortelle meg om nettstedet er tilgjengelig?

Nei. Automatiske testverktøy finner noen problemer raskt, men mange spørsmål om tilgjengelighet kan bare et menneske besvare. Da britiske Government Digital Service testet 10 verktøy på en side med 143 kjente feil, fant det beste 41 %. W3C sier det rett ut: testverktøy «kan ikke avgjøre tilgjengelighet, de kan bare hjelpe til med det.»

GDS-testen (åpnes i en ny fane) er fra februar 2017, og de 41 prosentene (fra Asqatasun) inkluderte verktøyets oppfordringer til manuelle sjekker. Verktøyene har blitt bedre siden, men gapet har samme årsak. Programvare kan se at et bilde mangler alternativ tekst. Den kan ikke se at «rød kjole» er feil beskrivelse av et bilde av en blå dress, eller om fokusrekkefølgen gir mening.

Se derfor på et testverktøy som en røykvarsler, ikke en tilstandsrapport. Det er likevel verdt å kjøre: WebAIM Million 2026 (åpnes i en ny fane) fant påviselige feil på 95,9 % av forsidene til de én million største nettstedene, så de fleste nettsteder har feil som er raske å rette. Som W3Cs veiledning om å velge verktøy (åpnes i en ny fane) sier: «Menneskelig skjønn er nødvendig.»

Hvilke gratis verktøy bør jeg bruke for å teste tilgjengelighet?

Bruk ett eller to automatiske testverktøy, et kontrastverktøy og en skjermleser. Verktøyene bruker ulike regler og rapporterer resultatene ulikt, så to verktøy fanger som regel mer enn ett. Alle verktøyene nedenfor har en gratisversjon. Sjekk gjeldende vilkår for hvert av dem før du stoler på det, for navn, funksjoner og priser endrer seg.

Hva kan jeg sjekke manuelt på 15 minutter?

Ganske mye. W3Cs Easy Checks (åpnes i en ny fane) dekker sidetitler, alternativ tekst, overskrifter, kontrast, hopp-lenker, synlig tastaturfokus, sidespråk, zoom, teksting og etiketter på skjemafelt. Velg én viktig side, som en produktside eller bestillingsskjemaet, og bruk et minutt eller to på hver sjekk. Du vil finne ting som ingen testverktøy rapporterer.

W3C sier at disse sjekkene «dekker bare noen få tilgjengelighetsproblemer», så de er ingen fullstendig vurdering. De er likevel det beste kvarteret du kan bruke:

1. Sidetittel (1 minutt). Sier fanen i nettleseren hva siden er, for eksempel «Bestill bord | Rosas kjøkken», i stedet for «Hjem» overalt?
2. Bilder (2 minutter). Vis den alternative teksten med WAVE eller lignende. Er den riktig? Blir rene pyntebilder hoppet over?
3. Overskrifter (2 minutter). List opp overskriftene og les dem alene. Fungerer de som en innholdsfortegnelse?
4. Kontrast (2 minutter). Sjekk brødtekst, liten grå tekst, knappetekst og tekst over bilder.
5. Tastatur (4 minutter). Legg bort musen og gå gjennom siden med Tab (se neste avsnitt).
6. Zoom (2 minutter). Kan du ved 200 %, og så 400 %, fortsatt lese alt og bruke menyen uten å rulle sidelengs?
7. Skjemaer og språk (2 minutter). Klikk på etiketten til hvert felt; i et godt bygd skjema havner markøren da i feltet. Sjekk verktøyets rapport for manglende sidespråk.

Hvordan tester jeg med tastatur?

Legg bort musen. Trykk Tab for å gå framover, Shift+Tab for å gå tilbake, Enter for å følge lenker, mellomrom eller Enter for å trykke på knapper, og piltastene i menyer og radioknapper. Alle interaktive elementer skal kunne nås, du skal alltid se hvor du er, og du skal aldri bli sittende fast.

På Mac hopper Safari over lenker når du trykker Tab, helt til du slår på valget for å utheve hvert objekt på en nettside med Tab under Avansert i Safari-innstillingene. Sjekk deretter:

• Ser du alltid hvor du er? Forsvinner fokusrammen, er en tastaturbruker på villspor.
• Er rekkefølgen logisk? Fokus skal følge leserekkefølgen.
• Er noe dekket til? En fast toppmeny eller et cookie-banner som skjuler elementet med fokus, bryter kriteriet Fokus ikke skjult i WCAG 2.2.
• Kommer du deg ut igjen? Åpne alle menyer, popup-vinduer og datovelgere, og prøv så å komme deg ut. Escape skal lukke dialoger.
• Virker hele kundereisen? Legg til et produkt, endre antallet, bruk en rabattkode og kom fram til betaling uten mus.

Skriv ned hver feil presist: «Størrelsesvelgeren på produktsiden kan ikke åpnes med Enter eller mellomrom» blir rettet mye raskere enn «tastaturet virker ikke».

Hvordan tester jeg med skjermleser for første gang?

Begynn med skjermleseren enheten din allerede har, eller NVDA på Windows, og lytt til én side. Du prøver ikke å bruke den som en ekspert. Du sjekker at overskrifter, lenker, knapper, bilder og skjemafelt leses opp med fornuftige navn, og at ikke noe viktig er stille.

• Mac: Command+F5 slår VoiceOver av og på; Control+Option+U åpner rotoren, en liste over overskrifter, lenker og skjemakontroller.
• Windows: i NVDA trykker du H for å hoppe mellom overskrifter og Insert+F7 for å liste opp lenker og overskrifter.
• Mobil: slå på VoiceOver (iPhone) eller TalkBack (Android) og sveip mot høyre for å gå fra element til element. Lær deg først hvordan du slår den av.

Lytt etter det som betyr mest. I WebAIMs skjermleserundersøkelse fra 2024 (åpnes i en ny fane) sa 71,6 % av respondentene at de først navigerer på en lang side via overskriftene, så begynn der. Hent så opp lenkelisten: fem lenker som heter «Les mer», sier ingen noe. «Legg i handlekurven, marineblå genser» er en nyttig knapp; «knapp» er det ikke. Fyll til slutt ut et skjema og sjekk at hvert felt og hver feil blir lest opp.

Vær beskjeden med konklusjonene. Høres det ødelagt ut for deg, er det trolig det; høres det greit ut, er det ikke noe bevis. Hvordan erfarne brukere faktisk jobber, kan du lese om i hvordan personer med funksjonsnedsettelser bruker nettet.

Hvordan sjekker jeg zoom, omflyt og tekstavstand?

Zoom nettleseren til 200 % og sjekk at teksten blir større uten å bli kuttet eller overlappe. Test deretter omflyt: ved 400 % zoom i et vindu som er 1 280 piksler bredt, skal innholdet passe uten at du må rulle sidelengs. Øk til slutt avstanden mellom bokstaver, ord, linjer og avsnitt, og sjekk at ingenting går i stykker eller forsvinner.

Dette svarer til WCAG-kriteriene Endring av tekststørrelse (1.4.4), Dynamisk tilpasning (1.4.10) (åpnes i en ny fane) og Tekstavstand (1.4.12) (åpnes i en ny fane). Dynamisk tilpasning bruker en bredde på 320 CSS-piksler, som W3C påpeker «tilsvarer et utgangsvindu på 1 280 CSS-piksler i bredden ved 400 % zoom.» Tekstavstand krever at ingenting går tapt når en leser setter linjehøyden til 1,5 ganger skriftstørrelsen, avsnittsavstanden til 2 ganger, bokstavavstanden til 0,12 ganger og ordavstanden til 0,16 ganger.

Et bokmerke for tekstavstand, et lite skript lagret som bokmerke, bruker alle fire verdiene med ett klikk. Se etter tekst som renner ut av knapper, og etiketter som kuttes i kanten. Ved 400 % zoom viser en bærbar PC omtrent det samme som en liten mobil, så et godt bygd responsivt nettsted består mye av dette allerede.

Hvordan sjekker jeg skjemaer, feilmeldinger og kassen?

Fyll ut hvert viktig skjema tre ganger: én gang riktig, én gang med alle felt tomme og én gang med bevisste feil. Hvert felt skal ha en synlig etikett, hver feil skal forklares med ord ved siden av feltet, og du skal kunne lime inn i felt for passord og bekreftelseskoder.

• Feil. «Ugyldig inndata» i rødt er ikke nok. «Skriv inn utløpsdatoen som MM/ÅÅ» ved siden av feltet er det. Etter innsending skal fokus flytte seg til feiloppsummeringen eller det første feltet med feil.
• Innlogging og koder. Etter WCAG 2.2s kriterium for tilgjengelig autentisering (åpnes i en ny fane) er det et brudd å blokkere innliming eller passordbehandlere, med mindre det finnes en annen vei inn.
• CAPTCHA og tidsfrister. Skjermleserbrukere rangerte CAPTCHA som det mest problematiske på nettet i WebAIMs undersøkelse. Sjekk at det finnes et tilgjengelig alternativ, og at tidsfrister kan forlenges.

Sjekklisten vår for tilgjengelige nettsteder har en fyldigere liste for nettbutikker, også om cookie-bannere og popup-vinduer.

Hva inneholder en profesjonell tilgjengelighetsrevisjon, og når trenger jeg en?

En tilgjengelighetsrevisjon er en spesialists strukturerte gjennomgang mot en navngitt standard, som regel WCAG 2.1 eller 2.2 nivå AA. Den kombinerer automatiske skanninger med manuell testing og testing med hjelpemiddelteknologi av de viktigste malene og kundereisene, og ender i en prioritert rapport. Du trenger en når loven gjelder for deg, før en stor lansering, eller når kunder ber om dokumentasjon.

Før dere blir enige om en pris, bør du spørre:

• Hvilken standard, versjon og nivå tester dere mot?
• Hvilke maler og kundereiser er med? For en nettbutikk: forside, kategori, produkt, handlekurv, kasse, kontosider og skjemaer.
• Tester dere manuelt med skjermlesere, tastatur og zoom, og i hvilke nettlesere og på hvilke enheter?
• Rangerer rapporten problemene etter alvorlighet, viser hvor de er, og foreslår løsninger?
• Er en ny test inkludert?

Prisene varierer mye med leverandør, land og omfang, så sammenlign hva som er inkludert. Omfattes du av EUs tilgjengelighetsdirektiv, underbygger en revisjon også den offentlige erklæringen din; guiden vår om EAA forklarer hvem som omfattes.

Hvorfor teste med brukere med funksjonsnedsettelser?

Fordi å oppfylle en standard og å være lett å bruke ikke er det samme. En kasse kan bestå alle WCAG-kriteriene og likevel ta tjue minutter for en skjermleserbruker. W3C sier at evaluering med brukere med funksjonsnedsettelser «avdekker brukbarhetsproblemer som ikke oppdages ved samsvarsvurdering alene», og den viser teamet ditt hvordan folk faktisk bruker nettstedet.

Du trenger ikke et laboratorium. Noen få økter på den viktigste oppgaven, som å finne et produkt og betale, lærer deg mer enn enda en runde med skanninger. Rekrutter via brukerorganisasjoner, analysebyråer eller dine egne kunder, og betal folk for tiden deres. La dem bruke egne enheter og innstillinger. W3Cs veiledning om å involvere brukere i evalueringen (åpnes i en ny fane) tar for seg den praktiske siden.

Hva gjør jeg med resultatene?

Sorter problemene etter hvor mye de hindrer folk og hvor de oppstår, rett dem i nettstedets egen kode og eget innhold, test på nytt og før opp det som gjenstår. Et skjemafelt uten etikett i kassen betyr mer enn en kontrastglipp i bunnteksten, og en rettelse i en felles mal reparerer alle sidene som bruker den.

1. Prioriter. Det som stopper folk i de viktigste kundereisene (kasse, bestilling, registrering) først, deretter felles maler, deretter enkeltsider.
2. Rett feilen der den oppstår. Endre temaet, komponenten eller innholdet, ikke bare symptomet.
3. Test på nytt. Gjenta de samme sjekkene, manuelt og med verktøy.
4. Dokumenter. List opp kjente problemer, med datoer, i tilgjengelighetserklæringen din. Guiden vår om WCAG 2.2 forklarer de nyere kriteriene.
5. Gjenta. Gjør en tastatursjekk og en skanning før hver ny versjon går ut.

Bruker du en tilgjengelighetswidget, også vår, bør du teste med den lukket. Et panel som SiteAccessible gir besøkende flere måter å tilpasse siden på, men WCAG spør om siden virker i standardtilstanden. Noen revisjonsordninger vurderer ikke sider som kjører et overlay-skript, så sjekk med revisoren først.