Universell utforming og brukervennlighet

Hvorfor universell utforming gjelder bedriftens nettside

En kunde kan bruke tastatur, skjermleser, forstørring eller mobil i krevende lys. Nettsiden må formidle informasjon og gjøre det mulig å fullføre oppgaver også når bruken er annerledes enn dere selv er vant til.

Norske regler om universell utforming kan gjelde både private og offentlige virksomheter. For private virksomheter er minstekravet til nettløsninger som er omfattet, 35 suksesskriterier i WCAG 2.0. Det er viktig å skille disse lovkravene fra et prosjektmål om WCAG 2.1 AA.

Se Uutilsynets forklaring av hvem reglene gjelder for og forskriftens krav til private virksomheter.

Før gjennomgangen bestemmer dere og jeg hvilket regelverk og hvilket nivå den skal dekke. En kontroll av noen utvalgte sider er ikke det samme som å ha vurdert hele nettstedet.

Hva testen dekker

Jeg kombinerer manuell gjennomgang med automatiske kontroller. WCAG er retningslinjer for tilgjengelig innhold på nett. En test mot WCAG 2.1 AA gir et konkret utgangspunkt, men kriteriene må vurderes i sammenheng med funksjonene dere har.

• Tastatur: om meny, knapper og skjemaer kan brukes uten mus, og om det er synlig hvor brukeren befinner seg.
• Skjermleser: om overskrifter, lenker og skjemaelementer har en struktur og navn som gir mening.
• Kontrast og lesbarhet: om informasjon er mulig å oppfatte, også uten å skille bestemte farger.
• Forstørring og mobil: om innhold og funksjoner fortsatt er tilgjengelige ved smal skjerm og større tekst.
• Skjemaer: om felter er forståelige, og om feil forklares slik at brukeren kan rette dem.
• Bilder og video: om innholdet har relevante tekstalternativer og nødvendig teksting i det avtalte utvalget.

Automatiske verktøy er nyttige for å finne bestemte feil, men de kan ikke avgjøre alt. For eksempel krever det en vurdering å avgjøre om en alternativ tekst forklarer bildet godt nok, eller om en feilmelding hjelper brukeren videre. W3C beskriver begrensningene ved automatiske tilgjengelighetsverktøy.

Før testingen velges representative sidetyper og viktige funksjoner. Hvis samme meny brukes overalt, er det nyttig å teste den grundig. Sider med skjemaer, pålogging eller andre særskilte funksjoner må vurderes i tillegg.

Brukervennlighet: de viktigste brukerreisene

Teknisk tilgjengelighet og brukervennlighet henger sammen, men er ikke det samme. Et skjema kan ha riktige feltnavn og likevel stille spørsmål kunden ikke forstår. En lenke kan fungere med tastatur, men være vanskelig å finne.

Jeg tar derfor utgangspunkt i konkrete oppgaver, for eksempel:

• finne riktig tjeneste og forstå hvem den passer for;
• finne kontaktinformasjon eller åpningstider;
• sende en forespørsel og forstå om den kom frem;
• gå videre fra en feilmelding uten å miste arbeidet.

Dere kjenner kundenes spørsmål. Jeg bruker den kunnskapen til å velge hva som bør testes, og ser etter uklare ord, unødvendige steg og informasjon som kommer for sent. Funn om brukervennlighet skilles fra konkrete avvik mot WCAG, slik at rapporten er presis.

Treg lasting gjør også en nettside vanskeligere å bruke. Den delen undersøker jeg i en egen gjennomgang for en raskere nettside.

Rapport på norsk med prioriterte funn

Rapporten skal kunne brukes til å ta beslutninger og bestille rettinger. Derfor beskriver jeg både hvor problemet finnes, hvordan det oppstår og hva det betyr for brukeren.

• Sted og fremgangsmåte: hvilken side eller funksjon som er testet, og hvordan problemet kan gjenskapes.
• Konsekvens: hvilken oppgave som blir vanskelig eller umulig å fullføre.
• Kriterium: relevant WCAG-kriterium når funnet gjelder et slikt avvik.
• Prioritet: hva som bør løses først ut fra konsekvens og omfang.
• Forslag til retting: en konkret forklaring som dere eller en utvikler kan arbeide videre med.

Et eksempel er et kontaktskjema der feilen bare vises som en rød ramme. Da beskriver jeg hva som mangler, hvordan det påvirker brukeren og hvordan en forståelig feilmelding bør formidles. Rapporten skal ikke bare si «skjemaet er utilgjengelig».

Dere får også vite hvilke sider, funksjoner og hjelpemidler som inngikk i kontrollen, og hva som ikke er vurdert. Det gjør resultatet lettere å tolke og følge opp.

Fortell hvilke sider og skjemaer som er viktigst for dere, så foreslår jeg et utvalg for gjennomgangen.

Utbedring av avtalte feil

Etter gjennomgangen avtales hvilke feil jeg skal rette. Noen kan løses i innholdet, andre krever endringer i tema, komponenter eller funksjonalitet. Feil i eksterne tjenester kan måtte håndteres av leverandøren deres.

1. Funnene gjennomgås og prioriteres.
2. Omfanget av rettingene avtales skriftlig.
3. Endringene gjøres i et egnet testmiljø.
4. De berørte oppgavene testes på nytt.
5. Dere får en oppdatert oversikt over hva som er rettet og hva som gjenstår.

Hvis dere vil bruke en annen utvikler, kan rapporten brukes som grunnlag. Det skal være tydelig når gjennomgangen og de avtalte rettingene er ferdige.

Er problemene så store at det lønner seg å starte på nytt, beskriver jeg overgangen på siden om ny nettside.

Slik arbeider jeg med tilgjengelighet i egne løsninger

På tilgjengelighetssiden for dette nettstedet beskrives målet, testingen og kjente mangler. Dokumentasjonen skal si noe om det som faktisk er undersøkt, ikke bare gjenta en ambisjon.

Tilgjengelig innhold handler også om mer enn kode. I CI Subtitles har jeg laget en arbeidsflyt for norske undertekster med menneskelig kontroll av transkripsjon og ordtiming. Det er et eksempel på hvordan jeg jobber med innhold som må kunne oppfattes på flere måter.

Vanlige spørsmål

Er universell utforming lovpålagt for private bedrifter?

Ja, når nettløsningen er omfattet av regelverket. Uutilsynet beskriver blant annet at den skal være rettet mot brukere i Norge og være en hovedløsning knyttet til virksomhetens alminnelige funksjon.

Hva er forskjellen på WCAG 2.1 og 2.2?

WCAG 2.2 videreutvikler 2.1 med flere kriterier, blant annet om fokus som ikke skjules, størrelse på trykkflater og tilgjengelig innlogging. En nyere standard blir ikke automatisk norsk lov; W3Cs WCAG 2.2 beskriver standarden.

Hvor lang tid tar en gjennomgang?

Det avhenger av antall sidetyper, funksjoner og brukeroppgaver som skal testes. Dere får en tidsplan når utvalget og omfanget er avklart.

Kan vi rette feilene selv etter rapporten?

Ja. Funnene beskrives slik at dere eller en annen utvikler kan arbeide med dem, og det kan avtales en ny kontroll av de aktuelle rettingene.

Hvilke oppgaver må kundene kunne fullføre?

Send adressen til nettsiden og fortell hvilke sider eller funksjoner dere vil få undersøkt. Jeg svarer innen én arbeidsdag og samarbeider digitalt med bedrifter i hele Norge.

Ta kontakt om tilgjengelighet og brukervennlighet