5 raske tips for bedre skjermleseropplevelse

Commodore hadde sine glansdager på 80-tallet, og den første skjermleseren så faktisk også dagens lys i 1986.

Universell utforming blir stadig viktigere. En av tingene vi må ta høyde for i arbeidet med universell utforming er å sørge for at løsningen også fungerer for de som bruker skjermlesere. Som den nysgjerrige personen jeg er, har jeg testet ulike nettsider med VoiceOver for å se hvordan brukeropplevelsen er. Mye er veldig bra, men det er også en god del som kan forbedres. Selv om WCAG-kravene er godkjente betyr ikke det nødvendigvis at brukeropplevelsen for skjermleserbrukere er noe bra. Her får du fem tips som ikke er krevende å implementere, og som kan gjøre opplevelsen mye bedre.

1: Bruk role="text" for å ha flyt i opplesningen

Når vi leser en setning på en nettside så forventes det at skjermleseren vil lese den opp på tilsvarende måte, men dette er ikke alltid tilfellet.

<div>
Du har <strong>5 uleste meldinger</strong> i din innboks.
</div

For en av de mest brukte skjermleserne, VoiceOver, vil tolke eksempelet over som tre elementer: “Du har”, “5 uleste meldinger” og “i din innboks”.

<div role="text">
Du har <strong>5 uleste meldinger</strong> i din innboks.
</div>

Legger vi til role="text"¹ blir dette tolket som én setning, slik som forventet.

NB: Om du bruker et JS-rammeverk, f.eks React, så kan en tekst bli delt opp i flere tekstnoder uten at du bruker flere elementer. I eksempelet nedenfor vil VoiceOver lese dette som “Du har”, “5”, “uleste meldinger i din innboks”.

render() {
  const count = 5;
  return <div>Du har {count} uleste meldinger i din innboks</div>
}

2: Ikke bruk role="text" for mye

<div role="text">
For å vite hva som skjedde, trykk <a href="#">her</a>.
</div>

Basert på tipset over så kan det være fristende å bruke role="text" på alt, men det er ikke lurt. Dersom du f.eks har en lenke som en del av setningen vil ikke skjermleseren forstå at det er en lenke her.

3: Husk fokus når du åpner modaler / dialoger

Det er vanlig å bruke modaler eller dialoger for å enten gi nødvendig informasjon til brukeren, eller for å kreve et aktivt valg av brukeren. Veldig ofte implementerer vi det slik at modalen er i bunnen av body — noe som fører til at det blir veldig lang vei for en skjermleserbruker å navigere seg dit når du vil ha brukerens oppmerksomhet.

Dette løser du ved å sette fokus på et element i modalen når den åpnes. Slik settes brukeren raskt i riktig kontekst. Når modalen lukkes kan du enten sende brukeren tilbake til det elementet de hadde fokus på (om det er naturlig), eller fokusere på noe annet.

onModalOpen() {
  this.returnFocusElement = this.activeElement;
  this.headerElement.focus();
}
onModalClose() {
  this.returnFocusElement.focus();
  this.returnFocusElement = null;
}

4: Bruk aria-live for å kunne gi bekreftelse / feedback for en handling brukeren gjør.

Når du handler på nett får du gjerne en oversikt av varer i en type liste- eller grid-format. Hver vare har en “Kjøp”-knapp som legger varen i handlekurven. Hvordan skal en skjermleserbruker få bekreftelse på at de trykket på “Kjøp”?

Ved å bruke aria-live-attributtet på et element vil skjermleseren lese opp innholdet av elementet når en endring skjer. Bruker duassertive vil teksten bli lest opp øyeblikkelig, men bruker dupolite leses det opp når skjermleseren har mulighet til det. I eksempelet over er det nok best å bruke polite.

Da er det bare å programmatisk sørge for at elementet med aria-live får en tekst som bekrefter når brukeren har trykket på "Kjøp".

<div aria-live="polite">Varen er lagt til i handlekurven</div>

5: Sett elementet med aria-live i bunnen av body

I utgangspunktet kan en skjermleserbruker navigere seg til elementet som har aria-live-attributtet. Dette er ikke helt heldig fordi beskjeden du ønsker å formidle kan komme ut av kontekst (feil tidspunkt / feil sted). En løsning kan være å fjerne innholdet i elementet etter at det har blitt lest opp, men problemet er at man ikke nødvendigvis vet helt når det er. Teksten kan være av ulike lengder, bli lest opp i ulike hastigheter og om det ikke er satt som assertive kan det komme med en viss delay (altså annen tekst blir lest opp først). Derfor er det nok tryggere å “gjemme” det bort i bunnen av body, men husk at det er nok lurt å fjerne teksten etter hvert.

Det var fem tips som forhåpentligvis ikke er for vanskelig å implementere og som kan bidra til at skjermleserbrukerene dine får en bedre opplevelse.

Until next time!

PS: Nysgjerrig på en karriere i Systek? Se våre ledige stillinger her

— —

Jeg ville holde det kort, men det er noen ting som bør nevnes.

¹ role="text var noe som var foreslått for over ti år siden, men har (foreløpig) ikke blitt akseptert inn i ARIA 1.1-spesifikasjonen. Skjermlesere som VoiceOver støtter dette attributtet og jeg ser ingen annen god måte å løse opplesningsproblemet akkurat nå. Om du vet om en bedre løsning gi meg en "heads up"!