Universell utforming av IKT-løsninger – WCAG-krav og tilgjengelighetserklæring
⚖ Rettslig grunnlag: Diskriminerings- og tilgjengelighetsloven § 17 og Forskrift om universell utforming av IKT-løsninger pålegger virksomheter å sikre at IKT-løsninger rettet mot allmennheten er universelt utformet. Brudd kan medføre pålegg fra Likestillings- og diskrimineringsombudet.
De fire WCAG-prinsippene (POUR)
WCAG 2.1 (Web Content Accessibility Guidelines) er den internasjonale standarden for tilgjengelig webinnhold. Standarden er bygget rundt fire grunnprinsipper:
P – Mulig å oppfatte
Informasjon og brukergrensesnitt må presenteres på måter brukerne kan oppfatte – uansett sans eller hjelpemiddel.
O – Mulig å betjene
Brukergrensesnittkomponenter og navigasjon må fungere uavhengig av inndataenhet.
U – Forståelig
Informasjon og betjening av grensesnittet må være forståelig for alle brukere.
R – Robust
Innholdet må tolkes pålitelig av et bredt spekter av brukeragenter, inkludert skjermlesere.
1. Mulig å oppfatte (Perceivable)
Informasjonen og brukergrensesnittkomponenter må presenteres for brukerne på måter de kan oppfatte.
| Formelt krav | Konkret utfordring | God løsning |
|---|---|---|
| Tekstalternativer for ikke-tekstlig innhold (1.1.1) | Bilder, grafikk og knapper uten tekst | Alt-tekster: Alle meningsbærende bilder og grafiske elementer må ha en beskrivende alt-tekst. Dekorative elementer skal ha tom alt-tekst (alt=»») slik at skjermlesere ignorerer dem. |
| Alternativer for tidsbaserte medier (1.2.1, 1.2.2, 1.2.5) | Video og lyd uten teksting eller synstolking | Teksting og transkripsjon: Tilby synkronisert teksting for forhåndsinnspilt video og transkripsjon for lydinnhold. Videoer med viktig visuell informasjon uten tale krever synstolking (AA). |
| Tilpasningsdyktig innhold (1.3.1–1.3.3) | Manglende struktur og meningsbærende presentasjon | Korrekt semantikk: Bruk korrekt HTML-struktur for overskrifter, lister, tabeller og skjemaer. Leserekkefølgen i koden må stemme med visuell rekkefølge. Ikke bruk farge alene for å formidle informasjon. |
| Kontrast og størrelse (1.4.3, 1.4.4, 1.4.11) | Lav kontrast og uleselig tekst | Kontrastforhold: All normal tekst må ha minimum 4,5:1 kontrastforhold mot bakgrunnen. Løsninger må tillate brukere å endre tekststørrelse opp til 200 % uten tap av innhold. |
2. Mulig å betjene (Operable)
Brukergrensesnittkomponenter og navigasjon må være betjenbare.
| Formelt krav | Konkret utfordring | God løsning |
|---|---|---|
| Tastaturbetjening (2.1.1) | Elementer som kun kan betjenes med mus | Full tastaturtilgjengelighet: All funksjonalitet må være tilgjengelig kun via tastatur (Tab, Enter, Space). |
| Tastaturfokus (2.4.7) | Manglende visuell fokusindikator | Tydelig fokusindikator: Det må alltid være en synlig indikator (ramme eller fargeendring) rundt elementet med tastaturfokus. |
| Tilstrekkelig tid (2.2.1) | Tidsbegrensede funksjoner | Justerbare tidsfrister: Unngå automatiske tidsbegrensninger. Gi brukeren mulighet til å forlenge, slå av eller justere fristen. |
| Navigasjon og orientering (2.4.1, 2.4.4, 2.4.6) | Forvirrende navigasjon og uklare lenker | Hopp til innhold: Inkluder en «Hopp til hovedinnhold»-lenke. Lenketekster må være beskrivende og forklare målet. |
3. Forståelig (Understandable)
Informasjonen og betjeningen av brukergrensesnittet må være forståelig.
| Formelt krav | Konkret utfordring | God løsning |
|---|---|---|
| Leselighet (3.1.1, 3.1.2) | Manglende språkinformasjon i koden | Angi språk: Definer hovedspråket i koden (lang=»nb»). For tekstpassasjer på annet språk, angi dette spesifikt. |
| Forutsigbarhet (3.2.1, 3.2.2) | Uventede endringer ved fokus eller input | Ingen plutselige endringer: Sørg for at det ikke skjer vesentlige endringer automatisk når et element får fokus. Bruk konsistent navigasjon på tvers av sider. |
| Hjelp til input (3.3.1, 3.3.3) | Vanskelige skjemaer og manglende feilmeldinger | Tydelige feilmeldinger: Identifiser inntastingsfeil tydelig i tekstformat. Foreslå korrektur der feilen er kjent. |
4. Robust (Robust)
Innholdet må være robust nok til at det kan tolkes pålitelig av et bredt spekter av brukeragenter, inkludert kompenserende teknologi som skjermlesere.
| Formelt krav | Konkret utfordring | God løsning |
|---|---|---|
| Kompatibilitet (4.1.1, 4.1.2) | Feil i koden og ukjent innhold for hjelpemidler | Korrekt og gyldig kode: Bruk ren, gyldig HTML og CSS. Bruk WAI-ARIA der standard HTML ikke strekker til, slik at hjelpemidler tolker komponenter riktig. |
God praksis i UU-arbeidet
De beste løsningene handler ikke bare om teknisk implementering, men om prosessen:
- Integrer UU tidlig: Inkluder universell utforming i designfasen – design-by-default.
- Kompetanse: Sørg for at redaktører og innholdsprodusenter har tilstrekkelig kunnskap om kravene.
- Testing: Kombiner automatiske verktøy (f.eks. WAVE, Axe) med manuell testing ved bruk av skjermleser.
- Tilgjengelighetserklæring: Dokumenter samsvar og beskriv hvordan brukere kan melde avvik.
- Kontinuerlig vedlikehold: Nye publiserte sider og oppdateringer av funksjonalitet må fortløpende testes mot kravene.
Tilgjengelighetserklæringen
Alle offentlige virksomheter er pålagt å utstede en tilgjengelighetserklæring. Tilsvarende gjelder for en rekke private virksomheter som leverer tjenester nødvendige for offentlig sektor eller tjener et allment formål.
Erklæringen tjener tre formål:
- Lovpålagt plikt: Å sikre at personer med nedsatt funksjonsevne får lik tilgang til digitale tjenester.
- Informasjonsverktøy: En redegjørelse for etterlevelse og handlingsplan for mangler som brukere kan lese.
- Styringssystemet: For å sikre kontinuerlig og systematisk arbeid må erklæringen forankres som en del av virksomhetens internkontrollsystem.
Trenger du hjelp med universell utforming eller tilgjengelighetserklæring?
Vi hjelper virksomheter med å kartlegge status, lage handlingsplan og forankre UU-arbeidet i styringssystemet.
Ta kontakt her