Introduksjon

Universell utforming betyr at løsningene vi lager skal fungere godt for alle mennesker, i alle situasjoner. Det handler ikke om å lage én versjon for «vanlige» brukere og så gjøre den tilgjengelig for noen få – det handler om å lage løsninger som er gode fra start.

En universelt utformet løsning er enklere å bruke for alle. Tydelig kontrast hjelper på bussen i sollys. Logisk navigasjon sparer tid for den stressede. God struktur gjør at skjermlesere fungerer. Det er ikke separate grupper – det er den samme brukeropplevelsen.

Mange tenker på universell utforming som en teknisk sjekkliste man går gjennom til slutt: kontrast, ARIA-attributter, tastaturnavigasjon. Det er viktige ting, men de er ikke hele bildet.

God universell utforming starter med å forstå problemet du skal løse, og hvem du løser det for – ikke med å pynte på en ferdig løsning etterpå.

Entur Reisevenn illustrerer dette godt. Reisevenn hjelper blinde og svaksynte å reise kollektivt, med beacons på holdeplasser og lydveiledning i appen. Løsningen ble ikke til ved å legge et tilgjengelighetslag oppå en eksisterende app. Den ble designet fra bunnen av, sammen med brukerne, for å løse et reelt problem. Resultatet gir verdi langt utover den opprinnelige målgruppen – eldre, turister og alle som er usikre i ukjente omgivelser har nytte av den samme løsningen.

Det er forskjellen mellom å reparere en løsning som ekskluderer, og å lage en løsning som inkluderer fra start.

Universell utforming er lovpålagt. Kort oversikt:

Det tar gjerne noen år fra en ny WCAG-versjon publiseres til den blir lovpålagt. Vi venter ikke på det: vi legger WCAG 2.2 nivå AA til grunn allerede nå, fordi de nyeste kriteriene (som god nok trykkeflate) gjør produktene bedre for alle – uavhengig av når loven tar dem inn.

Hvert team eier ansvaret for universell utforming i produktene sine. UU er ikke noe som gjøres av én spesialist på slutten – det er en del av hvordan vi designer, utvikler og tester.

Tilbakemeldinger på tilgjengelighet kan sendes til tilbakemelding@entur.org.

1. Tenk «fungerer dette i alle situasjoner?» – Test ideen din mentalt: Fungerer den med én hånd? I sollys? Under tidspress? Med skjermleser? Hvis ikke, juster designet.
2. Skriv forståelig – Unngå fagsjargong. Bruk korte setninger. Test teksten på noen som ikke kjenner produktet.
3. Sjekk kontrast tidlig – Bruk kontrastsjekkeren mens du designer, ikke etter du er ferdig.
4. Bruk relative størrelser – Slik at brukere som forstørrer tekst ikke mister funksjonalitet.
5. Gi tydelige tilbakemeldinger – Feilmeldinger skal si hva som gikk galt og hva brukeren kan gjøre.
6. Lag store nok trykkeflater – Minst 24×24 px for interaktive elementer (WCAG 2.2, se «Regelverk i Norge» over).

1. Bruk riktig HTML-element – <button> for knapper, <a> for lenker, <nav> for navigasjon. Semantisk HTML gir deg tilgjengelighet nesten gratis. Les mer.
2. Sørg for tastaturstøtte – Tab-rekkefølgen skal følge den visuelle layouten. Fokusmarkering skal alltid være synlig. Modaler skal fange fokus.
3. Test med skjermleser – Kjør VoiceOver (Mac) eller NVDA (Windows) og naviger gjennom løsningen. Gir det mening? Er rekkefølgen logisk?
4. La innholdet flyte – Bruk responsivt design som fungerer ved alle vindusbredder og ved forstørring opp til 400 %.
5. Husk video – Forhåndsinnspilt video fra offentlig sektor skal ha synstolking av viktig visuell informasjon, se testguiden.
6. Automatiser det du kan – Bruk axe og Lighthouse i CI for å fange opplagte feil, men de dekker langt fra alt. Se testguiden for en komplett tilnærming.

Se verktøy og ressurser for en fullstendig oversikt over standarder, testverktøy og læringsressurser.