<img height="1" width="1" src="https://www.facebook.com/tr?id=1272750026111903&amp;ev=PageView &amp;noscript=1">

Er din superavanserte webapplikasjon universelt utformet?

Øystein Rose

Øystein Rose | 03. oktober 2017

 Begreper brukt i denne artikkelen:

  • Single Page Application (forkortet SPA) er et navn som ofte brukes på moderne webapplikasjoner. Den største forskjellen på en tradisjonell nettside og en SPA, er at sistnevnte kommuniserer med serveren via AJAX-kall. På den måten slipper vi å laste hele nettsiden på nytt hver gang vi utfører handlinger på nettsiden. Målet med dette er å skape en brukeropplevelse på lik linje med en native desktop- eller mobilapplikasjon.

  • En skjermleser er et program som hjelper blinde og svaksynte med å få tak i informasjonen på en dataskjerm. Skjermleseren sin hovedoppgave er å tolke den visuelle informasjonen på skjermen slik at innholdet kan presenteres ved for eksempel syntetisk tale. En skjermleser brukes altså i kombinasjon med en nettleser.
    Hos Norges Blindeforbund kan du finne mer informasjon om skjermlesere og andre hjelpemidler.

  • Document Object Model (DOM) er en datamodell for HTML- eller XML-dokumenter. Dette er en trestruktur der hver enkelt node representerer en del av dokumentet. En nettleser som Internet Explorer eller Firefox tolker DOM-treet og presenterer innholdet for brukeren. Denne prosessen er tidkrevende og bruker mye ressurser. Derfor er det ønskelig med så få endringer i DOM-treet som mulig.

Tradisjonelle nettsider fungerer slik at når man klikker på en lenke så blir hele nettsiden lastet inn på nytt. Dette skjønner en skjermleser godt. Verre er det med Single Page Applications. Javascript-rammeverk som for eksempel AngularJS og React har gjort utviklingen av slike applikasjoner lettere. Disse rammeverkene holder endringene i DOM-treet til et minimum.

For at en skjermleser skal oppfatte endringene som skjer i en SPA, må man være påpasselig med å varsle om at noe har skjedd. Dersom man som webutvikler ikke er bevisst på dette, kan det være at brukeren ikke får med seg oppdateringene, og applikasjonen i seg selv vil være ganske ubrukelig.

I denne artikkelen skal jeg se nærmere på hvordan man kan løse denne utfordringen. Aller først skal vi se litt nærmere på universell utforming.

Generelt om universell utforming

Diskriminerings- og tilgjengelighetsloven (Lovdata.no) stiller krav om at fra og med 1. juli 2014 må alle nye nettsider rettet mot norske brukere være tilgjengelig for alle, og innen 1. januar 2021 vil kravene gjelde for alle nettsider, nye som gamle. Både private og offentlige virksomheter, lag og organisasjoner må følge regelverket. I 2017 ble det klart at også skoler og utdanningssektoren kommer inn under regelverket. Dersom man ikke etterkommer kravene, kan virksomheten risikere tvangsmulkt.

Kravene henviser til WCAG 2.0, som er retningslinjer for tilgjengelig webinnhold. Når disse retningslinjene følges, kan innholdet gjøres tilgjengelig for flere personer med nedsatt funksjonsevne, blant annet blinde og svaksynte, døve og hørselshemmede samt personer med lærevansker, kognitive funksjonsnedsettelser, nedsatt motorikk, talevansker, lysfølsomhet og kombinasjoner av disse. Selv om du ikke er pålagt å følge retningslinjene, så anbefaler vi likevel å gjøre det. Resultatet er ofte at nettsiden din blir mer brukervennlig generelt, og ikke minst unngår du å ekskludere brukere.

Nå foreligger det også et utkast til WCAG 2.1, datert august 2017. Dette utkastet er ventet å bli den nye standarden i løpet av 2018.

I tillegg til retningslinjene i WCAG 2.0, har også W3Cs Web Accessibility Initiative utarbeidet en spesifikasjon, Accessible Rich Internet Applications, bedre kjent som WAI-ARIA. Dette er en spesifikasjon som beskriver hvordan man, ved hjelp av attributter, kan berike HTML-koden slik at skjermlesere kan fungere bedre med avanserte webapplikasjoner.

ARIA-attributter

Attributtene er et predefinert sett som kan deles inn i to kategorier:

  1. Roles
  2. States and properties

1. Role-attributtene er av semantisk art, og kan hjelpe en skjermleser til å forstå hvordan en generisk tag er tenkt brukt. Et eksempel kan være når man skal bygge opp en meny. Dette gjør man ofte med en liste med lenker.
I eksemplet <li role="menuitem">...</li> ser man at role-attributtet forteller at elementet i listen er et menyelement.

2. States and properties-attributter brukes på elementer for å bygge opp brukergrensesnitt. Disse elementene kan være standard HTML-elementer som tekstfelter, nedtrekkslister eller avkrysningsbokser, i tillegg til mer avanserte komponenter som menyer og datovelgere. I eksempelet <input type="text" required aria-required="true" /> ser vi at tekstfeltet må fylles ut før skjemaet kan sendes inn.

Disse attributtene kan legges inn i HTML-en i responsen som kommer fra serveren, eller legges til/endres med Javascript i klienten.

Når bør man bruke ARIA-attributter?

Som en hovedregel skal ARIA-attributter brukes der hvor semantisk HTML i seg selv ikke er nok. Trenger du en knapp, så bruker du <button> og ikke <div role="button">.

Likevel kan det være lurt å bruke ARIA-attributter i tillegg for å hjelpe eldre nettlesere som kanskje ikke har god støtte for HTML5.

ARIA Live regions

For å løse problemet med DOM-endringer, kan man bruke “ARIA Live Regions”, og da spesielt aria-live-attributtet. Ved bruk av dette attributtet, vil skjermleseren lytte etter endringer og automatisk annonsere disse til sluttbrukeren. Monitoreringen gjøres i bakgrunnen, så selv om skjermleseren leser opp tekst andre plasser på siden, så vil fremdeles sluttbrukeren blir gjort oppmerksom på endringer i “live-regionen”.

Hvor “agressiv” skjermleseren skal være, angis av attributtverdien. Følgende verdier kan brukes:

  • Off — avslått. Ingen annonsering.
  • Assertive — skjermleseren avbryter det den holder på med, og gir beskjed øyeblikkelig. Bør kun brukes for feilmeldinger.
  • Polite — skjermleseren fullfører det den holder på med, og informerer deretter brukeren. Dette er den mest brukte verdien.

Eksempel på bruk av Aria Live

I eksemplet over har jeg også satt aria-atomic="true". Det betyr at dersom man i eksemplet endrer verdien inni <span class="amount"> så vil skjermleseren lese opp hele innholdet i live-regionen. Dersom attributtet er utelatt eller aria-atomic="false", så vil kun det nye beløpet leses opp.

I tillegg til aria-live, kan man også bruke aria-relevant. Dette attributtet sier noe om hvilke endringer innenfor regionen som brukeren skal bli gjort oppmerksom på. Standardverdien for dette attributtet er aria-relevant="additions text". Nedenfor ser du alle mulighetene du har:

  • “text” — Endringer i selve teksten bli lest opp.
  • “removals” — Dersom noder innenfor regionen blir fjernet, blir dette opplyst.
  • “additions” — Dersom noder innenfor regionen blir lagt til, blir dette annonsert.
  • “all” — en kombinasjon av alle de nevnte verdiene.

Roles

ARIA har også definert en ganske omfattende liste med roller som man kan sette på en node. Noen av disse setter implisitt aria-live="polite/assertive/off". Dette gjelder for rollene log, status, alert, progressbar, marquee og timer.

Dersom du har mulighet, så bør du bruke disse rollene. Legg gjerne på eksplisitt aria-live-verdi for økt kompatibilitet.

Støtte hos forskjellige nettlesere og skjermlesere

aria-live-attributtet er en effektiv løsning for å holde skjermlesere oppdatert på endringer på siden. Støtten for denne funksjonaliteten er relativt god, men det er som vanlig noen skjær i sjøen.

Det australske webdesign-byrået Max Design utførte en ganske grundig test av skjerm- og nettlesere i 2015. Resultatet viser at det er viktig å teste applikasjonen din før du slipper den ut i den store verden!

Har applikasjonen min blitt universelt utformet siden jeg har implementert “live regions”?

Dersom du ikke har hatt noe fokus på universell utforming tidligere, og kun har implementert “live regions” i applikasjonen din, så er svaret nei. Her må det kraftigere lut til.

Listen over krav som stilles i Diskriminerings- og tilgjengelighetsloven er ganske lang. For å lage et universelt utformet nettsted må du tenke på hvordan du bruker bilder, grafikk og video. I tillegg må navigasjonen være intuitiv. Den grafiske utformingen og presentasjonen må være tydelig og ha gode fargekontraster. Skjemaer på siden må være korrekt kodet slik at skjermleseren får en grei jobb med å lose sluttbrukeren trygt i havn. I tillegg må språket være enkelt å forstå.

Difi har laget en fin oversikt over alle kravene. Etter å ha sørget for å dekke disse, er det fremdeles ingen garanti for at nettsiden fungerer godt for alle. Test derfor applikasjonen din godt. Inviter gjerne personer som bruker skjermlesere i det daglige for å få et skikkelig godt inntrykk av hvordan nettopp din løsning fungerer. Lykke til!

 

Ønsker du å være med å utvikle fremtids-Norge? Se våre ledige stillinger

Del på sosiale medier: