Prompting for Accessibility: Sjekk av WCAG-konformitet i generert brukergrensesnitt

Det er ikke nok å generere et brukergrensesnitt med AI og tro at det er tilgjengelig. Mange tror at hvis en kode har alt som ser ut til å være riktig - en alt-tekst, en label, en fargekontrast - så er alt greit. Men det er ikke sant. En AI kan generere en alt-tekst som sier «bilde av en person», men hvis bildet viser en kvinne som bruker en hjelpemiddel for å gå, og alt-teksten ikke nevner det, så er den ikke tilgjengelig. Den er bare teknisk korrekt. Og det er her problemet ligger.

Hva er WCAG, og hvorfor gjelder det for AI-genererte grensesnitt?

WCAG, eller Web Content Accessibility Guidelines er en internasjonal standard for tilgjengelighet av webinnhold, utviklet av World Wide Web Consortium (W3C), består av fire prinsipper: Perceivable (oppfattelig), Operable (bruksvennlig), Understandable (forståelig) og Robust (robust). Disse prinsippene er ikke bare gode råd - de er krav. Og når AI genererer hele grensesnitt, må disse prinsippene bygges inn fra starten, ikke legges til etterpå.

En AI kan generere en side med 50 knapper, 12 skjemaer og 30 bilder på 10 sekunder. Men kan den forstå at en knapp som kun har en ikon og ingen tekst er umulig å bruke for en bruker som ikke ser? Kan den vite at en farge med kontrast 3:1 er utilstrekkelig for folk med fargeblindhet? Nei. Den kan bare sjekke om det er en alt-tekst. Ikke om den gir mening.

Hva kan automatiserte verktøy faktisk oppdage?

Automatiserte verktøy som axe-core er et åpen kildekode-verktøy som skanner HTML for tekniske WCAG-overtrædelser, Pa11y er et verktøy for automatisert tilgjengelighetstesting som kan integreres i CI/CD-pipeline, eller Microsoft Azure Cognitive Services tilbyr automatisk generering av alt-tekst for bilder basert på bildeanalyse kan finne en rekke tekniske feil:

• Manglende alt-tekst på bilder (WCAG 1.1.1)
• Manglende label til skjemaelementer (WCAG 1.3.1)
• Utilstrekkelig fargekontrast (WCAG 1.4.3)
• Manglende title på sider (WCAG 2.4.2)
• Tomme eller uklare lenker (WCAG 2.4.4)
• Manglende aria-label eller aria-labelledby på interaktive elementer

Disse feilene er enkle å finne. De er i koden. De er målbare. Og de kan skannes i sekunder. Men her kommer problemet: disse verktøyene finner bare 25 % av alle WCAG Level A-feil og 17 % av Level AA-feil, ifølge Ada Compliance Pros 2025. Det betyr at over 75 % av tilgjengelighetsproblemene blir stående uoppdaget.

Hvorfor kan automatiserte verktøy ikke finne de viktigste problemene?

Automatiserte verktøy ser på kode. De ser ikke på opplevelse. De kan ikke svare på spørsmål som:

• Er alt-teksten «bilde av en kaffe» riktig når bildet viser en kopp med damp og en skje, og brukeren trenger å vite at det er en kaffe som er for mye varm?
• Er navigasjonen logisk når en bruker med skjermleser går gjennom en AI-chat som genererer nye svar i en uendelig løkke?
• Hva skjer når en ny melding dukker opp i en chatboks uten at skjermleseren får beskjed om at noe har endret seg?
• Er en knapp som ser ut til å være en «send»-knapp faktisk en knapp, eller bare en div med en farge?

Disse spørsmålene krever menneskelig forståelse. De krever at noen sitter med en skjermleser og prøver å bruke grensesnittet. De krever at noen med fargeblindhet ser på fargene og sier: «Jeg kan ikke se forskjellen.»

Hva må du gjøre for å sikre tilgjengelighet i AI-generert UI?

Det finnes ingen enkel løsning. Men det finnes en god prosess. Den ser slik ut:

1. Bygg med semantisk HTML: AI-modeller må generere <nav>, <main>, <button>, <input> - ikke bare <div> med klikk-event. Et <button> er tilgjengelig av seg selv. En <div> med en klikk-event er ikke.
2. Legg til ARIA Live Regions: Hvis AI genererer ny innhold i en chat, en varselboks, eller en resultatliste, må du bruke aria-live="polite" eller aria-live="assertive". Uten dette, vil skjermlesere ikke fortelle brukeren at noe har endret seg.
3. Sjekk tastaturnavigasjon: Alle elementer må være tilgjengelige med Tab og Enter. Test det. Ikke bare sjekk om fokus er synlig - sjekk om du kan navigere gjennom hele grensesnittet uten mus.
4. Test med ekte skjermlesere: Bruk NVDA (Windows), VoiceOver (macOS/iOS), eller TalkBack (Android). Ikke bare bruk en simulator. En simulator kan si «alt er greit», mens en ekte bruker med nedsatt syn ser en uleselig liste.
5. Review alle AI-genererte alt-tekster: Azure og Google Cloud kan generere alt-tekst, men de gir ofte «en person» eller «et bord». Du må ha en menneskelig sjekk her. En alt-tekst skal fortelle hva bildet gjør, ikke bare hva det ser ut som.

Hva er den beste tilnærmingen?

Den eneste pålitelige metoden er en hybrid tilnærming:

• Automatisert: Bruk verktøy som axe-core og Pa11y i din byggepipeline. La dem fange de enkle feilene før du deploier.
• Manuell: Ha en tilgjengelighetsansvarlig som går gjennom hver ny generert komponent. Ikke bare sjekk koden - prøv den med en skjermleser.
• Brugertesting: Engasjér brukere med nedsatt funksjonsevne. Ikke bare «test med noen som har dårlig syn» - finn folk som faktisk bruker skjermlesere hver dag. De vil finne feil du ikke kan forestille deg.

Replay.build er et nytt verktøy som tar en skjermopptak av et grensesnitt og genererer både kode og tilgjengelig versjon av den samme løsningen. Det er ikke perfekt - men det viser veien. AI kan ikke bare generere UI. Den må også sjekke den.

Hva skjer hvis du ikke gjør dette?

Det er ikke bare et teknisk problem. Det er et etisk problem. Hvis du leverer et grensesnitt som ser bra ut, men som en person med nedsatt syn ikke kan bruke, så har du ikke bygd et tilgjengelig produkt. Du har bygd et produkt som ekskluderer.

Det er også et juridisk problem. I Europa, USA, og mange andre land, er tilgjengelighet en lovpliktig krav. WCAG er ikke et råd - det er en standard som brukes i dommerdommer. En bedrift som leverer et UI som ikke er tilgjengelig, kan bli siktet for diskriminering.

Hvordan starter du?

Hvis du nå jobber med AI-genererte grensesnitt, her er de tre første stegene:

1. Legg inn axe-core eller Pa11y i din CI/CD-pipeline. La den stoppe byggingen hvis det finnes en enkel WCAG-feil.
2. Sett opp en enkel testprosess: hver gang en ny komponent genereres, må en person teste den med en skjermleser i 5 minutter.
3. Legg til en kravliste: «Ingen alt-tekst uten manuell godkjenning. Ingen interaktive elementer uten tastaturnavigasjon. Ingen dynamisk innhold uten aria-live.»

Det handler ikke om å gjøre det perfekt. Det handler om å ikke ignorere det. Fordi når du ignorerer tilgjengelighet i AI-genererte grensesnitt, så ignorerer du mennesker. Og det er ikke teknologi. Det er uansvarlig.