Uu-tilsynet advarer mot AI-bruk: «Risikerer ond sirkel»
– Utilgjengelig kode inn, utilgjengelig kode ut, skriver Jan Beniamin Kwiek i Uu-tilsynet. Sånn bryter du sirkelen.
Kurt Lekanger har helt rett: AI og vibbekoding kan gi oss enda flere nettsider fulle av <div>-er og null semantikk.
Men må det egentlig være sånn?
AI kopierer mønstrene du mater den med.
Får den div-ørken, lager den mer div-ørken.
Får den norsk WCAG-tolkning og konkrete eksempler fra Uu-tilsynet, kan den foreslå semantikk, alt-tekster og tastaturstøtte.
AI lærer av gamle feil
Problemet er ganske enkelt: AI læres opp på kode som vi utviklere har lagt igjen på nettet de siste ti-tjue årene.
Og la oss være ærlige – universell utforming har sjelden stått øverst på prioriteringslista. Dermed får AI servert tusenvis av eksempler på kode som:
- knapper laget som <div>-i stedet for <button>
bilder uten alt-tekst
- overskrifter med tilfeldig bruk av <span> eller <div>, i stedet for <h1>, <h2> , osv.
- skjema uten label-koblinger, der skjermlesere famler i blinde
interaktive elementer uten tastaturnavigasjon, fordi tab-index er glemt eller misbrukt
Når AI så prøver å «hjelpe» oss, gjenskaper den nøyaktig disse mønstrene. Vi risikerer en ond sirkel: utilgjengelig kode inn, utilgjengelig kode ut.
Vi risikerer en ond sirkel: utilgjengelig kode inn, utilgjengelig kode ut.
WCAG – nyttig, men tungt
WCAG og andre tilgjengelighets-standarder kan, som Kurt påpeker, hjelpe som materiale for diverse spørringer og kodehjelp.
Men la oss være ærlige; selv for erfarne utviklere kan WCAG føles som en labyrint av byråkratiske formuleringer. Det er viktig og riktig som grunnmur, men vanskelig å bruke direkte i hverdagen.
Spør du tusen forskjellige «tilgjengelighetseksperter», så får du tusen forskjellige tolkninger av hva «All funksjonalitet som bruker flerpunkt eller stibaserte gester for betjening, kan betjenes med en enkelt peker uten stibasert gest, med mindre flerpunkt eller en stibasert gest er avgjørende» egentlig betyr, og ikke få meg til å starte med «hva er et meningsbærende bilde» engang.
Når du sitter midt i en sprint og bare vil få skjemaet ditt til å fungere, hjelper det lite å lese setninger som «Navigasjonsmekanismer som er gjentatt på flere nettsider innenfor et sett av nettsider, forekommer i samme relative rekkefølge».
Det hjelper også lite ikke å gi denne informasjonen til AI-en som skal hjelpe deg, og visste du at, enda bedre, i Norge har vi en egen tolkning av WCAG som er det som er «norsk lov» for å være compliant?
Gøy, eller?
Uu-tilsynet – WCAG på «utviklerspråk»
Her er det vi bør tenke annerledes.
På uutilsynet.no har WCAG allerede blitt gjort mer praktisk. Vi i Uu-tilsynet har laget veiledning for utviklere der vi skriver om WCAG slik at du kjappere skal forstå hva det er. Her finner du konkrete eksempler som:
- hvordan legge til aria-label riktig på knapper
- hvordan strukturere overskrifter slik at skjermlesere forstår innholdet
- hvordan teste tastaturnavigasjon på en enkel måte
- hvordan lage skjema som faktisk gir mening når du bruker leselist
Dette er utviklerspråk – kort, forståelig og med eksempler, som du kan mate inn i AI’en som grunnlag, for så å få den til å hjelpe deg, med den norske tolkningen og alt. Plutselig kan den faktisk bli en hjelp i stedet for en byrde.
Da får vi en assistent som minner oss på tilgjengelighet i farta, og ikke bare spytter ut flere <div>-er.
La oss kjøre en liten, uformell prompt-duell!
Prompt 1 WCAG-skjema-output:
Prompt 2 Uu-tilsynet-skjema-output:
Selv om den eneste forskjellen i prompten er hvilken kilde som ble brukt, er resultatet i koden ganske ulikt. I versjonen av skjemaet som kun benyttet WCAG-standarden som kilde, ble det brudd på flere testregler:
- 3.3.2a: Inndataelementer har instruksjon eller ledetekst. Dette er et brudd fordi obligatoriske felt ikke vises visuelt.
- 3.3.3a: Skjema gir forslag til retting dersom feil oppdages automatisk. Dette er et brudd fordi brukeren ikke får forslag til korrigering når det legges inn bokstaver i nummerfeltet eller tall i navnefeltet.
- 3.3.1b: Skjema gir feilmelding når ugyldig inndata oppdages automatisk. Dette er et brudd fordi brukeren ikke får feilmelding ved innlegging av bokstaver i nummerfeltet eller tall i navnefeltet.
Skjemaet som i stedet bygget på Uu-tilsynets veiledning, strøk derimot på 2.4.7: Innhold som kan brukes med tastatur skal ha synlig fokusmarkering. Dette er brudd fordi end-knappen har for dårlig fokusmarkering ved tastaturnavigasjon.
Dette er ikke nødvendigvis bevis for noe mer enn det Kurt påpeker: Utviklere må fortsatt bruke eget faglig skjønn. Samtidig kan det likevel indikere at valg av kilde har stor betydning for hvordan resultatet blir.
Fra risiko til mulighet
Vibbekoding er en reell fare, ja.
Men AI trenger ikke være synderen.
Med riktig input og god kildebruk kan AI bli en nyttig kollega som:
- sier fra når du har glemt alt-tekst
- foreslår semantiske elementer i stedet for generiske <div>
- lager deg gode tilgjengelige skjema
- gir deg konkrete tips hentet rett fra uutilsynet.no
AI kan bli en viktig hjelper for tilgjengelighet – hvis vi lærer den å bruke riktige og forståelige kilder.
Konklusjon
AI kommer ikke til å erstatte hodene våre. Vi må fortsatt tenke selv, og ta bevisste valg som utviklere (enn så lenge).
Men hvis vi gir AI de riktige ressursene, kan vi gjøre tilgjengelighet til en naturlig del av utviklerhverdagen – ikke et skippertak før lansering.
Så ja, vibbekoding kan skape mer utilgjengelig kode.
Men det kan også bli starten på bedre praksis.
AI kan bli en viktig hjelper for tilgjengelighet – hvis vi lærer den å bruke riktige og forståelige kilder. Inntil da handler det fortsatt om det samme: å bruke hodet, ta ansvar – og skrive kode alle kan bruke.
