I utgangspunktet hadde vi mangelfull fokus på tilgjengelighet. Som webutviklere tenker man lett at så lenge man lager ryddig og velstrukturert HTML-kode, går resten av seg selv. Da bør hjelpemidler som skjermlesere og leselister klare resten av jobben. Men så enkelt er det ikke.

Siden Easyfact er et verktøy for nettbaserte spørreundersøkelser og mange av våre kunder legger ut spørreskjemaer som er offentlig tilgjengelige, var det klart at vi var innenfor omfanget til den nye tilgjengelighetsloven. Vi måtte derfor forholde oss til følgende spørsmål:

Hvordan sikre universell utforming av Easyfacts nettbaserte spørreundersøkelser?

Vi satte i gang med dette arbeidet og kom i havn høsten 2013, og spørreskjemaene oppfyller nå alle suksesskriterier i WCAG 2.0-standarden nivå AA. I etterkant av dette arbeidet vil vi nå gjerne dele noen av våre erfaringer.

Et eksempel

Ta følgende eksempel, som er en hyppig brukt spørsmålstype i mange nettbaserte spørreskjemaer. Dette kalles et matrisespørsmål siden avkrysningsboksene er organsiert som en matrise (rutenett). Tenk deg at man stiller dette spørsmålet kundene i et kollektivtransportselskap for å få vite hvor fornøyde de er med tilbudet.

Bildet viser et matrisespørsmål som er utformet som en tabell. Første kolonne inneholder delspørsmålene ”Buss”, ”Trikk”, ”Båt” og ”Tog”. Første rad inneholder alternativene ”Svært fornøyd”, ”Fornøyd”, ”Verken eller”, ”Misfornøyd” og ”Svært misfornøyd”.
 
 

Som seende får man raskt overblikk over spørsmålsstrukturen og kan lett se hvilket delspørsmål/alternativ hver enkelt avkrysningsboks tilhører. Dermed forstår man lett konteksten til hver enkelt avkrysningsboks og vet dermed hva det innebærer å sette kryss. Dersom man for eksempel er fornøyd med busstilbudet, setter man et kryss til høyre for ”Buss” og under ”Fornøyd”.

Ideelt sett bør en skjermleser kunne gi den samme kontekstuelle forståelsen av hver enkelt avkrysningsboks. Når brukeren navigerer gjennom spørsmålsstrukturen fra avkrysningsboks til avkrysningsboks, bør skjermleseren fortløpene opplyse om både spørsmålstekst, delspørsmålstekst og alternativtekst. Et eksempel: ”Hvor fornøyd er du med følgende transportmidler; Buss; Svært fornøyd”.

Det er imidlertid ikke selvsagt at en skjermleser klarer dette. Hvordan kan den vite hvilken kontekstuell informasjon som er viktig for forståelsen av hver enkelt avkrysningsboks? Skjermleseren trenger rett og slett hjelp til å forstå spørsmålets struktur.

Løsning

Man må rett og slett legge inn nye kodeelementer i HTML-koden som sikrer at skjermleseren forstår konteksten og kan formidle den videre på en god måte. Dette gjorde vi ved hjelp av aria-parametre i koden. Aria-parametre er en del av WAI-ARIA-standarden som er definert av W3C.

I eksempelet er det lagt inn nye kodeelementer som gjør at hver eneste avkrysningsboks refererer til både spørsmål, delspørsmål og alternativ.

Fremgangsmåte

Hvordan bør man så gå fram hvis man skal gjennomføre en slik tilgjengeliggjøring? Man starter med å følge suksesskriteriene i WCAG og ta i bruk mekanismene i WAI-ARIA-standarden. I utgangspunktet skulle man kanskje tro at det bare er å følge dette, og så er man i mål. Men så enkelt er det ikke, av tre årsaker:

  • Disse standardene er kun tekniske standarder, og er ingen garanti for en tilstrekkelig formidling av konteksten.
  • Standardene er ikke alltid entydige og veldefinerte.
  • Hjelpemidlene i seg selv inneholder feil (bugs) som gjør at de ikke følger standarden til punkt og prikke.

Dermed er det kun én fullverdig måte å verifisere tilgjengeligheten på: At reelle testpersoner med kompetanse på bruk av aktuelle hjelpemidler (skjermleser osv) setter seg ned og tester websiden i praksis. Bare på denne måten kan man sikre en reell tilgjengeliggjøring.

Andre tiltak

Eksempelet over illustrerer den største utfordringen for brukere av skjermlesere, og det var denne delen av tilgjengeliggjøringen vi brukte mest tid på å løse. Vi fokuserte imidlertid også på en del andre temaer. Blant disse var:

  • Sideoverskrifter og sidenavigasjon: Få overblikk over hvor man er i spørreundersøkelsen
  • Fargevalg: Gode kontraster for svaksynte.
  • Feilmeldinger: At det er lett å navigere fra en feilmelding til spørsmålet som feilmeldingen gjelder.

Vil du vite mer?

Bare ta kontakt med oss i Easyfact dersom du ønsker å vite mer om vårt arbeid for å tilgjengeliggjøre spørreskjemaer eller om Easyfact generelt. Vil du vite hvordan vi gjennomførte løsningen vår i praksis? Ta kontakt med oss, så kan vi sende over eksempelkode. Eller gå rett og slett til Easyfact.no, opprett en bruker (det er gratis), lag et eksempel-spørreskjema og se på HTML-koden vår på selve siden.

Takk til

Deltasenteret i Bufetat som støttet dette tiltaket og Media LT som bidro med verdifull faglig kompetanse.

Forfatter

Portrettbilde av Anders Kjønnøy
Anders Kjønnøy
Anders Kjønnøy er daglig leder i Easyfact.no

2 Kommentarer

Skriv ny kommentar

* obligatorisk felt som du må fylle ut for å sende skjemaet.

Kommentarer

Har med stor interesse lest innlegget. Det er et stort paradoks at 30% av den voksne norske befolkning fikk en langt dårligere WEB-hverdag etter at den nye loven kom (uu av IKT). Dette gjelder de lesesvake som er en uhomogen gruppe (dyslektikere, svaksynte, CP etc.). Plutselig trodde tilsynelatende alle at bare en holdt seg til WCAG 2.0 AA, så var alle problemer løst. WCAG 2.0 løser på ingen måte problememe for denne gruppen. Det er kun på få teksten lest opp med en god talesyntese som duger, gjerne med utheving (highlighting) av den tekst som leses opp.Tilgjengelighet for alle er nedfelt som en menneskerettighet av FN, tilgjengelige nettsider for alle er selvfølgelig en del av dette. WCAG 2.0 er ikke nok, men selvfølgelig et bra tiltak i seg selv.

Hei, takk for innspel. Tilsynet fekk 13. mai ei sak frå Likestillings- og diskrimineringsombodet (LDO), der LDO ber oss om ei IKT-fagleg uttale om universell utforming, knytt til ei klage dei har fått inn. Klagen en generell, og gjeld mogleg diskriminering av brukarar med lese- og skrivevanskar. Saka er no under behandling. Tilsynet gir ei skriftleg tilbakemelding om utfordringane som klagen peikar på, sett opp mot reglane for universell utforming av IKT og WCAG. Tilbakemeldinga er klar om seks veker og blir sendt til LDO.