Innen 1 januar 2021 blir universell utforming gjeldende lov for absolutt alle nettsider. Loven har vært i kraft fra 2014 for alle nye løsninger, men også for de eksisterende som gjennomgår en betydelig oppgradering. Denne blir håndhevet av Digitaliseringsdirektoratets “Tilsyn for universell utforming av ikt”, og kan få konsekvenser i form av både bøter og uheldig mediadekning.

Universell Utforming betyr i praksis at løsningen du lager er tilgjengelig for alle. Språkbruket skal være forståelig, alle funksjoner skal være tilgjengelig via tab-tasten og skjermleser, trykkflatene store nok, fargene skal ha riktige kontraster og fontene kan forstørres. Det kan være litt abstrakt å forestille seg spesielle behov, men prøv å tenke over utfordringer du får ved for eksempel å bruke mobilen når du står i en overfylt buss. Du må da holde deg fast med en hånd, bussen rister og svinger, det er masse folk rundt deg, og du har selvfølgelig også glemt å sette på headphones på forhånd - og klarer nå ikke å få tak i dem for å se på den morsomme videoen noen har delt med deg. Her hadde det vært fint med knapper som er lett tilgjengelig å trykke på med en tommel, men også store nok at du ikke bommer når bussen rister. Videoen bør også ha tekst for at du kan få med deg innholdet uten å måtte skru på lyd og forstyrre alle rundt deg.

Web Content Accessibility Guidelines (WCAG2.0) er et forskrift som stiller krav til webløsninger. I praksis er det en liste med retningslinjer der 35 av 61 punkter er obligatoriske og resterende er anbefalinger. Kravene deles opp i 4 overordnede prinsipper:

  1. Mulig å oppfatte
  2. Mulig å betjene
  3. Forståelig
  4. Robust

De fire prinsippene inneholder 61 suksesskriterier med ulik vekt: A (minstekravet som må være på plass), AA (strengere enn A, noen er obligatoriske, andre er veiledende), og AAA (strengeste nivå, ikke obligatorisk). For å være på den sikre siden og lage en nettside alle kan ha glede av, kan det være lurt å sette som mål å tilfredstille alle krav i A og AA kategoriene.

Som utvikler er det fort gjort å fortsette å kode “som alltid før” og ta en opprydning etterpå, men det blir mye mer jobb enn hvis man tar det underveis. Det finnes en del gode verktøy som kan støtte deg, og som sørger for at reglene følges. Verktøy og testmetoder under er min samling fra ulike prosjekt jeg har vært på, og mye av inspirasjonen kommer fra et foredrag til Kristoffer Stenseth som han holdt for utviklerne på Altinn/DesignSystem prosjektet.

Noen nyttige verktøy når man skal utvikle for web:

Her er en sjekkliste som jeg bruker i frontend-prosjekter:

Generelt

Tastaturnavigasjon

Overskrifter

  • Definert som <h1> til <h6> i korrekt rekkefølge

Modalvinduer

  • Dekkende lag får riktig tastaturfokus
  • Det er mulig å lukke modalen ved hjelp av tastatur

Tabell

  • Tabeller deklarert som <table>
  • Ingen nesting av tabeller
  • Korrekte overskrifter (bruk av <th> og riktig scope)
  • Har Caption dersom tabellen har en tittel

Skjema

  • Skjemaelementer er korrekt kodet (type, label, evt. wai-area)
  • Logiske elementer er gruppert med for eksempel fieldset og legend

Søk

  • Søkeknapp er input, button evt. image med alt = «søk»

Media

Bilder

  • Ikke brukes til tekst eller knapper
  • Har beskrivende alt-tekst, eller ARIA-Label
  • Meningsbærende bilder skal ikke legges inn via CSS
  • Forståelig i svart-hvitt
  • Komplekse bilder har beskrivende tekst i nærheten av seg

Animasjoner

  • Bevegelse, blinking og rulling kan settes på pause/stoppes/skjules (med mindre det er helt nødvendig for handlingen)
  • Elementet blinker ikke mer enn tre ganger per sekund

Det kan være lurt å sette seg sammen to og to og gå gjennom layout når en oppgave er ferdig. Her er et forslag til punkter å gå gjennom på et slikt “design review”:

  1. Sammenligne avstander, farger, generell layout mot skissene
  2. Teste at layout er lik for Chrome, Firefox, IE
  3. Sjekk om layout er responsivt
  4. Sjekk at onhover på de ulike elementene oppfører seg riktig
  5. Sjekk Errors og Alerts i Wave Toolbar
  6. Test skjermleserfunksjonalitet/tabbing med ChromeVox
  7. Skru av CSS i nettleseren og sjekk at rekkefølge på komponenter er logisk, bruk feks disable-HTML
  8. Åpne Chrome Dev Tools og kjør Audits - sjekk ut evt feil under “Accessibility” i resultatet
  9. Kjør Ainspector Sidebar i Firefox (denne deler opp evt feil inn i WCAG standards)

Mobil

Apper på mobil skal følge de generelle retningslinjene for web der det er mulig. Her er hva som er kanskje ekstra viktig å huske på:

  • Inputfelt må ha tilhørende labels
  • Eget tastatur for inputfelt - epost, numerisk, passord etc.
  • Farger har god kontrast
  • Minste trykkflate på knapper er 48px
  • Teste at fontstørrelse-innstillinger på telefon overskriver fontinstillinger i appen
  • Kjør Accessibility Scanner på Android
  • Test med Voiceover (iOS) og Talkback (Android)

Teste appen med skjermleser

Skru på Voiceover eller Talkback ved å gå til innstillinger på din telefon. Det er viktig å gjøre det med jevne mellomrom, og spesielt når ny funksjonalitet kommer på plass. Her er tre punkter som er ekstra viktige:

  • Alle elementer av betydning er tilgjengelige - dvs at de blir markert og opplest riktig
  • Ved navigasjon settes fokus på det øverste elementet
  • Brukeren blir varslet når state på element endrer seg - typisk på en liste som oppdaterer seg, eller et søkeresultat som endrer visningen

Til slutt, en liten oppfordring: skru på Voiceover på din iPhone eller Talkback på Android - klarer du å ha den på i en hel dag? Happy uu-testing!