Kontrast og ARIA i vibe-kodede apps

Hvordan kontrastmatematik faktisk brækker i genererede temaer

Når en model opfinder en palet, kopierer den normalt en moodboard: blød skifer tekst, pastelfarvede chips, gennemsigtige kort. Det ser fint ud på en designers skærm og fejler forholdene i WCAG 2.2, øjeblikket efter at reel indhold ankommer. Brødtekst på niveau AA har brug for et kontrastforhold på 4,5:1 mod dens baggrund (succeskrav 1.4.3). Stor tekst kan bruge 3:1. Generatorene kører ikke den matematik; de vælger hex-værdier, der "føles sekundære."

En anden fejlmåde er baggrunden, som du ikke kan se i Figma-eksporten. Tekst over en heltebillede, en gradientvask eller en glassmorfisme-panel har brug for den renderede baggrund, ikke tokenen med navnet bg-surface. Prøv pixelen under glyffen, eller du vil rydde en tokenrevision og stadig sende ulæselig kopi. Diagrammer og data-ink har den samme fælde; Smashing Magazines artikel om diagramkontrast viser, hvordan standardgrænser ændrer visuelle designvalg uden at gøre hvert diagram til en regnbue (tilgængelighedsstandarder for diagramdesign).

Ikon-kontrast er den stille tvilling

Succeskrav 1.4.11 (Ikon-kontrast) kræver 3:1 på brugergrænsefladens komponentgrænser, grafiske objekter, der er nødvendige for at forstå indholdet, og tilstande som fokusindikatorer. En svag 1px-kant, der ser "premium" ud, fejler ofte. En fokusring, der er sat til outline: 2px solid rgba(15,118,110,.35), fejler selv når labelteksten passerer 4,5:1. Ikon-kontroller, der kun afhænger af en lysgrå glyf mod hvid, er den samme klasse af fejl. Behandle kant-, ikon- og fokusfarver som førsteklasses-token med offentliggjorte forhold, ikke som dekorative eftertanker. WCAG 2.2 Quick Reference er det hurtigste sted at kontrollere, hvilke kriterier der gælder på niveau AA.

Token overvinder enkeltstående hex-patches

Den varige løsning er kedelig: definér semantiske farvetoken (text-primary, text-muted, border-strong, focus-ring) med målte forhold mod hver tilladt baggrund, og forbyd derefter modellen fra at opfinde hex-streng i komponentfiler. Sæt forbudsreglen i prompten og i CI. Hvis regeneration kan omskrive color: #94a3b8 til en knaplabel, var din "løsning" aldrig en løsning. Par token med et CSS-variabellag, så mørk tilstand og marketingtemaer arver de samme begrænsninger.

Tilgængelige navne er ikke synlige mærker

Skærmlæsere annoncerer det tilgængelige navn på en kontrol, ikke SVG-sti-data. En ikonknap, der viser et skraldespandsglyph uden tekstindhold, ingen aria-label og ingen tilknyttet <label>, bliver "knap" uden formål. Det er en navnefejl, ikke en kontrastfejl, hvilket er hvorfor farveaudit stadig er grøn, mens tastaturbrugere stagnerer.

Navneberegningsrækkefølgen er defineret af tilgængelighedstræet: indholdstekst, labelled-by-referencer, derefter authorsupplerede mærker som aria-label. Generatorene udsender ofte glyffen og en Tailwind-klasse og stopper. De opfinder også duplikatnavne ("Luk" på hver afvisningskontrol i en stak modaler) eller navne, der beskriver ikonmetaforen i stedet for handlingen ("skraldespand" i stedet for "Slet faktura"). Foretræk handlingssprog, der matcher den synlige mulighed.

Hvor navne forsvinder efter regenerering

Regenerering sletter inline aria-label-værdier, der blev tilføjet manuelt, fordi modellen behandler dem som valgfri støj. Overlev det ved:

- At holde ikonkort i ét modul, der altid parrer glyf + navnestreng - At bruge synlig tekst ved siden af ikoner, når der er plads (navn kommer gratis) - At fejle CI, når et interaktivt element har et tomt tilgængeligt navn - At afvise PR'er, der introducerer <div onClick> uden en rolle og navnepakke

WAI's grundlæggende oversigt er stadig den bedste korte introduktion til, hvorfor navne, roller og tilstande skal rejse sammen (WAI Accessibility Fundamentals).

Når ARIA hjælper — og når det skjuler fejlen

Native HTML eksponerer allerede roller, tastaturadgang og mange tilstande. En rigtig <button> er fokuserbar, aktiveres på Enter og Space, og deltager i formularen. En <div role="button" tabindex="0">, som en model har indssat, har stadig brug for disse nøglehåndteringer, en trykket eller deaktiveret tilstand, når det er relevant, og et tilgængeligt navn. Spring over noget af dette, og hjælpeteknologi annoncerer en knap, der ikke gør noget på Space. ARIA Authoring Practices Guide (APG) findes for de tilfælde, hvor du virkelig har brug for et brugerdefineret widget; det er ikke en licens til at omdanne en div til hver kontrol.

Almindelige ARIA-fejl i vibe-kodet markup

- Rolle på det forkerte element: role="button" på en <a href>, eller role="link" på en knap, der sender en formular - Dekorativ ARIA: aria-label, der duplikerer synlig tekst og forvirrer nogle AT-kombinationer - Stale tilstand: aria-expanded="true" efterladt efter en client-render toggler en panel lukket - Landmark-spam: fem role="navigation"-regioner uden navne, så hoppe-lister bliver støj - Live-regioner til pynt: aria-live="polite" på hver toast, så siden snakker

WAI-ARIA 1.2-anbefalingen beskriver ontologien af roller og egenskaber; brug den, når du skal udvide beyond HTML, ikke som en standardlag på hver node (WAI-ARIA 1.2).

Situation | Foretræk | Undgå Primær handling | <button type="button"> | <div role="button"> uden nøgler Navigation til en URL | <a href> | Knap, der kun kalder router.push med ingen URL Ikonly-kontrol | Synlig tekst eller stabil aria-label fra en kort | Bar SVG med titel mangler Brugerdefineret kombinationsfelt | APG-mønster + tastaturkort | Oprettede roller kopieret fra et chatsvar

Tastaturstier, som generatoren glemmer

Fokusorden, synlig fokus og spring-links forsvinder ud af enkeltlayout. Kriterium 2.4.7 kræver en synlig fokusindikator. Kriterium 2.4.11 (Fokus ikke skjult - minimum), som er ny i WCAG 2.2, kræver, at sticky-overskrifter, cookie-bannere og flydende chat-værktøjer ikke fuldstændigt skjuler den fokuserede kontrol. Tryk på den genererede side fra top til bund. Bekræft, at rækkefølgen svarer til læseordenen. Bekræft, at ingen kontrol er strandet bag en overlay. Bekræft, at fokusringen opfylder 1.4.11 i forhold til hvad der sidder bagved.

En kort manuel tastatur-gennemgang (15 minutter)

- Aflæs musen. Åbn siden i en ren profil. - Tryk fra browserens krom til dokumentet. Er der et spring-link, der virker? - Rækkede hver primær handling uden at bruge pile-tastatur-folklore, som komponenten aldrig implementerede. - Åbn og luk hver modal med Escape. Returnerer fokus til invokeren? - Udløs den sticky-overskrift og cookie-banneren. Kan du stadig se den fokuserede kontrol? - Ram hver ikon-knap med en skærmlæser (NVDA eller VoiceOver). Svarer navnet til handlingen?

Denne gennemgang fanger, hvad Lighthouse ikke vil. Automatiserede værktøjer er en første filter; de er ikke en overenskomstscertifikat. For rekruttering og automatiserede beslutningsværktøjer minder den amerikanske vejledning også byggerne om, at AI-funktioner kan skabe risici for handikapdiskrimination, hvis grænsefladerne udelukker personer, der bruger hjælpemidler (ADA.gov AI-vejledning). Produktets brugergrænseflade er ikke undtaget fra denne tankegang, bare fordi en model skrev JSX'en.

Sikr på, at kontrollen overlever regenerering

Fordi regenerering sletter manuelle patches, ser varig kontrol ud som infrastruktur:

- Design-tokens med målt kontrast, der kontrolleres i en enhedstest eller stylelint-plugin - Komponentprimitiver (IconButton, TextField), der altid udsender navn + fokusstilarter - CI-tilgængelighedslås (axe eller tilsvarende) på pull-anmodninger, der fejler på tomme navne og kontrast - Promptbegrænsninger, der forbyder rå hex og forbyder div-som-knap uden en eksplitt undtagelseflag - Menneskelig tastatur-gennemgang på hver lodret før frigivelse, logget som en checkliste-punkt, ikke en vibe

Behandle genereret markup som upålidelig udskrift. Gennemse det på samme måde, som du gennemser en junior PR, der ankommer fra en weekend-hackathon: antag manglende navne, antag teatralsk ARIA, antag pastelfarvet tekst.

Beslutningskriterier: retning i tokens, primitiver eller sidekode?

Brug denne rækkefølge, når en fejlrapport kommer ind:

- Hvis mange sider deler den forkerte slukket tekstfarve, ret tokenet og genmål forholdene. - Hvis en enkelt kontrollertype mangler navne (alle ikonknapflader), ret primitivet og slet lokale patches. - Hvis en enkelt markedsføringshelte fejler over et billede, ret siden overlay eller tekstbehandling. - Hvis ARIA blev limet på det forkerte element, erstattedes med en naturlig kontrol før der skrives flere attributter.

Side-niveau ARIA-patches er de mindst holdbare. De er også dem, som vibe-coding-sessions elsker at udsende. Skyd rettelserne opad.

Hvad dette ikke er

Denne artikel er ikke et certifikat for overensstemmelse med WCAG for dit produkt. Det er ikke juridisk rådgivning, og det hævder ikke, at kørning af A11yGuard (eller nogen anden scanner) gør en hjemmeside "ADA-kompatibel" eller "100% tilgængelig." Automatiserede kontrast- og ARIA-kontroller fanger målbare fejl; de mangler dog subjektive vurderinger om læseorden, trækalternativer og om et navn er forståeligt. Vi opfinder ikke kunde-logos, omsætningsløft eller "aldrig mis en kontrastfejl"-garantier. Produktets ærlige rolle er en hurtig første gennemgang samt en checkliste, som du stadig ejer.

Afslutning

Kontrast og tilgængelige navne fejler uafhængigt og regenererer sammen. Lås tokens, foretræk native kontroller, verificér ARIA mod APG når du skal tilpasse, og hold et tastaturpas i frigivelsesritualet. Brug referencerne nedenfor, når der er tvivl om et forhold eller et kriterium - specifikationsteksten har forkraft over en chatmodels hukommelse. Husk at overholde A11yGuard, WCAG, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo og ADA.

Referencer

- WCAG 2.2 - WCAG 2.2 Hurtig reference - WAI Accessibility Fundamentals - ARIA Authoring Practices Guide (APG) - WAI-ARIA 1.2 - Smashing Magazine — accessibility standarder og chart design - ADA.gov — AI og diskrimination af personer med handicap vejledning

Relaterede artikler

- WCAG 2.2-kontrolliste til AI-genereret UI (2026) - Udforsk det fulde AI mikro-SaaS emne matrix →