Fra WCAG til komponentkrav: Gjør universell utforming testbart

Kategori: Universell utforming

Universell utforming blir ofte behandlet som en kontroll mot slutten av et webprosjekt. Da oppdager teamet gjerne feil i kontrast, tastaturnavigasjon, skjemaer og skjermleserstøtte etter at design, innhold og kode allerede er på plass. Feilene blir dyrere å rette, og de samme problemene kan dukke opp igjen neste gang noen lager en ny side.

En mer robust metode er å gjøre tilgjengelighet til en del av kravene for hver gjenbrukbare komponent. En meny, knapp, skjemafelt, dialogboks eller produktkort skal ikke bare se riktig ut. Komponenten skal også kunne brukes med tastatur, forstås av en skjermleser og fungere ved forstørring og ulike kontrastbehov.

Resultatet er en konkret definisjon av hva «ferdig» betyr. WCAG blir oversatt fra generelle retningslinjer til krav som designere, utviklere, redaktører og testere kan bruke i det daglige.

Start med komponentene som bærer brukerreisen

Det er sjelden nødvendig å spesifisere alt samtidig. Begynn med komponentene som brukes ofte, eller som brukeren er avhengig av for å gjennomføre en oppgave. På et vanlig bedriftsnettsted vil dette typisk være:

• Hovedmeny og mobilmeny
• Lenker og knapper
• Skjemafelt, avkrysningsbokser og feilmeldinger
• Søk og filtrering
• Dialogbokser og varsler
• Kort med bilde, overskrift og lenke
• Faner, trekkspill og annet innhold som åpnes og lukkes

Prioriter komponenter som finnes på mange sider. Én feil i hovedmenyen kan påvirke hele nettstedet, mens en feil i en sjelden brukt kampanjemodul har mindre rekkevidde. Dette betyr ikke at den siste feilen kan ignoreres, men det gir en fornuftig rekkefølge på arbeidet.

Oversett WCAG til observerbar atferd

WCAG gir et nødvendig rammeverk, men et utviklingsteam trenger krav som kan observeres og testes. «Komponenten skal følge WCAG» er for generelt som akseptansekriterium. Beskriv heller hva brukeren skal kunne gjøre, og hvilken informasjon hjelpemidler skal få.

For en mobilmeny kan akseptansekriteriene for eksempel være:

• Menyknappen kan nås og aktiveres med tastatur.
• Det er visuelt tydelig når menyknappen har fokus.
• Skjermleseren får informasjon om at knappen åpner en meny, og om menyen er åpen eller lukket.
• Fokus flyttes i en logisk rekkefølge når menyen er åpen.
• Menyen kan lukkes uten mus.
• Fokus returnerer til et fornuftig sted etter lukking.

Slike formuleringer gjør kravet forståelig for flere roller. De kan brukes i designgjennomgang, utvikling, manuell testing og senere regresjonstester.

Lag et tilgjengelighetskort for hver komponent

Et tilgjengelighetskort er en kort spesifikasjon som følger komponenten i designsystemet eller oppgaveverktøyet. Kortet bør være presist nok til å teste, men kort nok til at det faktisk blir brukt.

1. Formål og forventet bruk

Beskriv hva komponenten gjør, og når den skal brukes. En lenke fører brukeren til et annet sted. En knapp utfører en handling. Hvis disse elementene brukes om hverandre fordi de ser like ut, kan tastaturbruk og skjermleseropplevelse bli uforutsigbar.

2. Tastaturatferd

Angi hvilke elementer som skal motta fokus, hvilken rekkefølge de følger, og hvilke taster som styrer komponenten. Ikke gjør alle visuelle elementer fokuserbare. Bare interaktive elementer skal normalt inngå i tab-rekkefølgen.

Fokusmarkeringen må være synlig mot bakgrunnen og bør fungere i alle komponentens tilstander. Det holder ikke at den er tydelig på en hvit bakgrunn dersom den nesten forsvinner i en mørk meny eller over et bilde.

For komplekse komponenter bør kortet også beskrive hva som skjer når brukeren trykker Escape, piltaster eller Enter. Tastaturløsningen skal følge en kjent og konsistent modell, ikke en lokal oppfinnelse som brukeren må lære på nytt.

3. Semantikk og skjermleserstøtte

Skjermlesere er avhengige av struktur og programmatisk informasjon. Derfor bør komponentkortet angi hvilket navn, hvilken rolle og hvilken tilstand brukeren skal få formidlet.

Bruk ekte overskrifter, knapper, lenker, lister og skjemafelt der det finnes et passende HTML-element. Innebygd semantikk er som regel mer robust enn å bygge interaktive elementer av generelle beholdere. Ekstra tilgjengelighetsattributter skal supplere strukturen, ikke forsøke å reparere en grunnleggende feil elementtype.

Test også teksten som faktisk blir lest opp. En knapp med navnet «Les mer» kan være vanskelig å forstå når brukeren navigerer gjennom en liste med knapper uten resten av siden som visuell kontekst. «Les mer om bedriftsforsikring» gir et tydeligere mål.

4. Kontrast og visuelle tilstander

Fargekrav må defineres for mer enn vanlig brødtekst. Ved WCAG-nivå AA skal vanlig tekst som hovedregel ha et kontrastforhold på minst 4,5 til 1. Stor tekst kan ha minst 3 til 1. Grafiske deler som er nødvendige for å forstå eller bruke grensesnittet, som feltkanter og fokusmarkeringer, trenger også tilstrekkelig kontrast mot omgivelsene.

Kontroller alle tilstander: standard, peker over, fokus, aktiv, valgt, deaktivert og feil. En skjemafeil kan ikke kommuniseres bare ved at feltkanten blir rød. Legg til tekst og eventuelt et symbol, slik at informasjonen ikke er avhengig av fargesyn.

Designere bør spesifisere godkjente kombinasjoner av tekst- og bakgrunnsfarger. Da slipper redaktøren å gjette om en lys tekst kan legges over en bestemt profilfarge eller et bilde.

5. Skalering, tekstflyt og små skjermer

Komponenten må tåle at tekst forstørres og tar mer plass enn forventet. Knapper med fast høyde, kort med avkuttede overskrifter og menyer som forutsetter korte ord, kan bryte sammen når brukeren zoomer eller nettleseren øker tekststørrelsen.

Akseptansekriteriet bør være at viktig innhold og funksjonalitet fortsatt er tilgjengelig uten at tekst overlapper, klippes bort eller krever unødvendig vannrett rulling. Test med reelt norsk innhold, ikke bare korte plassholdertekster.

Behandle skjemaet som en samlet oppgave

Skjemafelt kan være teknisk korrekte hver for seg, mens hele skjemaet likevel er vanskelig å fullføre. Komponentkravene må derfor suppleres med en test av sammenhengen.

• Alle felt har synlige og programmatisk tilknyttede etiketter.
• Påkrevde felt er tydelig merket før innsending.
• Hjelpetekst forklarer format og forventninger før brukeren gjør feil.
• Feilmeldingen identifiserer feltet og forklarer hvordan feilen rettes.
• Fokus og feilsammendrag hjelper brukeren til riktig sted etter innsending.
• Informasjon som allerede er fylt ut, forsvinner ikke ved en valideringsfeil.
• Bekreftelsen etter innsending er tydelig, også for skjermlesere.

Unngå etiketter som bare ligger som plassholdertekst inne i feltet. Teksten kan forsvinne når brukeren begynner å skrive, og det blir vanskeligere å kontrollere hva feltet egentlig spør om.

Fordel ansvaret mellom rollene

Universell utforming svikter ofte i overleveringen mellom fagområder. Designeren har kontrollert kontrasten, men utvikleren mangler spesifikasjon for tastaturatferd. Utvikleren har laget god semantikk, men redaktøren publiserer utydelige lenketekster og hopper over overskriftsnivåer.

Fordel derfor ansvaret eksplisitt:

• Design: Kontrast, fokusutseende, tilstander, rekkefølge og oppførsel ved skalering.
• Utvikling: Semantisk struktur, tastaturstyring, fokusbehandling og informasjon til hjelpemidler.
• Innhold: Overskrifter, lenketekster, alternativ tekst, instrukser og forståelige feilmeldinger.
• Testing: Helhetlig bruk med tastatur, skjermleser, zoom og ulike skjermstørrelser.
• Produkteier: Prioritering, akseptansekriterier og beslutning om hva som stopper en publisering.

Ansvaret kan være fordelt, men kvaliteten må vurderes samlet. En komponent er ikke tilgjengelig dersom bare det visuelle eller bare koden er korrekt.

Bruk en fast testrekkefølge

Automatiske verktøy kan avdekke enkelte feil, men de kan ikke avgjøre om fokusrekkefølgen er logisk, om teksten er forståelig eller om en dialog er praktisk å bruke. Kombiner automatiske kontroller med korte manuelle tester.

1. Se på strukturen: Kontroller overskrifter, landemerker, knapper, lenker og etiketter.
2. Bruk bare tastatur: Gå gjennom komponenten i begge retninger, aktiver funksjoner og kontroller fokus.
3. Test med skjermleser: Lytt til navn, rolle, tilstand, instruksjoner og endringer etter handling.
4. Kontroller kontrast: Mål tekst, ikoner, feltkanter, feiltilstander og fokusmarkering.
5. Forstørr innholdet: Se etter klipping, overlapping, skjult funksjonalitet og vannrett rulling.
6. Test med reelt innhold: Bruk lange overskrifter, faktiske feilmeldinger og realistiske alternativer.

Noter testresultatet på komponentnivå. Da kan teamet skille mellom en lokal innholdsfeil og en systemfeil som påvirker alle sider der komponenten brukes.

Definer hva som stopper publisering

Ikke alle avvik har samme konsekvens. En manglende fokusmarkering i hovedmenyen kan blokkere navigasjonen for tastaturbrukere. En lite presis alternativ tekst på et dekorativt bilde har en annen alvorlighetsgrad.

Lag en enkel prioritering basert på tre spørsmål:

1. Hindrer feilen brukeren i å fullføre en viktig oppgave?
2. Finnes det en brukbar alternativ vei?
3. Hvor mange sider og brukerreiser er berørt?

Feil som blokkerer navigasjon, kjøp, innlogging, søknader eller kontakt bør normalt stoppe publisering. Mindre alvorlige avvik må fortsatt registreres med ansvar og frist. Ellers blir «midlertidig» fort permanent.

Gjør forbedringen varig

Den største gevinsten kommer når en rettelse bygges inn i den gjenbrukbare komponenten. Hvis fokusmarkeringen forbedres i designsystemets knapp, får alle sider som bruker knappen samme forbedring. Hvis teamet bare retter én side, vil feilen leve videre andre steder.

Et godt komponentbibliotek bør derfor vise godkjent utseende, forventet tastaturatferd, skjermleserinformasjon, innholdsregler og teststatus. Når dette inngår i definisjonen av ferdig, blir universell utforming en del av produksjonen fremfor en opprydding før lansering.

Begynn med fem kritiske komponenter og skriv testbare krav for hver av dem. Det er mer verdifullt enn en lang, generell sjekkliste ingen eier. Når metoden fungerer, kan den utvides til resten av nettstedet og brukes hver gang teamet designer, utvikler eller endrer en komponent.