A11y 2.1: Fortsättning i universell utformning

Kristoffer Nordström

Follow

Published in

SpareBank 1 Utvikling

5 min readDec 20, 2018

--

Innan du läser vidare bör du först läsa om grunderna i universell utformning.

Är inte meningen av denna bild tillgänglig för dig? Precis så kan webben upplevas när inte hänsyn till universell utformning tas — “Hello A11y”

I denna artikel får du en uppdatering i de senaste riktlinjerna i WCAG, en hjälpande hand i att komma igång med testande av universell utformning och några handfasta problemställningar med lösningsförslag.

Riktlinjer

Enhandsgrepp på vattenkranar är till hjälp för alla — medan du fyller din kopp kan du reglera både värme och flöde (fungerar dock inte när man håller i en mobilkamera med den andra handen).

Web Content Accessibility Guidelines (WCAG) 2.0 kom redan 2008 och sedan dess har det hunnit hända väldigt mycket i den tekniska utvecklingen. För att hålla riktlinjerna à jour kom därför en uppdatering tidigare i år till version 2.1.

Arbetet med en helt ny uppsättning riktlinjer, Accessibility Guidelines, är i full gång och som namnet antyder ska det inte längre enbart gälla webben. Dessa planeras vara klara till 2021.

WCAG 2.1

Innehåller 17 nya riktlinjer, varav 12 stycken är av nivå A eller AA:

Orientering, porträtt eller landskap, ska inte dölja viktigt innehåll eller funktionalitet.¹
Underlätta förståelsen för syftet med formulärfält, genom att ge dem semantisk mening.²
Undvik att ha scroll längs mer än en axel.³
Minimumkontrast även på annat än textinnehåll.⁴
Textavstånd som gör texten mer lättläst.⁵
Innehåll som visas vid hover eller focus ska vara möjligt att stäng utan att flytta hover/focus, fortsätta visas om hover/focus flyttas till det nya innehållet, fortsätta visas tills användaren själv väljer att dölja det.⁶
Använd inte accesskeys om de inte går att stänga av, byta om eller endast fungerar vid focus.⁷
Undvik funktionalitet kopplat till flerfinger- och mönsterrörelser.⁸
Inga event vid nedtryckning, annat än om de kan ångras eller avbrytas.⁹
Använd samma text på kontroller som det maskinläsbara namnet.¹⁰
Funktioner ska inte enbart kunna användas med rörelsesensorer.¹¹
Statusuppdateringar måste förmedlas, även utan att ges fokus.¹²

Bli tillgänglighetsexpert på 1–2–3

Skaffa verktyg
Testa med verktygen
💥 Slappa under en ⛱ med en 🍹 i ✋ medan 💰 rullar in*

Kom igång

Välj de verktyg som du är van vid eller trivs bäst med, själv använder jag mestadels axe för statisk analys och skärmläsarna VoiceOver (OS X / iOS) eller NVDA (Windows). Använd en guide och lathund för att komma igång. Lär dig alltid hur du stänger av skärmläsaren före du sätter på den! Skruva ner uppläsningshastigheten och bli inte avskräckt vid första försöket, när du märker hur svårt det är att använda.

Testa med verktygen:

Validera HTML (W3C)
Validera enligt WCAG (axe)
Kontrollera keyboard-navigation (allt är nåbart, följdordning, focus-stilar)
Kontrollera text (titel-hierariker, interaktiva element, bilder)
Kontrollera med skärmläsare

Statistik

För att bättre förstå sina användare, och på så sätt kunna utveckla bättre lösningar, behöver du samla statistik som visar hur de använder din applikation. Att samla statistik kring användande av hjälpmedel är något som kan anses kontroversiellt, men om statistiken är anonymiserad borde inte detta kunna vara ett problem. Det skiljer sig inte nämnvärt från att samla statistik kring webbläsare och operativsystem.

Att hitta sätt att samla denna statistik på är däremot mer komplicerat då hjälpmedlen allt som oftast ligger utanför webbläsaren och därmed inte kan fångas upp.

Tangentbordsnavigation

Det finns en teknik som gör att man med hjälp av skip links kan samla data kring tangentbordsnavigering. Vilket även i viss mån även går att härleda till användning av skärmläsare.

En helt vanlig skip link:

<style>
.ms-skip-link {
  left: -999em;
  position: absolute;
  &:focus {
    left: 0;
  }
}
</style><button 
  class="ffe-inline-button ffe-inline-button--tertiary ms-skip-link"
  ng-click="skipLinkClick()"
  ng-focus="skipLinkFocus()"
>
  <span class="ffe-inline-button__label">
    Gå til innhold
  </span>
</button><main tabindex="-1"></main>

Funktioner för att skicka data vid fokus och klick:

function skipLinkFocus(event) {
  ga('set', 'dimension11', 'keyboard-navigation');
  ga('send', 'event', 'skip-link', 'focus', event.target.textContent);
}function skipLinkClick(event) {
  ga('send', 'event', 'skip-link', 'click', event.target.textContent);
  document.querySelector('main').focus();
}

Om man här dessutom sätter en custom dimension så kan man sedan följa dessa användare och hur de använder webbapplikationen.

Problem och lösningar

WAI-ARIA

En stor del av de problem kring tillgänglighet som jag stöter på beror på felaktig användning av WAI-ARIA. Utvecklare är snabba med att få med sig webbstandarder och använder de gärna — i överflöd. Men det hjälper inte alltid att följa webbstandarden när skärmläsare stödjer dessa.

Skärmläsare är som webbläsare på tidigt 2000-tal

Om du inte kan testa det du gör bör du avstå från att använda det.

Följdordning

Ett typiskt fel vid öppnandet av modaler är att följdordningen på innehållet inte är korrekt. Ofta flyttas inte fokus till den öppnade modulen, men om det görs så ligger kanske knappen för att stänga densamma före det element som ges fokus vid öppnande. Användare som inte kan se detta får då problem med att komma tillbaka till sidans innehåll.

Knappen för att stänga söket ligger före det element som får fokus vid öppnande

Så flytta gärna fokus vid interaktion, det hjälper användaren att genomföra den planerade handlingen. Men se till att elementen ligger i rätt följdordning. Ska de grafiskt ligga före eller efter varandra kan detta lösas med css.

<label for="search" class="ffe-screenreader-only">Søk</label>
<input id="search" type="search" name="query" placeholder="Søk">
<input type="submit" value="Søk">
<button>
  Lukk
  <span class="ffe-screenreader-only"> søk</span>
</button>

En asterisk

Nyligen uppkom det en frågeställning om hur man kopplar samman två element med text så att skärmläsare förstår att de hänger samman?

<div class="bubble" aria-describedby="fine-print">
  Buy now! 100% discount *</div><form></form><div class="fine-print" id="fine-print">
  * fine print
</div>

Enligt webbstandarden ska aria-describedby fungera och göra så att det finstilta läses upp när texten får fokus. Men tester visar att detta i praktiken inte är så annat än på interaktiva element eller element med vissa typer av role.

En alternativ läsning kan vara att lägga den finstilta texten i samma element men dold för vanliga användare:

<div class="bubble">
  Buy now! 100% discount *
  <span class="ffe-screenreader-only">* fine print</span>
</div><form></form><div class="fine-print" aria-hidden="true">
  * fine print
</div>

“Sånne asterisker er irriterende for alle” -Kristofer Selbekk

Där satte Kristofer Selbekk 🔨 på spiken. Universell utformning handlar inte enbart om anpassning för skärmläsare. I detta fall handlar det heller inte enbart om universell utformning, utan att förenkla utformningen av erbjudandet och ta bort det krångliga villkoren är något som skulle vara samtliga användare till nytta.

Lycka till! 🤗

Nästa artikel — A11y DX: Developer Experience while abiding to accessibility

* Jag väntar fortfarande på att steg tre skall infrias. (Minns du den exakta meningen nottecknet markerade? Hoppade du direkt hit för att läsa fotnoten? Dessa frågor är direkt relaterade till annat innehåll i artikeln.)