Vad är tillgänglighetstestning? (Exempel)

Vad är tillgänglighetstestning?

Tillgänglighetstestning är en typ av programvarutestning som utförs för att bekräfta att en applikation är användbar av personer med funktionsnedsättningar, inklusive användare med syn-, hörsel-, motoriska, kognitiva och åldersrelaterade funktionsnedsättningar. Det är en delmängd av användbarhetstestning och verifierar att produkten fungerar med den hjälpmedelsteknik som dessa användare förlitar sig på varje dag.

Hjälpmedelsteknik hjälper personer med funktionsnedsättningar att använda en programvaruprodukt. Vanliga exempel inkluderar:

• Programvara för taligenkänning – Omvandlar talade ord till text som fungerar som indata för datorn.
• Programvara för skärmläsare – Läser upp texten och gränssnittselementen som visas på skärmen.
• Programvara för skärmförstoring – Förstorar delar av skärmen för att göra läsningen enklare för användare med nedsatt syn.
• Specialiserade tangentbord – Utformad för användare med motoriska svårigheter att göra typing lättare.
• Växla och ögon-trackungenheter – Tillåt användare med svåra motoriska funktionsnedsättningar att navigera och välja gränssnittselement.

Varför tillgänglighetstestning?

Anledning 1Tillgodose marknaden av användare med funktionsnedsättningar.

Enligt Världshälsoorganisationen lever cirka 1.3 miljarder människor, eller ungefär var sjätte i världen, med en betydande funktionsnedsättning.

• 1 av 10 personer har en allvarlig funktionsnedsättning.
• 1 av 2 personer över 65 år har nedsatt förmåga.

Funktionsnedsättningar inkluderar blindhet, dövhet, motoriska funktionsnedsättningar, kognitiva tillstånd och andra långsiktiga hälsoproblem. En produkt som är byggd för att vara tillgänglig kan nå denna stora marknad, och de flesta tillgänglighetsdefekter kan förebyggas när tillgänglighetstestning görs till en del av den normala programvarutestningens livscykel.

Anledning 2Följ tillgänglighetslagstiftningen.

Regeringar runt om i världen har antagit lagstiftning som kräver att IT-produkter ska vara tillgängliga för personer med funktionsnedsättning. Viktiga exempel inkluderar:

• USA: Americans with Disabilities Act (ADA, 1990) och avsnitt 508 i rehabiliteringslagen.
• Storbritannien: Jämställdhetslagen 2010 (som ersatte lagen om diskriminering av funktionsnedsättning från 1995).
• Europeiska unionen: Europeiska tillgänglighetslagen, som trädde i kraft för många produkter och tjänster i juni 2025, och standarden EN 301 549.
• Australien: Lagen om diskriminering av funktionsnedsättningar från 1992.
• Irland: Handikapplagen 2005.
• Kanada: Lagen om tillgängligt Kanada 2019.

Tillgänglighetstestning är avgörande för att säkerställa lagefterlevnad på alla marknader där din produkt säljs.

Anledning 3Undvik potentiella stämningar.

Stora företag har stämts upprepade gånger för att deras digitala produkter inte varit tillgängliga. Några framträdande fall inkluderar:

• Nationella blindförbundet (NFB) mot Target (2006, avgjort 2008).
• Förlikningen i NFB mot AOL (1999).
• Robles mot Domino's Pizza (2019), där USA SupremDomstolen fastställde ett beslut att ADA gäller webbplatser och mobilappar.
• Gil v. Winn-Dixie (2017), den första amerikanska rättegångsdomen som krävde att en otillgänglig webbplats skulle åtgärdas.

Antalet stämningar gällande webbtillgänglighet i USA har ökat varje år, med fler än 4 000 digitala mål enligt ADA Title III som inlämnats årligen sedan 2022. Att bygga tillgängliga produkter från början undviker dessa kostnader och skyddar varumärket.

Vilka funktionshinder att stödja?

En applikation måste stödja personer med funktionsnedsättningar såsom:

Typ av funktionshinder	Funktionshinder Description
Synnedsättning	Fullständig blindhet, färgblindhet eller nedsatt syn. Känslighet för visuella stroboskop och blinkande effekter.
Fysiskt handikapp	Oförmåga att använda mus eller tangentbord med en hand. Dåliga motoriska färdigheter, inklusive begränsad handrörelse eller muskeltröghet.
Kognitiv funktionsnedsättning	Inlärningssvårigheter, dåligt minne eller problem med att följa komplexa scenarier.
Läs- och skrivkunnighet Handikapp	Lässvårigheter som till exempel dyslexi.
Hörselnedsättning	Hörselproblem inklusive dövhet och hörselnedsättning. Oförmåga att höra ljud eller att höra det tydligt.

Tillgänglighetsstandarder och riktlinjer

Program för tillgänglighetstestning förlitar sig på en liten uppsättning allmänt antagna standarder. Att förstå vilken standard som gäller för din marknad är det första steget innan någon testplan skrivs.

• WCAG 2.2 – Riktlinjerna för tillgänglighet på webben, publicerade av W3C i oktober 2023, är det nuvarande globala riktmärket. De definierar tre överensstämmelsenivåer: A (grundläggande), AA (det lagstadgade minimumet i de flesta länder) och AAA (högsta).
• WCAG 3.0 – Ett W3C-arbetsutkast som introducerar en resultatbaserad poängsättningsmodell. Den är fortfarande under utveckling och har inte ersatt WCAG 2.2.
• Avsnitt 508 – Amerikansk federal upphandlingsregel som kräver att elektronisk och informationsteknik som köps in av federala myndigheter uppfyller WCAG 2.0 nivå AA-kriterierna.
• 301 549 – Europeisk harmoniserad standard för IKT-tillgänglighet, som används för att visa överensstämmelse med den europeiska tillgänglighetslagen.
• ADA-avdelning III – Amerikansk lag om medborgerliga rättigheter tillämpades på webbplatser och mobilappar för offentliga boenden; domstolar använder vanligtvis WCAG 2.1 eller 2.2 AA som riktmärke.

De flesta lagen behandlar WCAG 2.2 Nivå AA som deras arbetsmål eftersom det är både den gemensamma rättsliga baslinjen och ett praktiskt ingenjörsmässigt mål.

Hur gör man tillgänglighetstestning?

Tillgänglighetstestning kan utföras på två sätt:

1. Manuell
2. Automatiserad

Tillgänglighetstestning kan vara utmanande för testare som inte är bekanta med funktionsnedsättningar. Det är bäst att involvera användare med funktionsnedsättningar eller tillgänglighetsspecialister som kan beskriva verkliga utmaningar. Teknikerna nedan täcker de viktigaste kategorierna av funktionsnedsättningar.

1) Synnedsättning

Tänk dig att du inte kan se alls och behöver använda XYZ:s webbplats. Ditt enda praktiska alternativ är en skärmläsare. En skärmläsare är programvara som återger innehållet på en webbsida, inklusive text, länkar, radioknappar, bilder och video, så att en blind användare kan uppfatta gränssnittet. Populära skärmläsare inkluderar KÄFTAR, NVDA, Apple VoiceOver och Android Prata tillbaka.

När du startar JAWS och sedan öppnar en webbläsare läser JAWS upp sidtiteln. Om du flyttar fokus till adressfältet säger JAWS "Adressfält" och läser sedan upp varje tecken du skriver. Till exempel, typping google.com producerar ett meddelande som ser ut som följande:

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äsare läser upp ord för ord i textfält, annonserar länkar som "länk" och annonserar knappar som "knapp", så att en blind användare kan identifiera varje kontroll. Om en webbplats är dåligt byggd kan skärmläsaren felidentifiera element; till exempel kan en länk som är formaterad som vanlig text läsas som innehåll, vilket döljer en viktig åtgärd för användaren. Kostnaden för företaget är verkliga förlorade intäkter.

2) Färgblindhet

Färgblindhet innebär att en användare inte kan uppfatta vissa färger korrekt. Röd-grön färgblindhet är den vanligaste formen. Om en webbplats i hög grad förlitar sig på rött för att förmedla mening kan en användare med röd-grön färgblindhet missa budskapet.

Designteam bör aldrig använda enbart färg för att kommunicera information. En röd felknapp är mer lättillgänglig när den också är konturerad, märkt med en ikon och åtföljd av beskrivande text. Svartvitt är fortfarande den säkraste universella paletten, och verktyg som Stark-pluginet eller webbläsarsimulatorer för färgblindhet hjälper till att avslöja problem tidigt.

3) Nedsatt syn

Användare med nedsatt syn eller andra näthinneproblem behöver ytterligare stöd för att använda webbplatsen:

1. Undvik väldigt liten text. WCAG rekommenderar en standardstorlek för brödtexten som kan skalas bekvämt utan zoom.
2. Se till att layouten flödar om rent när texten förstoras upp till 200 procent (ett framgångskriterium enligt WCAG 2.2). Raderna ska inte vara avskurna och innehållet ska inte överlappa varandra.
3. Bibehåll ett minsta kontrastförhållande på 4.5:1 för normal text och 3:1 för stor text.

4) Motoriska och andra funktionsnedsättningar

Ett viktigt tillgänglighetskrav är att hela webbplatsen måste kunna användas utan mus. Varje länk, knapp, radioknapp, kryssruta, popup-fönster, rullgardinsmeny och kontroll ska vara tillgänglig och manövrerbar enbart med tangentbordet.

Till exempel, en användare med begränsad handrörlighet kanske inte kan använda en mus. Om kryssrutor eller länkar inte kan nås med Tab-tangenten är användaren utelåst från dessa 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 måste alltid vara synligt. När användaren trycker på Tabbtangenten ska den markerade kontrollen synas tydligt. Synligt fokus hjälper användare med nedsatt syn eller färgblindhet att följa sidans flöde och gör navigeringen förutsägbar för alla.

Användare med hörselnedsättning kan vanligtvis se det visuella innehållet på en webbplats, men ljud och video utgör problem. Varje video måste innehålla textning, och varje ljudfil måste innehålla en transkription eller beskrivande text. Till exempel bör en instruktionsvideo om hur man bokar en flygbiljett ha korrekta textningar så att en döv användare kan följa med.

Exempel på testfall för tillgänglighetstestning

Checklistan nedan används för att godkänna tillgänglighetstestning för en typisk webbapplikation. Använd den som utgångspunkt och utöka den med WCAG 2.2-framgångskriterierna som är relevanta för din produkt.

1. Finns tangentbordsekvivalenter för varje musoperation och dialogruta?
2. Förklarar användardokumentationen hur man använder applikationen med hjälpmedelsteknik?
3. Är tabbordningen logisk så att navigeringen flyter på naturligt?
4. Finns det kortkommandon för huvudmenyer?
5. Stöder applikationen alla utvalda operativsystem och skärmläsare?
6. Kommuniceras svarstiden för varje skärm eller sida tydligt så att användarna vet hur länge de ska vänta?
7. Är alla etiketter skrivna korrekt och programmatiskt länkade till sina kontroller?
8. Är färgvalen flexibla och testade mot färgblindhetssimulatorer?
9. Används bilder, ikoner och emojis på ett sätt som slutanvändare kan förstå?
10. Ger appen ljudaviseringar där de är användbara?
11. Kan användaren justera eller stänga av ljud- och videokontrollerna?
12. Kan användaren åsidosätta standardteckensnitt för utskrift och text på skärmen?
13. Kan användaren justera eller inaktivera blinkande, roterande eller rörliga displayer?
14. Se till att färg aldrig används som enda sätt att förmedla information.
15. Syns markeringen fortfarande när systemfärgerna är inverterade? Testa genom att ändra kontrastförhållandena.
16. Finns ljud- och videotranskriptioner eller textning tillgängliga för användare som inte kan höra?
17. Erbjuds utbildning för användare med funktionsnedsättningar för att hjälpa dem att bekanta sig med applikationen?
18. Är alla interaktiva kontroller tillgängliga, manövrerbara och avstängbara med enbart ett tangentbord?

Hur AI förändrar tillgänglighetstestning

AI omvandlasping Tillgänglighetstestning på tre praktiska sätt. För det första läser maskininlärningsskannrar nu den renderade DOM-filen tillsammans med datorseendemodeller för att upptäcka problem som regelbaserade verktyg missar, såsom olämplig alt-text eller färgkombinationer som misslyckas i verkliga layouter. För det andra föreslår generativ AI läsbara korrigeringar, inklusive bättre alt-text, tydligare felmeddelanden och ARIA-attribut för anpassade komponenter. För det tredje prioriterar AI resultat utifrån användarpåverkan, så att team kan lägga sin budget på de problem som är viktigast. Verktyg som Deque axe AI, Evinced, UserWay och Siteimprove inkluderar nu AI-funktioner. AI ersätter inte manuell skärmläsartestning eller användarundersökningar med personer med funktionsnedsättningar, men det minskar avsevärt den manuella prioriteringsarbetsbelastningen och hjälper tillgängligheten att flyttas åt vänster i utvecklingscykeln.

Myter om tillgänglighetstestning

Följande är vanliga myter om tillgänglighetstestning tillsammans med fakta:

Myt: Att skapa en tillgänglig webbplats är dyrt.

Faktum: Det är det inte. Att beakta tillgänglighet under designfasen, tillsammans med grundläggande tester, sparar pengar jämfört med eftermontering och minskar kostsamma omarbeten.

Myt: Att ändra en otillgänglig webbplats till en tillgänglig sådan är för tidskrävande och dyrt.

Faktum: Du behöver inte tillämpa alla korrigeringar på en gång. Börja med de ändringar som har störst inverkan på användare med funktionsnedsättningar och implementera resten i senare versioner.

Myt: Tillgängligheten är enkel och tråkig.

Faktum: Sidor kan fortfarande vara visuellt rika ochtractiv samtidigt som de uppfyller WCAG 2.2-riktlinjerna. W3C avråder uttryckligen från textversioner till förmån för en enda tillgänglig upplevelse för alla.

Myt: Tillgängligheten är endast för blinda och funktionshindrade användare.

Faktum: Att följa tillgänglighetsriktlinjerna förbättrar den övergripande användbarheten och gynnar alla användare, inklusive de som använder mobila enheter, i starkt solljus eller i bullriga miljöer.

Vanliga frågor