Kunstig intelligens i tilgjengelighet og inkluderende design

Gevinster:

• Evne til å kontrollere og forbedre fargekontrast, alternativ tekst, tastaturtilgang og WCAG-kriterier med støtte for kunstig intelligens
• Evne til å generere og verifisere tilgjengelighetstekster som skjermleseropplevelse, alt-tekst og skjemaetiketter med kunstig intelligens
• Forstå grensen for å validere AIs tilgjengelighetsanbefalinger med ekte hjelpeteknologi og brukertesting

Tilgjengelighet (a11y for kort) er evnen til et produkt til å brukes av alle, inkludert personer med nedsatt funksjonsevne: en synshemmet bruker kan navigere med en skjermleser (hjelpeprogramvare som konverterer tekst til tale), en person med motoriske vanskeligheter kan gjøre hva som helst med et tastatur, en fargeblind person kan motta informasjon uten å stole på farger. Inkluderende design er bredere: det setter menneskelig mangfold i sentrum av design, inkludert alder, språk, kultur, midlertidig funksjonshemming (brukt arm) eller kontekstuell funksjonshemming (skjerm i solen). Tilgjengelighet er ikke et «ekstra», men et grunnleggende ansvar og et lovkrav i de fleste land. AI er en kraftig prescreener og trekkgenerator på dette feltet; men ekte tilgjengelighet bekreftes bare av faktisk hjelpeteknologi og brukertesting.

WCAG og nøkkelkontrollområder

WCAG (Web Content Accessibility Guidelines) er et sett med internasjonalt aksepterte kriterier for tilgjengelighet; AA-nivå er generelt målrettet. Den har fire prinsipper: innholdet skal være oppfattelig, grensesnittet skal være brukbart, informasjonen skal være forståelig og teknisk forsvarlig. De vanligste kontrollområdene i praksis er:

• Fargekontrast: Er forskjellen mellom tekst og bakgrunn tilstrekkelig? (For AA, minst 4,5:1-forhold i normal tekst.)
• Alternativ tekst (alt tekst): Har bildene en tekstekvivalent som forklarer dem for skjermleseren?
• Tastaturtilgang: Kan alt gjøres uten mus? Gir fokusrekkefølgen mening?
• Kun fargeinformasjon: Fraser som "Fyll ut røde felt" ekskluderer den fargeblinde brukeren.
• Skjemaetiketter: Har hvert inndatafelt en etikett som skjermleseren vil lese?
• Berøringsmål: Er knappene store nok til å kunne trykkes komfortabelt med fingrene?

AI kan gjøre en rask foreløpig skanning i mange av disse områdene: du kan gi litt tekst og spørre "er kontrasten tilstrekkelig?", gi en bildebeskrivelse og spør "foreslå alternativ tekst", gi en grensesnittbeskrivelse og spørre "hva er problemer med tastaturtilgang".

Forsiktig: Bare fordi AI sier "det ser tilgjengelig ut" er ikke en garanti for tilgjengelighet. Den automatiske sjekken fanger bare opp noen av WCAG-feilene; Resten vil dukke opp ved faktisk bruk.

Alt-tekst: hemmeligheten bak god alt-tekst

Alt tekst erstatter bildet for synshemmede brukere. God alt-tekst formidler funksjonen og betydningen av bildet, ikke dens dekorative detalj. Alt-teksten for et "legg til i handlekurv"-ikonet skal være "Legg i handlekurv" og ikke "handlekurvbilde" fordi det er handlingen som betyr noe for brukeren. AI er god til å generere undertekstkonturer, men fordi den ikke kjenner konteksten, kan den produsere altfor beskrivende eller irrelevant tekst. Du spør hver alternativ tekst "hvorfor er dette bildet her?" Beskjær med spørsmålet.

visuelle

Svak undertekst

Sterk undertekst

Handlevognikon (knapp)

"Kurvikon, grå farge"

"Legg i handlekurv"

produktbilde

"bilde"

"Blå vinterfrakk, sett forfra"

dekorativ linje

"Ornament linje"

(la stå tomt - dekorativt)

Grafikk

"Grafisk bilde"

"2024-salg: øker hvert kvartal"

Inkluderende språk og omfang

Tilgjengelighet er ikke begrenset til tekniske kontroller; Språk er også inkluderende. Tekst som antar kjønn («brukeren og hans/hennes ektefelle»), ekskluderer basert på evner («blikk», «lett å høre»), eller inneholder kulturelle forutsetninger, vil ekskludere noen brukere. AI kan skanne teksten fra dette perspektivet, men du må sørge for at det "nøytrale" språket det foreslår forblir naturlig og forståelig; Overkorrigering kan gjøre teksten vanskelig.

tre minisaker

Tilfelle 1 — Kontrastfeil fanget opp tidlig. Et team fikk AI til å skanne tekstfargene på 20 skjermer og fant ut at kontrasten var under AA-terskelen på 7 steder. Rettelsene ble gjort uten å gå i utvikling; kostnadene ved etterfølgende korreksjon ble unngått. Men teamet hoppet fortsatt ikke over selve skjermlesertesten.

Tilfelle 2 — Bare fargerelatert informasjon ble korrigert. Ett skjema viste bare feilfelt med rød kant. AI flagget dette; Teamet la også til tekst og ikoner til hver feil. Fargeblinde brukere kunne nå se feilen. Leksjon: farge alene kan ikke formidle informasjon.

Sak 3 – AI villedet godkjenning. En designer hoppet over skjermlesertesting fordi han kalte AI "tilgjengelig." I den virkelige testen viste det seg at fokusrekkefølgen var forvirret og enkelte knapper ble ikke lest i det hele tatt. Leksjon: automatisk bekreftelse er begynnelsen; faktisk hjelpemiddeltesting er obligatorisk.

Kopiérbare spørsmål

Forhåndsskann denne grensesnittbeskrivelsen for tilgjengelighet:1) er det informasjon som utelukkende er basert på farge?2) er det en tekstetikett for hvert klikkbart element?3) er det noen elementer som ikke kan nås via tastaturet?4) gir fokusrekkefølgen mening? List opp hvert problem og forslag. Legg til merknad "Reell test nødvendig". Oppskrift: <<tekst>>

Foreslå alternativ tekst for disse bildene. Regel: formidle FUNKSJONEN/betydningen av bildet, ikke den dekorative detaljen. Skriv handlingen for knappikoner. For dekorative bilder, si "alt tekst skal stå tom". Kontekst- og bildebeskrivelser: <<liste>>

Sjekk disse tekstene for inkluderende språk: finnes det kjønnsantakelser, evnebasert ekskluderende språk (som «se», «høre»), kulturelle forutsetninger? Foreslå alternativer som forblir naturlige; ikke overkorriger. Tekster: <<liste>>

Skriv tilgjengelig feil og etiketttekst for dette skjemaet: synlig etikett for hvert felt, beskrivelse for skjermleseren og melding som beskriver feilen, uavhengig av farge (tekst + ikon). Stemme og tone: <<kort>>Skjemafelt: <<liste>>

Svak forespørsel / Sterk forespørsel

Svak: "Skriv alternativ tekst for dette bildet."

Resultatet: "Et bilde" eller altfor beskrivende tekst som mangler funksjonen.

Sterkt: "Foreslå alt-tekst for disse bildene; formidle funksjonen/betydningen av bildet; skriv handlingen for knappikoner; merk dekorative som 'må stå tomme'."

Resultatet: Kontekstuelle, funksjonsorienterte, nøyaktige undertekster.

Forskjell: sterk melding gir funksjonelt fokus + knappekonvensjon + dekorativ distinksjon.

Vanlige feil

• Ta feil av godkjenning av kunstig intelligens som en garanti for tilgjengelighet. Det er ikke en erstatning for ekte testing.
• Bare laster informasjon i farger. Fargeblinde brukere savner informasjon.
• Forklarer bildet, ikke funksjonen, i alt-teksten. En handling må skrives for knappikonet.
• Forlater tilgjengeligheten til sist. Hvis den ikke startes på wireframe-stadiet, vil det være dyrt å lappe den senere.
• Overkorrigert språk. Inkluderende språk som mister naturlighet svekker også forståelighet.

Oppsummert

Tilgjengelighet betyr at produktet er tilgjengelig for alle; Det er ikke en ekstra, det er et vesentlig og, de fleste steder, et juridisk ansvar. AI er verdifull som en rask preflight- og kladdgenerator for kontrast, alternativ tekst, tastaturtilgang og inkluderende språkskanning. Men automatisk godkjenning fanger bare opp noen av WCAG-feilene; Faktisk tilgjengelighet bekreftes ved testing med skjermlesere og reelle hjelpemiddelbrukere. Bruk modellen som en frontnettleser, få beviset fra ekte testing.

Søknadsoppgave

1. Forhåndsskann en grensesnittbeskrivelse for tilgjengelighet ved første melding.
2. Korriger kun fargebasert informasjon eller umerkede elementer.
3. Generer funksjonsorienterte alt-tekster for det visuelle på skjermen med den andre ledeteksten.
4. Sjekk tekstene dine for inkluderende språk med den tredje ledeteksten.
5. Hvis mulig, prøv selve testen med en skjermleser og legg merke til hva den automatiske skanningen går glipp av.

sjekkliste

• [ ] Jeg forhåndsskannet kontrast, tastaturtilgang og etiketter.
• [ ] Jeg la ikke informasjon basert utelukkende på farge.
• [ ] Jeg skrev undertekstene på en funksjonell måte og lot de dekorative stå tomme.
• [ ] Jeg laget en inkluderende språkkontroll, jeg bevarte naturligheten.
• [ ] Jeg anså ikke automatisk godkjenning som en garanti for tilgjengelighet.
• [ ] Jeg planla/implementerte faktisk hjelpemiddeltesting.