Sjekk universell utforming på nettsiden

Slik fungerer verktøyet

Du limer inn en nettadresse, og vi henter siden fra serveren vår. Så går vi gjennom markupen og tester de kravene i WCAG 2.1 AA som kan avgjøres av koden alene: språk, sidetittel, alt-tekster, ledetekster på skjemafelt, lenketekster, overskriftsrekkefølge, landemerker, zoom på mobil og tabellstruktur.

Hvert funn er knyttet til det suksesskriteriet det hører til, for eksempel 1.1.1 eller 2.4.4. Det er ikke pynt: når du skal be noen rette feilen, er kriterienummeret det raskeste du kan gi dem.

Funnene deles i to. «Brudd» er krav som ikke er oppfylt. «Å se nærmere på» er ting som svekker opplevelsen uten at det nødvendigvis er et brudd i seg selv.

Scoren er vår egen, regnet ut av funnene. Den er en temperaturmåler, ikke en attest.

Hva en automatisk test faktisk kan si

Dette er det viktigste avsnittet på siden. Automatiske tester fanger opp omtrent en tredel av kravene i WCAG. Resten krever at noen bruker siden.

Vi kan se at et bilde mangler alt-tekst. Vi kan ikke se om alt-teksten som finnes, faktisk beskriver bildet. «bilde1.jpg» og «Ansatt smiler mot kamera» ser like riktige ut for en maskin.

Vi kan se at et skjemafelt mangler label. Vi kan ikke se om feilmeldingen som kommer når noen fyller ut feil, blir lest opp av skjermleseren.

Og vi kan ikke se kontrast i det hele tatt, fordi kontrast avhenger av hva som faktisk tegnes opp på skjermen — hvilken farge teksten arver, hva som ligger under, og hvordan det ser ut på mobil.

Derfor står listen over det som må testes manuelt, synlig i resultatet. En høy score betyr at grunnlaget er på plass. Den betyr ikke at siden er tilgjengelig.

Slik tolker du resultatet

Begynn med bruddene. De er konkrete, de har som regel en konkret løsning, og flere av dem er raskt gjort.

Alt-tekster og ledetekster på skjemafelt er nesten alltid de to største postene, og begge er tekstarbeid mer enn utviklingsarbeid. Noen må se på hvert bilde og bestemme hva det faktisk viser.

Overskriftshopp og manglende landemerker er kodearbeid, men det er enkelt kodearbeid. Det handler om å bruke elementene som allerede finnes i HTML.

Når bruddene er borte, begynner den delen som krever et menneske. Sett av en time, legg fra deg musa, og prøv å komme gjennom hele siden med tastaturet. Du finner mer på den timen enn noe verktøy klarer.

Metode

Siden hentes én gang, med tidsgrense, og markupen testes mot faste regler. Resultatet mellomlagres i et døgn.

Hvem gjelder kravene for

I Norge gjelder kravene til universell utforming for nettsider rettet mot allmennheten, både i privat og offentlig sektor. For offentlig sektor er kravene strengere og omfatter også en tilgjengelighetserklæring.

For en vanlig bedrift er det enkleste å forholde seg til at WCAG 2.1 nivå AA er normen. Det er det nivået tilsynet måler mot, og det er det nivået utviklere kjenner.

[VERIFISER: gjeldende frister og krav for private virksomheter etter siste endring i regelverket.]

Uavhengig av hva loven krever: rundt hver femte person har en funksjonsnedsettelse som påvirker hvordan de bruker nett. Det er ikke en liten gruppe, og det er ikke bare blinde brukere. Det er også han som er midlertidig sengeliggende med brukket arm, og hun som leser siden i sollys på en telefon.

Vanlige feil

De samme tingene går igjen på nesten alle nettsteder vi tester.

• Ikonknapper uten navn. Hamburgermenyen og lukkeknappen er de to verstingene.
• Fokusmarkering fjernet fordi den ble oppfattet som et designproblem.
• Lenker som heter «les mer» femten ganger på samme side.
• Overskrifter valgt etter hvor stor teksten skulle være, ikke etter struktur.
• Skjemafelt der plassholderteksten brukes i stedet for en label. Den forsvinner idet du begynner å skrive.
• Karuseller som bytter bilde av seg selv, uten mulighet til å stoppe dem.

Hva det koster å rette

Det avhenger helt av når du tar det. Bygges tilgjengelighet inn fra start, koster det nesten ingenting ekstra — det er stort sett å bruke HTML riktig og å ta noen designvalg bevisst.

Rettes det på en ferdig side, er det mer arbeid, men fortsatt overkommelig. De fleste feilene vi finner, er systematiske: de ligger i malen og rettes ett sted.

Det som koster, er når tilgjengelighet krever at et designsystem gjøres om. Fargepaletter med for lav kontrast er det klassiske eksempelet, fordi det treffer merkevaren og dermed en beslutning som ligger høyere opp i organisasjonen.

Derfor er kontrast verdt å teste før en designprofil vedtas, ikke etter at den er rullet ut på tre hundre sider.

Når bør du få hjelp

Om siden har mange brudd av samme type, er det som regel én mal som må rettes. Det er en avgrenset jobb, og den er verdt å gjøre samlet i stedet for side for side.

Om dere skal ut på anbud mot offentlig sektor, bør tilgjengelighet være dokumentert før tilbudet sendes. Det etterspørres oftere enn før, og det er dårlig timing å oppdage etterpå.

Og om dere planlegger en ny nettside, er dette det billigste tidspunktet å ta det på. Da er det et krav i kravspesifikasjonen, ikke en regning som kommer etterpå.