Tips hur man testar tillgänglighet

Owned by Marielle Sellin
Last updated: okt. 12, 2022 by Rebecka Näsström
8 min read

Detta dokument tar upp tips för hur man testar diverse olika områden inom tillgänglighet. Det finns mycket att kolla på inom tillgänglighet och detta dokument täcker tyvärr inte allt men det är en bra start om man vill lära sig mer om att testa tillgänglighet.

Innehållsförteckning

 

Automatiserade verktyg

När man testar tillgänglighet så kan man ta hjälp av automatiska testverktyg för att få en snabböverblick över sidans status. Dessa automatiska verktyg är bra komplement till din testning, men det är viktigt att utföra manuella tester också då det kan finnas ”falska positiva/negativa” resultat. Dessa två verktyg är bra att testa med:

Tangentbordsnavigering

Vem berör detta?

Många användare använder sig utav tangentbordsnavigering, bland annat användare som har nedsatt syn och de som kan ha nedsatt motorik/precision då muspekaren blir svår att kontrollera.

Hur testar du:

Tabba runt på sidan och se till att alla interaktiva/klickbara element är nåbara med tangentbordet. Placeringen ska visas tydligt genom en fokusram när man tabbar över interaktiva element och användaren ska förflyttas med fokuset på sidan så användaren vet var de är. Fokusramen ska ha en tillräckligt stark kontrast så den syns tydligt (kontrastvärde på minst 3.0).

Om det kommer upp exempelvis en modul som tar upp större del av sidan så ska de inte gå att tabba ut ur rutan förens man har stängt den. Det ska alltså bara gå att tabba mellan knapparna i modulen tills den stängs. Detta är viktigt eftersom modulen kommer ligga i vägen för användaren om det går att tabba ur modulen till sidan som ligger bakom modulen.

Tabbordningen ska vara konsekvent genom hela sidan, de ska inte vara olika beteende. Ex tabbordningen ska hålla vänster till höger genom hela sidan, de ska inte skifta mellan vänster till höger och sedan höger till vänster igen osv. Tabbordningen ska vara logisk det vill säga att ordningen som du tabbar igenom sidan matchar det visuella ordningen.

 

Mer information om tangentbordsnavigering:

Utveckla systemet så att det går att hantera med enbart tangentbordet - Vägledning för webbutveckling

https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html  

Skärmläsare

Vem berör detta?

Exempelvis användare med nedsatt syn och de som har svårt för textförståelse kan använda skärmläsare som ett hjälpmedel för att ta del av innehåll på sidan.

Hur testar du?

Använd dig av en skärmläsare och kolla så komponenterna har maskinläsbartext, som inmatningsfällt, menyer och andra komponenter. Maskinläsbartext är som text-etiketter i koden som kan tydas av datorn så skärmläsaren kan berätta vad det är för en sorts komponent. Därför är det viktigt att den maskinläsbara texten stämmer överens med knappen, menyn, inputfältet etc så användaren förstår vad det är och vad den gör.

 

All text som visas på sidan inklusive bildtexter ska gå att få uppläst, så inte användaren utesluts från att ta del av all information.

Bilder som kommunicerar något eller som används för att förtydliga ett samband ska också beskrivas via skärmläsaren. Ett exempel kan se ut så här i HTML-koden: alt="Person pratar i telefon", detta kommer då skärmläsaren att läsa upp.  Är det dock en ”dekorativbild” som inte ger någon form av information så behöver det inte beskrivas via skärmläsare, då lämnas alt attributet i HTML-koden tomt: alt="".

Info om dekorativa bilder: Decorative Images

 

Felmeddelanden i exempelvis formulär som uppstår ska uppmärksammas och läsas upp när man är i ett fält med felaktigt värde. Felmeddelandet ska då förmedla vad som är fel och hur användaren ska åtgärda felet.

Om en händelse sker på en sida så ska användaren uppmärksammas om detta, exempelvis om du öppnar en dropdown-meny så ska uppmärksammas om den öppnas eller stängs.

Om de finns flera olika språk som används på en sida så ska ’lang’ attributet användas för språket i HTML-koden, annars kan uppläsningen av språket bli svårt att förstå om de uttalas exempelvis på svenska när texten egentligen är engelsk osv.

Om du vill prova på en skärmläsare så rekommenderas JAWS, NVDA och VoiceOver. JAWS - är den skärmläsare som används av majoriteten av användare i Sverige, den kostar pengar men det går att prova en 40min demo gratis.

NVDA - är en gratis skärmläsare.

VoiceOver – är en gratisskärmläsare som finns inbyggd i Mac och iPhone.

Hur man använder skärmläsaren NVDA med hjälp av tangentbordsnavigering: NVDA Keyboard Shortcuts | Screen Reader Keyboard Shortcuts and Gestures

NVDA skärmläsare:

JAWS skärmläsare:

Information om skärmläsare: WebAIM: Designing for Screen Reader Compatibility

 

Kontrast

Vem berör detta?

Detta berör de flesta användare eftersom om de är dålig kontrast på komponenter och texter så kan viktig information missas på sidan. Särskilt utsatta blir de som har nedsatt syn eller färgblindhet.

Hur testar du?

Se till att det är nog kontrast mellan bakgrund och text. Kolla så fokusmarkeringar, tabeller, knappar och andra komponenter också har tillräcklig kontrast mot bakgrund.

Detta kan kollas med hjälp av olika tillägg och sidor där man kan skriva in färgvärdet på komponenten och bakgrunden för att se om kontrasten är tillräckligt stark. Färgvärdet får du tag i om du tar inspect-mode (F12) och klickar på den komponent du vill ha information av som då visas i css-koden.

Kontraster mellan text och bakgrund ska vara minst 4,5 för vanlig text och minst 3,0 för stor text. Mellan komponent och bakgrund så ska det vara minst 3,0 i kontrastvärde. Använder du tillägget ’Wave’ så kan du se direkt hur kontrastvärdet ser ut i inspect-läge (F12), alternativt så använder du inspect-läge (F12) för att leta upp färgvärdet i CSS koden.

 

Verktyg för att validera kontrast

 

Kognitiva tester 

Vem berör detta?

Användare som exempelvis har svårt för textförståelse, inlärningssvårigheter, kortminne eller nedsatt syn.

Hur testar du?

Se så att texter är begripliga och att språket inte är onödigt svårt. Texten på sidan ska inte vara för hoptryckt eller klumpig. Se också till att det inte är för långa meningar utan komma eller punkter, och de ska inte heller vara beskrivningar som är för korta för att hjälpa användaren. Det ska dessutom gå att ändra avstånd mellan text, rader och bokstäver via hjälpmedel.

Det ska vara lätt för en användare att hitta hjälp för att slutföra uppgifter på webbplatsen. Finns det kontaktuppgifter eller en hjälpfunktion inom webbplatsen ska de presenteras och placeras på ett konsekvent sätt.

 Verktyg för att validera text

  • Här finns ett verktyg/program som kan användas för att analysera textstycken för att se om den är för komplicerad, klumpigt etc: Lix räknare

  • Här finns även en plugin som kan användas för att skapa avstånd mellan ord och bokstäver på webben eller i diverse dokument Helperbird for Chrome

  • Här finns en bookmarklet som skapar avstånd mellan text, bokstäver och meningar:

  • Information om ’hjälpfunktion’ WCAG Web Content Accessibility Guidelines (WCAG) 2.2

 

Struktur & Klickyta

Vem berör detta?

Detta kan påverka de flesta, men exempelvis användare med nedsatt syn, nedsatt motorik/precision som använder muspekare och för de användare som navigerar med hjälp av skärmläsare så kan detta vara mer påverkande.

Hur testar du?

Klickyta

Knappar och andra interaktiva komponenter får inte ligga för tätt ihop om även klickytan är väldigt liten, då riskerar användaren att klicka fel av misstag. Ex en ’Avbryt’ knapp för tätt inpå en ’Skicka’ knapp. Den klickbara ytan blir mer tillgänglig genom att inkludera ett område runt det som är länkat. I nya WCAG 2.2 så kommer ett nytt kriterium (september 2022) som kräver att klickbara ytor ska vara åtminstone 24 x 24 pixlar. Är de till exempel en meny som har alla menyval ihopsatta så är det då ok såvida de är åtminstone 24 x24 px per klickbaryta. Det skulle också vara ok om klickytan var 20 x 20 px men att det ligger 4 px mellan klickytorna.

Nedan finns ett exempel från W3C där dom visar olika scenarion:

 

 

Rubriknivåer (H1 – H6)

En del användare som använder sig utav skärmläsare navigerar på sidor genom att hoppa från rubrik till rubrik. Därför är det viktigt att rubriknivåer ska användas på ett konsekvent sätt så de håller strukturen. H1-H6 ska inte användas som ett sätt att justera storlek på text, de ska användas för att sätta upp en hierarki för att kunna förstå innehållets kontext på sidan. Rubriker ska inte heller lämnas utan innehåll på sidan eftersom de kan förvirra användaren med skärmläsare.

Använd exempelvis Web developer plugin och välj ’Information’ -> ’View document outline’ för att se hur strukturen är uppbyggd. Eller använd plugin verktyget: Wave.

Verktyg för att validera rubriknivåer

 

Länkar för mer information nedan

 

Förstorning och liten skärm

Vem berör detta?

Detta kan beröra alla användare, men särskilt användare med nedsatt syn.

Hur testar du?

Se så komponenten/sidan fungerar i olika vyer, full desktop, halv deskop, surfplatta och mobilenheter (beroende på om sidan är anpassad för mobila enheter). Prova med olika mobila enheter och browsers. Ett tips är att använda inspekteraläget (F12) för att byta mellan olika vyer eller att förminska fönstret manuellt i olika storlekar om du inte har olika telefoner eller enheter tillgängligt.

Det ska fortfarande gå att tabba igenom en mobilvy, och all funktionalitet ska vara fungerande trotts att skärmen är mindre.

Användaren ska inte behöva scrolla i mer än en riktning, dvs de ska inte vara behövligt att scrolla lodrätt och vågrätt för att nå all information.

Förstora/scrolla in mer än 200% - Det ska fortfarande vara funktionellt, all text ska vara läsbar, text ska inte överlappas, gå sönder och de ska gå att navigera på sidan trotts att du förstorar sidan upp till 200% enligt WCAG. Zooma in genom att använda ctrl och + eller ctrl och scrolla med musen.

Det ska gå att enbart förstora texten på sidan också. Detta görs via browserns inställningar, där kan du välja att fördubbla textstorleken. All text på sidan ska kunna förstoras med hjälp av denna inställning. Texten ska inte överlappas eller bli oläslig.

Se länkarna nedan för mer information kring responsivitet, förstorad text och in zoomning:

 

 

Övriga tips för tillgänglighet

  • Webbplatsen ska presenteras utan störande skärmflimmer och utan rörliga och blinkande element som ej går att stänga av

  • Sidorna har unika och relevanta sidtitlar

  • Sidors adresser bör vara beskrivande

  • När användaren gör något som förändrar något på sidan, postar ett formulär eller på annat sätt interagerar med gränssnittet behöver de få en återkoppling på vad som händer eller har hänt.

  • Alla meningsbärande grafiska objekt ska innehålla en kort alternativbeskrivning (alt-text) som motsvarar bildens funktion om den är klickbar annars bildens motiv. Dekorbilder har tomma alt-attribut.

  • Genom att ha en konsekvent placering av knappar, minskar du ansträngningen för användaren att göra rätt val. En knapp för att exempelvis bekräfta gjorda val ska ligga på samma plats på alla sidor och inte byta plats med en knapp för att exempelvis avbryta.

  • Det finns ledtexter och instruktioner som beskriver för användaren hur och vad denne ska fylla i formuläret

  • Sträva efter att sökningar genererar relevanta resultat. De träffar som hamnar högst upp ska också vara de som är mest relevanta, då få användare letar långt ner i träfflistan.

  • Sökfunktionen bör också ge relevanta träffar när användaren stavar sökordet fel eller söker på synonymer.

  • Bakgrundsljud ska enkelt kunna stängas av manuellt eller avslutas automatiskt inom 3 sekunder

  • Ljudinformation i förinspelad video och i ljudklipp återges genom textning

 

Testmetodik från DIGG

Här finns testmetodiken för tillgänglighetsgranskning som DIGG tagit fram för vidare läsning och tips.