Hvad er webtilgængelighed? WCAG og inklusivt design forklaret

Webtilgængelighed betyder at bygge hjemmesider og apps, så mennesker med handicap kan bruge dem — uanset om de er blinde og bruger en skærmlæser, ikke kan bruge en mus, har nedsat syn eller farveblindhed, er døve eller har kognitive eller læringsmæssige handicap. I praksis handler det om ting som tekstalternativer til billeder, nok farvekontrast, formularer med ordentlige labels, og at alt virker med kun tastaturet. Den internationale standard er WCAG, Web Content Accessibility Guidelines fra W3C.

Tilgængelighed forkortes ofte til a11y — »a«, derefter 11 bogstaver, derefter »y«.

Hvorfor tilgængelighed betyder noget, når du bygger med AI

AI-builders er gode til at lave apps, der ser rigtige ud. Tilgængelighed handler mest om det, du ikke kan se på et skærmbillede: om en knap virkelig er en knap, om et input har en label, en skærmlæser kan læse op, og om du kan nå menuen med Tab-tasten.

Derfor er det vigtigt at spørge:

• Det er let at overse. En tilpasset dropdown kan se perfekt ud og være umulig at bruge uden mus. Du bemærker det ikke, medmindre du tester for det.
• Det er billigere at få rigtigt tidligt. At bede om tilgængelige komponenter fra første prompt koster næsten ingenting. At eftermontere en færdig app betyder at røre ved hver skærm.
• Det hjælper alle. Undertekster hjælper folk i støjende omgivelser, god kontrast hjælper folk på telefoner i solskin, og tydelige labels hjælper alle med at udfylde formularer hurtigere.
• Det overlapper med SEO. Ordentlige overskrifter, beskrivende links og alt-tekst hjælper også søgemaskiner med at forstå dine sider — se SEO for AI-byggede hjemmesider.
• Det kan være et krav. Afhængigt af hvor du opererer og hvem du betjener, kan tilgængelighed være en juridisk forpligtelse.

En hverdagsanalogi

Tænk på indgangen til en bygning.

Trapper fungerer fint for mange mennesker. En rampe fungerer for kørestolsbrugere — og også for forældre med barnevogne, leveringsfolk med vogne og rejsende med kufferter. Automatiske døre, tydelige skilte, punktskrift på elevatorknapper og god belysning fjerner hver især en barriere for nogen.

Webtilgængelighed er den samme idé for digitale rum: rampene, skiltene og rækværkerne i din app. Og ligesom med en bygning er det langt lettere at tegne en rampe ind i planerne end at sætte en på, når betonen er støbt.

WCAG i et nøddeskal

WCAG udgives af W3C's Web Accessibility Initiative. Den aktuelle version er WCAG 2.2, første gang udgivet i oktober 2023. Den er bagudkompatibel: indhold, der opfylder WCAG 2.2, opfylder også 2.1 og 2.0, og W3C opfordrer til at bruge den nyeste version. WCAG 2.2 er også godkendt som international standard, ISO/IEC 40500:2025. En helt anden WCAG 3 er under udvikling som et tidligt udkast, ikke en færdig standard.

WCAG er organiseret under fire principper, ofte husket som POUR:

Hver retningslinje har testbare succeskriterier på tre niveauer:

• Niveau A — minimum. At fejle disse blokerer for nogle mennesker helt.
• Niveau AA — den almindelige målsætning og det niveau, de fleste love og politikker henviser til.
• Niveau AAA — det højeste niveau. Nyttigt at sigte efter visse steder, men W3C anbefaler ikke at kræve det for hele sites, fordi noget indhold ikke kan opfylde det.

WCAG 2.2 tilføjede ni succeskriterier til 2.1, herunder Target Size (Minimum) på niveau AA — klikbare mål bør generelt være mindst 24 gange 24 CSS-pixels, med undtagelser — og Accessible Authentication (Minimum), som begrænser login-trin, der bygger på hukommelse eller puslespil, fx at skulle genindtaste en adgangskode uden at måtte indsætte den. Den fjernede også det gamle »Parsing«-kriterium, fordi det var forældet.

Et praktisk eksempel: en tilmeldingsformular

Her er en tilmeldingsformular, en AI kunne producere, og hvad et tilgængelighedstjek finder:

Ingen af disse rettelser ændrer meget ved, hvordan formularen ser ud. Alle ændrer, om nogle mennesker overhovedet kan bruge den.

Vigtige termer

Almindelige misforståelser

• »Tilgængelighed betyder kun noget for blinde brugere.« Det dækker synshandicap, motoriske, hørsels-, tale- og kognitive handicap plus midlertidige situationer som en brækket arm.
• »Tilgængelige sites ser kedelige ud.« Tilgængelighed begrænser et par ting — kontrast, fokusstile, tekststørrelse — men flotte tilgængelige sites er normen, ikke undtagelsen.
• »Et automatisk tjek siger 100, så vi er færdige.« Automatiske værktøjer fanger kun nogle problemer. Om alt-tekst faktisk er meningsfuld, eller om et flow giver mening med en skærmlæser, skal et menneske vurdere.
• »En overlay-widget gør os compliant.« Værktøjslinjer skruet oven på kan ikke rette manglende labels eller ødelagt tastaturadgang i din kode. Ret kilden.
• »Vi har ingen brugere med handicap.« Du ved måske bare ikke det. Mange handicap er ikke synlige, og folk, der støder på en barriere, forlader typisk blot siden.

Hvad du beder din AI-builder om

• »Byg dette, så det opfylder WCAG 2.2 niveau AA.«
• »Brug semantisk HTML: rigtige knapper, links, overskrifter i rækkefølge og labels til hvert formularfelt.«
• »Sørg for, at alle interaktive elementer virker med kun tastaturet og har en synlig fokusstil.«
• »Tjek al tekst- og ikonfarve for kontrast — 4,5:1 for almindelig tekst, 3:1 for stor tekst og ikoner.«
• »Tilføj meningsfuld alt-tekst til informative billeder og tom alt-tekst til dekorative.«
• »Vis formularfejl som tekst, forbundet til feltet, ikke kun med farve.«
• »Respekter brugerens indstilling for reduceret bevægelse ved animationer.«
• »Kør et automatisk tilgængelighedstjek, og list hvad det ikke kan teste, så jeg kan tjekke det manuelt.«

Test derefter selv: læg musen væk, og prøv at gennemføre dit vigtigste flow med kun Tab, Shift+Tab, Enter og mellemrum. Prøv telefonens indbyggede skærmlæser på forsiden. Zoom browseren til 200 % og se, om noget går i stykker.

Tilgængelighed i Mythex

Mythex indeholder ikke et dedikeret tilgængelighedstjek, så behandl tilgængelighed som en del af dine prompts og din test. Bed om WCAG 2.2 AA fra første prompt, tjek resultatet i Preview med tastaturet, og brug /test til at lade agenten klikke sig igennem dine vigtigste flows, før du udruller — se App Testing. SEO-opskriften beder også om semantiske overskrifter og meningsfuld alt-tekst, som tjener begge mål.

For en praktisk tjekliste, se sådan gør du dit website tilgængeligt. Til design, læs sådan designer du en flot app med AI, og før lancering, sådan tester du din app inden lancering. W3C's egen WCAG-oversigt er den autoritative kilde.

Spørgsmål