Hvad er tilgængelighedstest? (Eksempler)

Hvad er tilgængelighedstest?

Tilgængelighedstest er en type softwaretest, der udføres for at bekræfte, at en applikation er brugbar af personer med handicap, herunder brugere med syns-, høre-, motoriske, kognitive og aldersrelaterede handicap. Det er en delmængde af usability test og verificerer, at produktet fungerer med den hjælpeteknologi, som disse brugere er afhængige af hver dag.

Hjælpeteknologi hjælper personer med handicap med at betjene et softwareprodukt. Almindelige eksempler inkluderer:

• Software til talegenkendelse – Konverterer talte ord til tekst, der fungerer som input til computeren.
• Software til skærmlæser – Læser teksten og grænsefladeelementerne højt, der vises på skærmen.
• Skærmforstørrelsessoftware – Forstørrer dele af skærmen for at gøre læsningen lettere for brugere med nedsat syn.
• Specialiserede tastaturer – Designet til brugere med motoriske kontrolvanskeligheder for at gøre typing lettere.
• Skift og øje-trackonge-enheder – Giv brugere med alvorlige motoriske handicap mulighed for at navigere og vælge grænsefladeelementer.

Hvorfor tilgængelighedstest?

Årsag 1Imødekomme markedet af brugere med handicap.

Ifølge Verdenssundhedsorganisationen lever omkring 1.3 milliarder mennesker, eller omtrent hver sjette på verdensplan, med et betydeligt handicap.

• 1 ud af 10 personer har et alvorligt handicap.
• 1 ud af 2 personer over 65 år har nedsat funktionsevne.

Handicap omfatter blindhed, døvhed, motoriske funktionsnedsættelser, kognitive lidelser og andre langvarige helbredsproblemer. Et produkt, der er bygget til at være tilgængeligt, kan nå dette store marked, og de fleste tilgængelighedsdefekter kan forebygges, når tilgængelighedstestning gøres til en del af den normale softwaretestnings livscyklus.

Årsag 2Overhold tilgængelighedslovgivningen.

Regeringer verden over har vedtaget lovgivning, der kræver, at IT-produkter skal være tilgængelige for mennesker med handicap. Vigtige eksempler inkluderer:

• USA: Americans with Disabilities Act (ADA, 1990) og afsnit 508 i rehabiliteringsloven.
• Storbritannien: Ligestillingsloven fra 2010 (som erstattede loven om forskelsbehandling af handicappede fra 1995).
• Den Europæiske Union: Den europæiske tilgængelighedslov, som trådte i kraft for mange produkter og tjenester i juni 2025, og standarden EN 301 549.
• Australien: Lov om forskelsbehandling af handicappede fra 1992.
• Irland: Handicaploven fra 2005.
• Canada: Lov om tilgængelighed i Canada 2019.

Tilgængelighedstest er afgørende for at sikre overholdelse af lovgivningen på alle markeder, hvor dit produkt sælges.

Årsag 3Undgå potentielle retssager.

Store virksomheder er blevet sagsøgt gentagne gange, fordi deres digitale produkter ikke var tilgængelige. Et par fremtrædende sager inkluderer:

• Landsforbundet for Blinde (NFB) v. Target (2006, afgjort 2008).
• Forlig i sagen NFB mod AOL (1999).
• Robles mod Domino's Pizza (2019), hvor USA SupremRetten stadfæstede en afgørelse om, at ADA gælder for websteder og mobilapps.
• Gil v. Winn-Dixie (2017), den første amerikanske retssag, der kræver, at et utilgængeligt websted rettes.

Antallet af retssager om webtilgængelighed i USA er steget hvert år, med mere end 4,000 digitale sager anlagt årligt i henhold til ADA Title III siden 2022. Ved at udvikle tilgængelige produkter fra starten undgår man disse omkostninger og beskytter brandet.

Hvilke handicap skal støttes?

En ansøgning skal understøtte personer med handicap såsom:

Type handicap	Handicap Description
Synshandicap	Fuldstændig blindhed, farveblindhed eller nedsat syn. Følsomhed over for visuel stroboskopisk belysning og blinkende effekter.
Fysisk handicap	Manglende evne til at bruge en mus eller et tastatur med én hånd. Dårlige motoriske færdigheder, herunder begrænset håndbevægelse eller muskeltrøst.
Kognitiv handicap	Indlæringsvanskeligheder, dårlig hukommelse eller problemer med at følge komplekse scenarier.
Læseevne handicap	Læsevanskeligheder såsom ordblindhed.
Hørehandicap	Høreproblemer, herunder døvhed og hørenedsættelse. Manglende evne til at høre lyd eller at høre den tydeligt.

Tilgængelighedsstandarder og retningslinjer

Programmer for tilgængelighedstestning er baseret på et lille sæt af bredt anvendte standarder. At forstå, hvilken standard der gælder for dit marked, er det første skridt, før der udarbejdes en testplan.

• WCAG 2.2 – Retningslinjerne for tilgængelighed af webindhold 2.2, som blev udgivet af W3C i oktober 2023, er den nuværende globale benchmark. De definerer tre overensstemmelsesniveauer: A (grundlæggende), AA (det lovpligtige minimum i de fleste lande) og AAA (højeste).
• WCAG 3.0 – Et W3C-arbejdsudkast, der introducerer en resultatbaseret scoringsmodel. Den er stadig under udvikling og har ikke erstattet WCAG 2.2.
• Sektion 508 – Amerikansk føderal indkøbsregel, der kræver, at elektronisk og informationsteknologi, der købes af føderale agenturer, opfylder WCAG 2.0 niveau AA-kriterierne.
• 301 549 – Europæisk harmoniseret standard for IKT-tilgængelighed, der bruges til at demonstrere overholdelse af den europæiske tilgængelighedslov.
• ADA-afsnit III – Amerikansk borgerrettighedslovgivning fandt anvendelse på hjemmesider og mobilapps tilhørende offentlige indkvarteringssteder; domstole bruger almindeligvis WCAG 2.1 eller 2.2 AA som benchmark.

De fleste hold behandler WCAG 2.2 Niveau AA som deres arbejdsmål, fordi det både er det fælles juridiske grundlag og et praktisk ingeniørmæssigt mål.

Hvordan laver man tilgængelighedstest?

Tilgængelighedstest kan udføres på to måder:

1. Manuel
2. Automatiseret

Tilgængelighedstest kan være udfordrende for testere, der ikke er bekendt med handicap. Det er god praksis at involvere brugere med handicap eller tilgængelighedsspecialister, der kan beskrive udfordringer i den virkelige verden. Teknikkerne nedenfor dækker de vigtigste kategorier af handicap.

1) Synshandicap

Forestil dig, at du slet ikke kan se, og at du er nødt til at bruge XYZ' hjemmeside. Din eneste praktiske mulighed er en skærmlæser. En skærmlæser er software, der læser indholdet på en webside, inklusive tekst, links, radioknapper, billeder og video, så en blind bruger kan se brugerfladen. Populære skærmlæsere inkluderer JAWS, NVDA, Apple VoiceOver og Android Tal tilbage.

Når du starter JAWS og derefter åbner en browser, læser JAWS sidens titel op. Hvis du flytter fokus til adresselinjen, siger JAWS "Adresselinje" og læser derefter hvert tegn, du skriver. For eksempel, typping google.com producerer en meddelelse som følger:

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

En skærmlæser læser ord for ord i tekstfelter, annoncerer links som "link" og annoncerer knapper som "knap", så en blind bruger kan identificere hver kontrol. Hvis et websted er dårligt bygget, kan skærmlæseren fejlagtigt identificere elementer; for eksempel kan et link, der er formateret som almindelig tekst, blive læst som indhold og skjule en kritisk handling for brugeren. Omkostningerne for virksomheden er reelt tabt omsætning.

2) Farveblindhed

Farveblindhed betyder, at en bruger ikke kan opfatte bestemte farver korrekt. Rød-grøn farveblindhed er den mest almindelige form. Hvis et websted i høj grad bruger rødt til at formidle mening, kan en bruger med rød-grøn farveblindhed gå glip af budskabet.

Designteams bør aldrig bruge farver alene til at kommunikere information. En rød fejlknap er mere tilgængelig, når den også er omridset, mærket med et ikon og ledsaget af beskrivende tekst. Sort og hvid er fortsat den sikreste universelle palet, og værktøjer som Stark-plugin'et eller browser-farveblindhedssimulatorer hjælper med at afsløre problemer tidligt.

3) Nedsat syn

Brugere med nedsat syn eller andre nethindeproblemer har brug for yderligere support for at bruge webstedet:

1. Undgå meget lille tekst. WCAG anbefaler en standardtekststørrelse, der skalerer komfortabelt uden zoom.
2. Sørg for, at layoutet ombrydes pænt, når teksten forstørres op til 200 procent (et WCAG 2.2 succeskriterium). Linjerne må ikke afskæres, og indholdet må ikke overlappe.
3. Oprethold et minimumskontrastforhold på 4.5:1 for normal tekst og 3:1 for stor tekst.

4) Motoriske og andre handicap

Et vigtigt tilgængelighedskrav er, at hele webstedet skal kunne betjenes uden mus. Alle links, knapper, radioknapper, afkrydsningsfelter, pop op-vinduer, rullemenuer og kontrolelementer skal kunne nås og betjenes udelukkende ved hjælp af tastaturet.

For eksempel, en bruger med begrænset håndmobilitet kan muligvis ikke bruge en mus. Hvis afkrydsningsfelter eller links ikke kan nås med Tab-tasten, er brugeren låst ude af disse funktioner.

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

Fokus skal altid være synligt. Når brugeren trykker på Tab, skal det fremhævede kontrolelement være tydeligt. Synligt fokus hjælper brugere med svagtseende eller farveblindhed med at følge sidens flow og gør navigationen forudsigelig for alle.

Brugere med hørehandicap kan normalt se det visuelle indhold på et websted, men lyd og video giver problemer. Hver video skal indeholde undertekster, og hver lydfil skal indeholde en transskription eller beskrivende tekst. For eksempel bør en instruktionsvideo om booking af en flybillet leveres med præcise undertekster, så en døv bruger kan følge med.

Eksempler på testcases til tilgængelighedstest

Tjeklisten nedenfor bruges til at godkende tilgængelighedstest for en typisk webapplikation. Brug den som udgangspunkt, og udvid den med WCAG 2.2-succeskriterierne, der er relevante for dit produkt.

1. Findes der tastaturækvivalenter til alle musefunktioner og dialoger?
2. Forklarer brugerdokumentationen, hvordan man betjener applikationen med hjælpeteknologi?
3. Er tabulatorrækkefølgen logisk, så navigationen flyder naturligt?
4. Er der genvejstaster til de primære menuer?
5. Understøtter applikationen alle målrettede operativsystemer og skærmlæsere?
6. Er svartiderne for hver skærm eller side tydeligt kommunikeret, så brugerne ved, hvor længe de skal vente?
7. Er alle etiketter skrevet korrekt og programmatisk knyttet til deres kontrolelementer?
8. Er farvevalg fleksible og testet mod farveblindhedssimulatorer?
9. Bruges billeder, ikoner og emojis på måder, som slutbrugerne kan forstå?
10. Giver applikationen lydalarmer, hvor de er nyttige?
11. Kan brugeren justere eller slå lyd- og videokontroller fra?
12. Kan brugeren tilsidesætte standardskrifttyper til udskrivning og tekst på skærmen?
13. Kan brugeren justere eller deaktivere blinkende, roterende eller bevægelige visninger?
14. Bekræft, at farver aldrig bruges som det eneste middel til at formidle information.
15. Er fremhævningen stadig synlig, når systemfarverne er inverteret? Test ved at ændre kontrastforholdene.
16. Er lyd- og videotransskriptioner eller undertekster tilgængelige for brugere, der ikke kan høre?
17. Tilbydes der træning til brugere med handicap for at hjælpe dem med at blive fortrolige med applikationen?
18. Kan alle interaktive kontroller nås, betjenes og lukkes ved hjælp af et tastatur alene?

Hvordan AI ændrer tilgængelighedstestning

AI er omstruktureretping Tilgængelighedstest på tre praktiske måder. For det første læser maskinlæringsscannere nu den gengivne DOM sammen med computervisionsmodeller for at opdage problemer, som regelbaserede værktøjer overser, såsom upassende alt-tekst eller farvekombinationer, der fejler i rigtige layouts. For det andet foreslår generativ AI menneskeligt læsbare rettelser, herunder bedre alt-tekst, tydeligere fejlmeddelelser og ARIA-attributter til brugerdefinerede komponenter. For det tredje prioriterer AI fund efter brugerpåvirkning, så teams kan bruge deres budget på de problemer, der betyder mest. Værktøjer som Deque axe AI, Evinced, UserWay og Siteimprove inkluderer nu AI-funktioner. AI erstatter ikke manuel skærmlæsertest eller brugerundersøgelse med personer med handicap, men det reducerer i høj grad den manuelle triage-arbejdsbyrde og hjælper tilgængelighed med at flyttes til venstre i udviklingscyklussen.

Myter om tilgængelighedstestning

Følgende er almindelige myter om tilgængelighedstestning sammen med fakta:

Myte: Det er dyrt at oprette en tilgængelig hjemmeside.

Faktum: Det er det ikke. At tage hensyn til tilgængelighed under design, sammen med grundlæggende test, sparer penge sammenlignet med eftermontering og reducerer dyrt omarbejde.

Myte: Det er for tidskrævende og dyrt at ændre en utilgængelig hjemmeside til en tilgængelig én.

Faktum: Du behøver ikke at implementere alle rettelser på én gang. Start med de ændringer, der har den største indflydelse på brugere med handicap, og udrul resten i senere udgivelser.

Myte: Tilgængelighed er simpel og kedelig.

Faktum: Sider kan stadig være visuelt rige og påtracsamtidig med at WCAG 2.2-retningslinjerne overholdes. W3C fraråder eksplicit tekstversioner til fordel for én tilgængelig oplevelse for alle.

Myte: Tilgængelighed er kun for blinde og handicappede brugere.

Faktum: Overholdelse af retningslinjerne for tilgængelighed forbedrer den samlede brugervenlighed og gavner alle brugere, inklusive dem på mobile enheder, i stærkt sollys eller i støjende omgivelser.

Ofte Stillede Spørgsmål