Barrierefreiheits‑Prompts für React- und Flutter‑UI‑Reviews

Was Menschen übersehen, wenn sie eine UI zugänglich machen wollen

Die meisten Barrierefreiheits-Probleme sind keine „großen Redesign“-Sachen. Es sind kleine Details, die entscheiden, ob jemand Ihre UI überhaupt verwenden kann.

Was normalerweise zuerst kaputtgeht, ist überraschend konsistent. Eine Seite kann optisch in Ordnung wirken, einen schnellen visuellen Check bestehen und trotzdem schwer per Tastatur oder Screenreader zu bedienen sein.

Das sind die ersten Bereiche, in denen UIs oft versagen:

• Tastaturzugänglichkeit: wichtige Steuerelemente sind nicht erreichbar oder man bleibt in einem Modal gefangen
• Fokusreihenfolge und Fokuszustände: der Fokus springt herum oder man sieht nicht, wo man sich befindet
• Beschriftungen und Namen: Eingaben und Buttons haben unklare oder fehlende zugängliche Namen
• Ansagen: dynamische Änderungen passieren, aber Screenreader werden nicht informiert
• Kontrast und Lesbarkeit: Text, Icons und Fehlerzustände sind schwer zu erkennen

Das Schwierige ist, wie leicht man regressiert. Eine „kleine“ Änderung wie ein Button durch ein Icon ersetzen, eine Karte in einen Gesten-Handler einhüllen oder ein benutzerdefiniertes Dropdown hinzufügen kann die Tastaturunterstützung entfernen, die Fokusreihenfolge zerstören oder eine Beschriftung verschwinden lassen, ohne dass es jemand bemerkt.

Ein häufiges Szenario: In einem React-Formular wird ein neues „Löschen“-Icon innerhalb eines Eingabefelds hinzugefügt. Es sieht nützlich aus, aber das Icon ist nicht fokusierbar, hat keinen Namen und überschreibt Klick-Events. Jetzt können Tastaturnutzer es nicht aktivieren, und Screenreader-Nutzer hören ein unbeschriftetes Steuerelement.

Dieser Beitrag liefert zwei Dinge: kopierbare Prompts, die Sie mit Ihrem UI-Code (React und Flutter) verwenden können, und einen wiederholbaren Prüfablauf, den Sie in Minuten durchführen können. Das Ziel ist nicht Perfektion am ersten Tag, sondern die Probleme zu finden, die echte Nutzer*innen blockieren.

Wenn Sie Produktbildschirme bauen, aber kein Accessibility-Spezialist sind, ist das für Sie. Es passt auch zu Teams, die mit Chat-basierten Tools wie Koder.ai arbeiten, wo UI-Änderungen schnell passieren und Sie schnelle, konsistente Checks brauchen. Wenn Sie einen praktischen Einstieg wollen, sind diese Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews so gestaltet, dass Sie sie jedes Mal wiederverwenden können, wenn Sie UI ausliefern.

Die 5 Checks, die die meisten Probleme schnell finden

Wenn Sie nur 15 Minuten haben, um einen Bildschirm zu prüfen, finden diese Checks die Probleme, die am häufigsten Nutzer*innen blockieren. Sie funktionieren für React und Flutter und passen gut in Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews.

1) Lässt sich die UI nur mit der Tastatur bedienen?

Versuchen Sie, sich ohne Maus durch die Seite zu bewegen. Verwenden Sie Tab und Shift+Tab zum Navigieren, Enter und Space zum Aktivieren und Pfeiltasten dort, wo ein Widget wie ein Menü, Tabs oder eine Liste aussieht.

Ein schneller Indikator: Wenn Sie in einem Modal gefangen sind oder ein wichtiges Steuerelement (z. B. „Schließen") nicht erreichen können, stimmt etwas nicht.

2) Ist die Fokusreihenfolge sinnvoll und ist der Fokus sichtbar?

Beim Tabben sollte der Fokus der visuellen Anordnung folgen (oben nach unten, links nach rechts) und niemals zu verborgenen Bereichen springen. Der Fokus muss außerdem offensichtlich sein. Wenn das Design subtile Konturen verwendet, prüfen Sie, dass diese auf hellen und dunklen Hintergründen sichtbar bleiben.

3) Haben Steuerelemente klare Namen?

Ein Screenreader sollte für jedes interaktive Element einen nützlichen Namen ankündigen. „Button“ reicht nicht. Icons brauchen ein zugängliches Label, und Formularfelder brauchen eine Beschriftung, die verbunden bleibt, auch wenn Platzhalter verschwinden.

4) Sind Kontrast und Textgröße in Ordnung?

Prüfen Sie kleinen Text, deaktivierten Text und Text auf farbigen Buttons. Testen Sie auch Zoom: vergrößern Sie die Schrift und stellen Sie sicher, dass das Layout nicht überlappt oder wichtigen Inhalt abschneidet.

5) Werden Änderungen klar angesagt?

Wenn sich etwas ändert (Fehler, Laden, Erfolg), sollten Nutzer*innen nicht raten müssen. Verwenden Sie inline Fehlermeldungen in der Nähe des Feldes, geben Sie Formularfehler bekannt und machen Sie Ladezustände deutlich.

Wenn Sie Bildschirme in Koder.ai bauen, fragen Sie es: „Verify keyboard-only flow, focus order, and screen reader labels for this page“, und überprüfen Sie dann das Ergebnis mit den obigen Schritten.

Legen Sie Ihren Prüfbereich fest, bevor Sie die UI ändern

Barrierefreiheitsarbeit geht schneller, wenn Sie vor dem Anfassen von Komponenten entscheiden, was Sie prüfen und was „gut genug“ ist. Ein enger Scope macht Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews nützlicher, weil das Modell sich auf echte Bildschirme und echte Interaktionen konzentrieren kann.

Wählen Sie die wichtigen Journeys

Beginnen Sie mit 2 bis 4 kritischen Nutzerreisen, nicht dem ganzen Produkt. Gute Kandidaten sind Prozesse, die Menschen abschließen müssen, um Wert zu erhalten, und die sie aussperren können, wenn sie fehlschlagen.

Für die meisten Apps ist das etwas wie Anmelden, ein primärer „Erstellen oder Kaufen“-Flow (Checkout, Buchung, Absenden) und ein Bereich wie Einstellungen oder Profil.

Schreiben Sie dann die genauen Bildschirme in jeder Journey auf (auch wenn es nur 5 bis 8 Bildschirme sind). Schließen Sie auch die „Zwischenzustände“ ein: Fehlermeldungen, leere Zustände, Ladezustände und Bestätigungsdialoge. Genau dort brechen Fokus und Screenreader-Ausgaben oft.

Ein konkretes Beispiel: Wenn Sie einen kleinen CRM-Bildschirm in Koder.ai bauen, scope ihn auf: „Sign in -> open Contacts -> add contact -> save -> see success message“. Dieser einzelne Flow berührt Formulare, Validierung, Dialoge und Ansagen.

Entscheiden Sie, was „Bestanden“ bedeutet

Bleiben Sie praktisch. Orientieren Sie sich an WCAG-AA-Erwartungen, aber übersetzen Sie das in einfache Checks, die Sie schnell anwenden können: Tastatur funktioniert Ende-zu-Ende, Fokus ist sichtbar und logisch, Namen und Labels sind sinnvoll und Kontrast ist lesbar.

Verwenden Sie ein einfaches Pass/Fail-Notat, damit Sie keine Zeit mit Debatten verlieren. Für jeden Bildschirm erfassen Sie:

• Check: (Tastatur, Fokusreihenfolge, Labels, Kontrast, Ansagen)
• Ergebnis: Pass oder Fail
• Beleg: ein Satz, der beschreibt, was passiert ist
• Vermutete Lösung: was wahrscheinlich geändert werden muss (Komponente, Prop, Styling)
• Retest: was nach der Lösung zu prüfen ist

Das hält die Prüfung konsistent zwischen React und Flutter und macht es einfach, Probleme an andere weiterzugeben, ohne das Problem neu zu erklären.

Kopierbare Prompts für React-Komponenten (Tastatur, Labels, Rollen)

Wenn Sie um eine Barrierefreiheitsprüfung bitten, sind die schnellsten Gewinne präzise: welche Komponente, welche Nutzeraktion und wie „gut“ aussehen soll. Diese Barrierefreiheits-Prompts für React und Flutter UI-Reviews funktionieren am besten, wenn Sie den Komponentencode plus eine kurze Beschreibung dessen, was die UI tun soll, einfügen.

Wenn Sie ein chatbasiertes Builder-Tool wie Koder.ai verwenden, fügen Sie den Prompt direkt nach der Erstellung eines Bildschirms oder einer Komponente hinzu, damit Probleme behoben werden, bevor sie sich durch die App ausbreiten.

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

Bevor Sie einen Prompt senden, fügen Sie diese Details hinzu, damit Sie nutzbare Fixes und keine generischen Ratschläge erhalten:

• Was die Komponente ist (z. B.: „Login-Form“, „Pricing-Toggle“, „Settings-Modal“).
• Der Tastaturpfad, dem Nutzer folgen sollen (Startpunkt und Endpunkt).
• Verwendete UI-Bibliothek (MUI, Chakra, Radix, eigene Komponenten).
• Zu testende Zustände (Laden, Fehler, deaktiviert, leere Ergebnisse).
• Ein konkretes Nutzerziel (z. B.: „Plan wechseln und bestätigen").

Kopierbare Prompts für Flutter-Widgets (Semantics, Fokus, Gesten)

Wenn Sie konsistente Ergebnisse wollen, fügen Sie einen Widget-Ausschnitt (oder den ganzen Bildschirm) ein und fragen Sie nach konkreten Checks. Diese Barrierefreiheits-Prompts für React und Flutter UI-Reviews funktionieren am besten, wenn Sie: den Widget-Tree, wie der Bildschirm erreicht wird, und etwaige benutzerdefinierte Gesten angeben.

Prompts, die Sie in die Prüfung einfügen können

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

Schnelle Fixes, die der Assistent vorschlagen sollte

Erwarten Sie Antworten, die ein paar konkrete Muster nennen:

• Hauptinhalt in FocusTraversalGroup einwickeln und FocusTraversalOrder nur bei Bedarf setzen.
• Semantics (oder MergeSemantics) für zusammengesetzte Steuerelemente verwenden und doppelte Labels vermeiden.
• InkWell, IconButton, ListTile, SwitchListTile statt roher GestureDetector-Nutzung bevorzugen.
• Shortcuts + Actions für Nicht-Text-Eingaben hinzufügen (z. B. Enter zum Aktivieren, Escape zum Schließen).

Ein minimales Beispiel, damit eine benutzerdefinierte Karte sich wie ein Button verhält:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

Schritt-für-Schritt: ein einfacher Tastatur- und Fokus-Prüfablauf

Ein schneller Tastatur- und Fokus-Check findet Probleme, die auch Screenreader und Switch-Geräte betreffen. Führen Sie ihn auf einem echten Seitenfluss durch (nicht nur ein einzelner Button) und notieren Sie sich die Schritte, damit Sie denselben Pfad später erneut prüfen können.

Der 5-Schritte-Flow

Wählen Sie zuerst einen „Happy Path“, den ein Nutzer typischerweise durchläuft, z. B. Anmelden, Einstellungen öffnen und Speichern.

1. Machen Sie den gesamten Flow nur mit der Tastatur. Legen Sie die Maus weg. Verwenden Sie Tab und Shift+Tab zum Navigieren, Enter und Space zum Aktivieren und Pfeiltasten dort, wo sie sinnvoll sind. Wenn etwas einen Klick oder Swipe erfordert, markieren Sie es.
2. Stellen Sie sicher, dass der Fokus immer eindeutig ist. Jedes Mal, wenn der Fokus wechselt, sollten Sie sofort sehen, wo er ist. Achten Sie auf dünne Konturen, die auf dunklen Hintergründen verschwinden, entfernte Fokus-Ringe durch CSS oder Flutter-Widgets, die „aktiv“ aussehen, aber keinen Fokus zeigen.
3. Prüfen Sie, ob die Reihenfolge dem Gesehenen entspricht. Der Fokus sollte der visuellen Anordnung und der Lesereihenfolge folgen. Häufige Warnsignale: Springen in die Fußzeile, im Sidebar hängenbleiben oder ein Feld überspringen, weil es nicht fokusierbar ist.
4. Belastungstest für Overlays. Öffnen Sie Menüs, Dialoge und Drawers. Der Fokus sollte in das Overlay wechseln, darin bleiben, solange es offen ist, und beim Schließen an eine sinnvolle Stelle zurückkehren. Escape sollte das Overlay schließen, wenn angebracht.
5. Wiederholen Sie den Test nach jeder Änderung. Beheben Sie ein Problem und führen Sie dann denselben Pfad erneut aus. Notieren Sie, was sich verbessert hat und was schlechter wurde, besonders Änderungen in der Fokusreihenfolge und neue „Dead Ends“.

Was Sie währenddessen protokollieren sollten

Halten Sie es einfach: Seitenname, was Sie gedrückt haben, was passiert ist und was Sie erwartet haben. Dieses kleine Log macht es einfach zu bestätigen, dass ein React-Refactor oder ein Flutter-Widget-Tausch die Tastaturzugänglichkeit nicht stillschweigend gebrochen hat.

Screenreader-freundliche Namen, Labels und Ansagen

Screenreader „sehen" Ihre UI nicht. Sie verlassen sich auf Namen, Rollen und kurze Meldungen, die erklären, was sich geändert hat. Fehlt der Name oder ist er vage, wird die App zur Ratespiel.

Beginnen Sie mit Formularfeldern. Jedes Eingabefeld braucht ein echtes Label, das auch dann gültig bleibt, wenn das Feld ausgefüllt ist. Platzhalter sind Hinweise, keine Labels, und verschwinden oft, sobald der Nutzer tippt.

Icon-only-Aktionen sind ein weiterer häufiger Fehler. Ein Papierkorb-Icon, ein Stift oder ein Drei-Punkte-Menü braucht einen aussagekräftigen Namen, der das Ergebnis beschreibt, nicht die Form. „Projekt löschen“ ist besser als „Button“ oder „Papierkorb".

Überschriften und Abschnittsbezeichnungen sind wichtig, weil sie die Seitenstruktur bilden. Verwenden Sie Überschriften, um Struktur zu vermitteln, nicht nur Styling. Ein Screenreader-Nutzer springt über Überschriften zu „Billing" oder „Team members", daher sollten die Bezeichnungen zum Inhalt passen.

Fehlermeldungen sollten spezifisch und handlungsorientiert sein. „Ungültige Eingabe" reicht nicht. Sagen Sie, was schiefgelaufen ist und was als Nächstes zu tun ist, z. B. „Passwort muss mindestens 12 Zeichen haben" oder „E-Mail-Adresse fehlt das @-Zeichen".

Kopierbare Prüf-Prompts (React und Flutter)

Verwenden Sie diese Prompts bei der Prüfung eines Bildschirms (oder wenn Sie ein Tool wie Koder.ai bitten, Komponenten zu aktualisieren):

• „Durchgehen Sie diesen Screen und stellen Sie sicher, dass jedes Texteingabefeld ein sichtbares Label hat und dass der zugängliche Name damit übereinstimmt (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText).“
• „Finden Sie icon-only Buttons und geben Sie jedem einen zugänglichen Namen, der die Aktion erklärt (React: aria-label; Flutter: Tooltip oder Semantics(label: ...)).“
• „Prüfen Sie Überschriften: Verwenden Sie in React die richtigen Heading-Level und in Flutter klare Abschnittstitel, damit die Struktur korrekt vorgelesen wird."
• „Überarbeiten Sie Validierungsfehler so, dass sie sagen, was passiert ist und wie man es behebt, und stellen Sie sicher, dass der Fehler beim Auftreten angekündigt wird."

Ansagen für dynamische Änderungen

Viele Bildschirme ändern sich ohne Seiten-Reload: Profil speichern, ein Element hinzufügen, Ergebnisse laden. Stellen Sie sicher, dass diese Änderungen angesagt werden.

Für React sind aria-live-Regionen sinnvoll (polite für „Gespeichert", assertive für kritische Fehler). Für Flutter nutzen Sie Semantics und machen Statusmeldungen sichtbar (z. B. Banner oder SnackBar), damit sie gelesen werden, nicht nur angezeigt. Ein schneller Check: Lösen Sie „Speichern" aus und bestätigen Sie, dass Sie eine kurze Meldung wie „Änderungen gespeichert" hören, ohne dass der Fokus vom Button wegspringt.

Kontrast- und visuelle Lesbarkeits-Checks, die nicht ewig dauern

Die meisten Kontrast- und Lesbarkeitsprobleme fangen Sie in wenigen Minuten ab, wenn Sie sich auf die Stellen konzentrieren, bei denen Menschen wirklich kämpfen: kleiner Text, Icons, Fokusringe und Statusfarben. Das ist ein praktischer Teil der Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews, weil es leicht zu prüfen und leicht zu beheben ist.

Ein 10-Minuten-Kontrast-Check

Scannen Sie einen Bildschirm bei 100% Zoom und dann bei 200%. Wenn etwas schwerer lesbar wird, ist es meist ein Kontrast-, Gewicht- oder Abstandproblem, nicht ein „Nutzerproblem".

Prüfen Sie diese fünf Stellen zuerst:

• Fließtext, Bildunterschriften und Hilfetext (insbesondere hellgrau auf weiß)
• Deaktivierte Zustände (deaktiviert sollte wie deaktiviert aussehen, aber trotzdem lesbar sein)
• Icons ohne Labels (ein blasses Icon ist für viele Nutzer*innen praktisch unsichtbar)
• Fokusindikatoren (Ring/Kontur sollte sich deutlich vom Hintergrund abheben)
• Fehler- und Erfolgsmeldungen (Text und Icon, nicht nur Farbe)

Eine einfache Regel: Wenn Sie zusammenkneifen müssen, müssen es auch Ihre Nutzer*innen. Wenn Sie bei einem Farbpaar unsicher sind, schalten Sie den Text testweise auf reines Schwarz oder reines Weiß. Wenn die Lesbarkeit deutlich besser wird, war der Kontrast zu niedrig.

Fokus-Sichtbarkeit wird oft übersehen. Stellen Sie sicher, dass der Fokusring dick genug ist, um aufzufallen, und nicht dieselbe Farbe wie der Hintergrund hat. Wenn Sie einen „ausgewählten" Zustand in einer Liste haben, sollte er auch in Graustufen erkennbar sein, z. B. durch ein Icon, eine Unterstreichung oder eine klare Umrandung.

Mobile Lesbarkeit: Targets und Themes

Auf Mobilgeräten geht es bei visueller Klarheit auch um Touch. Buttons und icon-only Aktionen sollten großzügige Tap-Ziele und Abstände haben, damit Nutzer*innen nicht das falsche Steuerelement treffen.

Führen Sie einen schnellen Theme-Check durch: Dark Mode umschalten und, falls verfügbar, High-Contrast-Einstellungen testen. Prüfen Sie Text auf Flächen, Trennlinien und Fokusringe erneut. Ein häufiger Bug ist ein Fokusring, der im Dark Mode verschwindet, oder ein inaktives Icon, das fast dieselbe Farbe wie sein Hintergrund annimmt.

Wenn Sie UI schnell in einem Tool wie Koder.ai generieren, fügen Sie einen zusätzlichen Prüfschritt hinzu: Bitten Sie nach dem ersten Layout um einen „Kontrast- und Fokusring-Pass", bevor Sie die Optik polieren.

Häufige Fehler, die immer wieder auftreten

Die meisten Accessibility-Bugs wiederholen sich, weil sie wie kleine UI-Anpassungen wirken, nicht wie Produktverhalten. Wenn Sie Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews verwenden, achten Sie zuerst auf diese Muster.

Platzhaltertext ist kein Label. Ein Platzhalter verschwindet, sobald jemand tippt, und viele Screenreader behandeln ihn nicht als Feldname. Verwenden Sie ein echtes sichtbares Label (oder einen expliziten zugänglichen Namen), sodass das Feld leer, ausgefüllt und im Fehlerfall verständlich bleibt.

Fokusstile werden entfernt, weil sie „unschön" aussehen. Das macht Tastaturnutzer*innen oft verloren. Wenn Sie die Standardkontur ändern, ersetzen Sie sie durch etwas ebenso Eindeutiges: einen starken Ring, eine Hintergrundänderung und genug Kontrast zur Seite.

Ein weiterer häufiger Fehler sind „Fake“-Buttons. In React ist es verlockend, ein div mit onClick zu verwenden, in Flutter einen Container mit GestureDetector. Ohne passende Semantik leiden Tastaturunterstützung und Screenreader. Native Controls (button, a, TextButton, ElevatedButton) geben Fokus, Rolle, deaktivierten Zustand und Aktivierungsverhalten kostenlos mit.

Dialog- und Formular-Fokus-Bugs sind subtil, aber schmerzhaft. Nach dem Schließen eines Modals oder dem Speichern eines Formulars springt der Fokus oft nach oben auf die Seite oder verschwindet. Das passiert, wenn der Fokus nicht auf das auslösende Element zurückgesetzt wird oder wenn die Speichern-Aktion die Seite neu rendert und den Fokus fallen lässt. Nutzer*innen müssen dann neu suchen, wo sie waren.

Übermäßiger Einsatz von ARIA (oder Flutter Semantics) kann ebenfalls Probleme verursachen. Rollen und Labels überall hinzuzufügen kann mit dem, was das native Element bereits bietet, kollidieren und zu doppelten Ansagen oder falschen Namen führen.

Eine kurze „Repeat Issues"-Prüfung, die Sie bei der Bildschirmprüfung anfordern können:

• Bestätigen Sie, dass jedes Eingabefeld ein persistentes Label hat, nicht nur einen Platzhalter
• Bestätigen Sie, dass jedes interaktive Element ein echtes Steuerelement mit korrekter Rolle ist
• Bestätigen Sie, dass Fokus immer sichtbar ist und nicht entfernt wird, ohne dass ein Ersatz vorhanden ist
• Bestätigen Sie, dass Fokus nach Dialogen, Toasts und Speichern zum Auslöser zurückkehrt
• Bestätigen Sie, dass ARIA/Semantics nur das ergänzt, was native Controls nicht leisten

Wenn Sie UI per Chat generieren (z. B. in Koder.ai), fügen Sie diese Punkte als Abnahmekriterien in Ihren Prompt, damit der erste Entwurf die häufigen Fallstricke bereits vermeidet.

Beispiel-Durchgang: ein Bildschirm, End-to-End

Stellen Sie sich einen einfachen Einstellungsbildschirm vor: ein Profilformular (Name, E-Mail), zwei Toggles (E-Mail-Benachrichtigungen, Dark Mode), ein „Änderungen speichern"-Button und ein Toast, das nach dem Speichern erscheint.

Beginnen Sie mit der Tastatur. Die erwartete Fokusreihenfolge sollte der visuellen Reihenfolge entsprechen: oben nach unten, links nach rechts. Beim Tabben darf der Fokus niemals in den Toast-Bereich, die Fußzeile oder ein verborgenes Menü springen.

Ein schneller Pass, der für die meisten Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews funktioniert:

• Drücken Sie Tab von oben: Fokus landet auf Name, dann E-Mail, dann Email-Benachrichtigungen-Toggle, dann Dark-Mode-Toggle, dann Änderungen speichern.
• Verwenden Sie Shift+Tab, um rückwärts zu gehen, und prüfen Sie, dass es sauber umkehrt.
• Bei Toggles sollte Space umschalten. Pfeiltasten sollten den Fokus nicht einsperren.
• Bei „Änderungen speichern" sollte Enter abschicken und der Fokus nach dem Absenden nicht verschwinden.
• Wenn der Toast erscheint, sollte der Fokus dort bleiben, wo er war, es sei denn, der Toast enthält eine Aktion (z. B. „Undo").

Prüfen Sie jetzt, was ein Screenreader ansagt. Jedes Steuerelement braucht einen klaren Namen, eine Rolle und einen Zustand. Zum Beispiel: „Name, Textfeld, erforderlich" und „Email-Benachrichtigungen, Schalter, an". Wenn das E-Mail-Feld einen Fehler hat, sollte dieser angesagt werden, wenn der Fokus das Feld betritt und wenn der Fehler erscheint (z. B.: "E-Mail, Textfeld, ungültig, Geben Sie eine gültige E-Mail-Adresse ein"). Der Speichern-Button sollte als „Änderungen speichern, Button" vorgelesen werden und nur dann deaktiviert sein, wenn auch der Grund kommuniziert wird.

Beim Kontrast prüfen Sie normalen Text, Platzhaltertext und Fehlermeldungen. Prüfen Sie auch den Fokusring: er muss sowohl auf hellen als auch dunklen Hintergründen gut erkennbar sein. Fehlerzustände sollten sich nicht nur über Rot unterscheiden. Fügen Sie ein Icon, klaren Text oder beides hinzu.

Wandeln Sie Ihre Funde in eine kurze Fixliste um:

• Fokusreihenfolge so fixen, dass sie dem Layout entspricht.
• Fehlende zugängliche Namen für Toggles und Icons hinzufügen.
• Fehler mit dem Feld verknüpft ansagen (nicht nur als Banner).
• Fokusstile und niedrig-kontrastigen Platzhalter-/Fehlertext verbessern.
• Den Toast nicht blockierend machen, oder nur fokusierbar, wenn er Aktionen enthält.

Wenn Sie in Koder.ai bauen, fügen Sie diese Bildschirmbeschreibung und Ihre Befunde in den Chat und bitten Sie darum, die React- oder Flutter-UI so zu aktualisieren, dass Tastatur- und Screenreader-Verhalten wie erwartet funktioniert.

Nächste Schritte: Wiederverwenden Sie diese Checkliste und integrieren Sie sie in Ihren Workflow

Damit sich Barrierefreiheits-Prompts für React- und Flutter-UI-Reviews langfristig auszahlen, behandeln Sie sie wie eine wiederkehrende Gewohnheit, nicht als einmalige Säuberung. Das Ziel ist, bei jeder neuen Seite oder Komponente dieselben kleinen Checks zu machen.

Behalten Sie eine einzige „Definition of Done" für UI-Änderungen. Bevor etwas ausgeliefert wird, führen Sie einen schnellen Pass durch, der Tastatur, Fokus, Namen und Kontrast abdeckt. Es dauert Minuten, wenn Sie es oft machen.

Hier ist eine schnelle Checkliste, die Sie auf fast jeder UI durchführen können:

• Tastatur: Erreicht man jedes interaktive Element und kann man es ohne Maus verwenden?
• Fokus: Ist Fokus sichtbar und bewegt er sich in sinnvoller Reihenfolge?
• Labels: Hat jedes Feld und jeder Button einen klaren Namen (inklusive Icons)?
• Ansagen: Werden Zustandsänderungen angesagt (Fehler, Laden, Erfolg)?
• Kontrast: Ist Text lesbar und sind deaktivierte Zustände noch verständlich?

Speichern Sie Ihre besten Prompts als Templates. Eine einfache Methode ist, einen „React-Review-Prompt" und einen „Flutter-Review-Prompt" parat zu haben, die Sie am Ende jeder Änderung einfügen. Fügen Sie dann eine kurze Zeile hinzu, die die neue Komponente und spezielles Verhalten beschreibt (Modal, Stepper, Liste mit infinite scroll).

Führen Sie dieselben Checks bei jeder neuen Komponente vor dem Release durch, auch wenn es sich repetitiv anfühlt. Accessibility-Probleme werden oft durch kleine Änderungen eingeführt: ein neues icon-only Button, ein benutzerdefiniertes Dropdown, eine Toast-Meldung oder eine Fokusfalle in einem Dialog.

Wenn Sie mit Koder.ai arbeiten, fügen Sie die Prompts in den Chat und fordern Sie konkrete Fixes, keine allgemeinen Verbesserungen. Verwenden Sie dann den Planungsmodus, um die Auswirkungen vor der Anwendung zu prüfen. Machen Sie einen Snapshot vor dem Accessibility-Pass und nutzen Sie Rollback, wenn ein Fix Layout oder Verhalten bricht. Das macht es sicherer, an Fokusreihenfolge und Semantik zu iterieren, ohne Angst zu haben.

Nach Ihrem Accessibility-Pass können Sie ihn als Release-Gate behandeln: Exportieren Sie den Quellcode für Ihren Repo-Workflow, oder deployen und hosten Sie die App und verbinden Sie eine Custom-Domain, wenn Sie mit dem Ergebnis zufrieden sind.