Tilgjengelighet i designsystemet — slik bygger du WCAG inn i tokens
Tilgjengelighet som sjekkes til slutt, blir en liste med avvik. Tilgjengelighet som ligger i tokens og komponenter, blir standarden. Her er hvordan jeg bygger det inn fra start.
Tilgjengelighet som testes til slutt, kommer alltid for sent.
På det tidspunktet er fargene valgt, komponentene bygget og fristen nær. Da blir WCAG en liste med avvik noen skal rekke å rette, og rettelsene blir lapper: en litt mørkere gråtone her, en aria-label der. Neste komponent gjør samme feil på nytt.
Alternativet er å flytte kravene ned i fundamentet, slik at det er vanskeligere å gjøre feil enn å gjøre riktig.
Kontrast er en egenskap ved token-paret, ikke ved fargen
En farge har ingen kontrast alene. Den får kontrast først i møte med en annen. Likevel dokumenteres paletter ofte som løse fargeverdier, og da må hver designer regne ut kombinasjonen på nytt hver gang.
Løsningen er å definere tokens i par som allerede er testet: en bakgrunn og teksten som hører til den. Da er valget «bruk denne overflaten» samtidig et valg av lesbar tekstfarge, og ingen trenger å vite kontrastforholdet for å treffe det.
I Foreldrekompasset, et foreldrestøtteprogram finansiert av Helsedirektoratet, la vi alle designverdier som CSS custom properties med egne skalaer for default, hover, active og surface per farge. Interaksjonstilstandene ble dermed forutsigbare i stedet for improviserte, og alle komponentene er WCAG 2.1 AA-verifisert.
Fokus og tastaturnavigasjon hører hjemme i komponenten
Den vanligste tilgjengelighetsfeilen er ikke manglende alt-tekst. Det er fokusmarkeringen noen har skrudd av fordi den var stygg, og tabbrekkefølgen ingen har testet.
Begge deler løses én gang hvis de ligger i komponenten. Når akkordeonen, kortet, filnedlasteren og navigasjonsknappen kommer med innebygd fokushåndtering og tastaturstøtte, arver hver ny side oppførselen automatisk. Utvikleren som bruker komponenten trenger ikke å kunne WCAG for å følge den.
Test temaene, ikke bare standardvisningen
Et system med flere fargetemaer har like mange muligheter til å feile. For iArbeid bygget vi en plattform der hver medlemsbedrift velger sitt eget tema. Alle syv temaene er testet for lesbarhet og kontrast, fordi et tema som ikke er testet i praksis er et tema som kommer til å brukes feil.
Det samme gjelder dark mode. Et mørkt tema er ikke et lyst tema med inverterte verdier. Det er et eget sett beslutninger som må verifiseres for seg.
Gevinsten er hastighet, ikke bare samsvar
Tilgjengelighet selges ofte som noe man må, med henvisning til likestillings- og diskrimineringsloven og WCAG 2.1 AA. Det stemmer, men det underselger poenget.
Et system der kravene ligger i tokens og komponenter, gjør hver eneste sideoppbygging raskere. Beslutningene er allerede tatt, én gang, av noen som hadde tid til å ta dem riktig. Justeringer rulles ut ved å endre én verdi i stedet for å åpne hver komponent på nytt.
Det er den egentlige forskjellen. Tilgjengelighet som legges til på slutten blir gjeld. Tilgjengelighet som ligger i fundamentet blir fart.