7 vanliga tillgänglighetsmisstag (och hur du undviker dem)

Chansen är stor att du har hört talas om digital tillgänglighet tidigare, och du vet att det är viktigt att optimera din onlineprodukt för personer med funktionsnedsättning. Det är förståeligt om du känner dig överväldigad av all information och alla uppgifter som du bör göra för att förbättra din produkt. Kanske har du kommit fram till att det är så komplicerat att du behöver anlita en expert för att göra jobbet. Under tiden bryr du dig! Du vet bara inte hur du ska komma igång.

Oroa dig inte; att åtgärda eller undvika dessa problem är ofta inte så tidskrävande! Om du vet var du ska leta och vad du ska göra istället. Under de år jag har arbetat som webbutvecklare och front-end software engineer har jag stött på många tillgänglighetsproblem. Ofta kokar de ner till samma uppsättning punkter. I de flesta fall tar det inte mycket tid att arbeta med tillgänglighetsfrågor. Det är inte svårare eller dyrare. Det handlar om att göra sitt dagliga arbete med ett annat tankesätt som förbättrar tillgängligheten enormt.

Men nu till saken: låt mig förklara vilka de vanligaste tillgänglighetsproblemen är och, ännu viktigare: hur man undviker dem.

Misstag 1: Dålig semantisk markering

Att undvika tillgänglighetsproblem kräver inte extra arbete. Det kräver helt enkelt ett annat arbete

Ett av de vanligaste misstagen med beklagligt stora konsekvenser är dålig semantisk markering. Om du kan lite om HTML kanske du vet att en sida består av element som definieras av HTML-taggar, till exempel <h1> och <p>. De flesta element är semantiska: de beskriver tydligt sin innebörd på ett sätt som är läsbart för människor och maskiner.

Om du tittar på källan till en webbsida kommer du också att märka en hel del <div> och <span> element; det här är de icke-semantiska elementen. Dessa element är generiska behållare som inte ger någon mening åt sitt innehåll.

Skärmläsare förlitar sig i hög grad på semantisk HTML. De bildar ett tillgänglighetsträd baserat på semantiken på sidan. En användare med en skärmläsare kan hoppa från element till element med hjälp av genvägar. Den talar om vilka som är knappar, vilka som är rubriker, var navigeringen finns, hur informationen på sidan förhåller sig till andra element på sidan och så vidare.

Överanvändning av icke-semantiska element

Om du använder <div> och <span>-element där ett semantiskt element borde ha varit, går viktig information förlorad direkt. Användare som har en synnedsättning kan inte se webbplatsens struktur utifrån vad de ser. De kan inte se knapparna eller navigeringsmenyn. Webbsidan blir en enda stor hög med ostrukturerat innehåll. Ännu värre är att interaktiva element - som knappar - ofta blir helt oanvändbara. När jag surfar på webben stöter jag ofta på <span>-element som styrs av JavaScript, utformade som en knapp. JavaScriptet är skrivet för att aktiveras med ett musklick. Det här fungerar bra för alla som kan använda en mus, men det går inte att styra med tangentbordet och det är ofta omöjligt för en skärmläsaranvändare att hitta det överhuvudtaget.

Tips: använd semantisk HTML

Om det ser ut som en knapp och beter sig som en knapp, bör det vara en knapp

Mitt tips för att undvika detta oönskade beteende är förmodligen inte en överraskning: använd lämpliga semantiska HTML-element så mycket som möjligt. De enda fallen du bör använda <div> och <span> element är när det inte finns något annat element tillgängligt för att förmedla mening. Detta handlar vanligtvis endast om dekorativa ändamål.

Genom att använda semantiska element ökar tillgängligheten på din webbsida exponentiellt. Detta beror på att de innehåller information för webbläsaren om hur de ska användas. Som utvecklare eller ingenjör sparar du dessutom tid. Du behöver inte tänka på att efterlikna beteendet hos till exempel en knapp eftersom den redan fungerar på det sättet från början.

Använda fel semantiska element

Ett annat vanligt misstag i denna kategori är att välja fel semantiskt element. Detta är ofta resultatet av att man väljer ett element för dess utseende istället för dess beteende eller syfte. Du kanske inte använde en inbyggd <button> eftersom du tyckte att den såg ful ut. Eller kanske hoppade du över några rubriknivåer och valde en <h4> istället för en <h2>, eftersom du gillade att den hade en mindre teckenstorlek. Det här är fel väg att gå, vi har CSS för det ändamålet.

Tips: välj ett element för dess betydelse

Använd HTML-element för att strukturera ditt innehåll baserat på varje elements betydelse, inte dess utseende. Använd sedan CSS för att skapa stilar efter eget tycke och smak.

Tips: använd automatiserade verktyg

Ett bra sätt att hjälpa dig med semantiken är att använda ett HTML-validatorverktyg. Vissa verktyg inkluderar detta i automatiserade tillgänglighetstester, till exempel axe Tools. Kom ihåg att automatiserade verktyg inte kan testa allt och att de ofta innehåller falska positiva och negativa resultat. Men det kan hjälpa till att snabbt upptäcka misstag som du kanske har förbisett. Det bästa alternativet är att kombinera automatiserad och manuell testning för tillgänglighet.

Misstag 2: Dåligt strukturerade formuläretiketter

Om det ser ut som en knapp och beter sig som en knapp, ska det vara en knapp.

Det här felet har också mycket att göra med semantisk HTML. Gör inga misstag: att utforma och implementera ett användbart, tillgängligt och snyggt formulär är en utmaning!

Inloggningsformuläret för Easy LMS. Etiketterna flyttas upp när du fyller i ett formulärfält, så att de förblir synliga.

Input och label är inte kopplade till varandra

Varje formulär har ett inmatningsfält och en etikett som beskriver inmatningsfältet. Jag har till exempel tre inmatningsfält: "Namn", "E-postadress" och "Företag". Jag skulle kunna lägga till namnen ovanför inmatningarna i vanlig text (t.ex. i ett <span>-element?). Tyvärr kommer en skärmläsaranvändare att hitta tre tomma textinmatningar utan en indikation på vad som ska fyllas i.

Tips: para ihop etikett och inmatning

Att använda semantiska HTML-element för etiketterna räcker redan långt, men om du verkligen vill hjälpa dina användare bör du också para ihop din etikett och inmatning. Nu vet webbläsaren att de två hör ihop. På Easy LMS skulle vi säga: vinst!

Använda platshållarattribut som etiketter

En annan tillgänglighetsrisk är att utelämna etiketter och istället använda platshållarattribut på inmatningarna. Detta är dålig praxis av ett par skäl. För det första är det ofta inte tillgängligt för många tekniska hjälpmedel. För det andra försvinner etiketterna så snart en användare skriver in inmatningen (eller fyller i formuläret automatiskt). Det är svårt att kontrollera om det finns fel i formuläret på det sättet. Slutligen är en platshållare avsedd som en extra ledtråd - inte som en etikett.

Tips och råd: Ersätt inte en etikett med en platshållare

Utelämna aldrig etiketter i ett formulär. Om du måste, använd platshållare endast för att ge ytterligare ledtrådar till (seende) användare i formulär. Men ännu bättre: använd inte platshållarattribut alls och se till att den viktiga informationen om formuläret är tillgänglig för alla.

Misstag 3: Använda länkar som inte är beskrivande

Hur ofta har du stött på länkar som säger "klicka här", "läs mer" eller "gå till den här sidan"? Min gissning: fler än du kan räkna! En anledning till att det här är dålig praxis är att det inte går att förstå länkens syfte utanför sammanhanget. Med hjälp av tekniska hjälpmedel kan användarna snabbt navigera genom länkarna på en sida. Föreställ dig att en skärmläsare kommunicerar följande till dig: "Här, länk. Läs mer, länk. Den här sidan, länk". Det säger väl egentligen ingenting, eller hur?

Tips: inkludera sidans ämne i länken

Så, hur undviker vi detta? I de flesta fall kan detta lösas enkelt genom att inkludera ämnet eller titeln på den sida du hänvisar till i länken. Låt mig ge dig ett exempel: du kan lära dig mer om olika typer av funktionsnedsättningar i den här artikeln av W3C. Nu kommer skärmläsaren att kommunicera: "olika typer av funktionsnedsättningar, länk". Vinst!

Tips: optimera upprepade länkar

Jag kan tänka mig att du inte vill inkludera titeln i varje "Läs mer"-länk under en artikellista. Det lägger till en hel del röran på sidan. Det finns ett antal olika tillvägagångssätt för att göra "läs mer"-länkar tillgängliga, och det skiljer sig från användningsfall till användningsfall vilken som skulle fungera bäst. På översikten över den här bloggen valde vi att optimera länkarna för skärmläsare genom att lägga till en aria-label som innehåller artikelns titel.

Misstag 4: Beroende på att bilder är det enda sättet att förmedla information

Jag är själv en visuell tänkare och vet hur mycket lättare det kan vara att förstå något utifrån en bild jämfört med att läsa text. Jag påstår inte att det är dåligt att använda bilder för att förklara eller hänvisa till i en förklaring. Faktum är att jag skulle vilja uppmuntra alla att använda bilder på det sättet, eftersom det för vissa funktionsnedsättningar (som dyslexi) faktiskt förbättrar tillgängligheten. Men att använda bilder som det enda sättet att förmedla information är inte bra.

Globalt är cirka 43 miljoner människor blinda och cirka 295 miljoner människor har måttlig till svår synnedsättning. Detta antal inkluderar inte bara total blindhet, utan också till exempel förlust av central eller perifer syn och suddig syn. Om du är beroende av bilder för att förklara din poäng riskerar du att en del av din publik missar en stor del av informationen.

Skärmdumpar

Ett exempel från verkligheten är när man förklarar hur man använder ett gränssnitt med hjälp av skärmdumpar. Texten lyder helt enkelt "klicka på knappen som är markerad i skärmdumpen" eller "ställ in din konfiguration enligt följande skärmdump". Utan dessa bilder är det omöjligt att veta vad man ska göra med dessa instruktioner. Med tanke på att den här typen av artiklar ofta finns i kunskapsbanker, dokumentation eller handledningar blir det ännu mer problematiskt.

Ett exempel på en skärmdump från vårt Help Center. Den medföljande texten i hjälpartikeln lyder: "Du kan justera inställningarna för din Pass-kategori genom att välja Redigera".

Tips: din text ska vara begriplig utan bilder

Din publik ska kunna förstå informationen utan bilderna. Med instruktioner i både text och bild kan läsaren välja det sätt hen föredrar att ta till sig informationen på eller har en reservlösning om hen inte kan ta till sig den. Ett knep som jag själv använder är att skriva texten i sin helhet och lägga till bilderna efteråt, som jag gjorde för den här bloggartikeln. På så sätt slipper jag gå i fällan att utelämna information för att den syntes i en bild medan jag skrev.

Avsaknad av alternativ text

Ofta har informativa bilder som du hittar på webbplatser antingen dålig alternativtext eller så har de ingen alls. Syftet med alt-texter är att beskriva bilden för skärmläsaranvändare. Om den är tom vet inte skärmläsaranvändare vad som finns på bilden eller om de har missat viktig information.

Tips: lägg till alternativa texter till funktionella och informativa bilder

Den alternativa texten kommer att kommuniceras till en användare som inte kan se bilden (ordentligt). Jag skulle vilja uppmuntra alla att inte ignorera dessa utan att lägga till en tydlig beskrivande alternativ text för bilden. Detta kan göras i källkoden. I ett CMS finns det ofta ett dedikerat inmatningsfält för det.

Tips: hantera dekorativa bilder för skärmläsare på olika sätt

Ibland läggs bilder bara till som dekoration för att göra en sida mer visuellt attraktiv. Ibland är det bäst om bilder helt och hållet hoppas över av en skärmläsare. Det finns olika sätt att hantera alternativa texter beroende på vad syftet med bilden är.

Text i bilder

Text i bilder är inte heller begriplig för personer med synnedsättning. Du skulle bli förvånad över hur mycket text som finns i bilder (titta bara på vilken social medieplattform som helst). Återigen, detta är inte dåligt i sig, men se till att du lägger till texten i en beskrivning eller som alternativ text också.

Misstag 5: Dålig färgkontrast

Välj ett HTML-element utifrån dess betydelse, inte dess utseende

Text med låg kontrast var det tillgänglighetsproblem som oftast upptäcktes i de automatiserade tester som utfördes av WebAIM. Detta är inte bara problematiskt för personer som lider av nedsatt syn utan påverkar även personer med färgsynsbrist (olika typer av färgblindhet). Omkring 1 av 12 män och 1 av 200 kvinnor har någon grad av färgseendebrist. Vissa människor är inte ens medvetna om att de har detta. Om du tittar på bilden nedan, vilken siffra ser du?

Which number do you see? Image source

Om du ser 74 kan du ha normal färgsyn. Om du ser 21 eller inget nummer alls, kan du ha en rödgrön färgsynsbrist. I så fall kan du ha stött på webbplatser med delar som var svåra att läsa.

I WCAG definieras ett framgångskriterium för när kontrasten mellan text och bakgrund är tillräckligt hög för att personer med måttlig synnedsättning ska kunna läsa den. WCAG:s riktlinjer är indelade i tre nivåer av överensstämmelse. På Easy LMS siktar vi på nivå AA. Kontrastförhållandena är 4,5:1 för liten text och 3:1 för stor text.

Tips: använd ett verktyg för att kontrollera färgkontrasten

Så hur tar du reda på om kontrasten i texten är tillräckligt hög? Det finns många färgkontrastverktyg tillgängliga som du kan använda för att köra tester på din webbsida. Du kan också testa färgkontrasten manuellt genom att ange färgkoderna för förgrunds- och bakgrundsfärgen i en online contrast checker.

Tips: använd mörkare eller ljusare nyanser av en färg

En utmaning som ofta uppstår i den här frågan är att färgerna som används i användargränssnittet matchar färgerna i varumärkeslogotypen. Detta kan göra det svårt att hantera, eftersom färgerna känns som om de är en del av varumärkesidentiteten. En bra metod är att använda en mörkare eller ljusare nyans av den färg du vill ha för att förbättra kontrasten. Vi justerade färgerna i Easy LMS av denna anledning för ett par år sedan!

Använda färg som det enda sättet att förmedla information

Jag har tidigare nämnt de problem som uppstår när bilder används som enda sätt att förmedla information. Samma sak gäller för färger. Färgerna rött och grönt används ofta som det enda sättet att informera om framgångs- och feltillstånd. Tyvärr är röd-grön färgblindhet den vanligaste typen av färgblindhet. För dessa drabbade användare kommer rött och grönt att se likadana ut.

Tips: tillhandahåll flera sätt att kommunicera stater

Det är OK att fortfarande använda rött och grönt för dessa ändamål, men se till att du alltid tillhandahåller ett annat sätt att kommunicera tillstånd, till exempel text, olika former eller (märkta) ikoner.

Misstag 6: Ger inte en visuell indikation på aktuellt fokus

De flesta användare navigerar på sina datorer med en pekdon, t.ex. en mus eller en styrplatta på en bärbar dator. På mobila enheter använder vi våra fingrar på en pekskärm. För vissa användare är detta antingen svårt eller omöjligt på grund av deras funktionsnedsättning. Exempel på detta är förlamning, en saknad kroppsdel, artrit eller repetitiv stressskada. I dessa fall byter användarna ofta till ett tangentbord eller en alternativ inmatningsenhet som kan efterlikna tangentbordets beteende. Användare med synnedsättning använder oftast ett tangentbord tillsammans med sin skärmläsare eller gester på sina mobila enheter.

Om du trycker på tabbtangenten på tangentbordet kan du hoppa mellan interaktiva element på en webbsida, t.ex. knappar och länkar. Du kan prova det på den här sidan: efter varje tabb ser du en visuell indikation på var du befinner dig på skärmen.

CSS-fokusstilar

I CSS kan du lägga till styling för flera olika tillstånd för knappar, till exempel svävande, fokus och aktiv. Ofta utelämnas några eller alla dessa tillstånd, och knappen ändrar inte utseende med interaktion. En tangentbordsanvändare flyger i blindo i det här fallet.

Tips: tillämpa fokusstilar tillsammans med hover-stilar

När du lägger till stilar för knapparnas hover-tillstånd är det bra att lägga till dem för fokustillstånden också. Helst ska fokusstilen vara tydligare än hoverstilen, så du kan också lägga till dem separat i en annan nyans.

Kontur för webbläsarfokus

En grundläggande fokusindikator tillhandahålls automatiskt av webbläsaren och visas vanligtvis som en kant. Om du bara tabbar dig igenom den här sidan kan du ha sett den. Tyvärr är denna kontur ofta inaktiverad med CSS på grund av estetiska skäl. Men när konturen är inaktiverad och det inte finns några fokusstilar är det omöjligt att navigera på en webbsida med enbart ett tangentbord.

Tips: inaktivera inte konturerna

Musanvändare kommer inte att se den webbläsarkontur som du ser när du tabbar dig igenom en webbsida med ett tangentbord. Inaktivera inte den här konturen med CSS, eftersom den är ett viktigt hjälpmedel för användare med funktionshinder. Den fungerar också bra som en reserv om dina fokusstilar är för otydliga eller saknas av misstag.

Tänk på att webbläsarnas indikatorer för tangentbordsfokus kan variera och ta sig olika uttryck. Av den anledningen kan du inte lita på dem helt och hållet. Å andra sidan skulle det krävas en hel del tester för att säkert veta om dina fokusstilar är tillräckligt tydliga för användare med funktionsnedsättning. Det är därför jag skulle rekommendera att alltid ha båda.

Misstag 7: Använda omärkta ikoner i knappar och länkar

Ikoner som används i programvara blir igenkännliga vid upprepad användning

Ikoner är ett bra sätt att undvika röran i din onlineprodukt. De har också förmågan att förbättra tillgängligheten för olika funktionshinder, det vill säga om de är otvetydiga. De flesta av oss vet att om vi ser en pennikon betyder det "redigera" och en papperskorg betyder "radera". När vi använder ikoner i ett användargränssnitt är det bäst att hålla sig till dem vi känner till för att undvika gissningar. Men även då är det mycket som kan gå fel när det gäller tillgängligheten.

Ikoner kan användas tillsammans med motsvarande textetikett eller på egen hand. Oftast finns det ingen etikett när de används ensamma. Jag lägger till exempel till en ikonknapp för en redigeringsåtgärd, med bara en ikon av en penna inuti. Om jag inte lägger till en textetikett för den här ikonen blir knappen en tom knapp. Det stämmer: en skärmläsare kommer att kommunicera till mig: "Knapp". Det är inte särskilt användbart.
Ännu mer så: Jag gör ett antagande om att användaren vet att en pennikon betyder "redigera". Men det vet jag inte säkert.

Tips: lägg till en etikett för ikoner

Om ikonen är en viktig del av ditt användargränssnitt är det bäst att lägga till en etikett. Det kan du göra genom att lägga till en aria-label på ikonen. Ett annat sätt är att lägga till text som du döljer för skärmar men som är synlig för skärmläsaranvändare. Det är bäst att lägga till ett titelattribut också. På så sätt visas etiketten om en musanvändare håller muspekaren över den.

Ikonknappar i Easy LMS-panelen som visar en titel när du håller muspekaren över den

Tips: dölj dekorativa ikoner

Om du har lagt till en ikon enbart som socker på toppen och informationen är begriplig utan den, är det bäst att dölj elementet för skärmläsaranvändare.

Slutsats: arbeta inte hårdare, arbeta smartare

Tanken på att du behöver ändra på dessa saker kan fortfarande vara lite överväldigande. När jag först fick höra talas om tillgänglighet reagerade jag på samma sätt. Det finns så mycket att lära sig och så många olika typer av funktionsnedsättningar. Det är svårt att skapa ett användargränssnitt som är perfekt för alla.

Men jag vill berätta för dig: det handlar inte om att se över din produkt eller webbplats. Jag har kommit fram till att det bästa sättet är att integrera det i arbetsflödet. Nästa gång jag skapar eller itererar på en del av produkten tillämpar jag det jag har lärt mig om tillgänglighet direkt. På så sätt kan vi förbättra tillgängligheten ett steg i taget. Som en av mina tillgänglighetshjältar Léonie Watson säger: "Det behöver inte vara perfekt, det behöver bara vara lite bättre än i går." Preach!