Hva er tilgjengelighetstesting? (Eksempler)

Hva er tilgjengelighetstesting?

Tilgjengelighetstesting er en type programvaretesting som utføres for å bekrefte at en applikasjon er brukbar av personer med funksjonsnedsettelser, inkludert brukere med syns-, hørsels-, motoriske, kognitive og aldersrelaterte svekkelser. Det er en delmengde av brukervennlighetstesting og bekrefter at produktet fungerer med hjelpeteknologien disse brukerne er avhengige av hver dag.

Hjelpeteknologi hjelper funksjonshemmede med å bruke et programvareprodukt. Vanlige eksempler inkluderer:

• Programvare for talegjenkjenning – Konverterer talte ord til tekst som fungerer som input til datamaskinen.
• Skjermleserprogramvare – Leser opp teksten og grensesnittelementene som vises på skjermen.
• Programvare for skjermforstørrelse – Forstørrer deler av skjermen for å gjøre lesingen enklere for brukere med svaksyn.
• Spesialiserte tastaturer – Utviklet for brukere med motoriske kontrollvansker for å lage typing lettere.
• Bryter og øye-trackongeenheter – La brukere med alvorlige motoriske funksjonshemminger navigere og velge grensesnittelementer.

Hvorfor tilgjengelighetstesting?

Årsak 1: Tilrettelegge for markedet av brukere med funksjonsnedsettelser.

Ifølge Verdens helseorganisasjon lever rundt 1.3 milliarder mennesker, eller omtrent én av seks på verdensbasis, med en betydelig funksjonshemming.

• 1 av 10 personer har en alvorlig funksjonshemming.
• 1 av 2 personer over 65 år har reduserte funksjonsevner.

Funksjonshemminger inkluderer blindhet, døvhet, motoriske svekkelser, kognitive tilstander og andre langsiktige helseproblemer. Et produkt som er bygget for å være tilgjengelig kan nå dette store markedet, og de fleste tilgjengelighetsfeil kan forebygges når tilgjengelighetstesting blir en del av den normale programvaretestings livssyklus.

Årsak 2Overhold tilgjengelighetslovgivningen.

Regjeringer over hele verden har vedtatt lovgivning som krever at IT-produkter skal være tilgjengelige for funksjonshemmede. Viktige eksempler inkluderer:

• USA: Americans with Disabilities Act (ADA, 1990) og paragraf 508 i rehabiliteringsloven.
• Storbritannia: Likestillingsloven av 2010 (som erstattet loven om diskriminering av funksjonshemmede av 1995).
• EU: Den europeiske tilgjengelighetsloven, som trådte i kraft for mange produkter og tjenester i juni 2025, og standarden EN 301 549.
• Australia: Lov om diskriminering av funksjonshemmede fra 1992.
• Irland: Lov om funksjonshemming fra 2005.
• Canada: Lov om tilgjengelighet i Canada 2019.

Tilgjengelighetstesting er viktig for å sikre samsvar med regelverket i alle markeder der produktet ditt selges.

Årsak 3Unngå potensielle søksmål.

Store selskaper har blitt saksøkt gjentatte ganger fordi deres digitale produkter ikke var tilgjengelige. Noen fremtredende saker inkluderer:

• Landsforbundet for blinde (NFB) v. Target (2006, avgjort 2008).
• Forliket i NFB mot AOL (1999).
• Robles mot Domino's Pizza (2019), der USA SupremRetten lot en kjennelse om at ADA gjelder for nettsteder og mobilapper stå ved like.
• Gil v. Winn-Dixie (2017), den første amerikanske rettssaken som krever at et utilgjengelig nettsted fikses.

Søksmål om nettilgjengelighet i USA har økt hvert år, med mer enn 4,000 digitale saker anlagt årlig i henhold til ADA Title III siden 2022. Å bygge tilgjengelige produkter fra starten av unngår disse kostnadene og beskytter merkevaren.

Hvilke funksjonshemninger å støtte?

En søknad må støtte personer med funksjonsnedsettelser, som for eksempel:

Type funksjonshemming	Uførhet Description
Synshemning	Fullstendig blindhet, fargeblindhet eller svaksyn. Følsomhet for visuell strobe og blinkende effekter.
Fysisk hemmet	Manglende evne til å bruke mus eller tastatur med én hånd. Dårlige motoriske ferdigheter, inkludert begrenset håndbevegelse eller muskeltreghet.
Kognitiv funksjonshemming	Lærevansker, dårlig hukommelse eller problemer med å følge komplekse scenarier.
Lese- og skrivefunksjonshemming	Lesevansker som dysleksi.
Hørselshemning	Hørselsproblemer, inkludert døvhet og hørselshemming. Manglende evne til å høre lyd eller å høre den tydelig.

Tilgjengelighetsstandarder og retningslinjer

Programmer for tilgjengelighetstesting er avhengige av et lite sett med bredt vedtatte standarder. Å forstå hvilken standard som gjelder for markedet ditt er det første trinnet før det skrives en testplan.

• WCAG 2.2 – Retningslinjene for tilgjengelighet på nett 2.2, som ble publisert av W3C i oktober 2023, er den nåværende globale referansen. De definerer tre samsvarsnivåer: A (grunnleggende), AA (det lovbestemte minimumsnivået i de fleste land) og AAA (høyeste).
• WCAG 3.0 – Et W3C-arbeidsutkast som introduserer en resultatbasert poengmodell. Den er fortsatt under utvikling og har ikke erstattet WCAG 2.2.
• § 508 – Amerikansk føderal anskaffelsesregel som krever at elektronisk og informasjonsteknologi kjøpt av føderale etater oppfyller WCAG 2.0 nivå AA-kriteriene.
• 301 549 – Europeisk harmonisert standard for IKT-tilgjengelighet, brukt til å demonstrere samsvar med den europeiske tilgjengelighetsloven.
• ADA-tittel III – Amerikansk sivilrettslovgivning gjaldt for nettsteder og mobilapper for offentlige overnattingssteder; domstoler bruker vanligvis WCAG 2.1 eller 2.2 AA som referansepunkt.

De fleste lagene behandler WCAG 2.2 nivå AA som deres arbeidsmål fordi det er både det felles juridiske grunnlaget og et praktisk ingeniørmål.

Hvordan gjøre tilgjengelighetstesting?

Tilgjengelighetstesting kan utføres på to måter:

1. Håndbok
2. Automatisert

Tilgjengelighetstesting kan være utfordrende for testere som ikke er kjent med funksjonsnedsettelser. Det er god praksis å involvere brukere med funksjonsnedsettelser eller tilgjengelighetsspesialister som kan beskrive utfordringer i den virkelige verden. Teknikkene nedenfor dekker de viktigste kategoriene for funksjonsnedsettelser.

1) Synshemning

Tenk deg at du ikke kan se i det hele tatt, og at du må bruke XYZ-nettstedet. Det eneste praktiske alternativet er en skjermleser. En skjermleser er programvare som forteller innholdet på en nettside, inkludert tekst, lenker, radioknapper, bilder og video, slik at en blind bruker kan oppfatte grensesnittet. Populære skjermlesere inkluderer KJEVER, NVDA, Apple VoiceOver og Android Snakke tilbake.

Når du starter JAWS og deretter åpner en nettleser, leser JAWS opp sidetittelen. Hvis du flytter fokus til adressefeltet, sier JAWS «Adressefelt» og leser deretter hvert tegn du skriver. For eksempel, typing google.com produserer en kunngjøring som ligner på følgende:

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 skjermleser leser ord for ord i tekstfelt, annonserer lenker som «lenke» og annonserer knapper som «knapp», slik at en blind bruker kan identifisere hver kontroll. Hvis et nettsted er dårlig bygget, kan skjermleseren feilidentifisere elementer. For eksempel kan en lenke som er formatert som ren tekst leses som innhold, og dermed skjule en kritisk handling for brukeren. Kostnaden for bedriften er reelle tapte inntekter.

2) Fargeblindhet

Fargeblindhet betyr at en bruker ikke kan oppfatte visse farger riktig. Rød-grønn fargeblindhet er den vanligste formen. Hvis et nettsted er sterkt avhengig av rødt for å formidle mening, kan en bruker med rød-grønn fargeblindhet gå glipp av budskapet.

Designteam bør aldri bruke farger alene for å kommunisere informasjon. En rød feilknapp er mer tilgjengelig når den også er omrisset, merket med et ikon og ledsaget av beskrivende tekst. Svart og hvitt er fortsatt den sikreste universelle paletten, og verktøy som Stark-pluginen eller fargeblindhetssimulatorer i nettlesere bidrar til å avdekke problemer tidlig.

3) Lavt syn

Brukere med svaksyn eller andre netthinneproblemer trenger ekstra støtte for å bruke nettstedet:

1. Unngå veldig liten tekst. WCAG anbefaler en standard brødtekststørrelse som skalerer komfortabelt uten zoom.
2. Sørg for at layouten flyter rent når teksten forstørres opptil 200 prosent (et suksesskriterium i henhold til WCAG 2.2). Linjene skal ikke kuttes av, og innholdet skal ikke overlappe.
3. Oppretthold et minimumskontrastforhold på 4.5:1 for vanlig tekst og 3:1 for stor tekst.

4) Motoriske og andre funksjonshemminger

Et viktig tilgjengelighetskrav er at hele nettstedet må kunne brukes uten mus. Alle lenker, knapper, alternativknapper, avmerkingsbokser, popup-vinduer, rullegardinmenyer og kontroller skal kunne nås og brukes kun ved hjelp av tastaturet.

For eksempel, kan det hende at en bruker med begrenset håndmobilitet ikke kan bruke musen. Hvis avmerkingsbokser eller lenker ikke kan nås med Tab-tasten, er brukeren utestengt fra disse funksjonene.

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 må alltid være synlig. Når brukeren trykker på Tab, skal den uthevede kontrollen være tydelig fremtredende. Synlig fokus hjelper brukere med svaksyn eller fargeblinde å følge flyten på siden og gjør navigasjonen forutsigbar for alle.

Brukere med hørselshemminger kan vanligvis se det visuelle innholdet på et nettsted, men lyd og video byr på problemer. Hver video må inneholde teksting, og hver lydfil må inneholde en transkripsjon eller beskrivende tekst. For eksempel bør en veiledningsvideo om bestilling av flybillett leveres med nøyaktige teksting slik at en døv bruker kan følge med.

Eksempeltesttilfeller for tilgjengelighetstesting

Sjekklisten nedenfor brukes til å godkjenne tilgjengelighetstesting for en typisk webapplikasjon. Bruk den som et utgangspunkt og utvid den med WCAG 2.2-suksesskriterier som er relevante for produktet ditt.

1. Finnes det tastaturekvivalenter for hver museoperasjon og dialog?
2. Forklarer brukerdokumentasjonen hvordan man bruker applikasjonen med hjelpeteknologi?
3. Er tabulatorrekkefølgen logisk slik at navigasjonen flyter naturlig?
4. Finnes det snarveier for hovedmenyene?
5. Støtter applikasjonen alle målrettede operativsystemer og skjermlesere?
6. Er responstiden for hver skjerm eller side tydelig kommunisert, slik at brukerne vet hvor lenge de skal vente?
7. Er alle etiketter skrevet riktig og programmatisk koblet til kontrollene sine?
8. Er fargevalgene fleksible og testet mot fargeblindhetssimulatorer?
9. Brukes bilder, ikoner og emojier på måter som sluttbrukere kan forstå?
10. Gir applikasjonen lydvarsler der de er nyttige?
11. Kan brukeren justere eller dempe lyd- og videokontroller?
12. Kan brukeren overstyre standardfonter for utskrift og tekst på skjermen?
13. Kan brukeren justere eller deaktivere blinkende, roterende eller bevegelige skjermer?
14. Bekreft at farger aldri brukes som eneste måte å formidle informasjon på.
15. Er uthevingen fortsatt synlig når systemfargene er invertert? Test ved å endre kontrastforholdene.
16. Er lyd- og videotranskripsjoner eller teksting tilgjengelig for brukere som ikke kan høre?
17. Gis det opplæring til brukere med funksjonsnedsettelser for å hjelpe dem med å bli kjent med applikasjonen?
18. Er alle interaktive kontroller tilgjengelige, betjenbare og avvisbare bare ved hjelp av et tastatur?

Hvordan AI endrer tilgjengelighetstesting

AI blir omstrukturertping Tilgjengelighetstesting på tre praktiske måter. For det første leser maskinlæringsskannere nå den gjengitte DOM-en sammen med datasynsmodeller for å oppdage problemer som regelbaserte verktøy overser, for eksempel upassende alt-tekst eller fargekombinasjoner som feiler i virkelige oppsett. For det andre foreslår generativ AI menneskelig lesbare rettelser, inkludert bedre alt-tekst, tydeligere feilmeldinger og ARIA-attributter for tilpassede komponenter. For det tredje prioriterer AI funn etter brukerpåvirkning, slik at team kan bruke budsjettet sitt på problemene som betyr mest. Verktøy som Deque axe AI, Evinced, UserWay og Siteimprove inkluderer nå AI-funksjoner. AI erstatter ikke manuell skjermlesertesting eller brukerundersøkelser med personer med funksjonsnedsettelser, men det reduserer den manuelle sorteringsarbeidsmengden betraktelig og hjelper tilgjengelighet med å flyttes til venstre i utviklingssyklusen.

Myter om tilgjengelighetstesting

Følgende er vanlige myter om tilgjengelighetstesting sammen med fakta:

Myte: Det er dyrt å lage en tilgjengelig nettside.

Faktum: Det er det ikke. Å ta hensyn til tilgjengelighet under design, sammen med grunnleggende testing, sparer penger sammenlignet med ettermontering og reduserer kostbart omarbeid.

Myte: Å endre et utilgjengelig nettsted til et tilgjengelig et er for tidkrevende og dyrt.

Faktum: Du trenger ikke å implementere alle rettelsene samtidig. Start med endringene som har størst innvirkning på brukere med funksjonsnedsettelser, og rull ut resten i senere utgivelser.

Myte: Tilgjengeligheten er enkel og kjedelig.

Faktum: Sider kan fortsatt være visuelt rike og påtracsamtidig som de oppfyller WCAG 2.2-retningslinjene. W3C fraråder eksplisitt tekstversjoner til fordel for én tilgjengelig opplevelse for alle.

Myte: Tilgjengelighet er kun for blinde og funksjonshemmede brukere.

Faktum: Å følge retningslinjene for tilgjengelighet forbedrer den generelle brukervennligheten og er til fordel for alle brukere, inkludert de som bruker mobile enheter, er i sterkt sollys eller i støyende omgivelser.

Spørsmål og svar