von A11yGuard (LX AI)

WCAG 2.2-Checkliste für künstlich generierte Benutzeroberflächen

Benutzeroberflächen, die von KI generiert werden, scheitern an der Barrierefreiheit auf vorhersehbare Weise: fehlende Alternativtexte, Div-Elemente, die als Schaltflächen verwendet werden, nicht beschriftete Steuerelemente und Fokuszustände, die unter festen Kopfzeilen verschwinden. Die WCAG 2.2 hat Erfolgskriterien hinzugefügt, die diese Probleme bei generierten Schnittstellen ansprechen. Führen Sie einen automatisierten ersten Durchlauf durch und überprüfen Sie dann die Checkliste manuell, bevor Sie veröffentlichen.

Was WCAG 2.2 für generierte Benutzeroberflächen geändert hat

WCAG 2.2 baut auf 2.1 auf und fügt neun Erfolgskriterien hinzu, die auf mobile, sehbehinderte und Mobilitätsbedürfnisse abzielen. Es wurde im Oktober 2023 zur W3C-Empfehlung; halten Sie den normativen Text während der Überprüfung offen (w3.org/TR/WCAG22). Für Teams, die AI-generierte Komponenten ausliefern, sind die wichtigsten Ergänzungen Fokus nicht verdeckt (2.4.11), Dragging-Bewegungen (2.5.7), Mindestgröße des Ziels (2.5.8), konsistente Hilfe (3.2.6), redundante Eingabe (3.3.7) und zugängliche Authentifizierung (3.3.8). Die meisten Produktorganisationen zielen auf Level AA ab. Die Grundseiten von WAI erklären immer noch, warum diese Regeln jenseits von "Passieren des Scanners" existieren (WAI-Zugänglichkeitsgrundlagen).

Generatoren scheitern hier, weil sie auf visuelle Dichte und Klick-Demo-Politur optimieren. Sie verkleinern die Symbol-Trefferbereiche, erfinden Drag-only-Kanban-Boards, stapeln klebrige Chrome, die fokussierte Felder abdeckt, und streuen ARIA-Rollen, die nicht mit dem Verhalten übereinstimmen. Die Checkliste unten ist für einen Release-Tag-Pass geordnet: messbare Elemente zuerst, Urteils-elemente zweitens.

Schritt-für-Schritt-Arbeitsablauf vor dem Versand

- Die generierte Zweigstelle einfrieren. Regenerieren Sie nicht weiter, während Sie messen. - Führen Sie einen automatisierten Zugänglichkeits-Scan (axe, Lighthouse oder Ihre CI-Schleuse) durch und ordnen Sie jeden Kontrast-/fehlenden-Namen-/ungültigen-ARIA-Treffer zu. - Gehen Sie die WCAG 2.2-Schnellreferenz-Filter für Level AA durch und markieren Sie die 2.2-only-Kriterien als explizite Zeilen in Ihrem Ticket. - Tastatur-only-Pass auf jeder primären Benutzerreise (Anmeldung, Zahlung, Kernaufgabe). - Bildschirmleser-Spot-Check (NVDA auf Windows oder VoiceOver auf macOS) auf Symbol-Schaltflächen und Dialogen. - Aufzeichnen des Restrisikos: Was der Scanner nicht sehen kann, was Sie aufgeschoben haben, wer den Follow-up besitzt.

A11yGuard ist für den messbaren ersten Pass konzipiert. Rechtliche Konformität und Urteilsentscheidungen benötigen immer noch einen menschlichen QA-Besitzer. Wenn Ihr Produkt AI in der Einstellung oder ähnlichen Entscheidungsflüssen verwendet, lesen Sie auch die US-Richtlinien zu Algorithmen und Behinderungsdiskriminierung, damit UI-Ausschluss nicht als kosmetischer Bug behandelt wird (ADA.gov AI-Richtlinien).

Kontrast, den man berechnen kann, Kontrast, den man nicht berechnen kann

Der Textkontrast ist der einfachste Fehler, den man erkennen kann: Fließtext benötigt ein Verhältnis von 4,5:1 gegenüber seinem Hintergrund; großer Text benötigt ein Verhältnis von 3:1 (Kriterium 1.4.3). Generierte Designs liefern häufig Grau-on-Grau oder Platzhalter-Gradienten, die fehlschlagen. Messen Sie gegen den gerenderten Hintergrund, einschließlich Bilder und Überlagerungen.

Nicht-Text-Kontrast (1.4.11) ist die Zwillingsregel: UI-Komponentengrenzen, Symbole, die zum Verstehen der Steuerung erforderlich sind, und Fokusindikatoren müssen ein Verhältnis von 3:1 gegenüber angrenzenden Farben erreichen. Eine Schaltfläche, die nur mit einer schwachen Umrandung gezeichnet wird, oder ein Fokusring, der auf eine niedrige Deckkraft eingestellt ist, fehlschlägt, auch wenn der Text der Beschriftung bestanden wird. Chart- und Dashboard-Benutzeroberflächen stoßen an die gleiche Wand; Smashing Magazine dokumentiert, wie Barrierefreiheitsstandards die visuelle Gestaltung von Charts umgestalten, ohne dekoratives Rauschen zu erfordern (Barrierefreiheitsstandards für die Chart-Gestaltung).

Checkliste - Kontrast

- Fließtext ≥ 4,5:1 auf jedem Design (einschließlich Dark Mode) - Großer Text / große Zahlen ≥ 3:1 - Fokusring ≥ 3:1 gegenüber der Oberfläche dahinter - Symbol-only-Affordances ≥ 3:1, wenn das Symbol Bedeutung trägt - Keine alleinige Abhängigkeit von Farbe für Fehler- oder Erfolgszustand (kombinieren mit Text oder Symbol)

Zielgröße und Ziehen nach WCAG 2.2

Mindestzielgröße (2.5.8) erfordert interaktive Ziele mit einer Mindestgröße von 24×24 CSS-Pixeln auf Level AA, mit begrenzten Ausnahmen für inline-Links und bestimmte Abstände. KI-Layouts erzeugen häufig 16-Pixel-Schaltflächen ohne Abstand. Das ist jetzt ein Konformitätsproblem, kein Geschmacksstreit. Abstand, Mindestbreite/Mindesthöhe oder größere Hit-Slop um das sichtbare Symbol herum zählen, wenn der Zeigerzielbereich die Größe erreicht.

Ziehbewegungen (2.5.7) bedeuten, dass jede Ziehinteraktion - Slider-Daumen, Kanban-Karte, Bereichsscrubber - eine einzeilige Alternative wie Pfeilschaltflächen, eine numerische Eingabe oder Klick-zum-Setzen benötigt. Wenn ein Benutzer die Aufgabe nicht ohne Ziehen abschließen kann, entspricht das Muster nicht den Vorschriften. Generatoren lieben Ziehdemos, weil sie in einem GIF interaktiv aussehen; liefern Sie die alternative Steuerung im gleichen PR.

Checkliste - Zeigerzugriff

- Jedes Symbol-Schaltflächen-Hit-Bereich ≥ 24×24 CSS-Px - Angrenzende Ziele haben ausreichenden Abstand oder teilen eine konforme Ausnahme - Jede Ziehbewegung hat einen nicht-Zieh-Pfad, der in der Benutzeroberfläche dokumentiert ist - Touch-Ziele funktionieren noch, wenn die OS-Textgröße erhöht wird

Fokusreihenfolge, Sticky-Chrome und 2.4.11

Fokus nicht verdeckt (Mindestanforderung) erfordert, dass ein Steuerelement, wenn es die Tastaturfokus erhält, nicht vollständig von autor-erzeugtem Inhalt verdeckt wird. Sticky-Header, Bottom-Navigationsleisten, Cookie-Banner und schwebende "AI-Hilfe"-Widgets sind die üblichen Störer in vibe-codierten Apps. Durchlaufen Sie die Seite mit diesen Schichten geöffnet. Wenn das fokussierte Feld unter einer 72px-Sticky-Leiste sitzt, korrigieren Sie die Scroll-Padding oder die Stapelung, nicht die Sehschärfe des Benutzers.

Bestätigen Sie auch 2.4.7 (Fokus sichtbar): Jedes interaktive Element zeigt einen sichtbaren Fokus-Indikator. Generatoren entfernen oft Umrandungen "aus ästhetischen Gründen." Stellen Sie einen hochkontrastigen Ring wieder her, der 1.4.11 erfüllt.

Checkliste — Fokus

- Sichtbarer Fokus auf Links, Buttons, Eingaben, benutzerdefinierten Widgets - Fokusreihenfolge entspricht der Lesereihenfolge für die Hauptflüsse - Modals fangen den Fokus ein und geben ihn beim Schließen an den Aufrufer zurück - Sticky/feste Benutzeroberfläche deckt das fokussierte Steuerelement nie vollständig ab (2.4.11) - Skip-Link vorhanden und funktionierend auf inhaltsreichen Seiten

ARIA: semantische HTML zuerst, ARIA zweite

Generatoren erfinden ARIA-Rollen, die nicht mit dem Verhalten übereinstimmen, oder fügen role="button" zu Elementen hinzu, die bereits Links sind. Prefer native Elemente: <button>, <a>, <nav>, <main>, Formularelemente. ARIA füllt Lücken; es ersetzt keine Semantik. Falsche Rollen verunsichern Screen-Reader und können die tatsächliche Aktion verbergen. Behandeln Sie jedes generierte aria-*-Attribut als zu überprüfende Behauptung.

Wenn Sie tatsächlich ein benutzerdefiniertes Widget benötigen, folgen Sie einem veröffentlichten Muster aus dem ARIA Authoring Practices Guide und überprüfen Sie Rollen/Zustände gegen WAI-ARIA 1.2. Das Kopieren und Einfügen einer Rollen-Zeichenfolge aus einer Chat-Antwort ohne Tastaturrecht ist, wie "zugängliches" Markup unzugängliches Verhalten wird.

Warum automatisierte Überprüfungen nur einen Teil des Bildes erfassen

Die Branche und die Dokumentation von Anbietern geben in der Regel eine automatisierte Abdeckung im Bereich von etwa 30-40% der realen Barrierefreiheitsprobleme an. Tools finden fehlendes Alt-Text, viele Kontrastfehler und ungültige ARIA. Sie können jedoch nicht vollständig beurteilen, ob die Fokusreihenfolge der Lesereihenfolge entspricht, ob Drag-Alternativen existieren oder ob der Name eines Icon-Buttons verständlich ist. Diese Lücke ist der Grund, warum ein sauberer Lighthouse-Score kein Beweis für die Konformität mit WCAG 2.2 ist. Kombinieren Sie einen automatisierten ersten Durchgang mit Tastaturtests und einer manuellen Überprüfung der generierten Markup.

Zitieren Sie keine einzelne Prozentzahl als Gesetz; behandeln Sie sie als Planungsannahme: Scanner sind notwendig und unzureichend. Budgetieren Sie menschliche Zeit für die Urteils Ebene bei jedem Release.

Häufige Fehler, die Teams bei der AI-Benutzeroberfläche machen

- Regenerieren nach manuellen Korrekturen ohne Sperren von Token oder Primitiven, so dass Kontrast und Namen verschwinden - Vertrauen in die Demo-Aufzeichnung (nur Maus) als Beweis, dass der Tastaturpfad funktioniert - Stapeln von ARIA, um einen Linter zu beruhigen, anstatt den Elementtyp zu korrigieren - Versand von Marketing-Gradienten, die nie im Live-DOM gemessen wurden - Bezeichnen eines grünen CI-Builds als "konform" in Vertriebspräsentationen - diese Sprache übertreibt

Entscheidungskriterien: AA jetzt oder später

Lieferung von Blockierern für die meisten B2B-Apps bei AA:

- Leere zugängliche Namen auf primären Aktionen - Body-Text unter 4,5:1 im Standard-Design - Kein Keyboard-Pfad durch den Checkout oder die Kernaufgabe - Fokus vollständig durch Sticky-UI auf erforderlichen Feldern versteckt - Drag-only-Kritische Aktionen ohne Alternative

Aufschieben nur mit einem Besitzer und einem Datum: sekundäre dekorative Animationen, nicht-kritische Diagramme mit einer bereits vorhandenen Daten-Tabelle-Alternative, Hilfe-Widget-Politur, die die Aufgaben nicht blockiert. Aufgeschoben ist nicht vergessen.

Wofür dies NICHT ist

Diese Checkliste ist keine vollständige WCAG-Prüfung, keine VPAT und keine Rechtsberatung. Sie behauptet nicht, dass A11yGuard (oder jedes Tool) die Konformität, die ADA-Konformität oder dass automatisierte Scans "nie verpassen" Probleme garantiert. Wir veröffentlichen keine erfundenen Kundenmetriken oder vorher/nachher-Umrechnungssprünge. Das Produkt automatisiert den messbaren ersten Durchgang; Sie benötigen immer noch eine menschliche QA für Urteilskriterien und für die Verwendung von Sprache mit Kunden oder Regulierungsbehörden.

Abschluss

Drucken Sie die Tabellen, frieren Sie den Branch ein, führen Sie den Scanner aus und führen Sie dann den Tastatur- und Namensvorgang durch. Halten Sie den normativen WCAG-Text und die Quick Reference während der Diskussion über Edge-Fälle offen. Wenn das Modell einen Bildschirm neu generiert, führen Sie die gleiche Liste erneut aus — die Accessibility-Schuld in vibe-codierten Apps ist eine Schleife, kein Einmalprojekt.

Referenzen

- WCAG 2.2 - WCAG 2.2 Quick Reference - WAI Accessibility Fundamentals - ARIA Authoring Practices Guide (APG) - WAI-ARIA 1.2 - Smashing Magazine — Accessibility-Standards und Chart-Design - ADA.gov — KI und Behinderten-Diskriminierungsrichtlinien