Lage tilgjengelige løsninger med KI

KI-verktøy har gjort det mulig å bygge løsninger på en helt annen måte enn tradisjonell koding. Designere kan nå realisere egne ideer med en gang, uten å vente på utviklerressurser.

Dette har åpnet et helt nytt rom, og tilgjengeliggjort implementering av løsninger for langt flere enn bare utviklere. Dynamikken i team kan endres fundamentalt, og det åpner for en mer interessant måte å jobbe på.

Når validering ikke er nok

Men hvordan påvirkes universell utforming når alle kan bygge løsninger med KI? Universell utforming handler om å designe løsninger slik at de kan brukes av flest mulig, uavhengig av funksjonsevne.

WCAG er et sett med internasjonale retningslinjer som konkretiserer krav til digital tilgjengelighet, og brukes som målestokk for om en løsning oppfyller minstekravene.

Språkmodellene utvikler seg raskt, og vi etablerer flere styringsmekanismer som hever kvaliteten på løsningene. Det finnes verktøy som kan dekke mange WCAG-krav, og resultatene blir stadig bedre. Det avgjørende spørsmålet er likevel ikke bare om koden validerer, men om selve hovedløsningen unngår å skape nye og unødvendige barrierer for brukerne.

Med hovedløsning mener vi den grunnleggende måten noe fungerer på, selve kjernen i hvordan brukeren interagerer med løsningen. Universell utforming handler om å designe denne hovedløsningen slik at den kan brukes av så mange som mulig med ulike forutsetninger og funksjonsevne. Tilgjengelighet handler ofte om å gjøre eksisterende løsninger tilgjengelige gjennom tekniske tilpasninger og hjelpemidler. Skillet er viktig fordi det påvirker hvor vi legger innsatsen.

To perspektiver som sjelden møtes tidlig nok

Tradisjonelt har designer og utvikler jobbet med universell utforming fra hver sin kant.

Designeren har fokusert på visuell tilgjengelighet:

• tilstrekkelig kontrast mellom tekst og bakgrunn
• lesbar typografi
• tydelige klikkflater
• konsistent interaksjonsdesign

De har tenkt på layout som fungerer ved forstørring, fargebruk som ikke er eneste informasjonsbærer, og visuell hierarki som gir mening. Dette er blikket som ser løsningen gjennom brukerens øyne.

Utvikleren har jobbet med teknisk tilgjengelighet:

• semantisk HTML som gir mening for hjelpeteknologi
• tastaturnavigasjon som fungerer logisk
• skjermleserstøtte gjennom riktige attributter
• god dokumentstruktur

De har sikret at fokusrekkefølge er fornuftig, at skjemaer validerer og gir tilbakemeldinger på riktig måte, og at dynamisk innhold annonseres for hjelpeteknologi. Dette er blikket som ser løsningens indre struktur.

Når kompensasjon blir løsningen

I dag kan flere bygge løsninger som validerer og formelt sett er tilgjengelige. Men det som ikke kan automatiseres eller sjekklistes, er å vurdere om selve hovedløsningen skaper unødvendige barrierer. Begge fagfelt har vært viktige, men de har sjelden møttes tidlig nok. Designeren har levert et ferdig design, og utvikleren har implementert det med nødvendige teknikker for å gjøre det tilgjengelig.

Ofte har dette betydd å legge på lag etter lag med kompenserende kode dersom hovedløsningen ikke er godt nok gjennomtenkt. Ekstra attributter, skjulte elementer, omfattende tastaturhåndtering. Teknikken fungerer og koden validerer, men noe føles tungvint.

Årsaken er ofte at hovedløsningen skaper barrierer fra starten av. Mange utviklere kjenner følelsen av å legge på unødvendig mange teknikker for å gjøre en hovedløsning tilgjengelig, men har ikke alltid stoppet opp for å spørre om selve hovedløsningen kunne vært annerledes.

Innovasjon gjennom tidlig samarbeid

Dette perspektivskiftet krever at begge fagfelt er til stede tidlig. Når designere nå kan bygge fungerende løsninger selv, blir gapet mellom intensjon og implementering synlig raskere. Dette er hvor innovasjon oppstår. I stedet for å akseptere designet og kompensere med teknikk, kan de stille et annet spørsmål: Må løsningen fungere slik?

Designeren bringer forståelse for brukerens kontekst, opplevelse og visuelle behov. Utvikleren bringer forståelse for hva som er teknisk robust, enkelt å implementere og vedlikeholde. Sammen kan de identifisere når hovedløsningen selv skaper barrierer, og finne alternativer som er bedre for alle.

Når flere kan bygge løsninger, akselereres denne prosessen. Designere kan teste ideer raskere og få raskere tilbakemelding på tekniske konsekvenser. Flere iterasjoner betyr flere muligheter til å justere hovedløsningen før den settes i produksjon.

Ikke design ferdig og levér. Ikke bygg ferdig og godta. Iterér sammen, tidlig og ofte.

WCAG er et viktig fundament, men løsninger blir sjelden gode av å bare oppfylle minimumskrav. De blir gode når teamet tør å spørre: skaper denne løsningen unødvendige barrierer? Kunne vi tenkt annerledes?

Universell utforming handler ikke om å følge regler eller kompensere med teknikk, men om å bygge riktig fra starten. Og det gjør vi best sammen.