Så testar du själv om er sajt är tillgänglig
Man behöver inte börja med att beställa en tillgänglighetsgranskning. En halvtimme, en webbläsare och lite nyfikenhet räcker för att hitta förvånansvärt mycket själv.
Det här är inte ett sätt att avgöra om er webbplats uppfyller WCAG. Det är snarare motsatsen: sju enkla sätt att snabbt upptäcka sådant som uppenbart behöver rättas.
Gör testerna där det faktiskt spelar roll. I kassan, inloggningen, bokningen eller ansökningsformuläret. Den viktigaste frågan är inte om startsidan ser tillgänglig ut, utan om människor kan göra det ni vill att de ska kunna göra.
1. Lägg undan musen
Börja här. Det tar några minuter och avslöjar väldigt mycket.
Klicka i adressfältet och tryck sedan Tabb. Fortsätt genom sidan utan att röra musen. Använd Enter och mellanslag för att aktivera knappar och kontroller och piltangenter där komponenten kräver det.
Håll framför allt utkik efter tre saker:
- Ser du hela tiden var du befinner dig? Fokusmarkeringen ska vara tydlig.
- Kommer du åt allt som går att klicka på med musen?
- Går det att förstå i vilken ordning du rör dig genom sidan?
Fokus behöver inte mekaniskt röra sig från sidans övre vänstra hörn till det nedre högra. Däremot ska ordningen vara begriplig och inte göra sidan svårare att använda. Och framför allt: du får inte kunna ta dig in någonstans med tangentbordet och sedan inte komma ut igen.
Försök sedan göra klart uppgiften. Köp varan. Skicka ansökan. Logga in.
Om det inte går utan mus har ni hittat något viktigare än en siffra i en revisionsrapport.
På Mac kan tangentbordsinställningarna påverka vilka element som får fokus, så kontrollera att tangentbordsnavigering är aktiverad innan ni börjar.
2. Zooma in
Förstora sidan till 200 procent.
Texten ska fortfarande gå att läsa och funktionerna ska gå att använda. Text får inte försvinna, klippas bort eller hamna ovanpå annan text bara för att användaren behöver större text. WCAG kräver att text ska kunna förstoras till minst 200 procent utan att innehåll eller funktion går förlorad.
Testa sedan ännu större förstoring. På en vanlig desktopskärm är 400 procent ett bra sätt att hitta problem med reflow: vanlig text ska inte kräva att du åker fram och tillbaka i sidled för att läsa varje rad. Vissa saker, exempelvis stora tabeller och kartor, är naturliga undantag.
Det här testet brukar vara brutalt mot gränssnitt som bara råkar fungera i den storlek designern ritade dem.
3. Kontrollera kontrasten
Ljusgrå text på vitt är fortfarande vanligt. Detsamma gäller tunna ljusgrå linjer runt formulärfält som nästan försvinner mot bakgrunden.
I Chrome kan ni högerklicka på ett element, välja Inspektera och titta på dess färger. Webbläsaren kan hjälpa till att visa kontrastförhållandet.
För vanlig text är gränsen normalt 4,5:1 och för stor text 3:1. För grafiska detaljer och delar av gränssnittet som måste synas för att man ska förstå att en kontroll finns eller vilket tillstånd den befinner sig i gäller också 3:1.
Det betyder inte att varje knapp måste ha en mörk ram. Det betyder att det som gör knappen, fältet eller fokusmarkeringen begriplig faktiskt måste gå att se.
4. Titta på bilderna
Bilder är svårare att kontrollera än man först tror, eftersom rätt alt-text beror på varför bilden finns där.
En bild som förmedlar information behöver ett textalternativ som förmedlar samma viktiga information. En bild som bara är dekoration ska normalt ha tom alt-text så att en skärmläsare kan hoppa över den. Och om bilden fungerar som en knapp eller länk ska textalternativet beskriva vad den gör, inte hur den ser ut.
Högerklicka på några av sidans viktiga bilder och välj Inspektera. Leta efter alt.
Men nöj er inte med att konstatera att något står där.
Fråga i stället:
Vilken information eller funktion tillför bilden som inte redan finns i texten runt omkring?
Det är ungefär det textalternativet behöver förmedla.
alt="bild" är inte mycket bättre än ingenting. alt="DSC_4837.jpg" är ett ganska tydligt tecken på att ingen har tänkt på frågan alls.
5. Läs bara rubrikerna
Rubriker är inte stora texter. De är sidans struktur.
En person som använder skärmläsare kan använda dem för att navigera mellan avsnitt på ungefär samma sätt som andra snabbt skannar rubrikerna med blicken. Därför spelar det roll om det som ser ut som en rubrik faktiskt också är en rubrik i koden.
Titta på sidans struktur. Huvudrubriken är normalt en H1. Sidans större avsnitt blir H2 och delar av dessa kan bli H3.
Det viktiga är hierarkin.
Om ett H2-avsnitt innehåller en underrubrik bör man inte plötsligt välja H4 bara för att den råkade ha rätt teckenstorlek. Däremot är det inget konstigt att gå från en H4 tillbaka till en H2 när nästa huvudavsnitt börjar.
Om ni väljer rubriknivå efter hur stor texten ska vara har ni blandat ihop design och semantik.
6. Gå igenom formulären
Här blir små tillgänglighetsproblem snabbt stora problem.
Börja med etiketterna. Ett formulärfält behöver gå att identifiera även efter att man börjat skriva i det. Placeholder-text inuti fältet är därför ingen bra ersättning för en riktig etikett. W3C rekommenderar att formulärkontroller har etiketter som är korrekt kopplade till respektive kontroll.
Ett enkelt test är att klicka på texten bredvid ett vanligt textfält. Hamnar markören i fältet är etiketten sannolikt kopplad till det. För kryssrutor och radioknappar ska etiketten på motsvarande sätt aktivera kontrollen.
Gör sedan fel med flit.
Lämna ett obligatoriskt fält tomt. Skriv fel format. Försök skicka.
Får du veta vad som är fel och vad du behöver göra åt det, eller blir kanten bara röd?
Kontrollera också vad som händer om formuläret tar lång tid att fylla i. Tidsgränser kan finnas, men användaren behöver i normalfallet få möjlighet att stänga av, justera eller förlänga dem.
Ingen ska behöva fylla i ett tjugominutersformulär två gånger därför att systemet bestämde att de var för långsamma.
7. Lyssna på sidan
Till sist kan ni höra vad gränssnittet faktiskt berättar när det visuella lagret försvinner.
Mac har VoiceOver inbyggt och Windows har Skärmläsaren/Narrator. Starta hjälpmedlet och navigera runt på sidan.
Ni behöver inte låtsas att ni efter fem minuter vet hur det är att använda skärmläsare varje dag. Det gör ni inte.
Lyssna i stället efter uppenbara problem.
En knapp som bara presenteras som "knapp". Flera länkar med samma obegripliga namn. Bilder vars filnamn läses upp. Formulärfält där det inte går att förstå vad man förväntas skriva. Rubriker som inte är rubriker.
Ni får plötsligt höra en annan version av samma gränssnitt.
Och ibland är den versionen betydligt sämre än den ni ser.
Kör ett automatiskt test också
När ni ändå håller på: öppna Lighthouse i Chromes utvecklarverktyg och kör Accessibility.
Verktyg som axe och WAVE kan gå ännu längre och hjälpa till att förklara vad de hittar.
Automatiska tester är bra på sådant som faktiskt går att avgöra automatiskt: vissa kontrastproblem, saknade attribut och en mängd problem i koden.
Men de kan inte avgöra allt. De vet exempelvis inte nödvändigtvis om en alt-text är bra, om en navigeringsordning är begriplig eller om hela köpet faktiskt går att genomföra på ett rimligt sätt. En full poäng i Lighthouse betyder därför inte att sidan är tillgänglig. Det betyder att den klarade det som Lighthouse testade. En fullständig bedömning behöver kombinera automatiska och manuella tester.
Konkreta problem med tillgänglighet
Efter en halvtimme kommer ni förmodligen inte ha ett betyg på er webbplats.
Däremot har ni konkreta problem att hugga tag i.
Börja med sådant som hindrar människor från att göra det viktigaste. En knapp i kassan som inte går att nå med tangentbord. Ett formulär som inte går att skicka. Text som försvinner när den förstoras.
Fortsätt sedan med sådant som gör tjänsten onödigt svår att använda.
Det betyder inte att övriga WCAG-krav försvinner. Det är bara ett vettigt sätt att börja rätta en produkt som människor redan använder.
När det inte räcker
De här sju kontrollerna är inte en tillgänglighetsgranskning. En webbplats kan klara allihop och fortfarande ha betydande tillgänglighetsproblem. Det är också så W3C beskriver den här typen av enkla kontroller: som ett sätt att få en första bild, inte att avgöra om en webbplats uppfyller WCAG.
Men om ni hittar femton problem på en halvtimme behöver ni inte heller beställa en rapport för att få veta att det finns arbete att göra.
Rätta det ni redan vet.
När ni sedan vill veta vad som återstår kan vi hjälpa till med resten. Så jobbar vi med tillgänglighet. Vi granskar mot WCAG 2.2 AA, men kan också gå vidare och rätta problemen vi hittar.
Börja gärna med de sju ovan.
Det är billigare att låta oss hitta problem ni själva inte kunde hitta.