Checklista för tillgänglighet på webben

När vi bygger webbplatser finns idag möjlighet att nå långt fler människor än med traditionella medier, just för att digitalt innehåll går att tolka och hanteras av så många olika sorters verktyg. Digitalt innehåll är sökbart, det går visuellt att ändra storlek och typsnitt, det går att få uppläst av talsyntes och mycket mer. Det här gör att vi med en och samma lösning kan erbjuda innehåll som kan användas, förstås och tolkas av långt fler människor än vilken pappersprodukt som helst.

Men…

för att det digitala innehållet ska kunna ha denna flexibilitet i sin användning och verkligen kunna uppfattas på det sätt vi vill, så måste vi också presentera innehållet på rätt sätt, både när det gäller sidans tekniska struktur och när det gäller det pedagogiska upplägget och språket. Det är här tillgänglighet för webben kommer in.

Många projekt jag stöter på nedprioriterar tillgänglighet som fenomen, lägger det som ett sidospår eller har det inte ens i åtanke. Ofta handlar det om okunskap och ointresse. Tillgänglighet ses som något som kostar mycket pengar och osäkerheten gör att man inte ens närmar sig det på ett vettigt sätt. Någon säger “WCAG?” och alla duckar.

Det är hög tid att många fler webbplatser tar det där ack så viktiga första steget. Ta tillgänglighet på allvar. Kanske kan man inte göra allt, men man kan med enkla medel göra så oerhört mycket.

En checklista för alla

Därför erbjuder jag denna enkla checklista som kan användas av alla som testar en webbplats.

• En designer kan säkerställa att det finns en visuell representation för de delar som checklistan tar upp.
• För varje sida som byggs kan en utvecklare snabbt checka av listan.
• Med checklistan till hjälp kan en systemtestare snabbt scanna igenom en webbsida för att bekräfta att tillgänglighet finns i åtanke i alla relevanta delar.

Klarar man av detta, och det gör alla, så klarar man av att förstå hur lätt det kan vara att uppfylla stora delar av det som utgör teknisk tillgänglighet, och skapar förståelsen för att också jobba vidare med språk och media för att ta nästa steg i tillgängligheten.

Checklistans styrka ligger i att enkelt bara testa av de delar som är relevanta för den specifika sidan. Om sidan inte innehåller media eller formulär kan man skippa de avsnitten. För de flesta sidor har du alltså endast 14 checkpunkter att ta hänsyn till. Klarar webbplatsen att uppfylla alla dessa så har man kommit längre än de flesta.

» Ladda ner checklista för tillgänglighet på webben (PDF)

Checklista för tillgänglighet

Här kan du läsa innehållet i checklistan:

Enskilda element på en sida

• Det finns genomtänkta textalternativ för allt innehåll som inte är text (alt-text för bilder, texter som beskriver innehåll i video, och så vidare.
• Om bilder inte är betydelsebärande så är alt-texten tom. Attributet måste dock finnas.
• Bilder används inte för att representera enbart textinnehåll.
• Samtliga element har tillräckligt hög kontrast (text, rubriker, knappar, bilder).
  Verktyg för analys av text: http://www.paciellogroup.com/resources/contrastanalyser/
• Färg används inte som enda sätt att urskilja eller särskilja visuellt innehåll. Enbart färg räcker till exempel alltså inte för att indikera länkar.
• Instruktioner till användaren förlitar sig inte enbart på form, storlek eller visuell placering Detta är exempelvis fel: ”klicka på den fyrkantiga ikonen” eller ”läs instruktionerna i kolumnen till höger”.

Hela sidan

• Sidans titel (title) är logisk och intuitiv. Den ska gå att förstå utanför sitt sammanhang.
• Det går att navigera med tab-tangenten från start till slut och samtliga länkar och trigger-områden (klickbara element/ytor) går att aktivera med tangentbordet, och de aktiveras i en logisk följd. Det är samtidigt visuellt tydligt vilken länk som är aktiverad.
• Det finns en tydlig struktur i dokumentet. Det innebär bland annat att rubriknivåer h1-h5 används och innehållet kommer i en logisk följd, även i koden.
• Det går, från sidans topp, att hoppa direkt till sidans huvudinnehåll. Syftet är att hoppa över header/meny för att undvika att de blir upplästa vid varje omladdning av webbtjänsten. En tydlig rubrik i koden kan räcka.
• Länkar eller knappar med samma text som går till olika platser är direkt särskiljbara.
• Tabeller används för tabulär data. Tabeller används inte enbart för layout.
• När ett element på sidan får fokus (inget klick) så förändras inte sidan på ett sätt som kan desorientera användaren. Det ska inte ske någon förändring av övrigt innehåll på sidan, det startar alltså inte en popup eller lightbox, tangentbordets fokus förändras inte, och så vidare.
• Betydande fel i validering av HTML/XHTML undviks.
  Kan testas med http://validator.w3.org/

Formulär

• I formulär används rätt label för rätt element. Detta kan testas genom att klicka på rubriken vilket ska aktivera inmatningsfältet så att markören placeras där.
• Obligatoriska formulärfält som kräver en viss längd, ett visst format eller ett visst värde upplyser om det inom etiketten (label) för det formulärfältet, eller om det inte finns en etikett så inom ”title”-attributet för fältet.
• Om de används så presenteras felmeddelanden vid validering på ett effektivt, intuitivt och tillgängligt sätt. Felet är tydligt identifierat, det finns snabb access till elementet/fältet där felet återfinns och användaren kan lätt åtgärda felet och skicka om formuläret.
• Det finns tillräckligt med etiketter, vägvisare och instruktioner för obligatoriska interaktiva element på sidan. Dessa kan vara i form av instruktioner, exempel, korrekt placerade fältetiketter och/eller användning av fieldset/legend.
• Om ett inmatningsfel upptäcks, antingen via klientvalidering eller validering på servern, ges förslag som påvisar hur felet kan rättas till.

Media / rörlig grafik

• Det finns textalternativ som förklarar budskapet i eventuellt video/ljud.
• Det finns stöd för att pausa, stoppa, tysta eller justera volymen för ljud som spelas i mer än 3 sekunder.
• Innehåll som automatiskt blinkar eller rullar i perioder längre än 5 sekunder kan stoppas, pausas eller döljas av användaren.
• Inget innehåll på sidan blinkar mer än 3 gånger per sekund såvida inte blinkandet är tillräckligt litet, med låg kontrast och inte har för mycket rött.

Automatisk utloggning och tidsgränser

• Om en sida har en tidsgräns så får användaren alltid möjlighet att förlänga, stänga av eller justera den tidsgränsen. Detta gäller inte för live-event (exempelvis en auktion) eller om tidsgränsen är mer än 20 timmar.

Så, nu har vi bockat av det grundläggande, det är inte toksvårt. Börja nu prata med människor och lyssna och se på hur de använder din tjänst i sin vardag.

Och vill du fördjupa dig lite mer i WCAG (Web Content Accessibility Guidelines) har jag även en mer omfattande guide: Koll på tillgänglighet. E-delegationens Vägledning för webbutveckling erbjuder också en hel del matnyttigt om tillgänglighet på svenska.