Alt om WCAG

WCAG står for Web Content Accessibility Guidelines og er et internasjonalt rammeverk for hvordan man lager innhold som er tilgjengelig for alle – uavhengig av funksjonsevne, alder, situasjon eller teknologi. Dette er tekniske krav innen universell utforming.

Retningslinjene er utviklet av World Wide Web Consortium (W3C), og brukes globalt som standard for universell utforming av digitale løsninger. Med andre ord handler ikke WCAG bare om teknikk – det handler (faktisk først og fremst) om mennesker. Når en løsning følger WCAG, er den enklere å bruke for mange: folk som bruker skjermleser, som ikke kan bruke mus, som har fargeblindhet, dysleksi eller bare en ustø internettforbindelse.

Det er også god business. Tilgjengelige løsninger når flere brukere, gir færre barrierer og reduserer risikoen for brudd på lovkrav. WCAG gir deg språket og strukturen for å jobbe systematisk med tilgjengelighet – og sikre kvalitet i alle ledd.

Kort fortalt: hvis du har en digital løsning som skal brukes av folk, er sjansen stor for at du må forholde deg til WCAG.

Hvis bedriften din er i...

• Offentlig sektor: må du følge . Dette er pålagt gjennom og følges opp av .
• Privat sektor: bør du følge WCAG-kravene. Spesielt hvis du leverer digitale løsninger til offentlig sektor, tilbyr allmenne tjenester eller ønsker å være inkluderende og lovlydig.

WCAG bygger på fire prinsipper – kalt POUR:

• Perceivable
• Operable
• Understandable
• Robust

De danner grunnlaget for 13 retningslinjer og over 70 suksesskriterier.

WCAG er delt i tre nivåer:

• A – minimumskrav
• AA – nivået som vanligvis kreves i Norge
• AAA – ambisiøst, men ofte urealistisk å oppnå fullt ut

Her er noen typiske krav i WCAG 2.1 AA:

• Fargekontrast mellom tekst og bakgrunn
• Alternativ tekst for bilder og ikoner
• Navigasjon med tastatur – ikke alle bruker mus
• Meningsfull rekkefølge – både visuelt og i koden
• Beskrivende lenker og skjemaetiketter

Å "oppfylle WCAG" betyr ikke å være perfekt – men å møte relevante krav på riktig nivå. Det handler om kvalitet, ikke kvantitet.

Det korte svaret: så tidlig som mulig – og hos hele teamet.

WCAG bør ikke være noe du "sjekker av" mot slutten av prosjektet. Tvert imot: tilgjengelighet må tenkes inn i alt fra idé og design til utvikling og testing. Jo tidligere du involverer kompetanse på WCAG, desto enklere, rimeligere og bedre blir resultatet.

Her er hvordan de ulike rollene typisk bør bidra:

• Produktledere og prosjektledere
  Sikrer at tilgjengelighet er en del av kravene fra starten, og prioriterer det i utviklingsløpet.
• UX-designere og tjenestedesignere
  Tenker på universelle behov, brukerreiser og friksjonsfri navigasjon uten barrierer tidlig i prosessen.
• UI-designere
  Ansvarlige for farger, kontraster, komponentstruktur og interaksjoner som må oppfylle WCAG-krav.
• Utviklere (frontend og fullstack)
  Bygger løsninger som følger semantisk HTML, tilgjengelig kode og ARIA-best practices.
• Innholdsprodusenter og redaktører
  Skriver tydelig, bruker riktige lenketekster og fyller inn alternativtekster og skjemaetiketter riktig.
• QA og testere
  Tester med skjermleser, tastatur og automatiske verktøy – og fanger opp WCAG-avvik før lansering.

Bonus: Hvis du har en intern design- eller komponentbibliotekgruppe, bør WCAG-krav ligge som grunnlag i alle komponenter.

Når alle bidrar, slipper du at tilgjengelighet blir et ekstraarbeid på slutten – og du unngår å måtte redesigne løsningen i etterkant. Det gir bedre produkter for alle.

Basert på erfaringene våre med digitale prosjekter i ulike bransjer, ser vi ofte disse situasjonene der WCAG-kompetanse utgjør en stor forskjell:

• Redesign i offentlig sektor
  En virksomhet skal redesigne en nettside, og må følge WCAG 2.1 AA. Et konsulentteam bidrar med audit av eksisterende løsning, rådgivning i designfasen og støtte under utvikling – slik at universell utforming og tilgjengelighet blir en naturlig del av prosessen, ikke en ekstrakostnad i etterkant.
• Audit og opprydding i privat sektor
  Et selskap i finansbransjen får henvendelser fra brukere som sliter med tastaturnavigasjon og skjemaer. En konsulent gjennomfører en WCAG-gjennomgang, prioriterer tiltak og samarbeider med det interne teamet for å fikse det som har størst effekt.
• Komponentbibliotek og opplæring
  Et produktteam ønsker å sikre at designsystemet deres støtter tilgjengelighet. En konsulent med WCAG-kompetanse går gjennom eksisterende komponenter, anbefaler justeringer og holder enkle opplæringsøkter for designere og utviklere.

Disse scenarioene er representative for behovene vi ofte ser – og illustrerer hvordan riktig kompetanse kan gjøre komplekse krav konkrete og gjennomførbare.