EUs Web Accessibility Directive er tatt inn i norsk lov, og det betyr at offentlige nettsider må ha en tilgjengelighetserklæring.
Tilgjengelighetserklæringen skal gi nettsidens brukere en oversikt over innhold på nettstedet som ikke er tilgjengelig og hvorfor. Den skal fortelle folk hvor de kan få tilgjengelige alternativer, og gi folk mulighet til å ta kontakt med organisasjonen for å melde inn uu-feil.
Skal teamet mitt lage en tilgjengelighetserklæring?
Oppskriften for hva dere skal gjøre er litt ulikt avhengig av type tjeneste og hvor den er publisert.
Nettsider og tjenester på nav.no
Tilsynet har bestemt at det bare skal utarbeides én tilgjengelighetserklæring per nettside, derfor skal dere ikke lage en egen formell tilgjengelighetserklæring selv.
Det dere skal gjøre er å teste løsningen deres, dokumentere testfunnene og sende resultatene til uu-teamet innen 16. desember 2022. UU-teamet skal deretter sammenstille resultatene til én erklæring for hele nav.no.
Oppskriften for hvordan du går frem finner du på følgende side:
Nettsider og tjenester utenfor nav.no
Dere må utarbeide egen tilgjengelighetserklæring og publisere denne på uustatus.no.
Dette gjelder også for intranett og ekstranett som er nye eller vesentlig oppdaterte etter 1.2.2023.
Eksempler på slike nettsider kan være:
- Arbeidsplassen (www.arbeidsplassen.no)
- Aksel (design.nav.no / aksel.nav.no)
- Etterlevelseskatalogen (etterlevelse.intern.nav.no)
- Hjelpemiddeldatabasen (www.hjelpemiddeldatabasen.no)
- Idebanken (www.idebanken.org)
- osv.
Veiledning for hvordan du går frem finner du på følgende side:
Saksbehandlingsløsninger, arbeidsverktøy og fagsystemer
Dere er unntatt kravet om å publisere en tilgjengelighetserklæring. Dere trenger heller ikke rapportere WCAG-status til uu-teamet.
Disse løsninger skal likevel være universelt utformet og oppfylle WCAG-kravene så langt som mulig.
Spørsmål og svar
Det er umulig å gi et generelt tidsoverslag siden løsningene vi lager i NAV varierer så mye i kompleksitet og omfang. Jo mer interaktivt løsningen din er, jo mer tid det tar å teste.
Nei. Du må sende inn en oppdatert rapport minst én gang hvert år og ved vesentlige endringer til løsningen din. Sørg for at du planlegger tid til å teste og fylle ut rapporten i forbindelse med større leveranser. Det er også lurt å legge rapporteringa inn i årshjulet ditt slik at du husker å sette av tid til det.
Det er lurt at én person på teamet har hovedansvar for det praktiske, f.eks. å velge ut sidene som skal testes og produsere og sende inn rapporten, men hele teamet kan og bør delta i selve testinga. Hvis alle deltar, går det raskere og alle lærer om prosessen. Det er lettere for designere å tolke designkravene, utviklere å tolke de tekniske kravene, osv.
Aller best er å sette opp et par workshops der alle på teamet tester samtidig og fyller ut rapporten i fellesskap. Da kan dere dra nytte av hverandres kunnskap, og dere får dannet en felles forståelse av hvordan dere ligger an.
Nei. Komponenter som i utgangspunktet møter WCAG-kravene kan integreres på måter som bryter med kravene. Designsystemkomponenter må alltid testes i kontekst.
Vi i Team Aksel gjør vårt beste for å kvalitetssikre det vi leverer, men det kan hende vi går glipp av noe. Finner du feil i en komponent under testing, si fra på #designsystem på Slack (NAV-internt, åpner i en ny fane).
16. desember-fristen gjelder rapportering, ikke fiksing. Hvis du finner en WCAG-feil, så betyr det at løsningen din ikke er i samsvar med lovkravene til universell utforming, og feilen skal utbedres.
Ta kontakt med uu-teamet hvis det er noe du lurer på. Vi har ikke kapasitet til å teste løsningen din for deg, men vi kan svare på spørsmål og peke deg i riktig retning.