A11y 101: Grunderna i universell utformning
De flesta har säkert någon gång hört talas om universell utformning och tänker kanske då på skärmläsare och blinda användare — antagligen för att det är svårast att relatera till hur någon utan syn använder webben. Men universell utformning handlar om mycket mer än så.
Jag går igenom grunderna i universell utformning — vad det är, vem det berör och hur man kan arbeta med det.
A11y – A-elvabokstäver-y – Accessibility
Men varför ska jag bry mig?
Att webben ska vara tillgänglig för alla krävs både av en FN-konvention och Norsk lag. Lagar och konventioner är något som vi gemensamt bestämt som en grundläggande baslinje för moral, medmänsklighet och civilisation.
Enligt Direktoratet for forvaltning og ikt (här efter Difi) så är det hela 17% av Norges arbetsföra befolkning och enligt WHO 15% av världens befolkning som har någon funktionsnedsättning. Alltså är det en stor del användare som direkt berörs.
I den fysiska världen är vi vana vid hjälpmedel så som övergångsställen med både ljud- och ljussignaler, automatiska dörrar, ramper, enhandsgrepp på vattenkranar, textning av ljud på TV, med mera — det är en självklarhet att alla ska ha den personliga friheten och rättigheten att nyttja samhällsrummet och därtill hörande tjänster. Dessa hjälpmedel är till stor nytta för alla — med eller utan funktionsnedsättningar. Men på webben är oftast universell utformning eftersatt, kanske för att webben är ett ungt medium, men för att det ska bli bättre krävs att alla får upp ögonen, tar det på allvar och inser att det även här är en rättighet att ha frihet.
WCAG 2.0 är en baslinje inte en mållinje
Alla nya eller uppdaterade tjänster på webben ska som minimum följa WCAG 2.0 A eller AA, och alla gamla tjänster ska vara uppdaterade senast 2021. Difi har redan börjat genomföra tester, och till och med utdelat böter till de som inte följer kraven. Men varför enbart nöja sig med att följa kraven när man kan erbjuda användarna en ännu bättre upplevelse? WCAG 2.0 är en baslinje inte en mållinje.
Snart kommer även ett EU-direktiv med regler om universell utformning som troligen kommer pålägga medlemsländerna att följa WCAG 2.1.
Alla har ansvar vid universell utformning
Jag hade en gång en produktägare som sa att det bara var för utvecklarna att lägga in universell utformning i koden. Inget kan vara så fel! Det handlar inte enbart om teknisk tillrättaläggning eller design. Alla i ett utvecklingsteam berörs och har ansvar för universell utformning — produktägare, projektledare, designers, utvecklare, testare, men kanske inte drift.
Typer av funktionsnedsättningar
Det finns flera olika typer av funktionsnedsättningar. De kan kategoriseras till syn, hörsel, motorik och kognition.
Syn
Man kan ha nedsatt syn, vara blind eller vara färgblind — något som upp mot 8% av alla män är. Men att ha eller inte ha färgseende är inte bara svart-vitt 🥁 utan kan vara i varierande grad, precis som alla andra typer av hinder. Men alla kan även råka ut för temporära funktionsnedsättningar i form av en dålig skärm, bländande solljus eller trasiga glasögon.
Hörsel
Man kan ha nedsatt hörsel eller vara döv. Eller trasiga högtalare eller buller.
Motorik
Man kan ha dålig öga-hand koordination eller vara lam. Eller ha tjocka fingrar, liten skärm, bruten arm, trasig mus, dålig touchpad eller sitta på en skakig buss.
Kognition
Man kan ha dyslexi, adhd eller autism. Eller stress, kontorslandskap, barn, sömnbrist eller vara påverkad av alkohol.
Anpassningar
Syn
För att hjälpa till vid problem med synen bör man ha stöd för skärmläsare, tydlig kontrast, skalerbar text, tillräckligt textavstånd och tillåta zoom.
Hörsel
För hörsel tillhandahålla textalternativ eller andra visuella signaler till ljud.
Motorik
För motorik stora klickytor och stöd för tangentbordsnavigation.
Kognition
För att undvika kognitiva problem bör man ha ett lättförståeligt språk, semantisk kod och god interaktionsdesign.
Ett första steg i rätt riktning
Det är mycket att tänka på när det gäller universell utformning. Men här är några konkreta saker, mestadels tekniskt, att starta med.
Validera och automatisera
Se till att din html är giltig och validerar med W3C-validator. Något som är påkrävt av Difi och WCAG 2.0.¹ Det är en grundförutsättning för att hjälpmedel ska kunna tolka din applikation korrekt.
Kontrollera din applikation med en WCAG-validator: Axe (tillägg till Chrome eller Firefox), Google Accessibility Developer Tools (tillägg till Chrome) eller WAVE för att upptäcka uppenbara fel.
För att undgå onödiga slarvfel bör du automatisera så mycket som möjligt. Det finns ESLint-tillägg för både JSX och Vue. Med Pa11y eller Axe kan du köra tester via kommandolinjen, oberoende av val av frontend-ramverk, eller tillsammans med end-to-end tester.
Less is more
Använd html där det är möjligt istället för WAI-ARIA — exemplevis hellre en <button> än role=”button”. Ingen grund att uppfinna hjulet på nytt. Större andel hjälpmedel kan tolka innebörden av ren html och har standardiserat stöd för funktionalitet. I vissa specialfall kan det dock finnas undantag.
Tangentbordsnavigation
Underlätta tangentbordsnavigering genom tydliga stilar för focus- och hover-tillstånd, genom att ha en naturlig följdordning på innehåll frånskilt visuell presentation, behålla fokus vid dynamiska uppdateringar.²
Semantik
Att skriva semantisk kod som ger innehållet berikad mening är till hjälp för användaren. Tänk på att ha korrekta titel-heirarkier, de ska vara skrivna precis som i ett vanligt textdokument.³ Många användare navigerar mellan titlar och titel-nivåer. Slå av css eller använd ett hjälpmedel som presenterar titel-listor för att kontrollera.
Textinnehåll
Se till att allt innehållet är skrivet med ett lättförståeligt språk — detta är till stor nytta för samtliga användare!⁴
Att länkar, knappar, bilder och funktioner har beskrivande texter. Det är ganska vanligt förekommande med länkar av typen Les mer eller Klikk her, i en länk-lista som används för att navigera vidare genom applikationen ger dessa texter ingen mening och försvårar för användaren.⁵ Där texten inte ger mening för de utan syn kan man använda aria-label och för visuella element som inte ger någon mening till desamma kan man använda aria-hidden.
Att texter och textavstånd är tillräckligt så att de kan skalera och fortsatt vara läsliga.⁶
Att inte enbart färg används för att kommunicera och att kontrasten är tillräckligt god.⁷
Manuella tester
Skärmläsare är som webbläsare på tidigt 2000-tal
Skärmläsare är som webbläsare på tidigt 2000-tal — du kan inte bara följa webbstandarden och tro att det ska fungera. Samma skärmläsare kan dessutom fungera olika beroende på vilken webbläsare man använder. Därför bör du manuellt testa så många varianter som möjligt. Exempel på skärmläsare: VoiceOver (OS X / iOS), Narrator (Windows), NVDA (Windows), ChromeVox (tillägg till Chrome) och JAWS (Windows).
Vanliga fel
Att ha länkar utan href-attribut eller att använda andra typer av element som klickbara länkar med javascript gör att de inte kan nås med tangentbord och döljs från länk-listor. Detta hindrar användare från att använda dessa länkar.
Dubblerad information i exempelvis länkar och tillhörande ikoner gör att användare får samma information flera gånger och gör det svårare att förstå innehållet. Det är också hjälpsamt att lägga särskiljande information i början av texter eftersom användare med skärmläsare då enbart behöver lyssna på starten av texten.
Att dekorativa bilder och illustrationer inte är dolda för skärmläsare med aria-hidden=”true” och role=”presentation”.
Oigenomtänkt användande av aria-live kan dölja visst innehåll — eller i värsta fall dölja allt innehåll! Exemplevis genom aria-live=”assertive” på ett element som uppdateras hela tiden, såsom en klocka med sekunder.
För ivrigt användande av WAI-ARIA. Vad blir presenterat som label här:
<label id="label" for="id">Etikett</label>
<input id="id" type="text" aria-label="Etikett" aria-labelledby="label">Vet du inte svaret bör du avstå. Vid användandet av både <header> och role=”banner” kan det plötsligt framställas som två olika headers. Men hur kan mindre vara bättre? Fler och motsägande besked gör tolkningen av applikationen svårare för hjälpmedel. Se den tidigare regeln om att använda html istället för WAI-ARIA där det är möjligt.
Avslutning
När du utformar din webbapplikation universellt gör du inte enbart det för att uppfylla lagar och regler. Du gör det främst för att tillhandahålla en så problemfri upplevelse som möjligt och tillfredsställa behov hos riktiga människor. Människor som är kunder och konsumenter, som kan välja en konkurrent som erbjuder bättre service.
Universell utformning på webben har även den, precis som i det fysiska rummet, stor nytta för alla användare. Alla har glädje av lättförståelig text, tydliga kontraster, skalerbar text, stora klickytor, med mera. Det underlättar allas användande och blir snart något vi alla tar för givet.
Lycka till! 😄
Nästa artikel – A11y 2.1: Fortsättning i universell utformning
- ¹ 4.1.1 Parsing (A)
- ² 1.3.2 Meaningful sequence (A), 2.1.1 Keyboard (A), 2.1.2 No keyboard trap (A), 2.4.3 Focus order (A), 2.4.7 Focus visible (AA)
- ³ 1.3.1 Info & relationships (A), 2.4.6 Headings & labels (AA)
- ⁴ 3.1 Readable (A-AAA)
- ⁵ 1.1.1 Non-text content (A), 2.4.4 Link purpose (A)
- ⁶ 1.4.4 Resize text (AA), 1.4.12 Text spacing (AA)
- ⁷ 1.4.1 Use of colour (A), 1.4.3 Contrast (AA)
