Universell utforming og WCAG for nettsider

Mange behandler universell utforming (UU) som en sjekkliste de må gjennom for å unngå bøter. I praksis handler det om at folk får brukt løsningen. Det er et kvalitetskrav til hele nettsiden, og det gjelder langt flere enn de fleste tror.

Når en nettside er universelt utformet, er koden ryddig, designet logisk og språket klart. Da fungerer den bedre for alle: for den som er blind og bruker skjermleser, for den som har brukket armen og må navigere med tastatur, og for den som sitter på bussen med sola i skjermen og har glemt brillene. En universelt utformet nettside er som regel også bedre kodet, raskere og enklere å vedlikeholde.

Vi er utviklere og designere. Når vi reviderer en løsning, retter vi også feilene i koden, designet og innholdet, eller vi viser utviklerne dine nøyaktig hva som må endres.

Er universell utforming lovpålagt?

Ja. Gjennom likestillings- og diskrimineringsloven og forskrift om universell utforming av IKT-løsninger er det krav om at IKT-løsninger rettet mot allmennheten skal være universelt utformet. Kravet gjelder både offentlige og private virksomheter, og det gjelder nettsider, nettbutikker, apper og selvbetjeningsløsninger.

Mange har regnet dette som noe som mest gjelder offentlig sektor. Med EUs tilgjengelighetsdirektiv (EAA) blir kravene strengere for privat næringsliv også. Direktivet gjelder blant annet e-handel, banktjenester, transport, e-bøker og elektroniske kommunikasjonstjenester. Det har gjeldt i EU siden sommeren 2025, og Norge skal innføre det gjennom EØS-avtalen. Driver du nettbutikk, lønner det seg å være i forkant.

Tilsynet for universell utforming av ikt (Uu-tilsynet) fører kontroller og kan gi dagbøter til virksomheter som ikke retter avvikene. Hvordan reglene slår ut for offentlig og privat sektor, går vi gjennom på siden om tilgjengelighetserklæring.

WCAG og kravene i Norge

For å måle om en side er universelt utformet, bruker vi den internasjonale standarden WCAG (Web Content Accessibility Guidelines). Kravene er delt i tre nivåer: A, AA og AAA. Lovverket krever nivå AA, som dekker barrierene som rammer flest brukere.

I Norge er kravet i dag WCAG 2.1 nivå AA, og tilsynet kontrollerer 48 krav når det ser på en offentlig løsning. WCAG 2.2 er den nyeste versjonen og har 55 suksesskriterier på nivå A og AA. Den legger blant annet til krav om at fokus ikke skal skjules bak andre elementer, at knapper og lenker skal være store nok til å treffe, og at innlogging ikke skal kreve at brukeren husker eller løser noe. Egne løsninger bygger vi etter WCAG 2.2 AA, så de holder også når kravet skjerpes.

Det kan virke teknisk, men alt bygger på fire prinsipper:

1. Mulig å oppfatte: Brukeren må kunne få med seg innholdet. Det betyr god kontrast for svaksynte og tekstbeskrivelser på bilder, så blinde kan få dem lest opp.
2. Mulig å betjene: Alt må kunne gjøres med tastaturet. Virker ikke musen, eller har brukeren motoriske utfordringer, skal siden fortsatt fungere fullt ut.
3. Forståelig: Navigasjonen må være forutsigbar, feilmeldingene må gi mening og språket må være klart. En knapp skal se ut som en knapp.
4. Robust: Koden må være god nok til at den fungerer med ulike hjelpemidler, som skjermlesere, og i ulike nettlesere og på ulike enheter.

Hvorfor det lønner seg

Vi prioriterer universell utforming i alle prosjektene våre. Loven krever det, og det lønner seg forretningsmessig.

Du når hele markedet. I Norge har mellom 15 og 20 % av befolkningen en funksjonsnedsettelse, og vi blir stadig flere eldre. Fungerer ikke nettsiden for dem, kan du sende opptil hver femte kunde rett til konkurrenten.

Google leser siden omtrent som en skjermleser. Søkemotorer bryr seg om semantisk kode, logiske overskrifter og gode beskrivelser av innholdet. God universell utforming går derfor ofte hånd i hånd med god teknisk SEO.

Rampeeffekten. Da byene senket fortauskantene for rullestolbrukere, viste det seg at det også hjalp foreldre med barnevogn, folk med trillekoffert og syklister. Det samme gjelder på nett: god kontrast og tydelig språk hjelper svaksynte, og alle som leser på mobilen i sollys. Skjemaer med tydelige feilmeldinger gir færre avbrutte kjøp, uansett hvem kunden er.

Fallgruvene du bør unngå

Markedet er fullt av kjappe løsninger for universell utforming. Disse bør du styre unna:

• Tilgjengelighetsoverlegg: Du har kanskje sett et lite ikon som åpner en meny for å endre kontrast eller skriftstørrelse. Både fagfolk og brukere advarer mot dem. De retter ikke feilene i koden, og de kan gjøre siden vanskeligere å bruke for dem som allerede har egne hjelpemidler.
• Blind tro på automatiske tester: «Vi kjørte en skanning og fikk grønt lys.» Det betyr dessverre ikke at siden oppfyller kravene. Automatiske verktøy kan bare sjekke rundt 20–30 % av WCAG-kravene. De kan sjekke om et bilde har en tekstbeskrivelse, men ikke om beskrivelsen gir mening, og de merker ikke at fokus forsvinner når en dialog åpnes.
• At det bare er utviklerens ansvar: Universell utforming skjer i designet og innholdet like mye som i koden. Det kommer vi tilbake til nedenfor.

Hvem har ansvaret?

Juridisk er det virksomheten som eier nettsiden som har ansvaret. Leverandøren har likevel plikt til å levere løsninger som oppfyller gjeldende krav. Stiller du krav om WCAG i avtalen med leverandøren, blir det tydelig hvem som skal rette hva.

I praksis skjer universell utforming i tre ledd:

• Design: kontrast, skriftstørrelse, tydelige knapper og fokusmarkering.
• Utvikling: semantisk kode, tastaturstyring, fokus og riktige navn og roller for skjermlesere.
• Innhold: klart språk, alternativ tekst, gode lenketekster og teksting av video.

Leverer designeren lav kontrast, kan ikke utvikleren kode seg rundt det. Legger redaktøren inn bilder uten alternativ tekst, hjelper det lite at malen er riktig. Derfor må alle tre leddene med fra starten.

Slik gjennomfører vi en UU-revisjon

Først velger vi ut hva som skal testes. Vi trenger ikke teste hver eneste side, bare alle sidemalene og de viktigste brukerreisene: forsiden, en artikkel, søk, skjemaer, innlogging og hele kjøpsløpet i en nettbutikk.

Deretter tester vi i to runder:

• Automatiske verktøy tar de enkle feilene raskt, som manglende alternativ tekst, lav kontrast og tomme lenker.
• Manuell testing tar resten. Vi går gjennom løsningen med bare tastatur, med skjermleser som NVDA og VoiceOver, og med zoom opp til 400 %. I en nettbutikk går vi gjennom hele kjøpet uten å se på skjermen.

Hvert funn får en referanse til WCAG-kravet det bryter, en beskrivelse av hva brukeren opplever, og et forslag til hvordan det rettes. Vi rangerer funnene etter alvorlighetsgrad, så du ser hva som stopper brukerne helt, og hva som kan vente.

Slik retter vi feilene i koden

Vi jobber direkte i koden, uansett om du bruker React, Vue, WordPress, Optimizely eller Sanity, og retter feilene der de oppstår.

• Teknisk opprydding: Vi bytter ut meningsløs kode, såkalt div-suppe, med semantisk HTML og sørger for at fokusstyringen virker. Det er særlig viktig i enkeltsideapplikasjoner (SPA-er), der sideskift ofte forvirrer skjermlesere.
• Komponenter først: En feil i en knapp eller et skjemafelt finnes ofte på hundre sider. Retter vi komponenten, forsvinner feilen overalt på én gang.
• Lukking av avvik: Har du fått en rapport fra tilsynet eller en revisor, tar vi feilene som hindrer bruk først, og jobber oss systematisk gjennom listen.

Det er sjelden du må bygge alt på nytt. Typiske funn er manglende ARIA-etiketter, feil i skjemavalideringen og bilder uten alternativ tekst, og slike feil retter vi uten at designet blir ødelagt. Skal løsningen likevel bygges på nytt, bygger vi universell utforming inn fra første dag. Det er langt billigere enn å rette opp etterpå.

Kan egne utviklere rette feilene?

Ja. Har du egne utviklere eller en annen leverandør, skriver vi rapporten slik at de kan jobbe rett fra den. Hvert funn peker på hvor i løsningen feilen er, hvilket krav den bryter og hvordan den rettes.

Mange velger en mellomløsning: teamet ditt retter de enkle feilene, mens vi tar de vanskelige, som fokusstyring i dialoger, tilgjengelige menyer og komplekse skjemaer. Når rettingene er gjort, tester vi på nytt og bekrefter hva som er lukket.

Tilgjengelighetserklæring

En tilgjengelighetserklæring er et lovpålagt dokument som skal ligge synlig på nettsiden. Den skal fortelle ærlig hvor løsningen står:

• Hvor tilgjengelig er nettstedet?
• Hvilke kjente feil er ikke rettet ennå?
• Hvordan kan brukerne si fra hvis de står fast?

Alle offentlige virksomheter må ha dette i dag, og erklæringen fylles ut i Digdirs løsning uustatus.no. Med EU-direktivet vil kravet også treffe store deler av privat sektor. En erklæring som bare sier «vi jobber med saken», holder ikke, for arbeidet må dokumenteres. Vi hjelper deg gjennom hele prosessen, fra den tekniske vurderingen til ferdig utfylt erklæring.

Hva koster universell utforming?

Tilgjengelighetserklæringen er sluttresultatet av en grundig teknisk revisjon, ikke et skjema som fylles ut for seg. Arbeidet krever manuell testing og teknisk forståelse. For mindre nettsteder starter en full WCAG-revisjon med tilgjengelighetserklæring på 35 000 kr.

For større løsninger avhenger prisen mest av fire ting:

• Antall sidemaler: ti maler tar lengre tid enn tre, uansett hvor mange sider som bruker dem.
• Hvor sammensatt løsningen er: innlogging, skjemaer i flere steg og dynamisk innhold krever mer testing enn rene artikkelsider.
• Antall brukerreiser: hver reise testes fra start til slutt med tastatur og skjermleser.
• Hvor mye som er galt: det avgjør hva utbedringen koster, ikke revisjonen.

Utbedring av avvikene tar vi på timepris fra 1 500 kr, eller som fastpris når omfanget er tydelig etter revisjonen.

Slik holder du nivået etterpå

En nettside endrer seg hver uke. Nye sider, bilder og funksjoner kan gi nye feil, så universell utforming må inn i den daglige driften.

• Kurs og kompetanse: Vi lærer opp redaktørene, designerne og utviklerne dine, så du kan holde løsningen universelt utformet selv og ikke blir avhengig av konsulenter.
• Designsystem: Vi bygger universell utforming inn i designsystemet ditt. Da er knappene, fargene og skjemaene riktige før de i det hele tatt brukes på nettsiden.
• Fast kontroll: Automatiske tester fanger de enkle feilene ved hver endring, og en ny manuell gjennomgang etter større endringer holder erklæringen oppdatert.

Hvorfor velge PXL?

Vi skiller oss fra rene rådgivningsmiljøer ved at vi er utviklere og designere i bunn. Der andre leverer en PDF med problemer, leverer vi ferdig kode.

Vi forstår hvorfor feilen oppsto, og vi vet hvordan arkitekturen må endres for å fjerne den for godt. Feilene som stopper brukerne, tar vi først, og deretter jobber vi oss systematisk gjennom resten. Alle hos oss har over ti års erfaring, og egne løsninger bygger vi etter WCAG 2.2 AA. Nettstedet vårt har 100 i tilgjengelighet i Google Lighthouse. Les hvordan vi kom fra 90 til 100.