# Universell utforming ## Hva det er Universell utforming av et nettsted, en app eller et verktøy handler om hvor godt det fungerer for folk med funksjonsnedsettelser. W3Cs Web Accessibility Initiative (WAI) definerer det ut fra hva folk skal kunne gjøre: oppfatte, forstå, navigere og samhandle med nettet, og bidra til det selv. Det siste verbet veier tungt. Et nettsted der en blind besøkende kan lese hver eneste artikkel, men verken kan skrive en kommentar, laste opp en fil eller fullføre en registrering, oppfyller halve definisjonen. Mange sier også digital tilgjengelighet, på engelsk accessibility, og forkortelsen a11y teller de elleve bokstavene mellom a og y. Omfanget er alle funksjonsnedsettelser som påvirker tilgangen til nettet. WAI nevner hørsel, kognisjon, nevrologi, motorikk, tale og syn, og hver av dem har sine egne barrierer: video uten teksting, instruksjoner som krever at du husker mye, bevegelse som utløser symptomer, kontroller som trenger en stødig hånd og en mus, stemmestyring som forventer flytende tale, og tekst som bare fungerer i én størrelse og med én kontrast. Under den synlige siden bygger nettleseren en egen struktur for hjelpemidler. ARIA-spesifikasjonen kaller den tilgjengelighetstreet: et tre av tilgjengelige objekter der hver node står for et element i grensesnittet, f.eks. en trykknapp eller en avkrysningsboks, og eksponeres gjennom plattformens tilgjengelighets-API. Skjermlesere, stemmestyring, brytere og leselister for punktskrift arbeider ut fra dette treet, ikke ut fra piksler. Hver node har et navn, en rolle og en tilstand, og WCAG-kriteriet 4.1.2 Navn, rolle, verdi krever at programvare kan lese dem ut for hver komponent i grensesnittet. Standarden påpeker at innebygde HTML-kontroller allerede oppfyller 4.1.2 når de brukes slik spesifikasjonen sier. En `div` med en klikkhandler havner i treet som vanlig tekst, uten rolle og uten plass i tastaturrekkefølgen. WAI understreker at universell utforming avhenger av at flere deler spiller sammen: webteknologiene, nettleserne, publiseringsverktøyene og selve nettstedene. Den som eier et nettsted, styrer den siste av disse, og det er der WCAG beskriver i testbare formuleringer hva innholdet må gjøre. ## Hvorfor det er viktig Nettet bærer utdanning, arbeid, offentlige tjenester, handel og helsetjenester, og WAI viser til at FNs konvensjon om rettighetene til mennesker med nedsatt funksjonsevne definerer tilgang til informasjons- og kommunikasjonsteknologi, nettet inkludert, som en grunnleggende menneskerettighet. Universell utforming er også lovpålagt i mange sammenhenger, og innkjøpere gjør det om til en linje i kontrakten som nevner WCAG 2.2 nivå AA. Den linjen avgjør hva leverandøren må bygge og dokumentere. I Norge sier Uutilsynet at ikt-løsninger skal være universelt utformet, at det gjelder nettløsninger, apper og automater, og at både private og offentlige virksomheter må følge regelverket. Det samme arbeidet hjelper folk som aldri ville kalt seg funksjonshemmet. WAI nevner selv folk på mobil, klokke og TV med små skjermer og andre måter å styre på, eldre hvis evner endrer seg med alderen, en som har brukket armen eller mistet brillene, en som står i sterkt sollys eller et sted der lyd ikke kan spilles av, og alle med treg eller dyr forbindelse. Teksting hjelper på et stille tog, og sterk kontrast hjelper på en telefon midt på dagen. Tidspunktet bestemmer prisen. WAI kaller det mest effektivt å bygge inn universell utforming helt fra starten av et prosjekt, så arbeidet slipper å gjøres om. Å velge en innebygd knapp koster ingenting første dag. Å bytte ut en hjemmesnekret knapp etter lansering betyr å rette komponenten og deretter teste på nytt hver side som brukte den, på hvert språk og i hvert tema nettstedet leverer. Evalueringen følger samme logikk. Verktøy hjelper, men WAI sier rett ut at intet verktøy alene kan avgjøre om et nettsted oppfyller retningslinjene, og at det kreves evaluering av mennesker som kan faget. En regelmotor leser hva oppmerkingen sier. En person med tastatur og skjermleser finner ut hva siden gjør. ## Slik ser det ut i praksis Et nettsted besto de automatiske reglene for universell utforming og hadde likevel [elleve feil som nettleseren meldte som friske](/nb/portfolio/fixed-11-accessibility-defects-the-browser-called-healthy-131/), hver av dem en egenskap ved hvordan siden ble gjengitt, ikke ved hva oppmerkingen sa. Åtte lenker i bunnteksten ble værende i tabulatorrekkefølgen bak en egenskap som fjerner pekerinteraksjon og ingenting annet, så et tastatur kunne lande på lenker som var usynlige på skjermen. To av feilene satt i selve vaktene. Hvert vindu layoutkontrollen åpnet, var ni hundre piksler høyt, så på en telefon i liggende format på 852 ganger 393 sto to elementer sju piksler fra hverandre uten at noen så etter. Regelmotoren hadde kjørt sytti av sine hundre og fem regler. Fire regler kom ut av arbeidet, blant dem at en vakt som tester én akse, forsvarer én akse, og at synlighet bevises i piksler og ikke i dokumentet. Da layoutkontrollen ble åpnet på nytt, nå på riktig måte, feilet den hundre og tjueåtte ganger på tvers av tre språk. Siden om [å gi alle sytten ikonkontrollene et navn](/nb/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/) flytter blikket fra et nettsted til en applikasjon bygd med SwiftUI. Et systemsymbol uten tilgjengelighetsetikett leses opp med sitt interne navn, så sendeknappen presenterte seg som «arrow up circle, button», og alle de andre rene ikonkontrollene gjorde det samme på sin måte: sytten i alt beskrev grafikken sin i stedet for funksjonen. Nå har hver av dem en etikett som navngir handlingen, og der betydningen avhenger av tilstand, følger etiketten tilstanden. En linter krever en etikett innenfor åtte linjer fra hver konstruksjon som lager en ren ikonkontroll. Regelen er bevisst grov og valgt ved måling, og en attende kontroll kan ikke legges til uten etikett. Siden oppgir også grensen for regelen: den beviser at en etikett finnes i nærheten, og om etiketten er riktig, krever fortsatt at noen lytter. [Siden om å være klar for AI-agenter](/nb/ai-ready/) legger til en nyere leser. Mange agenter som styrer en nettleser, leser en side slik en skjermleser gjør, gjennom tilgjengelighetstreet. Ekte knapper, nettskjemaer med etiketter, overskrifter i riktig rekkefølge og landemerker gjør et nettsted brukbart uten mus, og det er det samme arbeidet som lar en agent finne et skjema og fylle det ut. ## Hvor det går galt **En egen nedtrekksmeny fungerer med mus og stenger alle andre ute.** En `div` med en klikkhandler har ingen rolle, tar ikke tastaturfokus og melder ingen åpen eller lukket tilstand, så en skjermleser leser opp ren tekst og Tab-tasten hopper forbi. Begynn med det innebygde elementet, `select`, `button` eller `details`, som har rolle, fokus og tilstand med seg. Trenger designet virkelig en egen komponent, følger du mønsteret i ARIA Authoring Practices Guide og tester den med tastatur og skjermleser. **Alternativteksten beskriver bildet, mens leseren trengte å vite hva det gjør.** Kriterium 1.1.1 Ikke-tekstlig innhold ber om et tekstalternativ som tjener samme formål, og en lenket logo beskrevet som «blå sekskantlogo» sier ingenting til en skjermleserbruker om hvor lenken går. Skriv alternativet ut fra bildets rolle: målet for et lenket bilde, funnet for et diagram, ordene for et bilde av tekst. Gi rent dekorative bilder en tom `alt=""`, så hjelpemidlene hopper over dem. **Fokus faller til toppen av siden når en dialog lukkes.** Når en dialog lukkes eller ruten endres i en enkeltsideapp, forsvinner elementet som hadde fokus. Fokus faller tilbake til dokumentets `body`, og en bruker med tastatur eller skjermleser mister plassen sin. Send fokus tilbake til kontrollen som åpnet dialogen. Etter et rutebytte på klienten flytter du fokus til hovedoverskriften i den nye visningen, med `tabindex="-1"` så den kan ta imot fokus, og skjermleseren forteller hvor brukeren har havnet. **Feil vises bare som en rød ramme.** Kriterium 1.4.1 Bruk av farge krever at farge ikke er det eneste visuelle virkemiddelet for å formidle informasjon, og 3.3.1 Identifikasjon av feil ber om at en oppdaget inndatafeil identifiseres og beskrives for brukeren i tekst. En rød kant gjør ingen av delene for en som ikke skiller rødt fra grått eller ikke ser feltet i det hele tatt. Sett en kort melding ved siden av feltet som sier hva som er galt og hvordan det rettes, koble den til med `aria-describedby` så skjermleseren leser begge sammen, og behold fargen som et ekstra signal. ## Les mer - [Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/) — WAIs definisjon, hvem som har nytte av det, og hvorfor evaluering trenger mennesker i tillegg til verktøy. - [How People with Disabilities Use the Web](https://www.w3.org/WAI/people-use-web/) — historier om brukere, barrierene de møter, og verktøyene og teknikkene de stoler på. - [The Business Case for Digital Accessibility](https://www.w3.org/WAI/business-case/) — rekkevidde, innovasjon, omdømme og juridisk risiko, skrevet for dem som godkjenner budsjetter. - [Evaluating Web Accessibility Overview](https://www.w3.org/WAI/test-evaluate/) — fra enkle stikkprøver til en full samsvarsevaluering, med verktøy og rapportering. - [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — mønstre for egne komponenter, med rollene, tilstandene og tastaturoppførselen hver av dem trenger. - [Regelverk, Uutilsynet](https://www.uutilsynet.no/regelverk/regelverk/266) — det norske tilsynets oversikt over gjeldende og kommende krav til universell utforming av ikt.