von A11yGuard (LX AI)

Kontrast und ARIA in vibe-codierten Apps

Vibe-codierte Benutzeroberflächen scheitern an zwei Punkten, die Scanner selten gemeinsam erfassen: Kontrastmathematik und zugängliche Namen. Ein Component kann eine Farbprüfung bestehen und dennoch unbrauchbar sein, wenn seine Rolle falsch ist oder sein Name leer ist. Beides bricht erneut bei der Regeneration, sodass die Korrektur in einer Checkliste und nicht in einer Einzelbearbeitung gehören sollte.

Wie Kontrastmathematik in generierten Designs tatsächlich fehlschlägt

Wenn ein Modell eine Palette erfindet, kopiert es normalerweise eine Mood-Board: weiche Schiefer-Texte, Pastell-Chips, transparente Karten. Das sieht auf einem Designer-Monitor gut aus und scheitert an den Verhältnissen in WCAG 2.2, sobald echter Inhalt hinzugefügt wird. Body-Texte benötigen für Level AA ein Kontrastverhältnis von 4,5:1 gegenüber ihrem Hintergrund (Erfolgskriterium 1.4.3). Großer Text kann ein 3:1-Verhältnis verwenden. Generatoren führen diese Mathematik nicht aus; sie wählen Hex-Werte, die sich "zweitrangig" anfühlen.

Ein zweiter Fehlermodus ist der Hintergrund, den man im Figma-Export nicht sehen kann. Text über einem Hero-Bild, einem Farbverlauf oder einem Glassmorphismus-Panel benötigt den gerenderten Hintergrund, nicht den Token-Namen bg-surface. Proben Sie den Pixel unter dem Glyphen oder Sie werden eine Token-Prüfung bestehen und dennoch unleserlichen Text versenden. Diagramme und Daten-Tinte haben die gleiche Falle; Smashing Magazines Schreibweise über Diagramm-Kontrast zeigt, wie Standard-Schwellenwerte die visuelle Gestaltung ändern, ohne jedes Diagramm in einen Regenbogen zu verwandeln (Barrierefreiheitsstandards für die Diagrammgestaltung).

Nicht-Text-Kontrast ist der stille Zwilling

Erfolgskriterium 1.4.11 (Nicht-Text-Kontrast) fordert ein 3:1-Verhältnis für die Grenzen von Benutzeroberflächen-Komponenten, grafische Objekte, die zum Verständnis des Inhalts erforderlich sind, und Zustände wie Fokus-Indikatoren. Eine schwache 1px-Grenze, die sich "premium" anfühlt, scheitert oft. Ein Fokus-Ring, der auf outline: 2px solid rgba(15,118,110,.35) gesetzt ist, scheitert auch dann, wenn der Label-Text 4,5:1 besteht. Icon-only-Steuerungen, die auf einem hellen Grau-Glyphen gegen Weiß basieren, sind die gleiche Klasse von Fehlern. Behandeln Sie Grenz-, Icon- und Fokus-Farben als erste-Klasse-Tokens mit veröffentlichten Verhältnissen, nicht als dekorative Nachgedanken. Die WCAG 2.2-Schnellreferenz ist der schnellste Ort, um zu überprüfen, welche Kriterien auf AA anwendbar sind.

Tokens schlagen einheitliche Hex-Patches

Die dauerhafte Lösung ist langweilig: definieren Sie semantische Farb-Tokens (text-primary, text-muted, border-strong, focus-ring) mit gemessenen Verhältnissen gegen jeden zugelassenen Hintergrund, dann verbieten Sie dem Modell, Hex-Strings in Komponenten-Dateien zu erfinden. Legen Sie die Verbotsregel in der Aufforderung und in CI fest. Wenn die Regeneration color: #94a3b8 in eine Schaltflächen-Bezeichnung umschreiben kann, war Ihr "Fix" nie ein Fix. Kombinieren Sie Tokens mit einer CSS-Variable-Schicht, damit Dark-Mode und Marketing-Themes die gleichen Einschränkungen erben.

Barrierefreie Namen sind keine sichtbaren Bezeichnungen

Screen-Reader sprechen den barrierefreien Namen einer Steuerung aus, nicht die SVG-Pfad-Daten. Eine Icon-Schaltfläche, die ein Mülleimer-Glyphen ohne Textinhalt, ohne aria-label und ohne zugehörige <label> zeigt, wird zu "Schaltfläche" ohne Zweck. Das ist ein Benennungsfehler, kein Kontrastfehler, daher bleiben Farb-Prüfungen grün, während Tastatur-Benutzer blockieren.

Die Reihenfolge der Namensberechnung ist durch den Barrierefreiheits-Baum definiert: Inhaltstext, labelled-by-Referenzen, dann autor-supplizierte Bezeichnungen wie aria-label. Generatoren emittieren oft den Glyphen und eine Tailwind-Klasse und hören auf. Sie erfinden auch doppelte Namen ("Schließen" auf jeder Abbrechen-Steuerung in einem Stapel von Modals) oder Namen, die die Icon-Metapher beschreiben, anstatt der Aktion ("Mülleimer" anstatt "Rechnung löschen"). Bevorzugen Sie Aktions-Sprache, die der sichtbaren Ausführung entspricht.

Wo Namen nach der Regeneration verschwinden

Regeneration löscht inline aria-label-Werte, die von Hand hinzugefügt wurden, weil das Modell sie als optionales Rauschen behandelt. Überleben Sie das, indem Sie:

- Icon-Karten in einem Modul halten, das immer Glyphen + Namenszeichen paart - Sichtbaren Text neben Icons verwenden, wenn Platz vorhanden ist (Name kommt kostenlos) - CI fehlschlagen, wenn ein interaktives Element einen leeren barrierefreien Namen hat - PRs ablehnen, die <div onClick> ohne Rolle und Namenspaket einführen

WAI's Grundlagen-Überblick ist immer noch der beste kurze Leitfaden darüber, warum Namen, Rollen und Zustände zusammen reisen müssen (WAI Accessibility Fundamentals).

Wenn ARIA hilft — und wenn es den Fehler versteckt

Native HTML gibt bereits Rollen, Tastaturverhalten und viele Zustände aus. Ein echter <button> ist fokussierbar, aktiviert sich bei Enter und Space und nimmt an Formularen teil. Ein <div role="button" tabindex="0">, das ein Modell eingefügt hat, benötigt immer noch diese Tasten-Handler, einen gedrückten oder deaktivierten Zustand, wenn relevant, und einen zugänglichen Namen. Wenn man eines davon auslässt, kündigt die Assistenztechnologie einen Button an, der nichts auf Space tut. Der ARIA Authoring Practices Guide (APG) existiert für die Fälle, in denen man tatsächlich ein benutzerdefiniertes Widget benötigt; er ist keine Lizenz, um einen Div in jede Steuerung umzustellen.

Häufige ARIA-Fehler in vibe-codierter Markierung

- Rolle auf dem falschen Element: role="button" auf einem <a href>, oder role="link" auf einem Button, der ein Formular sendet - Dekoratives ARIA: aria-label, das sichtbaren Text dupliziert und einige AT-Kombinationen verwirrt - Veralteter Zustand: aria-expanded="true" nach einem Client-Render, das ein Panel schließt - Landmark-Spam: fünf role="navigation"-Regionen ohne Namen, so dass Skip-Listen zu Rauschen werden - Live-Regionen für Eitelkeit: aria-live="polite" auf jedem Toast, so dass die Seite plappert

Die WAI-ARIA 1.2-Empfehlung beschreibt die Ontologie von Rollen und Eigenschaften; verwenden Sie sie, wenn Sie über HTML hinausgehen müssen, nicht als Standardlayer auf jedem Knoten (WAI-ARIA 1.2).

Tastaturpfade, die der Generator vergisst

Fokus-Reihenfolge, sichtbarer Fokus und Skip-Links fallen aus einem Einmal-Layout heraus. Kriterium 2.4.7 erfordert einen sichtbaren Fokus-Indikator. Kriterium 2.4.11 (Fokus nicht verdeckt — Minimum), neu in WCAG 2.2, erfordert, dass Sticky-Header, Cookie-Banner und Floating-Chat-Widgets den fokussierten Steuerung nicht vollständig verdecken. Taben Sie die generierte Seite von oben nach unten. Bestätigen Sie, dass die Reihenfolge der Lesereihenfolge entspricht. Bestätigen Sie, dass keine Steuerung hinter einer Überlagerung zurückgelassen wird. Bestätigen Sie, dass der Fokus-Ring den 1.4.11 gegenüber dem Hintergrund erfüllt.

Ein kurzer manueller Tastatur-Durchlauf (15 Minuten)

- Trennen Sie die Maus. Öffnen Sie die Seite in einem sauberen Profil. - Taben Sie von der Browser-Chrome in das Dokument. Gibt es einen Skip-Link, der funktioniert? - Erreichen Sie jede primäre Aktion ohne Pfeil-Tasten-Folklore, die die Komponente nie implementiert hat. - Öffnen und schließen Sie jedes Modal mit Escape. Kehrt der Fokus zum Aufrufer zurück? - Aktivieren Sie den Sticky-Header und den Cookie-Banner. Können Sie den fokussierten Steuerung noch sehen? - Drücken Sie jeden Icon-Button mit einem Screen-Reader (NVDA oder VoiceOver). Entsprechen der Name und die Aktion?

Dieser Durchlauf erfasst, was Lighthouse nicht erfasst. Automatisierte Tools sind ein erster Filter; sie sind kein Konformitätszertifikat. Für die Einstellung und automatisierte Entscheidungstools erinnert die US-Leitlinie auch daran, dass AI-Features Risiken der Behinderungsdiskriminierung schaffen können, wenn Schnittstellen Menschen ausschließen, die Assistenztechnologie verwenden (ADA.gov AI-Leitlinie). Produkt-UI ist nicht von diesem Denken ausgenommen, nur weil ein Modell das JSX geschrieben hat.

Stellen Sie sicher, dass der Check die Regeneration überlebt

Da die Regeneration manuelle Patches löscht, sieht dauerhafte Kontrolle aus wie Infrastruktur:

- Design-Tokens mit gemessenem Kontrast, überprüft in einem Unit-Test oder Stylelint-Plugin - Komponenten-Primitives (IconButton, TextField), die immer Namen und Fokus-Stile ausgeben - CI-Zugang für Barrierefreiheit (axe oder äquivalent) auf Pull-Requests, der bei leeren Namen und Kontrast fehlschlägt - Einschränkungen für Prompts, die rohe Hex-Codes und div-as-Button ohne explizite Ausnahmeflagge verbieten - Überprüfung der Tastatur durch einen Menschen auf jeder vertikalen Ebene vor der Veröffentlichung, protokolliert als Checkliste-Punkt, nicht als Stimmung

Behandeln Sie generierte Markup als unvertrauenswürdigen Entwurfsoutput. Überprüfen Sie es auf die gleiche Weise, wie Sie einen Junior-PR überprüfen, der von einem Wochenend-Hackathon stammt: Nehmen Sie an, dass Namen fehlen, nehmen Sie an, dass ARIA theatralisch ist, nehmen Sie an, dass der Text pastellfarben ist.

Entscheidungskriterien: Fehler in Tokens, Primitives oder Seiten-Code beheben?

Verwenden Sie diese Reihenfolge, wenn ein Fehlerbericht eingegangen ist:

- Wenn viele Seiten den falschen abgedunkelten Textfarbwert teilen, korrigieren Sie den Token und messen Sie die Verhältnisse erneut. - Wenn ein Steuerelementtyp Namen fehlt (alle Symbol-Schaltflächen), korrigieren Sie das Primitive und löschen Sie lokale Patches. - Wenn ein einzelnes Marketing-Hero über einem Foto fehlschlägt, korrigieren Sie die Überlagerung oder die Textbehandlung auf dieser Seite. - Wenn ARIA auf das falsche Element geklebt wurde, ersetzen Sie es durch ein natives Steuerelement, bevor Sie weitere Attribute schreiben.

Seitenbezogene ARIA-Patches sind die weniger haltbaren. Sie sind auch diejenigen, die Vibe-Coding-Sitzungen gerne ausgeben. Drücken Sie Korrekturen nach oben.

Was dies nicht ist

Dieser Artikel ist kein Zertifikat für die Konformität mit den WCAG-Richtlinien für Ihr Produkt. Es handelt sich nicht um eine Rechtsberatung und es wird nicht behauptet, dass die Verwendung von A11yGuard (oder einem anderen Scanner) eine Website "ADA-konform" oder "100% zugänglich" macht. Automatisierte Kontrast- und ARIA-Prüfungen erfassen messbare Fehler, verpassen jedoch Urteilsentscheidungen über die Lesereihenfolge, Drag-Alternativen und ob ein Name verständlich ist. Wir erfinden keine Kundenlogos, Conversion-Lifts oder "nie einen Kontrastfehler verpassen"-Garantien. Die ehrliche Produktrolle ist ein schneller erster Durchgang plus eine Checkliste, die Sie immer noch besitzen.

Schluss

Kontrastmathematik und zugängliche Namen scheitern unabhängig voneinander und regenerieren sich zusammen. Sperren Sie Token, bevorzugen Sie native Steuerelemente, überprüfen Sie ARIA gegen APG, wenn Sie anpassen müssen, und halten Sie eine Tastaturprüfung im Release-Ritual ein. Verwenden Sie die nachfolgenden Referenzen, wenn ein Anspruch über ein Verhältnis oder ein Kriterium strittig ist - der Spezialtext gewinnt gegen das Gedächtnis eines Chat-Modells.

Referenzen

- WCAG 2.2 - WCAG 2.2 Schnellreferenz - WAI-Zugriffsgrundlagen - ARIA-Autorenhandbuch (APG) - WAI-ARIA 1.2 - Smashing Magazine — Zugriffsstandards und Chart-Design - ADA.gov — KI und Leitfaden zur Behinderungsdiskriminierung