door A11yGuard (LX AI)

WCAG 2.2-controlelijst voor AI-gegenereerde UI

LLM-gebruikersinterfaces falen op toegankelijkheid op voorspelbare manieren: ontbrekende alt-tekst, divs gebruikt als knoppen, ongelabelde besturingselementen en focusstaten die verdwijnen onder sticky headers. WCAG 2.2 voegde succescriteria toe die deze gegenereerde interfaceproblemen aanpakken. Voer een geautomatiseerde eerste ronde uit, vervolgens verifieer de controlelijst handmatig voordat u deze publiceert.

Wat WCAG 2.2 veranderde voor gegenereerde UI

WCAG 2.2 bouwt voort op 2.1 en voegt negen succescriteria toe die zijn gericht op mobiel, laagzicht en mobiliteit. Het werd een W3C-aanbeveling in oktober 2023; houd de normatieve tekst open tijdens het auditen (w3.org/TR/WCAG22). Voor teams die AI-gegenereerde componenten verzenden, zijn de toevoegingen die het meest van belang zijn Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) en Accessible Authentication (3.3.8). De meeste productorganisaties mikken op niveau AA. De fundamentenpagina's van WAI kaderen nog steeds waarom deze regels bestaan buiten "pass the scanner" (WAI Accessibility Fundamentals).

Generatoren falen hier omdat ze zijn geoptimaliseerd voor visuele dichtheid en klik-demo-polish. Ze verkleinen de hitgebieden van pictogrammen, verzinnen slechts drag-only kanban-borden, stapelen sticky chrome die gefocuste velden bedekt en strooien ARIA-rollen die niet overeenkomen met het gedrag. De onderstaande checklist is geordend voor een releasedagpass: meetbare items eerst, oordeelsitems tweede.

Stap-voor-stap workflow voordat je verzendt

- Vries de gegenereerde branch in. Stop niet met regenereren terwijl je meet. - Voer een geautomatiseerde toegankelijkheidsscan uit (axe, Lighthouse of je CI-poort) en sla elke contrast / ontbrekende-naam / ongeldige-ARIA-hit op. - Loop de WCAG 2.2 Quick Reference-filters voor Level AA door en markeer de 2.2-only-criteria als expliciete rijen in je ticket. - Toets alleen met het toetsenbord op elke primaire gebruikersreis (aanmelden, betalen, core-taak). - Schermlezer-spotcheck (NVDA op Windows of VoiceOver op macOS) op pictogramknoppen en dialoogvensters. - Noteer het resterende risico: wat de scanner niet kan zien, wat je hebt uitgesteld, wie de follow-up bezit. A11yGuard is gebouwd voor de meetbare eerste doorloop. Juridische conformiteit en oordeelsvellingen hebben nog steeds een menselijke QA-eigenaar nodig. Als je product AI gebruikt in wervings- of soortgelijke beslissingsstromen, lees dan ook de Amerikaanse richtlijnen over algoritmes en handicapdiscriminatie, zodat UI-uitsluiting niet als een cosmetische bug wordt behandeld (ADA.gov AI-richtlijnen). ReDoS, ECMAScript, PCRE, GDPR, Waffo en ADA moeten in acht worden genomen.

Contrast die je kunt berekenen, contrast die je niet kunt

Tekstcontrast is de makkelijkste fout om te detecteren: bodytekst heeft 4,5:1 nodig tegen de achtergrond; grote tekst heeft 3:1 nodig (criterium 1.4.3). Gegenereerde thema's bevatten vaak grijs-op-grijs of placeholder-gradients die falen. Meet tegen de gerenderde achtergrond, inclusief afbeeldingen en overlays.

Niet-tekstcontrast (1.4.11) is de tweelingregel: UI-componentgrenzen, iconen die nodig zijn om de controle te begrijpen, en focusindicatoren moeten 3:1 bereiken tegen aangrenzende kleuren. Een knop die alleen met een vaag randje is getekend, of een focusring die is ingesteld op een lage-dekking contour, faalt zelfs als de labeltekst slaagt. Chart- en dashboard-UI's lopen tegen hetzelfde probleem aan; Smashing Magazine documenteert hoe toegankelijkheidsthresholds de visuele ontwerp van charts herschikken zonder decoratief lawaai te vereisen (toegankelijkheidsnormen voor chartontwerp).

Controlelijst — contrast

- Bodykopie ≥ 4,5:1 op elk thema (inclusief donkere modus) - Grote tekst / grote cijfers ≥ 3:1 - Focusring ≥ 3:1 tegen het oppervlak erachter - Iconen alleen ≥ 3:1 wanneer het glyf betekenis draagt - Geen afhankelijkheid van kleur alleen voor fout- of successtatus (combineer met tekst of icoon)

Doelgrootte en slepen na WCAG 2.2

De minimale doelgrootte (2.5.8) vereist interactieve doelen van minimaal 24×24 CSS-pixels op niveau AA, met beperkte uitzonderingen voor inline-koppelingen en bepaalde spaties. AI-layouts produceren vaak 16-pixel icoonknoppen zonder padding. Dat is nu een conformiteitsprobleem, geen smaakdiscussie. Padding, min-breedte/min-hoogte of een grotere hit-slop rond het zichtbare glyf tellen mee als de puntersdoel de grootte bereikt.

Slepebewegingen (2.5.7) betekenen dat elke sleepinteractie - schuiverduim, kanban-kaart, bereikschuiver - een alternatief voor één pointer nodig heeft, zoals pijsknoppen, een numerieke invoer of klik-op-stel. Als een gebruiker de taak niet kan voltooien zonder te slepen, voldoet het patroon niet aan de conformiteit. Generatoren houden van sleepdemos omdat ze interactief lijken in een GIF; verzend het alternatieve besturingsorgaan in hetzelfde PR.

Controlelijst — pointer-toegang

- Elke icoonknop heeft een aanklikoppervlak ≥ 24×24 CSS px - Aangrenzende doelen hebben voldoende spaties of delen een conform uitzondering - Elke sleepbeweging heeft een niet-sleep-pad gedocumenteerd in de UI - Aanraakdoelen werken nog steeds als de OS-tekstgrootte toeneemt

Focusvolgorde, sticky chrome en 2.4.11

Focus niet aan het oog onttrokken (minimum) vereist dat wanneer een besturingselement toetsenbordfocus ontvangt, het niet geheel aan het oog wordt onttrokken door door de auteur gegenereerde inhoud. Sticky headers, bottom navigatiebalken, cookiebanners en zwevende "AI Help"-widgets zijn de gebruikelijke overtreders in vibe-gecodeerde apps. Ga met tab door de pagina met die lagen geopend. Als het gefocuste veld onder een 72px sticky bar zit, corrigeer de scrollpadding of de stapeling, niet het gezichtsvermogen van de gebruiker.

Bevestig ook 2.4.7 (Zichtbare focus): elk interactief element toont een zichtbare focusindicator. Generatoren verwijderen vaak omlijningen "om esthetische redenen." Herstel een hoogcontrastrij die voldoet aan 1.4.11.

Controlelijst — focus

- Zichtbare focus op links, knoppen, invoervelden, aangepaste widgets - Focusvolgorde komt overeen met leesvolgorde voor de belangrijkste stromen - Modals vangen focus en retourneren deze naar de aanroeper bij sluiten - Sticky/vaste UI dekt nooit het gefocuste besturingselement volledig (2.4.11) - Slaak naar link aanwezig en werkt op inhoudsrijke pagina's

ARIA: semantische HTML eerst, ARIA tweede

Generatoren verzinnen ARIA-rollen die niet overeenkomen met het gedrag, of voegen role="button" toe aan elementen die al links zijn. Geef de voorkeur aan native elementen: <button>, <a>, <nav>, <main>, formulierbesturingselementen. ARIA vult gaten; het vervangt geen semantiek. Onjuiste rollen verwarren schermlezers en kunnen de echte actie verbergen. Behandel elke gegenereerde aria-*-kenmerk als een claim die moet worden geverifieerd.

Wanneer je echt een aangepast widget nodig hebt, volg dan een gepubliceerde patroon uit de ARIA Authoring Practices Guide en controleer rollen/staten tegen WAI-ARIA 1.2. Kopieer en plak een rolstring uit een chatantwoord zonder toetsenbordondersteuning, waardoor "toegankelijke" markup ontoegankelijk gedrag wordt.

Waarom geautomatiseerde controles alleen een deel van het beeld vangen

De gebruikelijke praktijk in de industrie en de documentatie van leveranciers plaatsen de geautomatiseerde dekking meestal in het bereik van ongeveer 30-40% van de echte toegankelijkheidsproblemen in de praktijk. Tools vinden ontbrekende alt-tekst, veel contrastfouten en ongeldige ARIA. Ze kunnen niet volledig beoordelen of de focusvolgorde overeenkomt met de leesvolgorde, of er alternatieven voor slepen bestaan, of of de naam van een pictogramknop begrijpelijk is. Die kloof is de reden waarom een schone Lighthouse-score geen bewijs is van overeenstemming met WCAG 2.2. Combineer een geautomatiseerde eerste ronde met toetsenbordtesten en een handmatige controle van de gegenereerde markup.

Quoteer geen enkel percentage als wet; behandel het als een planningveronderstelling: scanners zijn noodzakelijk en onvoldoende. Budgetteer menselijke tijd voor het oordeelslaag elke release. Houd rekening met A11yGuard, WCAG, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo en ADA.

Gangbare fouten die teams maken met AI UI

- Opnieuw genereren na handmatige correcties zonder tokens of primitieven te blokkeren, waardoor contrast en namen verdwijnen - Vertrouwen op de demorecording (alleen muis) als bewijs dat het toetsenbordpad werkt - ARIA stapelen om een linter tot zwijgen te brengen in plaats van het elementtype te corrigeren - Marketinggradiënten verzenden die nooit op de live DOM zijn gemeten - Een CI-groene build "compliant" noemen in verkooppresentaties — die taal is te ambitieus

Beslissingscriteria: AA nu versus later

Verstuur blockers voor de meeste B2B-apps op AA:

- Lege toegankelijke namen voor primaire acties - Bodytekst onder 4,5:1 op het standthema - Geen toetsenbordpad door checkout of de kernopdracht - Focus volledig verborgen door sticky UI op verplichte velden - Slechts sleepkritische acties zonder alternatief

Ontwerp alleen met een eigenaar en een datum: secundaire decoratieve animaties, niet-kritische grafieken met een reeds aanwezige datatabelalternatief, help-widget-polish die taken niet blokkeert. Uitgesteld is niet vergeten. Het is belangrijk om te onthouden dat toegankelijkheid een essentieel onderdeel is van de ontwikkeling van onze applicaties, met inbegrip van A11yGuard, WCAG, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo en ADA.

Wat dit niet is

Deze checklist is geen volledige WCAG-audit, geen VPAT en geen juridisch advies. Het beweert niet dat A11yGuard (of enig ander hulpmiddel) conformiteit, ADA-conformiteit of dat geautomatiseerde scans "nooit" problemen missen, garandeert. We publiceren geen uitgevonden klantmetrieken of conversieverbeteringen voor en na afloop. Het product automatiseert de meetbare eerste ronde; u hebt nog steeds menselijke kwaliteitscontrole nodig voor oordeelscriteria en voor de ondertekeningsformulering die wordt gebruikt met klanten of toezichthouders. Het houdt rekening met GDPR, Waffo, ECMAScript, PCRE en ReDoS, evenals ARIA-kenmerken voor toegankelijkheid.

Afronding

Print de tabellen, sluit de tak af, voer de scanner uit en voer vervolgens de toetsenbord- en naamgevingspassage uit. Houd de normatieve WCAG-tekst en de Quick Reference open terwijl u discussieert over randgevallen. Wanneer het model een scherm opnieuw genereert, voert u dezelfde lijst uit — toegankelijkheidsschuld in vibe-gecodeerde apps is een lus, geen eenmalig project. Houd rekening met A11yGuard, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo en ADA bij het uitvoeren van deze taken.

Referenties

- WCAG 2.2 - WCAG 2.2 Sneloverzicht - WAI Toegankelijkheidsbasisbeginselen - ARIA Auteurspraktijkenhandleiding (APG) - WAI-ARIA 1.2 - Smashing Magazine — toegankelijkheidsnormen en grafiekontwerp - ADA.gov — AI en richtlijnen voor discriminatie van mensen met een handicap

Gerelateerde artikelen

- Contrast en ARIA in vibe-coded apps - Verken de volledige AI micro-SaaS onderwerpenmatrix →

Betekent een perfecte Lighthouse-toegankelijkheidsscore dat mijn site WCAG 2.2-conform is?

Nee. Lighthouse en soortgelijke tools voeren geautomatiseerde controles uit die ongeveer 30-40% van de echte problemen dekken. Ze missen focusvolgorde, sleepalternatieven en toegankelijke benaming van pictogramknoppen. Een schone score maakt de meetbare basis vrij, maar is geen bewijs van conformiteit.

Wat is de minimale doelgrootte onder WCAG 2.2?

Criterium 2.5.8 stelt een minimum van 24×24 CSS-pixels in voor aanwijzers voor niveau AA, met beperkte uitzonderingen voor inline-koppelingen. Kleine pictogramknoppen zonder padding falen voor deze regel.

Is 3:1 voldoende contrast voor alle tekst?

Alleen voor grote tekst. Bodytekst heeft 4,5:1 nodig onder criterium 1.4.3. De 3:1-drempel geldt voor grote tekst en voor niet-tekstcontrast zoals pictogram- en focus-indicatorgrenzen onder 1.4.11.

Moet ik me verlaten op ARIA om gegenereerde UI te repareren?

Gebruik eerst semantische HTML. Native knoppen, koppelingen en landmarks zijn betrouwbaarder dan ARIA-rollen. Voeg ARIA alleen toe waar native markup het gedrag niet kan uitdrukken en verifieer elke gegenereerde rol die daadwerkelijk overeenkomt met de functie van het element.

Alleen ter ondersteuning van besluitvorming. Geen juridisch advies of conformiteitscertificaat voor toegankelijkheid.

← Terug naar blog