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
labeltil skjemaelementer (WCAG 1.3.1) - Utilstrekkelig fargekontrast (WCAG 1.4.3)
- Manglende
titlepå sider (WCAG 2.4.2) - Tomme eller uklare lenker (WCAG 2.4.4)
- Manglende
aria-labelelleraria-labelledbypå 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:
- 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. - Legg til ARIA Live Regions: Hvis AI genererer ny innhold i en chat, en varselboks, eller en resultatliste, må du bruke
aria-live="polite"elleraria-live="assertive". Uten dette, vil skjermlesere ikke fortelle brukeren at noe har endret seg. - 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.
- 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.
- 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:
- Legg inn axe-core eller Pa11y i din CI/CD-pipeline. La den stoppe byggingen hvis det finnes en enkel WCAG-feil.
- Sett opp en enkel testprosess: hver gang en ny komponent genereres, må en person teste den med en skjermleser i 5 minutter.
- 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.
Kan automatiserte verktøy alene sikre WCAG-konformitet i AI-genererte grensesnitt?
Nei. Automatiserte verktøy kan bare oppdage om tekniske elementer eksisterer - som om en alt-tekst er til stede eller om fargekontrasten er over 4,5:1. De kan ikke vurdere om alt-teksten gir mening, om navigasjonen er logisk, eller om en knapp virkelig fungerer med en skjermleser. Bare 25 % av WCAG Level A-feil og 17 % av Level AA-feil blir oppdaget av automatiserte verktøy. Resten krever menneskelig vurdering og brukertesting.
Hva er de vanligste tilgjengelighetsproblemene i AI-genererte grensesnitt?
De vanligste problemene er: manglende eller meningsløse alt-tekster, manglende semantisk HTML (f.eks. bruk av div istedenfor button), ingen støtte for tastaturnavigasjon, manglende ARIA-live-regioner for dynamisk innhold, og uklar fargekontrast. AI-genererte grensesnitt har også en tendens til å legge til for mye dynamisk innhold uten å varsle skjermlesere - noe som gjør det umulig for brukere med nedsatt syn å følge med.
Hva er ARIA live regions, og hvorfor er de viktige?
ARIA live regions er attributter som forteller skjermlesere når innhold på siden endrer seg uten at brukeren har gjort noe. For eksempel, hvis en AI-chat legger til et nytt svar, må du bruke aria-live="polite" for å sikre at skjermleseren leses opp det nye innholdet. Uten dette, vil brukeren ikke vite at noe har endret seg - og det kan føre til at de mister kontrollen over hva som skjer på siden.
Hvorfor er manuell testing med skjermlesere nødvendig?
Automatiserte verktøy kan ikke forstå kontekst. De kan ikke si om en alt-tekst som sier «en person» er tilstrekkelig når bildet viser en person som bruker en rullestol. De kan ikke si om en knapp som ser ut som en knapp faktisk er en knapp. Bare en person som bruker en skjermleser hver dag kan oppdage disse problemene. Manuell testing er ikke et valg - det er en nødvendighet.
Hva er de beste verktøyene for å teste WCAG-konformitet i AI-generert UI?
For automatisert testing: axe-core og Pa11y er de mest pålitelige. For manuell testing: bruk NVDA (Windows), VoiceOver (macOS/iOS), og TalkBack (Android). For alt-tekst-generering: Microsoft Azure Cognitive Services og Google Cloud Vision, men alltid med manuell gjennomgang. For integrasjon i byggepipeline: Replay.build er et nytt verktøy som genererer både UI og tilgjengelig kode fra skjermopptak.
Post Comments (7)
ikkje forstå kva som skjer med alle dei her AI-sakene-no har eg prøvd å bruke ein side med ein alt-tekst som seier «ein person» og det er ikkje nok. eg er blind, og eg treng meir enn eit ord. kva for ein person? kva gjør han/hon? er det nokon som tenkjer på dette før dei deploier?
Det er viktig å understreke at tilgjengelighet ikkje er eit ekstra krav-det er ein grunnleggende rett. AI kan generere innhald, men det er menneskeleg forståing som gjer det gyldig. Eg har jobba med brukarundersøkingar i 15 år, og kvart år blir det tydelegare at tekniske sjekkar ikkje er nok. Ein alt-tekst må fortelje kva bildet formål er, ikkje kva det ser ut som. Det er ikkje ein detalj-det er essensen av tilgjengelighet.
Vi må slutte å tenke på tilgjengelighet som ein teknisk oppgåve og starte med å sjå det som ein etisk forpliktelse. Når vi gjer det, blir løysingane meir menneskelege.
Det er feil å tro at automatiserte verktøy er utilstrekkelige. Dei er perfekte for å fange systematiske feil-manglende alt-tekster, feil fargekontrast, manglende ARIA-attributt. Det er ikkje verktøya si feil at dei ikkje kan tolke kontekst. Det er utviklarane sine. Hvis ein AI genererer ein div med ein klikk-event og ingen label, er det ein feil i prompten, ikkje i axe-core. Vi må fokusere på å forbedre input, ikkje klagge på output.
Verktøy som Pa11y og axe-core burde vere standard i alle CI/CD-pipelines. Alt anna er uansvarleg utvikling. Menneskelig testing er nyttig, men det er ingen erstatning for strukturert, automatisert sikkerhet.
haha ja altså, AI genererer ein knapp som ser ut som ein knapp, men er bare ein div. så skjermlesaren går «div, div, div» og så er du borte. eg prøvde ein chatbot sist og den sa «ny melding» 17 gonger utan at eg kunne skrive svar. det er ikke teknologi. det er ein skikkelig katastrofe. vi må stoppe å la AI lage grensesnitt utan ein menneske som siterer «nei, det der fungerer ikkje».
Jeg vil understreke at ARIA live regions er en av de mest oversete, men kritiske, komponentene i AI-genererte grensesnitt. Når en chatbot legger til et nytt svar, og det ikke er signalert til skjermleseren, blir brukeren liggende i en uendelig løkke av forvirring. Dette er ikke et spørsmål om «gode praksiser»-det er en teknisk nødvendighet. Hvis du bruker React, Vue, eller andre rammeverk, så er det en enkel prop å legge til. Ikke la AI gjøre det for deg. Skriv det selv. Test det. Dokumenter det. Det er ikke vanskelig-det er bare viktig.
Det samme gjelder for tastaturnavigasjon. Jeg har sett nettsteder med 50 interaktive elementer, men kun 5 av dem var tilgjengelige med Tab. Det er ikke en feil i koden. Det er en feil i designprosessen. AI må lære å generere semantisk HTML, ikke bare visuelt tiltalende div-er.
La oss være ærlige: AI-genererte grensesnitt er bare en ny måte å ekskludere folk på. De fleste selskaper bruker AI fordi det er billig, ikke fordi det er bra. Og så legger de på en liten «tilgjengelighetstest» for å kunne si at de er «inkluderende». Men ingen tester med folk som faktisk bruker rullestol, eller har kognitive utfordringer, eller er fargeblinde. Det er bare en skikkelig skuffelse. Det er ikke teknologi som er problemet-det er kapitalisme.
Replay.build? Haha. Det er bare en annen løsning som tar penger fra folk som trenger hjelp, og gir dem en falsk trygghet. Vi trenger mer enn verktøy. Vi trenger politisk vilje. Og ingen har den.
hvorfor snakker alle om WCAG? det er bare en stor bedrift som vil ha kontroll. AI er bedre enn mennesker. du tror at en person med nedsatt syn vil ha lyst til å høre en lang alt-tekst om en kopp kaffe? neida. AI kan si «varm kaffe» og det er nok. alle mennesker som sier «det må være menneskelig» er bare redd for å bli erstattet. vi trenger mindre testing, mer AI. og mindre WCAG. det er bare en politisk felle.