Fra WCAG til publiseringsklar side: Lag en fast tilgjengelighetskontroll

Kategori: Universell utforming

WCAG kan være vanskelig å bruke direkte i en travel publiseringshverdag. Retningslinjene beskriver hva som skal være mulig, men sier ikke nødvendigvis hvordan markedsavdelingen, designeren og utvikleren bør samarbeide før en ny side publiseres.

En mer håndterbar tilnærming er å gjøre universell utforming til en fast godkjenningskontroll. Målet er ikke å gjennomføre en full revisjon av hele nettstedet hver gang. Målet er å fange vanlige barrierer mens de fortsatt er enkle å rette.

Kontrollen bør følge den faktiske brukeroppgaven på siden. Kan en besøkende forstå innholdet, navigere uten mus, bruke skjermleser og fullføre et skjema uten å bli stående fast? Da blir WCAG et praktisk arbeidsverktøy, ikke bare en kravliste.

Start med brukeroppgaven, ikke sjekklisten

Velg først hva brukeren skal kunne gjøre. På en kontaktside kan oppgaven være å finne riktig avdeling og sende en forespørsel. På en produktside kan den være å forstå tilbudet, velge en variant og legge produktet i handlekurven.

Beskriv oppgaven i én setning og test hele forløpet. Enkeltkomponenter kan fungere isolert, samtidig som den samlede reisen er vanskelig. Et skjema kan for eksempel ha riktige feltnavn, men ligge etter en ulogisk rekke av menyer, faner og bokser når siden brukes med tastatur.

Avklar også hvem som har ansvar for hva:

• Redaktøren kontrollerer overskrifter, lenketekster, alternativ tekst og forståelige instruksjoner.
• Designeren kontrollerer kontrast, visuelle tilstander, rekkefølge og plassering.
• Utvikleren kontrollerer semantikk, tastaturfunksjon, fokusstyring og tekniske tilbakemeldinger.
• Produkteieren avgjør om alvorlige feil skal stoppe publisering.

En slik fordeling hindrer at universell utforming blir et uklart ansvar som alle antar at noen andre ivaretar.

Kontroll 1: Er innholdet forståelig og riktig strukturert?

Begynn uten spesialverktøy. Les siden fra toppen og vurder om overskrifter, avsnitt og handlingsknapper gir mening. Overskriftene skal beskrive innholdet under dem, ikke bare fungere som store dekorative tekster.

En tydelig overskriftsstruktur gjør siden enklere å skanne visuelt og enklere å navigere med hjelpemidler. Ikke velg overskriftsnivå etter ønsket skriftstørrelse. Utseendet skal styres av designet, mens nivået skal gjenspeile innholdets hierarki.

Kontroller samtidig følgende:

• Lenketekster forteller hvor lenken fører, også uten avsnittet rundt.
• Knapper beskriver handlingen, for eksempel «Send forespørsel» fremfor «Klikk her».
• Instruksjoner er ikke avhengige av bare farge, plassering eller form.
• Bilder som formidler informasjon, har en alternativ tekst med samme formål.
• Dekorative bilder blir ikke unødvendig lest opp.

Alternativ tekst bør beskrive bildets funksjon i sammenhengen. Et portrett ved siden av kontaktinformasjon kan identifisere personen. Det samme portrettet som ren dekorasjon trenger ikke en detaljert beskrivelse av klær, bakgrunn og lyssetting.

Kontroll 2: Kan siden brukes med bare tastaturet?

Legg bort musen og bruk tabulatortasten, skift og tabulatortasten, piltaster, mellomrom og Enter. Gå gjennom hele oppgaven fra start til slutt.

Følg spesielt med på hvor tastaturfokuset befinner seg. En synlig fokusmarkering er nødvendig for å vite hvilket element som aktiveres. Markeringen må være tydelig mot bakgrunnen og ikke forsvinne fordi en designregel har fjernet standardstilen.

Kontroller at:

• Alle lenker, knapper og skjemafelt kan nås.
• Rekkefølgen følger en forståelig vei gjennom siden.
• Ingen komponent fanger tastaturet slik at brukeren ikke kommer videre.
• Nedtrekksmenyer, dialogbokser og trekkspill kan åpnes og lukkes.
• Fokus flyttes fornuftig når innhold åpnes, lukkes eller oppdateres.
• Skjult innhold ikke mottar fokus.

Ikke godkjenn en komponent bare fordi tabulatortasten kommer frem til den. Brukeren må også kunne forstå hva komponenten gjør, aktivere den og komme seg videre etterpå.

Kontroll 3: Tåler designet reelle kontrastbehov?

Lav kontrast oppstår ofte i dempet brødtekst, plassholdertekst, sekundære knapper og tekst som ligger oppå bilder. Problemet blir gjerne større på mobil, i sollys eller på skjermer med andre innstillinger enn designeren brukte.

Som praktisk utgangspunkt krever vanlig tekst et kontrastforhold på minst 4,5 til 1, mens stor tekst kan ha minst 3 til 1. Men kontrollen må omfatte mer enn tekst. Kan brukeren se grensene rundt skjemafelt, valgt tilstand, feilmeldinger, ikoner og fokusmarkeringer?

Farge skal heller ikke være den eneste informasjonsbæreren. Et ugyldig felt bør få en forklarende feilmelding, ikke bare en rød kant. En graf bør bruke etiketter eller mønstre i tillegg til fargeforskjeller.

Bygg godkjente fargekombinasjoner inn i designsystemet eller malverket. Da slipper redaktøren å gjøre en ny kontrastvurdering for hver knapp og informasjonsboks. Begrens samtidig muligheten til å velge tilfeldige tekst- og bakgrunnsfarger i publiseringsverktøyet.

Kontroll 4: Gir siden mening med skjermleser?

En skjermlesertest avdekker problemer som ikke er synlige. Elementer kan se riktige ut, men bli presentert med feil rolle, manglende navn eller uforståelig rekkefølge.

Test den viktigste oppgaven med en skjermleser som passer operativsystemet dere bruker. Lytt etter om siden har en tydelig tittel, om overskriftslisten gir et forståelig sammendrag, og om knapper og lenker har meningsfulle navn.

Vær særlig oppmerksom på dynamiske endringer. Hvis et produkt legges i handlekurven eller et skjema avvises, må tilbakemeldingen være tilgjengelig uten at brukeren må lete gjennom hele siden på nytt. Visuell tekst alene er ikke alltid nok dersom fokus og teknisk varsling ikke håndteres.

Skjermlesertesten bør likevel ikke reduseres til at en seende tester lytter én gang. Ved viktige tjenester er erfaring fra brukere som faktisk benytter hjelpemidler, verdifullt. De oppdager ofte friksjon som en teknisk kontroll ikke viser.

Kontroll 5: Kan skjemaet fullføres og rettes?

Skjemaer er vanlige stoppunkter fordi flere krav møtes samtidig: språk, kontrast, tastatur, etiketter, validering og tilbakemeldinger. Test derfor både en vellykket innsending og en innsending med feil.

Hvert felt skal ha en synlig og teknisk tilknyttet etikett. Plassholdertekst er ikke en erstatning for etiketten. Den forsvinner når brukeren skriver, har ofte svak kontrast og kan gjøre det vanskelig å huske hva feltet gjaldt.

Når noe er feil, bør meldingen forklare både problemet og hvordan det kan rettes. «Ugyldig verdi» er lite nyttig. «Skriv telefonnummeret med åtte sifre» gir en konkret vei videre.

Kontroller også at:

• Obligatoriske felt er tydelig merket med mer enn bare farge.
• Felt bruker riktig type og støtter forventet inndata.
• Feilmeldingen ligger nær feltet og kan oppfattes av skjermleser.
• Brukeren ikke mister tidligere utfylte opplysninger etter en feil.
• Fokus flyttes eller ledes til feiloversikten på en forståelig måte.
• Sendeknappen ikke blir stående uten tydelig respons.

Test også zoom og liten skjerm. Et skjema som fungerer på en stor skjerm, kan bli vanskelig dersom etiketter, felt og feilmeldinger overlapper eller krever vannrett rulling.

Gjør funnene mulige å prioritere

En lang liste med avvik hjelper lite dersom ingen vet hva som må rettes først. Beskriv hvert funn med bruker, handling og konsekvens.

Et godt funn kan formuleres slik: «En tastaturbruker kan åpne menyen, men kommer ikke videre til undermenyens lenker. Det hindrer tilgang til produktsidene.» Da er både problemet og virkningen tydelig.

Del funnene inn i tre praktiske nivåer:

1. Stopper publisering: Brukeren kan ikke fullføre den sentrale oppgaven, forstå kritisk informasjon eller komme seg ut av en komponent.
2. Skal rettes raskt: Oppgaven kan fullføres, men krever unødvendig mye arbeid eller skaper stor usikkerhet.
3. Forbedring: Endringen gjør opplevelsen tydeligere og mer robust, men dagens løsning har en fungerende vei videre.

Alvorlighet bør vurderes ut fra konsekvens og hvor mange sider eller oppgaver feilen påvirker. En feil i en felles meny eller skjemakomponent er viktigere enn den samme typen feil på én lite brukt side, fordi komponentfeilen gjentas over hele nettstedet.

En publiseringskontroll som faktisk blir brukt

Hold kontrollen kort nok til at den gjennomføres, og tydelig nok til at den fanger reelle barrierer. En praktisk rutine kan bestå av fem trinn:

1. Beskriv sidens viktigste brukeroppgave.
2. Kontroller innhold, overskrifter, lenker og alternativ tekst.
3. Fullfør oppgaven med bare tastatur.
4. Kontroller kontrast, zoom, mobilvisning og skjemaets feiltilstander.
5. Test hovedforløpet med skjermleser og dokumenter eventuelle stoppunkter.

Lagre resultatet sammen med øvrig kvalitetssikring for siden. Noter hvilken mal, komponent eller innholdstype feilen gjelder. Da kan teamet rette årsaken i stedet for å reparere den samme feilen side for side.

Universell utforming blir mest effektiv når den er en del av definisjonen på ferdig. Den bør være med i designvalg, komponentutvikling, innholdsarbeid og godkjenning. En fast tilgjengelighetskontroll før publisering gir ikke automatisk et feilfritt nettsted, men den gjør barrierer synlige tidlig og plasserer ansvaret der feilene faktisk kan løses.