WCAG 2.2-kontrolliste for AI-genereret UI

Hvad WCAG 2.2 ændrede for genereret UI

WCAG 2.2 bygger på 2.1 og tilføjer ni succeskriterier rettet mod mobile, lavsyns- og mobilitetsbehov. Det blev en W3C-anbefaling i oktober 2023; hold den normative tekst åben, mens du gennemfører en revision (w3.org/TR/WCAG22). For teams, der leverer AI-genererede komponenter, er tilføjelserne, der betyder mest, Fokus Ikke Skjult (2.4.11), Trækbevægelser (2.5.7), Mål Størrelse Minimum (2.5.8), Konsistent Hjælp (3.2.6), Redundant Indtastning (3.3.7) og Tilgængelig Autentificering (3.3.8). De fleste produktorganisationer sigter mod niveau AA. WAI's grundlæggende sider rammer stadig, hvorfor disse regler findes ud over "bestå scanneren" (WAI Accessibility Fundamentals).

Generatorene fejler her, fordi de optimerer for visuel tæthed og klik-demo-polering. De mindsker ikonernes rammeområder, opfinder træk-alene kanban-boards, stablet fast chrome, der dækker fokuserede felter, og spredte ARIA-roller, der ikke matcher adfærd. Kontrollisten nedenfor er sorteret for en frigivelsesdagsgodkendelse: målbare punkter først, vurderingspunkter anden.

Trin-for-trin-arbejdsgang før du frigiver

- Frys den genererede gren. Stop ikke med at regenerere, mens du måler. - Kør en automatiseret tilgængelighedsscan (axe, Lighthouse eller din CI-port) og arkiver hver kontrast / manglende-navn / ugyldig-ARIA-træf. - Gennemgå WCAG 2.2 Quick Reference-filtre for niveau AA og markér de 2.2-kriterier, der kun er eksplisitte rækker i din billet. - Tastaturkunstnerisk pas på hver primær brugerrejse (tilmelding, betaling, kerneopgave). - Skærm-læser-punktsjek (NVDA på Windows eller VoiceOver på macOS) på ikonknappe og dialoger. - Optegn resterende risiko: hvad scanneren ikke kan se, hvad du har udsat, hvem ejer opfølgningen.

A11yGuard er bygget til den målbare første pas. Juridisk overensstemmelse og vurderingsbeslutninger kræver stadig en menneskelig QA-ejer. Hvis dit produkt bruger AI i rekruttering eller lignende beslutningsflader, læs også den amerikanske vejledning om algoritmer og handikapdiskrimination, så UI-eksklusion ikke behandles som en kosmetisk fejl (ADA.gov AI-vejledning).

Kontrast du kan beregne, kontrast du ikke kan

Tekstkontrast er den letteste fejl at fange: brødtekst kræver 4,5:1 mod dens baggrund; stor tekst kræver 3:1 (kriterium1.4.3). Genererede temaer sender ofte grå-på-grå eller placeholder-gradueringer, der fejler. Mål mod den renderede baggrund, herunder billeder og overlæg.

Ikke-tekstkontrast (1.4.11) er den tvillingeregels: brugergrænseflader, ikoner, der er nødvendige for at forstå kontrollen, og fokusindikatorer skal nå3:1 mod tilstødende farver. En knap, der er tegnet med kun en svag kant, eller en fokusring, der er sat til en lav-opacitet kontur, fejler, selvom tekstetiketten passerer. Chart- og dashboard-brugergrænseflader rammer samme væg; Smashing Magazine dokumenterer, hvordan tilgængelighedstrin grænser om chart-design uden at kræve dekorativ støj (tilgængelighedstandarder for chart-design).

Checkliste - kontrast

- Brødtekst ≥ 4,5:1på hver tema (herunder mørk tilstand) - Stor tekst / store tal ≥ 3:1 - Fokusring ≥ 3:1 mod overfladen bagved - Ikoner, der kun bærer mening ≥ 3:1, når glyffen bærer mening - Ingen afhængighed af farve alene til fejl- eller successtatus (par med tekst eller ikon)

Mål og trækning efter WCAG 2.2

Mål Størrelse Minimum (2.5.8) kræver interaktive mål på mindst 24×24CSS-punkter på niveau AA, med begrænsede undtagelser for inline-links og visse afstandssager. AI-layouts producerer ofte 16-pixel ikonknappe uden padding. Det er nu et konformitetsproblem, ikke en smagdebat. Padding, min-bredde/min-højde eller større hit-slop omkring det synlige glyf tæller, hvis peker-målet opfylder størrelsen.

Trækbevægelser (2.5.7) betyder, at enhver trækinteraktion - slider-tum, kanban-kort, range-scrubber - behøver en enkelt-peker-alternativ, såsom pileknapper, et numerisk input eller klik-for-at-sætte. Hvis en bruger ikke kan fuldføre opgaven uden at trække, overholder mønsteret ikke. Generatorelskere elsker træk-demos, fordi de ser interaktive ud i en GIF; lever den alternative kontrol i samme PR.

Checkliste - pekeradgang

- Hver ikonknaps hitområde ≥ 24×24 CSS px - Tilstødende mål har nok afstand eller deler en overholdt undtagelse - Hver trækgestus har en ikke-trækvej dokumenteret i brugergrænsefladen - Berøringsmål fungerer stadig, når operativsystemets tekststørrelse øges

Fokusorden, sticky chrome og 2.4.11

Fokus Ikke Skjult (Minimum) kræver, at når et kontrolfelt modtager tastaturets fokus, er det ikke helt skjult af indhold, som er oprettet af forfatteren. Sticky overskrifter, bundnav, cookie-bannere og flydende "AI-hjælp"-widgets er de sædvanlige forsyndere i vibe-kodede apps. Gennemgå siden med disse lag åbne. Hvis det fokuserede felt sidder under en 72px sticky bar, retter du rullepuden eller lagene, ikke brugerens syn.

Bekræft også 2.4.7 (Fokus Synligt): hvert interaktivt element viser et synligt fokussignalt. Generatorene fjerner ofte konturer "til æstetikken." Gendan en højkontrastring, der opfylder 1.4.11.

Checkliste — fokus

- Synligt fokus på links, knapper, indtastninger, brugerdefinerede widgets - Fokusorden svarer til læseorden for hovedstrømmene - Modaler fanget fokus og returnerer det til opkaldsstanden, når den lukkes - Sticky/fixed UI dækker aldrig fuldstændigt det fokuserede kontrolfelt (2.4.11) - Spring-link til stede og fungerer på indholdsstærke sider

ARIA: semantisk HTML først, ARIA anden

Generatorene opfinder ARIA-roller, der ikke matcher adfærd, eller tilføjer role="button" til elementer, der allerede er links. Foretræk native elementer: <button>, <a>, <nav>, <main>, formkontroller. ARIA udfylder huller; det erstatter ikke semantik. Forskellige roller forvirrer skærmoplæsere og kan skjule den virkelige handling. Behandle hver genereret aria-*-attribut som en påstand, der skal verificeres.

Når du virkelig har brug for et brugerdefineret widget, følg en offentliggjort mønster fra ARIA Authoring Practices Guide og check roller/stater mod WAI-ARIA 1.2. Kopiering af en rollestreng fra en chatsvar uden tastaturets understøttelse er, hvordan "tilgængeligt" markup bliver utilgængelig adfærd.

Genereret lugt | Hvad at gøre | WCAG / praksis-hook <div onClick> som CTA | Erstat med <button> eller <a href> | Navn, rolle, tastatur Ikonsk knap, tom navn | Tilføj synligt tekst eller stabil aria-label | 4.1.2 Navn, Rolle, Værdi Drag-kun-bræt | Tilføj flyttningsknapper eller menuer | 2.5.7 Dragging Movements 16px ikon ramme | Pad til ≥24×24 CSS px | 2.5.8 Target Size Fokus under sticky header | scroll-padding / lag-fiks | 2.4.11 Fokus Ikke Skjult Pynterolle="button" på link | Fjern rolle; behold naturlig link | APG / ARIA 1.2

Hvorfor automatiserede kontroller kun fanger en del af billedet

Branchens praksis og leverandørdokumentation placerer typisk den automatiserede dækning i området 30-40% af virkelighedens tilgængelighedsproblemer. Værktøjer finder manglende alt-tekst, mange kontrastfejl og ugyldig ARIA. De kan ikke fuldt ud dømme, om fokusorden svarer til læseorden, om der findes alternativer til dragning, eller om en ikonknappe kan forstås. Denne lukke er årsagen til, at en ren Lighthouse-score ikke er bevis for overensstemmelse med WCAG 2.2. Kombiner en automatiseret første gennemgang med tastaturtest og en manuel gennemgang af den genererede markup.

Citer ikke et enkelt procenttal som lov; behandle det som en planlægningsantagelse: scannere er nødvendige og utilstrækkelige. Budgetér tid for den menneskelige bedømmelseslag hver udgivelse.

Almindelige fejl, teams begår med AI-brugergrænseflade

- Regenererer efter manuelle rettelser uden at låse tokens eller primitiver, så kontrast og navne forsvinder - Stoler på demo-optagelsen (kun mus) som bevis for, at tastaturstien virker - Stakker ARIA for at tie en linter i stedet for at rette elementtypen - Sender marketing-gradients, der aldrig er målt på det levende DOM - Kalder en CI-grøn bygning "overensstemmende" i salgsdæk - det sprog overkræver

Beslutningskriterier: AA nu vs senere

Lever blokeringsfunktioner for de fleste B2B-apps på AA-niveau:

- Tomme tilgængelige navne på primære handlinger - Brødtekst under 4,5:1 på standardtemaet - Ingen tastaturstier gennem checkout eller kerneopgaven - Fokus fuldstændigt skjult af sticky UI på påkrævede felter - Kun træk-kritiske handlinger uden alternativ

Udsæt kun med en ejer og en dato: sekundære dekorative animationer, ikke-kritiske diagrammer med en allerede til stede datatabelalternativ, hjælpwidget-polering, der ikke blokerer opgaver. Udsat er ikke glemt.

Hvad dette ikke er

Denne tjekliste er ikke en fuld WCAG-revision, ikke en VPAT og ikke juridisk rådgivning. Den hævder ikke, at A11yGuard (eller noget værktøj) garanterer overensstemmelse, ADA-overholdelse eller at automatiserede scans "aldrig misser" problemer. Vi offentliggør ikke opfundne kundemetrics eller før/efter omvendingsløft. Produktet automatiserer den målbare første gennemløb; du har stadig brug for menneskelig QA til domskriterier og til godkendelsessprog brugt med kunder eller tilsynsmyndigheder.

Afslutning

Print tabelerne, lås grenen, kør scanneren og derefter tastaturet og navngivningspasset. Hold det normative WCAG-tekst og Quick Reference åbent, mens du diskuterer om kanttilfælde. Når modellen regenererer en skærm, kør den samme liste igen - accessibility-gæld i vibe-kodede apps er en løkke, ikke en engangspolitik.

Referencer

- WCAG 2.2 - WCAG 2.2 Quick Reference - WAI Accessibility Fundamentals - ARIA Authoring Practices Guide (APG) - WAI-ARIA 1.2 - Smashing Magazine — accessibility-standards og chart-design - ADA.gov — AI og handicapdiskrimineringsrettledning

Relaterede artikler

- Kontrast og ARIA i vibe-kodede apps - Udforsk det fulde AI micro-SaaS emne matrix →