Jobber du med digitale løsninger for en offentlig virksomhet? Da må du forberede deg på kravet om tilgjengelighetserklæring!

Allerede nå kan du begynne å forberede virksomheten internt på hva det vil si å forfatte, lansere og forvalte en tilgjengelighetserklæring. For dette kan ta litt tid!

Selv om løsningen din ikke er en del av en offentlig virksomhet, bør du uansett sørge for at løsningen møter alle krav til universell utforming. Det skilles på krav og anbefalinger.

En tilgjengelighetserklæring er et dokument hvor du forplikter deg til hvilket nivå av tilgjengelighet løsningen din skal bestrebe å nå. Du skal også informere brukerne dine om hva statusen på tilgjengeligheten av innholdet ditt er. Tilgjengelighetserklæringen skal også ha en tilbakemeldingsfunksjon (skjema, e-postadresse eller telefonnummer) som gir brukere en mulighet til å melde om feil eller mangler på tilgjengeligheten av løsningen.

For å kunne skrive en tilgjengelighetserklæring må du gjøre opp status på tilgjengelighet i løsningene (teste løsningene), forbedre feil/mangler, rapportere status på tilgjengeligheten i løsningen regelmessig, og deretter publisere tilgjengelighetserklæringen.

Kort oppsummert skal du:

1. Gjøre deg kjent med kravene til universell utforming
2. Teste nettstedet
3. Fylle ut resultatet ditt/statusen på uustatus.no (OBS: tjenesten er fortsatt ikke åpen for innlogging, men offentlige virksomheter vil få tilsendt påloggingsinformasjon i løpet av siste kvartal av 2022)
4. Publisere lenke til tilgjengelighetserklæring på nettstedet ditt

Hvordan gjør du opp en status? Test, test og test!

Om dere ikke har gjennomført en tilgjengelighetstest (kan også kalles «test av universell utforming») på nettstedet/tjenesten før, så er det på tide å gjøre dette nå. Min anbefaling er å begynne med å innføre rutiner på å kjøre uu-tester gjennom hele utviklingsløpet (manuelle tester før dere publiserer, automatiske tester på kode og test-servere). Gjennom dette blir hele teamet kjent med hva universell utforming er.

Designere må ha god kjennskap til f.eks. fargekontraster, avstander og størrelse på klikkeflater og endringer på input (for eksempel er element states noe som er typisk å glemme å designe for, states som  :active, :focus og :hover er viktige interaktive tilstander som du kan glemme i den statiske designfasen i Figma o.l.).

Utviklere må ha kjennskap til hva som skal til for å skrive riktig semantisk kode, og hvordan de retter opp vanlige feil og mangler i kode.

Testere må vite hva de skal teste på for å avdekke feil og mangler, og sist, men ikke minst må prosjektledere sette av tid og ressurser til å få dette gjennomført.

Testingen kan deles opp i to:

1. Automatiske tester:
   Bruk et verkøy eller en kombinasjon av verktøy for å finne feil som kan lukes ut automatisk. Bruk disse som et fundament for å utføre de manuelle testene.
   • Eksempler på gode verktøy:
     • https://ace.useit.se/
     • https://accessibilityinsights.io/
     • Axe devTools (innebygd i Chrome)
2. Manuelle tester:
   Den anbefalte rutinen for manuell testing er følgende:
   • Input: Tastatur – test med tastatur og test også med tastatur+skjermleser
   • Input: Touch – test på mobil, både med og uten skjermleser (talkback på android eller voiceover på iphone)
   • Visuell presentasjon
   • Alternativ tekst
   • Lyd og video
   • Semantikk og dokumentstruktur
   • Skjema
   • Dynamisk innhold
   • Custom widgets

I tillegg bør du ta høyde for tilbakemeldinger fra brukerne dine. Sørg derfor for at brukere av nettstedet har en måte å melde inn feil og mangler på!

Alt dette sammenlagt er statusen på tilgjengeligheten. Er det noen punkter som må legges i backloggen er det hensiktsmessig å liste det opp i tilgjengelighetserklæringen. Slik forplikter du deg til å fikse mangelen/feilen, samtidig som du informerer brukere som har oppdaget samme feil og er i ferd med å rapportere feilen inn til dere.

Hva skjer fremover?

Utfallet av å ikke ha tilgjengelighetserklæringen på plass etter februar 2023 kan føre til pålegg om retting og dagbøter. Uutilsynet skriver selv på sine nettsider at virksomheter uten tilgjengelighetserklæring har en vesentlig større sannsynlighet for å bli utvalgt til kontroller og tilsyn. 

Jeg forstår at dette kan høres veldig rigid og strengt ut, men jeg lover dere – alt av feil og mangler kommer ikke til å bli oppdaget i første omgang. Det er utrolig mange kombinasjoner av enheter, operativsystemer, nettlesere og brukerutstyr som blir veldig vanskelig å teste for. Derfor er tilbakemeldingsfunksjonen så viktig å ha på plass!

Hovedpoenget, og det viktigste å trekke ut av fra denne endringen, er etter min mening at du fremover alltid må ha en plass i budsjettet til universell utforming. På denne måten sørger du i tillegg for å ha kompetanse på det i virksomheten, noe som jo bare er positivt!