Hvordan finner dere ut om nettsiden faktisk er universelt utformet – og ikke bare utstyrt med en rapport der de fleste lampene lyser grønt? Start med én kritisk brukerreise og test den fra start til mål. Det kan være å finne et produkt, bestille en time, søke på en stilling eller sende en forespørsel.
Denne metoden gir mer nytte enn å begynne med en tilfeldig liste over WCAG-kriterier. Kriteriene er nødvendige, men brukeren opplever ikke nettsiden kriterium for kriterium. Hun opplever en sammenhengende oppgave der ett utilgjengelig felt, én fokusfelle eller én uforståelig feilmelding kan stoppe hele reisen.
Et tilgjengelighetsverktøy som legger en knapp oppå nettsiden, løser heller ikke grunnproblemene. Det blir omtrent som å montere ringeklokke på en trapp og erklære inngangen trinnfri. Test heller det som faktisk er bygget.
Velg reisen som betyr mest
Velg først en oppgave som både er viktig for brukeren og virksomheten. Reisen bør ha en tydelig start og slutt, for eksempel fra landingsside til bekreftet innsending. Ta med alle mellomsteg: navigasjon, søk, dialogbokser, innlogging, skjema og kvittering.
Beskriv reisen med konkrete handlinger, ikke med interne sidenavn. «Brukeren finner tjenesten, forstår vilkårene, fyller ut skjemaet og mottar bekreftelse» er mer nyttig enn «test tjenesteside 4B». Førstnevnte avslører sammenhengen. Sistnevnte høres mest ut som en mappe ingen tør å slette.
En slik gjennomgang er ikke det samme som en full WCAG-revisjon. Den gir derimot et godt bilde av de mest alvorlige hindrene i en viktig oppgave. Full samsvarsvurdering må dekke relevante sidetyper, komponenter, innhold og WCAG-krav. Hvilke lovkrav som gjelder, avhenger også av virksomheten og bør verifiseres mot gjeldende regelverk.
Avklar dette før testen
- Mål: Hva skal brukeren kunne fullføre?
- Startpunkt: Kommer brukeren fra forsiden, et søk eller en kampanje?
- Sluttpunkt: Hva viser at oppgaven er fullført?
- Varianter: Finnes det valideringsfeil, tomme søkeresultater eller alternative valg?
- Testmiljø: Bruk realistisk innhold og samme komponenter som skal publiseres.
Test i fem lag – i riktig rekkefølge
Begynn med automatiserte tester, men ikke stopp der. Slike verktøy er gode til å finne bestemte kodefeil, som manglende alternativ tekst, enkelte kontrastbrudd og ugyldige ARIA-attributter. De kan ikke avgjøre om en alternativ tekst er nyttig, om fokusrekkefølgen er logisk eller om instruksjonene faktisk gir mening.
Grønt resultat betyr derfor «ingen maskinelt påviste feil i det som ble kontrollert», ikke «alle kan bruke løsningen». En automatisk test er en røykvarsler, ikke et komplett brannvesen.
1. Struktur og innhold
Les siden uten å bruke designet som støtte. Har siden én tydelig hovedoverskrift? Følger underoverskriftene en forståelig struktur? Beskriver lenketekstene målet, eller består siden av en samling «les mer» som blir meningsløse uten visuell sammenheng?
Kontroller også at bilder har riktig tekstalternativ. Informative bilder trenger en kort beskrivelse av relevant innhold eller funksjon. Dekorative bilder bør ignoreres av hjelpemidler. Et bilde av et diagram trenger mer enn «diagram»; det er teknisk korrekt på omtrent samme måte som å beskrive et regnskap som «tall».
2. Tastatur og synlig fokus
Legg musen til side. Bruk Tab og Shift+Tab for å bevege deg, Enter og mellomrom for å aktivere elementer, piltaster der komponenttypen tilsier det, og Escape for å lukke dialoger eller menyer. Alle interaktive elementer må kunne nås og brukes, og fokusrekkefølgen må følge oppgaven på en logisk måte.
Fokusmarkeringen skal være tydelig mot både lyse og mørke flater. Den må ikke klippes bort eller skjules bak klebrige toppfelt. Å fjerne fokusmarkeringen fordi den «forstyrrer uttrykket», er en klassiker fra designskolen der brukeren helst ikke skal etterlate spor.
Test spesielt menyer, faner, karuseller, nedtrekksfelt og dialogbokser. En dialog skal flytte fokus inn når den åpnes, holde tastaturfokuset på relevante elementer mens den er aktiv, og returnere fokus til et fornuftig sted når den lukkes. Brukeren skal aldri bli sittende fast.
3. Kontrast, zoom og visuell forståelse
WCAG på nivå AA krever normalt minst 4,5:1 i kontrast for vanlig tekst og 3:1 for stor tekst. Viktige grafiske objekter og tilstander i brukergrensesnittet har også kontrastkrav. Mål faktiske fargekombinasjoner; skjermens lysstyrke og designerens godt trente magefølelse er upresise instrumenter.
Ikke bruk farge som eneste signal. Et rødt felt er ikke nødvendigvis forståelig for en bruker som ikke oppfatter fargen, og heller ikke for en skjermleser. Kombiner farge med tekst, ikon eller annen tydelig markering. Test dessuten siden med høy zoom og smalt vindu. Innhold og funksjoner skal ikke forsvinne, overlappe eller kreve unødvendig vannrett rulling.
4. Skjermleser og programmatisk informasjon
Gå gjennom reisen med en skjermleser som passer operativsystemet og nettleseren dere tester i. Lytt til overskrifter, lenker, knapper, feltetiketter, tilstander og feilmeldinger. Målet er ikke at siden skal høres identisk ut i alle hjelpemidler, men at navn, rolle, verdi og tilstand formidles korrekt.
Vær særlig oppmerksom på komponenter som endres uten at en ny side lastes. Hvis et produkt legges i handlekurven, et søk oppdateres eller et skjema lagres, må relevant status kunne oppfattes. Ellers har grensesnittet utført et lite tryllenummer: Systemet vet hva som skjedde, mens brukeren får gjette.
Test gjerne overskriftslisten og landemerkene først. De fungerer som innholdsfortegnelse og veiskilt. En megameny med hundre lenker før hovedinnholdet kan teknisk sett leses opp, men det er en nokså grundig måte å si «velkommen» på.
5. Skjemaer og feil
Alle felt må ha synlige etiketter som også er programmatisk knyttet til riktig felt. Plassholdertekst er et supplement, ikke en etikett; den forsvinner når brukeren skriver og har ofte svak kontrast. Instruksjoner bør stå før de trengs, særlig når felt krever et bestemt format.
Fremprovoser feil med vilje. Meldingen må forklare hvilket felt som har feil, hva problemet er, og hvordan det kan rettes. Feilen må være knyttet til feltet slik at en skjermleser oppfatter den. Ved innsending bør fokus flyttes til en tydelig feiloppsummering eller første relevante feil, avhengig av skjemaets oppbygning.
Behold informasjon brukeren allerede har skrevet inn. Et skjema som tømmer alle feltene etter én feil, gjør validering til en utholdenhetsidrett ingen ba om. Bekreftelsen etter vellykket innsending må også være tydelig og tilgjengelig, ikke bare et kort grønt blink.
Knytt funnene til WCAG og brukerens konsekvens
Registrer hvert funn med side, komponent, teststeg, forventet oppførsel og faktisk resultat. Legg ved en kort beskrivelse av hvordan feilen påvirker brukeren. Knytt deretter funnet til relevant WCAG-suksesskriterium. Da får utviklere noe konkret å rette, og virksomheten får sporbarhet mot kravene.
Prioriter først hindringer som stopper oppgaven: elementer som ikke kan nås med tastatur, manglende feltetiketter, utilgjengelige dialoger, uleselig tekst eller feil som ikke formidles. Deretter tar dere problemer som gjør reisen unødvendig krevende, før mindre avvik og forbedringer.
- Kritisk: Oppgaven kan ikke fullføres for enkelte brukere.
- Alvorlig: Oppgaven kan fullføres, men med betydelig ekstraarbeid eller usikkerhet.
- Moderat: Løsningen er forståelig, men har et tydelig tilgjengelighetsproblem.
- Forbedring: Ikke nødvendigvis et brudd, men løsningen kan bli enklere og mer inkluderende.
Gjør testen til en del av leveransen
Den største gevinsten kommer når testen gjentas etter endringer. Legg den kritiske brukerreisen inn i akseptansekriteriene for design, utvikling og publisering. Automatiser kontrollene som lar seg automatisere, og behold manuelle sjekkpunkter for tastatur, skjermleser, zoom, innhold og feilhåndtering.
Fordel ansvaret. Designere må spesifisere kontrast, fokus og tilstander. Utviklere må bygge semantikk og tastaturatferd. Redaktører må skrive forståelige overskrifter, lenker og tekstalternativer. Testere må kontrollere hele reisen. Universell utforming fungerer dårlig som en seremoniell mappe som sendes til «noen tekniske» to dager før lansering.
Når én viktig brukerreise fungerer med tastatur, høy zoom, skjermleser og tydelige skjemaer, har dere løst noe konkret. Deretter tester dere neste reise og utvider dekningen. Det er mindre spektakulært enn en magisk tilgjengelighetsplugin, men til gjengjeld virker det.
