Sådan tester du tilgængelighed: gratis værktøjer og manuelle tjek

Her er en historie, vi hører tit. Nogen kører Lighthouse, får en grøn 100 for tilgængelighed og går videre. En uge senere skriver en kunde, at vedkommende ikke kunne betale, fordi kortformularen ikke kan nås med tastaturet. Begge dele er sande. Det automatiske tjek bestod, og hjemmesiden svigtede alligevel et rigtigt menneske.

Denne guide viser, hvordan du tester ordentligt på et lille budget: hvilke gratis værktøjer du skal køre, en manuel rutine på 15 minutter, et første forsøg med en skærmlæser, og hvornår det er værd at betale for en audit.

Kan et automatisk værktøj fortælle mig, om min hjemmeside er tilgængelig?

Nej. Automatiske værktøjer finder nogle problemer hurtigt, men mange spørgsmål om tilgængelighed kan kun besvares af et menneske. Da den britiske Government Digital Service testede 10 værktøjer på en side med 143 kendte fejl, fandt det bedste 41 %. W3C siger det ligeud: evalueringsværktøjer »kan ikke afgøre tilgængelighed, de kan kun hjælpe med det.«

Testen fra GDS (åbner i en ny fane) er fra februar 2017, og dens 41 % (fra Asqatasun) omfattede værktøjets opfordringer til manuelle tjek. Værktøjerne er blevet bedre siden, men hullet har samme årsag. Software kan se, at et billede mangler alternativ tekst. Den kan ikke se, at »rød kjole« er en forkert beskrivelse af et foto af et blåt jakkesæt, eller om din fokusrækkefølge giver mening.

Se derfor et værktøj som en røgalarm, ikke som en tilstandsrapport på hele huset. Det er stadig værd at køre: WebAIM Million 2026 (åbner i en ny fane) fandt påviselige fejl på 95,9 % af forsiderne på de en million største hjemmesider, så på de fleste hjemmesider er der fejl, som er lette at rette. Som W3C's guide til at vælge værktøjer (åbner i en ny fane) siger: »Der kræves menneskelig dømmekraft.«

Hvilke gratis værktøjer til tilgængelighedstest skal jeg bruge?

Brug et eller to automatiske værktøjer, et kontrastværktøj og en skærmlæser. Værktøjerne anvender forskellige regler og rapporterer resultaterne forskelligt, så to værktøjer fanger som regel mere end ét. Alle værktøjerne nedenfor har en gratis version. Tjek de aktuelle vilkår for hvert af dem, før du stoler på dem, for navne, funktioner og priser ændrer sig.

Hvad kan jeg tjekke manuelt på 15 minutter?

En hel del. W3C's Easy Checks (åbner i en ny fane) dækker sidetitler, alternativ tekst, overskrifter, kontrast, spring over-links, synligt tastaturfokus, sidesprog, zoom, undertekster og formularetiketter. Vælg én vigtig side, f.eks. en produktside eller din bookingformular, og giv hvert tjek et minut eller to. Du vil finde ting, som intet automatisk værktøj rapporterer.

W3C siger, at disse tjek »kun dækker nogle få tilgængelighedsproblemer«, så de er ikke en fuld evaluering. De er stadig det bedste kvarter, du kan bruge:

1. Sidetitel (1 minut). Siger fanen i browseren, hvad siden er, f.eks. »Bestil bord | Rosas Køkken«, i stedet for »Forside« overalt?
2. Billeder (2 minutter). Vis den alternative tekst med WAVE eller lignende. Er den korrekt? Bliver pynt sprunget over?
3. Overskrifter (2 minutter). Vis listen over overskrifter, og læs dem for sig. Fungerer de som en indholdsfortegnelse?
4. Kontrast (2 minutter). Tjek brødtekst, lille grå tekst, knaptekst og tekst på billeder.
5. Tastatur (4 minutter). Læg musen væk, og gå siden igennem med Tab-tasten (se næste afsnit).
6. Zoom (2 minutter). Kan du ved 200 % og derefter 400 % stadig læse alt og bruge menuen uden at scrolle sidelæns?
7. Formularer og sprog (2 minutter). Klik på hvert felts etiket; i en velbygget formular sætter det markøren i feltet. Tjek i værktøjets rapport, om sidesproget mangler.

Hvordan tester jeg med tastatur?

Læg musen væk. Tryk på Tab for at gå frem, Skift+Tab for at gå tilbage, Enter for at følge links, mellemrum eller Enter for at trykke på knapper og piletasterne i menuer og radioknapper. Alle interaktive elementer skal kunne nås, du skal altid kunne se, hvor du er, og du må aldrig sidde fast.

På en Mac springer Safari links over, når du trykker på Tab, indtil du slår indstillingen til, der lader Tab fremhæve hvert element på en webside, under Avanceret i Safaris indstillinger. Tjek derefter:

• Kan du altid se, hvor du er? Hvis fokusrammen forsvinder, er en tastaturbruger på herrens mark.
• Er rækkefølgen logisk? Fokus skal følge læserækkefølgen.
• Bliver noget dækket? En fastgjort topmenu eller et cookiebanner, der skjuler det fokuserede element, dumper efter kriteriet Focus Not Obscured i WCAG 2.2.
• Kan du komme ud igen? Åbn alle menuer, pop op-vinduer og datovælgere, og prøv så at komme ud. Escape skal lukke dialogbokse.
• Virker hele forløbet? Læg et produkt i kurven, ret antallet, brug en rabatkode, og nå frem til betalingen uden musen.

Skriv hver fejl præcist ned: »Størrelsesvælgeren på produktsiden kan ikke åbnes med Enter eller mellemrum« bliver rettet langt hurtigere end »tastaturet virker ikke«.

Hvordan tester jeg med en skærmlæser for første gang?

Start med den skærmlæser, din enhed allerede har, eller NVDA på Windows, og lyt til én side. Du prøver ikke at bruge den som en ekspert. Du tjekker, at overskrifter, links, knapper, billeder og formularfelter bliver læst op med fornuftige navne, og at intet vigtigt er tavst.

• Mac: Kommando+F5 slår VoiceOver til og fra; Ctrl+Alt+U åbner rotoren, en liste over overskrifter, links og formularkontroller.
• Windows: i NVDA trykker du på H for at hoppe mellem overskrifter og Insert+F7 for at vise links og overskrifter.
• Telefon: slå VoiceOver (iPhone) eller TalkBack (Android) til, og stryg til højre for at gå fra element til element. Lær først, hvordan du slår det fra igen.

Lyt efter det, der betyder mest. I WebAIMs skærmlæserundersøgelse fra 2024 (åbner i en ny fane) svarede 71,6 %, at de først navigerer på en lang side via overskrifterne, så start der. Hent derefter listen over links: fem links, der hedder »Læs mere«, siger ingen noget. »Læg i kurven, marineblå sweater« er en brugbar knap; »knap« er det ikke. Udfyld til sidst en formular, og tjek, at hvert felt og hver fejl bliver læst op.

Vær beskeden med konklusionerne. Hvis det lyder i stykker for dig, er det sandsynligvis i stykker; hvis det lyder fint, er det ikke et bevis. Hvordan erfarne brugere faktisk arbejder, kan du læse om i hvordan personer med handicap bruger nettet.

Hvordan tjekker jeg zoom, ombrydning og tekstafstand?

Zoom browseren til 200 %, og tjek, at teksten bliver større uden at blive skåret af eller overlappe. Test derefter ombrydningen: ved 400 % zoom i et vindue, der er 1.280 pixels bredt, skal indholdet kunne være der uden vandret scrolling. Øg til sidst afstanden mellem bogstaver, ord, linjer og afsnit, og tjek, at intet går i stykker eller forsvinder.

Det svarer til WCAG-kriterierne 1.4.4 Ændring af tekststørrelse, 1.4.10 Ombrydningsvisning (åbner i en ny fane) og 1.4.12 Tekstafstand (åbner i en ny fane). Ombrydning tager udgangspunkt i en bredde på 320 CSS-pixels, hvilket ifølge W3C »svarer til et visningsområde, der fra start er 1.280 CSS-pixels bredt, ved 400 % zoom.« Tekstafstand kræver, at intet går tabt, når en læser sætter linjehøjden til 1,5 gange skriftstørrelsen, afstanden mellem afsnit til 2 gange, bogstavafstanden til 0,12 gange og ordafstanden til 0,16 gange.

Et bogmærkescript til tekstafstand, et lille script gemt som et bogmærke, anvender alle fire værdier med ét klik. Kig efter tekst, der flyder ud af knapper, og etiketter, der bliver skåret af i kanten. Ved 400 % zoom viser en bærbar computer omtrent det samme som en lille telefon, så en velbygget responsiv hjemmeside består allerede meget af dette.

Hvordan tjekker jeg formularer, fejlmeddelelser og checkout?

Udfyld hver vigtig formular tre gange: én gang korrekt, én gang med alle felter tomme og én gang med bevidste fejl. Alle felter skal have en synlig etiket, alle fejl skal forklares med ord ved deres felt, og du skal kunne indsætte i felter til adgangskoder og bekræftelseskoder.

• Fejlmeddelelser. »Ugyldigt input« med rødt er ikke nok. »Skriv udløbsdatoen som MM/ÅÅ« ved siden af feltet er nok. Når formularen er sendt, skal fokus flytte til fejloversigten eller det første felt med en fejl.
• Login og koder. Efter kriteriet Accessible Authentication (åbner i en ny fane) i WCAG 2.2 dumper det at blokere indsættelse eller adgangskodeadministratorer, medmindre der er en anden måde at logge ind på.
• CAPTCHA og tidsfrister. Skærmlæserbrugere vurderede CAPTCHA som det mest problematiske på nettet i WebAIMs undersøgelse. Tjek, at der er et tilgængeligt alternativ, og at tidsfrister kan forlænges.

Vores tjekliste for webtilgængelighed har en mere fyldestgørende liste til webshops, bl.a. med cookiebannere og pop op-vinduer.

Hvad indeholder en professionel tilgængelighedsaudit, og hvornår har jeg brug for en?

En tilgængelighedsaudit er en specialists strukturerede gennemgang op mod en bestemt standard, som regel WCAG 2.1 eller 2.2 niveau AA. Den kombinerer automatiske scanninger med manuelle test og test med hjælpemidler af dine vigtigste skabeloner og forløb og ender med en prioriteret rapport. Du har brug for en, når loven gælder for dig, før en større lancering, eller når kunder beder om dokumentation.

Spørg om følgende, før I aftaler en pris:

• Hvilken standard, version og hvilket niveau tester I op mod?
• Hvilke skabeloner og forløb er med? For en webshop: forside, kategori, produkt, kurv, checkout, kontosider og formularer.
• Tester I manuelt med skærmlæsere, tastatur og zoom, og i hvilke browsere og på hvilke enheder?
• Rangordner rapporten problemerne efter alvor, angiver den, hvor de findes, og foreslår den løsninger?
• Er en gentest inkluderet?

Priserne varierer meget med leverandør, land og omfang, så sammenlign, hvad der er med. Er du omfattet af European Accessibility Act, underbygger en audit også det, du skriver i din offentlige erklæring; vores guide til European Accessibility Act forklarer, hvem der er omfattet.

Hvorfor teste med brugere med handicap?

Fordi det ikke er det samme at opfylde en standard og at være let at bruge. En checkout kan bestå alle kriterier i WCAG og alligevel tage tyve minutter for en skærmlæserbruger. W3C skriver, at evaluering med brugere med handicap »afdækker brugervenlighedsproblemer, som ikke opdages ved en overensstemmelsesevaluering alene«, og den viser dit team, hvordan folk faktisk bruger hjemmesiden.

Du behøver ikke et laboratorium. En håndfuld sessioner med din vigtigste opgave, f.eks. at finde et produkt og betale, lærer dig mere end endnu en runde scanninger. Find deltagere gennem handicaporganisationer, analysebureauer eller blandt dine egne kunder, og betal folk for deres tid. Lad dem bruge deres egne enheder og indstillinger. W3C's guide til at inddrage brugere i evalueringen (åbner i en ny fane) dækker den praktiske side.

Hvad gør jeg med resultaterne?

Sortér problemerne efter, hvor hårdt de stopper folk, og hvor de opstår, ret dem i hjemmesidens egen kode og eget indhold, test igen, og skriv ned, hvad der stadig mangler. Et felt uden etiket i checkout betyder mere end en kontrastfejl i sidefoden, og en rettelse i en fælles skabelon reparerer alle sider, der bruger den.

1. Prioritér. Blokeringer i vigtige forløb (checkout, booking, tilmelding) først, derefter fælles skabeloner og så enkeltsider.
2. Ret ved kilden. Ret temaet, komponenten eller indholdet, ikke kun symptomet.
3. Test igen. Gentag de samme tjek, manuelt og med værktøjer.
4. Dokumentér. Oplist kendte problemer med datoer i din tilgængelighedserklæring. Vores guide til WCAG 2.2 forklarer de nyere kriterier.
5. Gentag. Tilføj et tastaturtjek og en scanning til hver udgivelse.

Bruger du en tilgængelighedswidget, også vores, så test med den lukket. Et panel som SiteAccessible giver besøgende flere måder at tilpasse siden på, men WCAG spørger, om siden virker i sin standardtilstand. Nogle auditordninger vurderer ikke sider, der kører et overlay-script, så afstem det med din auditor på forhånd.