Universell utforming i Designsystemet

Endelig har vi et felles offentlig designsystem! Kristian feirer lanseringen ved å dele noen refleksjoner og forbedringspotensialer.

Dette er et leserinnlegg originalt skrevet for UX Norge 18. Mars 2025.

«Et tilgjengelig designsystem er nøkkelen til å lykkes med universell utforming på lang sikt». Dette er noe jeg ofte sier når jeg som konsulent bistår kunder i arbeidet med universell utforming. Hvis hver avdeling, hvert team eller hver ansatt skal «finne opp knappen på nytt», vil man ende opp med UU-problem som raskt løper ut av kontroll. 

De fleste mellomstore og store virksomheter – ja, til og med mange små – har i dag egne designsystemer. Men å opprette og vedlikeholde et designsystem er både dyrt og tidkrevende. For at komponentene i et designsystem skal samsvare med kravene til universell utforming, kreves det høy kompetanse både innen design og teknologi samt god brukerinnsikt. 

Noen lurer sikkert på om et felles designsystem betyr at nettsidene deres kan endre seg uten forvarsel. Det er viktig å understreke at de fleste forbedringer knyttet til lovkrav handler om tekniske aspekter ved tilgjengelighet og sjeldent påvirker den visuelle utformingen av komponentene.

Da jeg først hørte om Designsystemet i fjor, tenkte jeg: «Endelig! Dette kan spare samfunnet for store summer! ». Mye av bakgrunnen for denne tanken er hvordan vi ser at ulike kommuner og offentlig virksomheter har sitt helt eget designsystem, med andre ord bruker hver av disse virksomhetene tid og penger på å gjøre «den samme jobben». Om Designsystemet lykkes med å bli benyttet av flere aktører vil de lykkes med å være «en felles digital verktøykasse» og bespare samfunnet for unødige kostnader.

Hvordan Designsystemet løser UU-utfordringer

Fra et universell utformings-perspektiv bidrar Designsystemet til å løse flere store utfordringer:

1. Kostnadseffektivitet: Kommuner og offentlige virksomheter slipper å utvikle og vedlikeholde de samme komponentene hver for seg, noe som sparer både tid og ressurser.
2. Deling av forbedringer: Eventuelle feil eller forbedringer som gjøres på én komponent vil komme alle som bruker Designsystemet til gode. Hvis for eksempel Utsira oppdager en feil i tabell-definisjonen, kan rapportering og utbedring av feilen komme alle kommuner i Norge til gode.
3. Veiledning: Designsystemet tilbyr ikke bare ferdige komponenter, de tilbyr også ressurser og veiledning til samsvar med funksjonelle lovkrav fra WCAG, slik som hvordan man bør gå frem når det kommer til obligatoriske skjemafelter.
4. Forhindring av dårlige teknologivalg: Mange som har designsystemer og komponentbiblioteker bygger ofte disse på en mal, eller et utgangspunkt fra en leverandør av et designsystem eller komponentbibliotek. Det å vurdere og velge rett løsning i slike tilfeller krever mye arbeid. Det vil kreve enda mer arbeid å rette opp feil dersom man oppdager avvik fra lovkravene og må gå via leverandøren for å få endringene gjennomført.
5. Teknisk komplekse UI-elementer: Det er flere komponenter som krever flere spesifikke HTML- og ARIA-attributter med spesifikke verdier og komplekse metoder som fokushåndtering og dynamisk annonsering til skjermlesere for at de skal innfri lovkravene. Jobben blir enda mer krevende når man også må ta hensyn til hvordan skjermlesere og nettlesere støtter et gitt attributt eller element i kombinasjon. Dette er problemstillinger hver enkelt aktør ikke skal måtte løse selvstendig.

Et forbilde: Aksel, NAVs designsystem

Når jeg snakker med kunder som ønsker et eksempel på et designsystem som ivaretar universell utforming på en god måte, viser jeg ofte til Aksel, NAVs designsystem. Ikke bare er komponentene av høy kvalitet, takket være grundig testing, men det finnes også god dokumentasjon for hvordan hver komponent bør implementeres for å sikre universell utforming. Slik nødvendig informasjon er det lagt opp til i Designsystemet, men flere viktige aspekter er ikke nevnt eller tilstrekkelig adressert.

Designsystemet har et enormt potensial til å bli et kostnadsbesparende verktøy for offentlig sektor. Det er dog noen konkrete forbedringerjeg mener bør adresseres når det kommer til universell utforming:

• Mer eksplisitte retningslinjer for bruk: Enkelte komponenter burde ha mer detaljert veiledning om riktig bruk for å sikre tilgjengelighet. Noen eksempler inkluderer:
  
  • Tabs: Det er ingen spesifiseringer rundt tilgjengelighet ved bruk av tab og tablist elementene. Dette er elementer vi i Inklud ofte ser at brukere av hjelpemiddelverktøy har utfordringer med. Samtidig opplever vi også ofte at slike elementer blir feilaktig rapportert som feil da man ikke kan tabbe til alternativene i tablisten. Det ville vært nyttig å forklare hvilke forventninger man skal ha for slike komplekse elementer. Bruk av tabindex burde også vurderes som et alternativ for å påse at alle brukere får tilgang til tab-elementene. 
  • Input type: Under retningslinjer for bruk av Textfield står det «Bruk gjerne inndatatyper som viser hva du ber om, for eksempel telefonnummer og e-post». Dette vil skape et feilaktig inntrykk av at dette er valgfritt. I henhold til 1.3.5 SKAL riktig input type benyttes. En liten omskrivning vil føre til at man unngår unødvendige misforståelser av lovkravene.
• Flere mønstre: Det er til nå kun mønstre for Obligatoriske felt, Feilmeldinger og Systemvarsler. Med det sagt er Systemvarsel mønsteret beskrevet på en svært god måte og det er referert til at Representasjon og Eksterne lenker er kommende mønstre. Noen mønstre som etterspørres er:
  
  • Skjema for endring av brukerdata og skjema med økonomisk eller juridisk konsekvenser: WCAG kriteriet 3.3.4 krever at slike skjemaer skal håndteres med spesifikkemønstre. En bekreftelsesside for slike skjemaer er ett av flere alternativer som bør greies ut om.
  • Innloggingssesjoner: Innloggingssesjoner kommer til dels frem i eksempel om modaler, men det refereres ikke noe sted om innloggings lengden og muligheter brukere skal ha for å utvide tiden. Suksesskriteriet 2.2.1 gir ytterligere informasjon som burde inkluderes i et mønster, slik som advarsel om at tid holder på å gå ut og funksjonalitet for å utvide sesjonen.
• Småjusteringer på det tekniske: Først må det understrekes at nivået på komponentene i designsystemet, når det kommer til teknisk tilgjengelighet, er svært høy. Med det sagt er det enkelte forbedringer som burde vurderes:
  
  • Href ikke påkrevd: Det er ikke påkrevd å definere en href verdi for lenker. Det er ikke meningen å være filosofisk men er en lenke uten et mål en lenke? Svaret er nei, den blir i det minste ikke tab-fokuserbar uten en href. Det virker ikke være noe mening at dette attributtet skal være valgfritt å bruke i komponentbiblioteket.
  • Bruk av Role over aria: Det benyttes og refereres mye til role alert og role status for dynamisk annonsering av viktige beskjeder til skjermleserbrukere. Roller kan sees på som en pakke av aria-attributter som blir definert. Problemet er at disse mer komplekse rollene har dårligere støtte enn attributtene den definere.
  • Feilmeldinger er dupliserte: Man bruker en kombinasjon av skjult skjermlesertekst som dynamisk annonseres med aria-live samt å duplisere denne informasjonen visuelt. Dette fører til at skjermleserbrukere vil møte på feilmeldingen to ganger om man sekvensielt navigerer gjennom skjemaelementer med feil. Her burde man justere på det tekniske for å påse at innhold ikke blir presentert dobbelt.
• Oppdatering og forbedringer i eksempler: Det finnes samlet test og showcase sider for de ulike elementene som er tilgjengelige gjennom komponentbiblioteket. Det er mitt sterke ønske at også slike eksempelsider skal være utformet på en måte som innfrir lovkravene. Til eksempel er det flere elementer uten tilgjengelige navn på siden «Testing». På samme side er det også utdaterte elementer (som input med type text og rollen combobox) som bryter med lovkravet 4.1.2, dette er fremhevet i skjermdumpen under. Det samme er også tilfellet på siden «Showcase».

 

Veien videre

Ved å videreutvikle Designsystemet med disse aspektene i bakhodet, kan vi gjøre universell utforming til en naturlig og integrert del av all offentlig digitalisering. Det vil ikke bare sikre at offentlige løsninger blir tilgjengelige for alle – det vil også spare samfunnet for store kostnader på lang sikt.

Så langt bidrar Nav, Digdir, Skatteetaten, Brønnøysundregistrene, Oslo Origo, Oslo Kommune, Entur, Politiet, Mattilsynet og Utdanningsdirektoratet til Designsystemet. Det er nok ikke tilfeldig at de som bidrar er aktører som er kjent for å være langt fremme når det kommer til digital tilgjengelighet. På vegne av UX-Norge og alle oss i Inklud takker vi for deres innsats så langt og ønsker dere og alle fremtidige bidragsytere lykke til videre med å få Designsystemet til å oppnå sitt fulle potensiale.