door A11yGuard (LX AI)

Contrast en ARIA in vibe-gecodeerde apps

Vibe-gecodeerde UI's falen op toegankelijkheid op twee punten waar scannertools zelden samen opvangen: contrastwiskunde en toegankelijke namen. Een component kan een kleuraudit doorstaan en toch onbruikbaar zijn als de rol verkeerd is of de naam leeg is. Beide breken opnieuw af bij regeneratie, dus de fix hoort in een checklist, niet in een eenmalige bewerking.

Hoe contrastwiskunde daadwerkelijk kapot gaat in gegenereerde thema's

Wanneer een model een palet uitvindt, kopieert het meestal een moodboard: zachte slategrijze tekst, pastelkleuren, transparante kaarten. Dat ziet er goed uit op het scherm van een ontwerper en faalt de verhoudingen in WCAG 2.2 op het moment dat echte inhoud wordt toegevoegd. Bodytekst op niveau AA heeft een contrastverhouding van 4,5:1 tegen de achtergrond nodig (succescriterium 1.4.3). Grote tekst kan 3:1 gebruiken. Generatoren voeren deze wiskunde niet uit; ze kiezen hex-waarden die "secundair aanvoelen."

Een tweede foutmodus is de achtergrond die je niet kunt zien in de Figma-export. Tekst over een helder beeld, een gradiëntwas of een glassmorphism-panel heeft de gerenderde achtergrond nodig, niet de token met de naam bg-surface. Neem een monster van het pixel onder het glyf, of je zult een tokenaudit doorstaan en nog steeds onleesbare kopieën verzenden. Grafieken en gegevensinkt hebben dezelfde valkuil; Smashing Magazine's artikel over grafiekcontrast laat zien hoe standaarddrempels visuele ontwerpkeuzes veranderen zonder elke grafiek in een regenboog te veranderen (toegankelijkheidsnormen voor grafiekontwerp).

Niet-tekstcontrast is de stille tweeling

Succescriterium 1.4.11 (niet-tekstcontrast) vraagt om 3:1 op UI-componentgrenzen, grafische objecten die nodig zijn om inhoud te begrijpen en staten zoals focusindicatoren. Een vaag 1px-borderrand dat "premium" lijkt, faalt vaak. Een focusring ingesteld op outline: 2px solid rgba(15,118,110,.35) faalt zelfs wanneer de labeltekst 4,5:1 doorstaat. Icon-only-controles die afhankelijk zijn van een lichtgrijze glyf tegen wit zijn dezelfde klasse van bug. Behandel rand-, icoon- en focuskleuren als first-class-tokens met gepubliceerde verhoudingen, niet als decoratieve nasmaak. De WCAG 2.2 Quick Reference is de snelste plek om te controleren welke criteria op niveau AA van toepassing zijn.

Tokens verslaan eenmalige hex-patches

De duurzame oplossing is saai: definieer semantische kleurentokens (text-primary, text-muted, border-strong, focus-ring) met gemeten verhoudingen tegen elke toegestane achtergrond, en verbied de model om hex-strings in componentbestanden uit te vinden. Zet de verbodregel in de prompt en in CI. Als regeneratie kleur: #94a3b8 kan herschrijven in een knoplabel, was je "oplossing" nooit een oplossing. Koppel tokens aan een CSS-variabelelaag, zodat donkere modus en marketingthema's dezelfde beperkingen erven.

Toegankelijke namen zijn geen zichtbare labels

Schermlezers kondigen de toegankelijke naam van een besturingselement aan, niet de SVG-paadgegevens. Een knop met een prullenbakglyf zonder tekstinhoud, geen aria-label en geen geassocieerde <label> wordt "knop" zonder doel. Dat is een benoemingsfout, niet een contrastfout, waardoor kleuraudits groen blijven terwijl toetsenbordgebruikers stil staan.

De naamcomputervolgorde wordt gedefinieerd door de toegankelijkheidstree: inhoudstekst, labelled-by-referenties, dan door de auteur geleverde labels zoals aria-label. Generatoren geven vaak de glyf en een Tailwind-klasse uit en stoppen daar. Ze geven ook dubbele namen uit ("Sluiten" op elke annuleringsknop in een stapel modals) of namen die de icoonmetafoor beschrijven in plaats van de actie ("prullenbak" in plaats van "Factuur verwijderen"). Geef de voorkeur aan actietaal die overeenkomt met de zichtbare affordance.

Waar namen verdwijnen na regeneratie

Regeneratie wist inline aria-label-waarden die handmatig waren toegevoegd omdat het model ze als optioneel lawaai behandelt. Overleef dat door:

- Het opslaan van icoonkaarten in één module die altijd glyf + naamstring koppelt - Het gebruik van zichtbare tekst naast iconen wanneer de ruimte het toelaat (naam komt gratis) - Het falen van CI wanneer een interactief element een lege toegankelijke naam heeft - Het afwijzen van PR's die <div onClick> introduceren zonder rol- en naamverpakking

WAI's overzicht van de basisbeginselen is nog steeds de beste korte inleiding over waarom namen, rollen en staten samen moeten reizen (WAI Accessibility Fundamentals).

Wanneer ARIA helpt — en wanneer het de bug verbergt

Native HTML exposeert al rollen, toetsenbordgedrag en veel staten. Een echte <button> is focusbaar, activeert bij Enter en Space, en neemt deel aan formulieren. Een <div role="button" tabindex="0"> die een model plakt, heeft nog steeds die sleutelhandlers nodig, een ingedrukte of uitgeschakelde staat wanneer relevant, en een toegankelijke naam. Sla een van deze over en hulpmiddelen voor toegankelijkheid kondigen een knop aan die niets doet bij Space. De ARIA Authoring Practices Guide (APG) bestaat voor de gevallen waarin u echt een aangepast widget nodig heeft; het is geen licentie om een div opnieuw te stylen in elke controle.

Veelvoorkomende ARIA-fouten in vibe-gecodeerde markup

- Rol op het verkeerde element: role="button" op een <a href>, of role="link" op een knop die een formulier verzendt - Decoratieve ARIA: aria-label die zichtbare tekst dupliceert en sommige AT-combinaties verwarrend maakt - Verouderde staat: aria-expanded="true" die achterblijft nadat een client-render een paneel sluit - Landmark-spam: vijf role="navigation"-regio's zonder namen, zodat skip-lijsten ruis worden - Live-regio's voor ijdelheid: aria-live="polite" op elke toast, zodat de pagina kletst

De WAI-ARIA 1.2-aanbeveling beschrijft de ontologie van rollen en eigenschappen; gebruik deze wanneer u verder moet gaan dan HTML, niet als een standaardlaag op elk knooppunt (WAI-ARIA 1.2).

Toetsenbordpaden die de generator vergeet

Focusvolgorde, zichtbare focus en skip-koppelingen vallen weg uit one-shot-layouts. Criterion 2.4.7 vereist een zichtbare focusindicator. Criterion 2.4.11 (Focus Not Obscured — Minimum), nieuw in WCAG 2.2, vereist dat sticky headers, cookie-banners en zwevende chatwidgets de gefocuste controle niet volledig verbergen. Tab de gegenereerde pagina van boven naar beneden. Bevestig dat de volgorde overeenkomt met de leesvolgorde. Bevestig dat geen controle achter een overlay strandt. Bevestig dat de focusring voldoet aan 1.4.11 tegen alles wat erachter zit.

Een korte handmatige toetsenbordpassage (15 minuten)

- Verbind de muis los. Open de pagina in een schoon profiel. - Tab van de browserchrome in het document. Is er een skip-koppeling die werkt? - Bereik elke primaire actie zonder arrow-key-folklore die de component nooit heeft geïmplementeerd. - Open en sluit elke modale met Escape. Keert de focus terug naar de aanroeper? - Activeer de sticky header en de cookie-banner. Kan je de gefocuste controle nog steeds zien? - Raak elke pictogramknop met een schermlezer (NVDA of VoiceOver). Komt de naam overeen met de actie?

Die passage vangt wat Lighthouse niet zal vangen. Geautomatiseerde tools zijn een eerste filter; ze zijn geen conformiteitscertificaat. Voor het werven en geautomatiseerde beslissingshulpmiddelen herinnert de Amerikaanse richtlijn ook bouwers eraan dat AI-functies risico's op handicapdiscriminatie kunnen creëren als interfaces mensen uitsluiten die hulpmiddelen voor toegankelijkheid gebruiken (ADA.gov AI-richtlijn). Product-UI is niet vrijgesteld van die denkwijze alleen omdat een model de JSX heeft geschreven.

Zorg ervoor dat de controle de regeneratie overleeft

Omdat regeneratie handmatige patches wist, ziet duurzame controle eruit als infrastructuur:

- Ontwerp tokens met gemeten contrast, gecontroleerd in een eenheidstest of stylelint-plugin - Componentprimitieven (IconButton, TextField) die altijd naam + focusstijlen emitteren - CI-toegankelijkheidspoort (axe of equivalent) op pull-aanvragen, mislukken bij lege namen en contrast - Promptbeperkingen die ruwe hex verbieden en div-as-button zonder een expliciete uitzonderingsvlag verbieden - Menselijke toetsenbordpass op elke verticale voor release, geregistreerd als een checklist-item, niet een vibe

Behandel gegenereerde markup als onbetrouwbare conceptoutput. Beoordeel het op dezelfde manier als je een junior PR beoordeelt die van een weekend hackathon komt: ga ervan uit dat namen ontbreken, ga ervan uit dat theatrale ARIA, ga ervan uit dat pasteltekst.

Beslissingscriteria: fix in tokens, primitieven of paginacode?

Gebruik deze volgorde wanneer een bugrapport binnenkomt:

- Als veel pagina's de verkeerde gedempte tekstkleur delen, fix de token en meet de verhoudingen opnieuw. - Als één besturingselementtype namen ontbeert (alle icon buttons), fix de primitief en verwijder lokale patches. - Als een enkele marketingheld boven een foto faalt, fix de overlay of tekstbehandeling van die pagina. - Als ARIA aan het verkeerde element was gelijmd, vervang door een native besturingselement voordat je meer attributen schrijft.

Paginabrede ARIA-patches zijn het minst duurzaam. Ze zijn ook degene die vibe-codesessies graag emitteren. Druk fixes omhoog.

Wat dit niet is

Dit artikel is geen certificaat van WCAG-conformiteit voor uw product. Het is geen juridisch advies en het beweert niet dat het uitvoeren van A11yGuard (of enige scanner) een site "ADA-compliant" of "100% toegankelijk" maakt. Geautomatiseerde contrast- en ARIA-controles detecteren meetbare fouten; ze missen oordelen over leesvolgorde, sleepalternatieven en of een naam begrijpelijk is. We verzinnen geen klantlogo's, conversieverbeteringen of "nooit een contrastfout missen"-garanties. De eerlijke productrol is een snelle eerste doorloop plus een checklist die u nog steeds bezit.

Afsluiting

Contrastwiskunde en toegankelijke namen falen onafhankelijk en regenereren samen. Vergrendel tokens, geef de voorkeur aan native besturingselementen, verifieer ARIA tegen APG wanneer u moet aanpassen en houd een toetsenborddoorloop in de release-ritus. Gebruik de onderstaande referenties wanneer een claim over een verhouding of een criterium in twijfel wordt getrokken — de specificatietekst wint het van het geheugen van een chatmodel.

Referenties

- WCAG 2.2 - WCAG 2.2 Sneloverzicht - WAI Toegankelijkheidsbasisbeginselen - ARIA Auteurpraktijkenhandleiding (APG) - WAI-ARIA 1.2 - Smashing Magazine — toegankelijkheidsnormen en grafiekontwerp - ADA.gov — AI en richtlijnen voor handicapdiscriminatie

Gerelateerde artikelen

- WCAG 2.2-controlelijst voor AI-gegenereerde UI (2026) - Verken de volledige AI micro-SaaS-onderwerpmatrix →

Waarom gaat mijn component een kleuraudit door, maar voelt het nog steeds kapot?

Een kleuraudit controleert het tekstverhouding. Het controleert niet of het besturingselement een toegankelijke naam, een zichtbare focusstatus of een toetsenbordhandler heeft. Deze lacunes zijn gebruikelijk in gegenereerde markup en zijn geen contrastproblemen.

Is ARIA voldoende om een div te laten gedragen als een knop?

Nee. Een div met role="button" heeft nog steeds een tabindex, Enter/Space-toetsenhandlers en een toegankelijke naam nodig. Een native <button> biedt alle drie. Gebruik het native element, tenzij u een specifieke reden heeft om dat niet te doen.

Hoe stop ik fixes die verdwijnen bij regeneratie?

Blokkeer kleur- en spatietokens in het ontwerpsysteem, zodat het model geen waarden kan verzinnen, en voer een geautomatiseerde toegankelijkheidspoort in CI uit. Behandel gegenereerde UI als een concept en beoordeel het op dezelfde manier als onbetrouwbare output.

Wat is de 3:1-niet-tekstcontrastregel?

Criterium 1.4.11 vereist dat UI-componentgrenzen, pictogrammen en focusindicatoren een contrast van 3:1 bereiken ten opzichte van aangrenzende kleuren. Het is afgezonderd van de 4,5:1-tekstregel en wordt vaak gemist door gegenereerde thema's.

Alleen ter ondersteuning van besluitvorming. Niet als juridisch advies of een conformiteitscertificaat voor toegankelijkheid.

← Terug naar blog