Testa webbplatsens tillgänglighet: gratisverktyg och manuella test

Här är en historia som vi hör ofta. Någon kör Lighthouse, får en grön 100 för tillgänglighet och går vidare. En vecka senare skriver en kund och berättar att hen inte kunde betala, eftersom kortformuläret inte går att nå med tangentbordet. Båda sakerna är sanna. Den automatiska kontrollen godkändes, och webbplatsen svek ändå en verklig människa.

Den här guiden visar hur du testar ordentligt med liten budget: vilka gratisverktyg du ska köra, en manuell rutin på 15 minuter, ett första försök med skärmläsare och när det är värt att betala för en granskning.

Kan ett automatiskt verktyg avgöra om min webbplats är tillgänglig?

Nej. Automatiska verktyg hittar vissa problem snabbt, men många tillgänglighetsfrågor kräver en människa för att besvaras. När brittiska Government Digital Service testade 10 verktyg på en sida med 143 kända fel hittade det bästa 41 %. W3C säger det rakt ut: utvärderingsverktyg ”kan inte avgöra tillgänglighet, de kan bara hjälpa till med det.”

Testet från GDS (öppnas i en ny flik) är från februari 2017, och dess 41 % (från Asqatasun) inkluderade verktygets uppmaningar till manuella kontroller. Verktygen har blivit bättre sedan dess, men glappet har samma orsak. Programvara kan se att en bild saknar alternativtext. Den kan inte se att ”röd klänning” är fel beskrivning av ett foto av en blå kostym, eller om din fokusordning är begriplig.

Se alltså ett verktyg som ett brandlarm, inte som en besiktning av hela huset. Det är ändå värt att köra: WebAIM Million 2026 (öppnas i en ny flik) hittade upptäckbara fel på 95,9 % av startsidorna hos de en miljon största webbplatserna, så på de flesta webbplatser finns det fel som är lätta att rätta. Som W3C:s guide till att välja verktyg (öppnas i en ny flik) säger: ”Mänskligt omdöme krävs.”

Vilka gratisverktyg för tillgänglighetstest ska jag använda?

Använd ett eller två automatiska verktyg, ett kontrastverktyg och en skärmläsare. Verktygen tillämpar olika regler och redovisar resultaten på olika sätt, så två verktyg hittar oftast mer än ett. Alla verktyg nedan har en kostnadsfri version. Kontrollera de aktuella villkoren för vart och ett innan du förlitar dig på det, eftersom namn, funktioner och priser ändras.

Vad kan jag kontrollera för hand på 15 minuter?

Ganska mycket. W3C:s Easy Checks (öppnas i en ny flik) omfattar sidtitlar, alternativtexter, rubriker, kontrast, hopplänkar, synligt tangentbordsfokus, sidspråk, zoom, undertexter och formuläretiketter. Välj en viktig sida, till exempel en produktsida eller ditt bokningsformulär, och ge varje kontroll en minut eller två. Du kommer att hitta saker som inget automatiskt verktyg rapporterar.

W3C säger att de här kontrollerna ”bara täcker några få tillgänglighetsproblem”, så de är ingen fullständig utvärdering. De är ändå den bästa kvarten du kan lägga:

1. Sidtitel (1 minut). Säger fliken i webbläsaren vad sidan är, till exempel ”Boka bord | Rosas kök”, i stället för ”Start” överallt?
2. Bilder (2 minuter). Visa alternativtexterna med WAVE eller liknande. Stämmer de? Hoppas dekorativa bilder över?
3. Rubriker (2 minuter). Lista rubrikerna och läs dem för sig. Fungerar de som en innehållsförteckning?
4. Kontrast (2 minuter). Kontrollera brödtext, liten grå text, knapptext och text på bilder.
5. Tangentbord (4 minuter). Lägg undan musen och tabba dig igenom sidan (se nästa avsnitt).
6. Zoom (2 minuter). Kan du med 200 % zoom, och sedan 400 %, fortfarande läsa allt och använda menyn utan att rulla i sidled?
7. Formulär och språk (2 minuter). Klicka på varje fälts etikett; i ett välbyggt formulär hamnar markören då i fältet. Kontrollera i verktygets rapport om sidspråket saknas.

Hur testar jag med tangentbord?

Lägg undan musen. Tryck på Tab för att gå framåt, Skift+Tab för att gå bakåt, Enter för att följa länkar, mellanslag eller Enter för att trycka på knappar och piltangenterna i menyer och radioknappar. Varje interaktivt element ska gå att nå, du ska alltid se var du är och du ska aldrig fastna.

På en Mac hoppar Safari över länkar när du trycker på Tab, tills du slår på inställningen för att markera varje objekt på en webbsida med Tab under Avancerat i Safaris inställningar. Kontrollera sedan:

• Ser du alltid var du är? Om fokusramen försvinner är en tangentbordsanvändare vilse.
• Är ordningen logisk? Fokus ska följa läsordningen.
• Täcks något? Ett fast sidhuvud eller en cookiebanner som döljer det fokuserade elementet underkänns enligt kriteriet Focus Not Obscured i WCAG 2.2.
• Kommer du ut igen? Öppna varje meny, popup-fönster och datumväljare och försök sedan ta dig ut. Escape ska stänga dialogrutor.
• Fungerar hela flödet? Lägg en produkt i varukorgen, ändra antalet, använd en rabattkod och ta dig till betalningen utan musen.

Skriv ner varje fel exakt: ”Storleksväljaren på produktsidan går inte att öppna med Enter eller mellanslag” blir åtgärdat mycket snabbare än ”tangentbordet fungerar inte”.

Hur testar jag med skärmläsare för första gången?

Börja med den skärmläsare som redan finns i din enhet, eller NVDA i Windows, och lyssna på en sida. Du försöker inte använda den som en expert. Du kontrollerar att rubriker, länkar, knappar, bilder och formulärfält läses upp med begripliga namn och att inget viktigt är tyst.

• Mac: Kommando+F5 slår på och av VoiceOver; Kontroll+Alternativ+U öppnar rotorn, en lista över rubriker, länkar och formulärkontroller.
• Windows: i NVDA trycker du på H för att hoppa mellan rubriker och Insert+F7 för att lista länkar och rubriker.
• Mobil: slå på VoiceOver (iPhone) eller TalkBack (Android) och svep åt höger för att gå från objekt till objekt. Lär dig först hur du stänger av den.

Lyssna efter det som betyder mest. I WebAIMs skärmläsarenkät från 2024 (öppnas i en ny flik) svarade 71,6 % att de först navigerar en lång sida via rubrikerna, så börja där. Ta sedan fram länklistan: fem länkar som heter ”Läs mer” säger ingenting till någon. ”Lägg i varukorgen, marinblå tröja” är en användbar knapp; ”knapp” är det inte. Fyll till sist i ett formulär och kontrollera att varje fält och varje fel läses upp.

Var försiktig med slutsatserna. Om det låter trasigt för dig är det förmodligen trasigt; om det låter bra är det inget bevis. Hur vana användare faktiskt arbetar kan du läsa om i hur personer med funktionsnedsättning använder webben.

Hur kontrollerar jag zoom, omflödning och textavstånd?

Zooma webbläsaren till 200 % och kontrollera att texten växer utan att klippas av eller överlappa. Testa sedan omflödningen: med 400 % zoom i ett fönster som är 1 280 pixlar brett ska innehållet få plats utan att du behöver rulla i sidled. Öka till sist avståndet mellan bokstäver, ord, rader och stycken och kontrollera att inget går sönder eller försvinner.

Det motsvarar WCAG-kriterierna Förändring av textstorlek (1.4.4), Reflow (1.4.10) (öppnas i en ny flik) och Text Spacing (1.4.12) (öppnas i en ny flik). Reflow utgår från en bredd på 320 CSS-pixlar, vilket enligt W3C ”motsvarar ett visningsområde som från början är 1 280 CSS-pixlar brett vid 400 % zoom.” Text Spacing kräver att inget går förlorat när en läsare ställer in radavståndet på 1,5 gånger teckenstorleken, styckeavståndet på 2 gånger, teckenavståndet på 0,12 gånger och ordavståndet på 0,16 gånger.

Ett bokmärkesskript för textavstånd, ett litet skript som sparas som ett bokmärke, tillämpar alla fyra värdena med ett klick. Leta efter text som väller ut ur knappar och etiketter som klipps av i kanten. Med 400 % zoom visar en bärbar dator ungefär det som en liten mobil visar, så en välbyggd responsiv webbplats klarar redan mycket av detta.

Hur kontrollerar jag formulär, felmeddelanden och kassan?

Fyll i varje viktigt formulär tre gånger: en gång korrekt, en gång med alla fält tomma och en gång med avsiktliga fel. Varje fält ska ha en synlig etikett, varje fel ska förklaras i ord bredvid sitt fält och du ska kunna klistra in i fält för lösenord och verifieringskoder.

• Felmeddelanden. ”Ogiltig inmatning” i rött räcker inte. ”Ange giltighetstiden som MM/ÅÅ” bredvid fältet gör det. Efter att formuläret skickats ska fokus flyttas till felsammanfattningen eller det första fältet med fel.
• Inloggning och koder. Enligt kriteriet Accessible Authentication (öppnas i en ny flik) i WCAG 2.2 underkänns det att blockera inklistring eller lösenordshanterare, om det inte finns ett annat sätt att logga in.
• CAPTCHA och tidsgränser. Skärmläsaranvändare rankade CAPTCHA som det mest problematiska på webben i WebAIMs enkät. Kontrollera att det finns ett tillgängligt alternativ och att tidsgränser kan förlängas.

Vår checklista för webbtillgänglighet har en mer fullständig lista för webbutiker, med bland annat cookiebanners och popup-fönster.

Vad ingår i en professionell tillgänglighetsgranskning, och när behöver jag en?

En tillgänglighetsgranskning är en specialists strukturerade genomgång mot en angiven standard, oftast WCAG 2.1 eller 2.2 nivå AA. Den kombinerar automatiska skanningar med manuella tester och tester med hjälpmedel av dina viktigaste mallar och flöden, och avslutas med en prioriterad rapport. Du behöver en när lagen gäller dig, före en större lansering eller när kunder ber om belägg.

Ställ de här frågorna innan ni kommer överens om ett pris:

• Vilken standard, version och nivå testar ni mot?
• Vilka mallar och flöden ingår? För en webbutik: startsida, kategori, produkt, varukorg, kassa, kontosidor och formulär.
• Testar ni för hand med skärmläsare, tangentbord och zoom, och i vilka webbläsare och på vilka enheter?
• Rangordnar rapporten problemen efter allvarlighetsgrad, anger var de finns och föreslår åtgärder?
• Ingår ett nytt test efter åtgärderna?

Priserna varierar mycket med leverantör, land och omfattning, så jämför vad som ingår. Omfattas du av tillgänglighetsdirektivet ger en granskning också stöd för det du skriver i din offentliga redogörelse; vår guide till tillgänglighetsdirektivet förklarar vem som omfattas.

Varför testa med användare med funktionsnedsättning?

För att det inte är samma sak att uppfylla en standard och att vara lätt att använda. En kassa kan klara varje kriterium i WCAG och ändå ta tjugo minuter för en skärmläsaranvändare. W3C skriver att utvärdering med användare med funktionsnedsättning ”identifierar användbarhetsproblem som inte upptäcks enbart genom en utvärdering av överensstämmelse”, och den visar ditt team hur folk faktiskt använder webbplatsen.

Du behöver inget labb. Några testtillfällen på din viktigaste uppgift, till exempel att hitta en produkt och betala, lär dig mer än ännu en omgång skanningar. Rekrytera via funktionsrättsorganisationer, undersökningsföretag eller bland dina egna kunder, och betala deltagarna för deras tid. Låt dem använda sina egna enheter och inställningar. W3C:s guide om att involvera användare i utvärderingen (öppnas i en ny flik) tar upp det praktiska.

Vad gör jag med resultaten?

Sortera problemen efter hur hårt de stoppar folk och var de uppstår, åtgärda dem i webbplatsens egen kod och eget innehåll, testa igen och skriv ner det som återstår. Ett fält utan etikett i kassan är viktigare än en kontrastmiss i sidfoten, och en åtgärd i en gemensam mall lagar varje sida som använder den.

1. Prioritera. Hinder i viktiga flöden (kassa, bokning, registrering) först, sedan gemensamma mallar, sedan enskilda sidor.
2. Åtgärda vid källan. Ändra temat, komponenten eller innehållet, inte bara symtomet.
3. Testa igen. Upprepa samma kontroller, för hand och med verktyg.
4. Dokumentera. Lista kända problem, med datum, i din tillgänglighetsredogörelse. Vår guide till WCAG 2.2 förklarar de nyare kriterierna.
5. Upprepa. Lägg till en tangentbordskontroll och en skanning i varje release.

Använder du en tillgänglighetswidget, vår egen inräknad, ska du testa med den stängd. En panel som SiteAccessible ger besökarna fler sätt att anpassa sidan, men WCAG frågar om sidan fungerar i sitt standardläge. Vissa granskningssystem bedömer inte sidor som kör ett overlay-skript, så stäm av med din granskare först.