Blogg

Vanliga misstag av UX-designers och gränssnittsutvecklare

  • 06 december 2018
  • 0

När jag utvärderar tillgänglighet eller granskar arbetsprov stöter jag på en del återkommande problem med hur webblösningars gränssnitt är uppbyggda. Det kan handla om både visuell design, interaktionsdesign och hur gränssnittet är kodat. 

Artikelverktyg:

Hur allvarliga problemen är varierar och kan bero på enkla misstag eller – i en del fall – att man tyvärr saknar kunskap om hur man skapar webblösningar som är användbara för alla. 

Jag skulle vilja ta upp en del av de vanligaste och mest problematiska misstagen för att förklara varför de orsakar problem och hur man kan undvika dem. 

Var i processen från wireframes och interaktionsdesign till formgivning och slutligen gränssnittsutveckling ett problem uppstår varierar, men jag har ändå försökt göra en grov indelning mellan formgivning och interaktionsdesign samt gränssnittsutveckling, alltså den tekniska implementationen. 

Formgivning och interaktionsdesign 

Dålig kontrast mellan text och bakgrund 

För att så många som möjligt ska kunna tyda text utan att behöva använda hjälpmedel som ökar kontrasten behöver kontrasten mellan text och bakgrund vara tillräcklig. Vad som är tillräcklig kontrast beror på hur stor texten är och om den är fet. I WCAG 2.1 Contrast (Minimum) finns en detaljerad förklaring. 

Man behöver också kunna skilja länkar från den omgivande texten. Standardsättet, och det enklaste, är att låta länkad text vara understruken. 

Dålig kontrast mellan text och bakgrund är ett väldigt vanligt designproblem som drabbar inte bara personer med nedsatt syn utan även den som använder en enhet i en miljö som inte har optimala ljusförhållanden, till exempel en telefon, pekplatta eller laptop utomhus eller en projektor. 

Ingen fokusmarkering 

När man enbart använder tangentbordet för att navigera på en webbsida är man beroende av att kunna se vilket element som har tangentbordsfokus. Ibland kan det vara svårt eller helt omöjligt eftersom designern har bestämt att webbläsarens standardsätt att markera fokus är fult och ska stängas av. Det är helt ok att göra så länge man ersätter standardutseendet med något som är minst lika tydligt. 

Det är också vanligt att fokusmarkeringen anpassas för vissa element, tas bort helt för en del och inte rörs för andra. En tumregel är att antingen låta webbläsarens standardutseende gälla för all fokusmarkering eller anpassa den och göra den enhetlig och tydlig för alla interaktiva element. 

Formulärfält utan etikett 

När man ska använda ett webbformulär är det avgörande att man vet vad de olika fälten och kontrollerna berör och vad man förväntas fylla dem med. En visuell trend som gör det svårare för användaren är att designa bort etiketter, särskilt för textfält. 

Ofta ersätts det av text som visas i textfältet med hjälp av placeholder-attributet. Det finns flera problem med att göra så: 

placeholder-attributet är inte till för att användas på det sättet, utan för att ge ett kort tips om vad som ska fyllas i, till exempel vilket format man ska använda 

När man börjar skriva ersätts placeholder-texten och därmed informationen om vad fältet ska innehålla 

För att användaren inte ska tro att fältet redan är ifyllt måste placeholder-texten ha tillräckligt låg kontrast för att man ska förstå att det inte är ett riktigt värde. Det är svårt att samtidigt ha tillräcklig kontrast för att texten ska vara läsbar för alla. 

Skärmläsare hanterar placeholder olika. En del läser först upp label-elementet, om ett finns, och sedan placeholder. Andra läser inte upp placeholder alls. Används placeholder som det är tänkt är detta inget stort problem, men använder man det i stället för label kommer en del användare inte att få reda på vad de ska fylla fältet med. 

Den absolut enklaste och bästa lösningen är att låta etiketter i formulär vara synliga. Huvudargumentet för att dölja dem är att spara utrymme, men det lilla utrymme man (kanske) sparar kompenserar inte för den information man undanhåller från användaren. 

Extremt långa länktexter 

I en strävan efter att göra vissa klickytor större har det blivit populärt att låta länkar från puffar (komponenter som ofta består av bild, rubrik och ett stycke text) omge hela puffens innehåll. Det ger visserligen en större klickyta, men det är inte utan nackdelar: 

Om man använder skärmläsare är en praktisk funktion att man kan få fram en lista av de länkar som finns på en sida. Den listan blir inte särskilt användbar när många länkar är flera rader långa. 

Det blir väldigt krångligt att markera delar av texten i en puff. 

Förr eller senare kommer önskemål om att ha fler länkar i en puff. Då måste man stänga av ”helpuffslänken” för vissa puffar och får ett inkonsekvent gränssnitt. 

Fokuserad länktext är bättre för sökmotoroptimering än att länka hela meningar eller stycken. 

Länka i stället den text som bäst beskriver (på ett koncist sätt) länkens syfte. I en puff av den typ jag tänker på här är det nästan alltid rubriken. Låt det också synas att just den texten är länkad – du måste inte använda standardutseendet på understrykning utan har möjlighet att anpassa det. 

Gränssnittsutveckling 

Bilder och ikoner saknar textalternativ 

Varje grafiskt element som tillför information måste ha ett alternativtext eller visas i direkt anslutning till en text. Det blir ofta bortglömt när en ikon är det enda innehållet i en knapp eller länk. För den som ser och förstår ikonen är det inget problem, men om man använder skärmläsare stöter man då på knappar vars funktion blir uppläst som ”Bild, knapp”, eller kanske endast ”Knapp”. 

Exakt hur man lägger in alternativtext beror på hur man har lagt in bilden: 

För img-element är alt-attributet det självklara valet 

För svg-element använder man ett title-element 

För CSS-bakgrunder kan man använda ett visuellt dolt element med text i, eller aria-label på det element som bakgrundsbilden ligger på 

Kom ihåg att en ikon ska ha alternativtext bara om det inte redan finns en text i anslutning till den. 

Tangentbordsnavigering fungerar inte 

Gränssnitt byggda med HTML är i grunden tillgängliga för alla, oavsett vad man använder för att interagera med webben. Om man inte nöjer sig med de element som HTML erbjuder kan man skapa sina egna, men då tar man på sig ansvaret för att det man bygger är minst lika tillgängligt. Tyvärr blir det inte alltid så, och en grupp som ofta drabbas hårt är tangentbordsanvändare, dvs personer som inte kan använda mus eller andra pekdon utan måste klara sig med enbart tangentbord. 

Några vanliga problem man stöter på är: 

Dropdownmenyer/megamenyer som inte visas när man tabbar till menyn 

Hjälptexter som visas endast vid :hover 

Widgets som datumväljare, dialoger och karuseller som inte alls fungerar med tangentbord, eller fungerar rent tekniskt men är obegripliga 

Avsaknad av Progressive Enhancement 

Som jag har skrivit om tidigare i Agil utveckling och Progressive Enhancement går hand i hand (OBS ändra till rätt URL) lägger Progressive Enhancement grunden för en robust webblösning. Det är tyvärr vanligt att utvecklare – av olika anledningar – bortser från PE och bygger lösningar som är helt beroende av att allt fungerar perfekt. Minsta störning, som att ett scriptfel uppstår, användaren blockerar ett spårningsscript eller en bild inte laddas, kan leda till en obrukbar webbsida. 

En tumregel är att hela tiden fråga sig ”Vad händer om…” 

  • Webbläsaren saknar stöd 
  • Bilder inte laddas 
  • Ett scriptfel uppstår 
  • JavaScript är inaktivt 
  • Tredjepartskomponenter (statistik- och spårningsscript, typsnitt, CSS) inte laddas 

Felaktiga rubriknivåer 

För skärmläsaranvändare underlättar korrekt använda rubriker mycket, dels för att bilda sig en uppfattning av sidans innehåll, dels för att snabbt kunna hoppa till olika delar. Man kan nämligen få fram en lista med rubriker, inklusive deras nivåer. Om rubrikstrukturen då är felaktig för att utvecklaren (eller redaktören) har valt rubriktyp efter vilket utseende och inte efter nivå kan det bli väldigt förvirrande. 

Tänk dig en webbsidas rubrikstruktur som en boks innehållsförteckning. h1-rubriken motsvarar bokens titel, h2-rubriker motsvarar kapitlen och h3 och lägre är underrubriker det kapitel de tillhör. Låt alltid strukturen avgöra vilken rubriknivå du använder. 

Tänk enkelt och gör det enkelt, för dig själv och för användaren 

Flera av problemen jag har beskrivit här kan man undvika genom att sätta enkelhet före komplexitet och beprövad funktionalitet före kreativt nyskapande. Då faller det mesta naturligt på plats utan att man behöver ta till komplicerade tekniska lösningar. 

Nu kanske du tänker att det känns ”tråkigt” eller ”okreativt”, och kanske har du rätt i det. Men tänk i stället på att de webblösningar du bygger nästan utan undantag är till för slutanvändaren i första hand. Om designern och kunden dessutom tycker att det är snyggt och modernt är det en bonus, men det ska inte vara huvudsyftet. 

Om du kan underlätta för människor att använda det du skapar kanske det är värt det? 

Vill du veta mer om hur vi arbetar med tillgänglighet?

Välkommen att kontakta oss via formuläret så berättar vi gärna mer!

0 kommentarer

Skriv kommentar