📸: Analise Benevides / Unsplash
📸: Analise Benevides / UnsplashVis mer

A11y 101: Guide til universell utforming

«Alle har glede av forståelig tekst, tydelige kontraster, skalerbar tekst og store klikkoverflater!»

De fleste har sikkert hørt om universell utforming, og tenker kanskje da på skjermlesere og blinde brukere – trolig fordi det er vanskeligst å relatere til hvordan noen uten syn bruker webben.

Men universell utforming handler om mye mer enn det.

Jeg går her gjennom det grunnleggende i universell utforming – hva det er, hvem det påvirker og hvordan man kan jobbe med det.

Men hvorfor skal jeg bry meg?

At webben skal være tilgjengelig for alle kreves både av en FN-konvesjon og norsk lov. Lover og konvensjoner er noe som vi sammen har bestemt som en grunnleggende basis for moral, medmenneskelighet og sivilisasjon.

Ifølge Direktoratet for forvaltning og IKT (Difi) så er det hele 17 prosent av Norges arbeidsføre befolkning, og ifølge WHO 15 prosent av verdens befolkning, som har noen form for funksjonsnedsettelse. Altså er det en stor del av brukerne som berøres direkte.

I den fysiske verdenen er vi vant til hjelpemidler, som fotgjengerfelt med både lyd- og lyssignaler, automatiske dører, ramper, enhåndsgrep på vannkraner, teksting av lyd på TV og så videre. Det er en selvfølge at alle skal ha den personlige friheten og rettigheten å bruke sosiale rom og tilhørende tjenester.

Disse hjelpemidlene er til stor nytte for alle – med eller uten funksjonsnedsettelser. Men på webben er ofte universell utforming neglisjert, kanskje fordi webben er et ungt medium, men for at det skal bli bedre kreves det at at alle får opp øynene, tar det på alvor og innser at det også her er en rettighet å ha frihet.

«A11Y – A, elleve bokstaver, Y – Accessibility»

Alle nye eller oppdaterte tjenester på webben skal som minimum følge WCAG 2.0 A eller AA, og alle gamle tjenester skal oppdateres senest i 2021. Difi har allerede begynt å gjennomføre tester, og til og med delt ut bøter til dem som ikke følger kravene. Men hvorfor bare nøye seg med å følge kravene, når man kan tilby brukerne en enda bedre opplevelse? WCAG 2.0 er en basislinje, ikke en mållinje.

Snart kommer også et EU-direktiv med regler om universell utforming, som trolig kommer til å pålegge medlemslandene å følge WCAG 2.1.

Alle har ansvar

Jeg hadde en gang en produkteier som sa at det bare var for utviklerne å legge inn universell utforming i koden. Ingenting kan være så feil!

Det handler ikke bare om teknisk tilrettelegging eller design. Alle i et utviklings-team berøres og har ansvar for universell utforming – produkteiere, prosjektledere, designere, utviklere, testere, men kanskje ikke drift.

At lyd komplementerer visuelle signaler ved fotgjengerfelt hjelper alle. I stedet for å se etter lyset når man venter kan man se på mobilen, og du kan se etter lyset om du hører på musikk. 📸: Sparebank 1
At lyd komplementerer visuelle signaler ved fotgjengerfelt hjelper alle. I stedet for å se etter lyset når man venter kan man se på mobilen, og du kan se etter lyset om du hører på musikk. 📸: Sparebank 1 Vis mer

Syn, hørsel, motorikk, kognisjon

Det finnes flere ulike typer funksjonsnedsettelser. De kan kategoriseres til syn, hørsel, motorikk og kognisjon.

  • Syn: Man kan ha nedsatt syn, være blink eller være fargeblind – noe oppmot åtte prosent av alle menn er. Men å ha eller ikke ha fargesyn er ikke bare svart/hvitt. 🥁 Det kan ha varierende grad, akkurat som alle andre typer hinder. Og alle kan oppleve midlertidige funksjonsnedsettelser i form av dårlig skjerm, blendende sollys eller dårlige briller.
  • Hørsel: Man kan ha nedsatt hørsel eller være døv. Eller ha dårlige høyttalere eller støy.
  • Motorikk: Man kan ha dårlig øye-hånd-koordinasjon eller være lam. Eller ha tykke fingre, liten skjerm, brukket arm, dårlig mus, dårlig touchpad eller sitte på en humpete buss.
  • Kognisjon: Man kan ha dysleksi, ADHD eller autisme. Eller stress, kontorlandskap, barn, søvnmangel eller være påvirket av alkohol.

Tilpasninger

  • Syn: For å hjelpe til med synsproblemer, bør man ha støtte for skjermleser, tydelig kontrast, skalerbar tekst, nok tekstavstand og tillate zoom.
  • Hørsel: For hørsel bør man tilby tekstalternativer eller andre visuelle signaler for lyd.
  • Motorikk: Store klikk-overflater og støtte for tastaturnavigasjon.
  • Kognisjon: For å unngå kognitive problemer bør man ha et forståelig språk, semantisk kode og god interaksjonsdesign.

Det er mye å tenke på når det gjelder universell utforming. Men her er noen konkrete saker, mest teknisk, å starte med.

Validere og automatisere

Pass på at HTML-en din er gyldig og validerer med W3C-validator. Noe som er påkrevd av Difi og WCAG 2.0. Det er en forutsetning for at hjelpemidler skal kunne tolke applikasjonen din korrekt.

Kontroller applikasjonen din med en WCAG-validator; Axe (tillegg til Chrome eller Firefox), Google Accessibility Developer Tools (tillegg til Chrome) eller WAVE for å oppdage åpenbare feil.

For å unngå unødvendige slurvefeil bør du automatisere så mye som mulig. Det finnes ESLint-tillegg for både JSX og Vue. Med Pa11y eller Axe kan du kjøre tester fra kommandolinjen, uavhengig av valg av frontend-rammeverk, eller sammen med end-to-end-tester.

Less is more

Bruk HTML der det er mulig i stedet for WAI-ARIA – for eksempel heller enn role="button". Ingen grunn til å finne opp hjulet på nytt. De fleste hjelpemidler kan tolke betydningen av ren HTML, og har standardisert støtte for funksjonalitet. I visse spesialtilfeller kan det dog finnes unntak.

Tastatur-navigasjon

Tilrettelegg for tastaturnavigasjon gjennom tydelige stiler for fokus- og hover-tilstander, naturlig sekvens i innholdet fraskilt den visuelle presentasjonen og behold fokus ved dynamiske oppdateringer.

Semantikk

Å skrive semantisk kode som gjør innholdet beriket mening, er til hjelp for brukeren. Tenk på å ha korrekte tittel-hiarkier, som skal være skrevet akkurat som i et vanlig tekstdokument. Mange brukere navigerer mellom titler og tittel-nivåer. Slå av CSS eller bruk et hjelpemiddel som presenterer tittel-lister for å kontrollere.

Tekstinnhold

Pass på at alt innhold er skrevet med et forståelig språk – dette er til stor hjelp for alle brukere!

  • At lenker, knapper, bilder og funksjoner har beskrivende tekster. Det er ganske vanlig med lenker av typen «les mer» eller «klikk her», men i en lenkeliste som brukes for å navigere videre gjennom applikasjonen gir ikke slike tekster mening, og gjør det vanskeligere for brukeren. Der teksten ikke gir mening for de uten syn, kan man bruke aria-label, og for visuelle elementer som ikke gir mening kan man bruke aria-hidden.
  • At tekster og tekstavstand er nok, så de kan skalere og fortsatt være lesbare.
  • At ikke bare farge brukes for å kommunisere, og at kontrasten er god nok.

Manuelle tester

Skjermlesere er som nettlesere på tidlig 2000-tallet; du kan ikke bare følge standarden og tro at det skal fungere. Samme skjermleser kan dessuten fungere på ulike måter ut fra hvilken nettleser man bruker. Derfor bør du manuelt teste så mange varianter som mulig.

For eksempel: VoiceOver (OS X / iOS), Narrator (Windows), NVDA (Windows), ChromeVox (tillegg til Chrome) og JAWS (Windows).

Vanlige feil

  • Å ha lenker uten href-attributter, eller bruke andre typer elementer som klikkbare lenker med Javascript, gjør at de ikke kan leses med tastatur, og skjules fra lenkelister. Dette hindrer brukerne fra å bruke lenkene.
  • Duplisert informasjon i for eksempel lenker og tilhørende ikoner gjør at brukerne får samme informasjon flere ganger, og gjør det vanskeligere å forstå innholdet. Det er også hjelpsomt å legge inn den unike informasjonen i begynnelsen av tekstene, så brukere med skjermlesere bare trenger å høre på starten av teksten.
  • At dekorative bilder og illustrasjoner ikke er skjult fra skjermlesere med aria-hidden=”true” og role=”presentation”.
  • Ugjennomtenkt bruk av aria-live kan skjulte innhold, i verste fall alt innhold! For eksempel ved aria-live="assertive" på et element som oppdateres hele tida, som en klokke med sekunder.
  • For ivrig bruk av WAI-ARIA. Hva presenteres for en <input> med en <label>, samt aria-label og aria-labelledby – alt eller ingenting? Ved bruk av både <header> og role="banner" kan det plutselig framstilles som to ulike headers. Hvordan mindre kan være bedre? Flere og motsigende beskjeder gjør tolkningen av applikasjonen vanskeligere for hjelpemidler. Se den tidligere regelen om å bruke HTML i stedet for WAI-ARIA der det er mulig.
«Alle har glede av forståelig tekst»

Avslutning

Når du utformer din web-applikasjon universelt gjør du det ikke bare for at du skal oppfylle lover og regler. Du gjør det først og fremst for å gi en så problemfri opplevelse som mulig, og tilfredsstille behov hos ekte mennesker. Mennesker som er kunder og konsumenter, som kan velge en konkurrent som tilbyr bedre service.

Universell utforming på webben har, akkurat som i den fysiske verdenen, stor nytte for alle brukere. Alle har glede av forståelig tekst, tydelige kontraster, skalerbar tekst og store klikkoverflater. Det forenkler alles bruk, og blir snart noe vi alle tar for gitt.

Lykke til! 😄

Lesetips: