Barrierefreiheits-Code-Review

Das Problem

Barrierefreiheitsmaengel schliessen 15% der Weltbevoelkerung aus und setzen Unternehmen rechtlicher Haftung aus. Entwickler bauen eigene Dropdowns, die nur mit der Maus funktionieren, verwenden Div-Suppen, die Screenreader nicht parsen koennen, und waehlen Farbkombinationen, die fuer farbenblinde Nutzer verschwinden. Die meisten dieser Probleme sind bei der Entwicklung unsichtbar, weil sehende Entwickler, die mit der Maus testen, ihnen nie begegnen.

Der Prompt

Pruefe den folgenden Frontend-Code auf Barrierefreiheit. Handle als WCAG 2.2 AA Auditor, der den Quellcode vor automatisierten Tests untersucht.

FRAMEWORK: [z.B. React, Vue, Astro, HTML/CSS]
KOMPONENTENTYP: [z.B. Navigationsmenü, Formular, Modal-Dialog, Datentabelle]

CODE:
[Komponenten-Code hier einfuegen]

Pruefe gegen diese WCAG 2.2 AA Kriterien:

1. **Semantische Struktur**
   - Werden korrekte HTML-Elemente verwendet (button statt div[onClick], nav, main, header)?
   - Ist die Ueberschriftenhierarchie logisch (h1 → h2 → h3, keine uebersprungenen Ebenen)?
   - Sind Listen als ul/ol ausgezeichnet, nicht als div-Sequenzen?

2. **Tastaturnavigation**
   - Koennen alle interaktiven Elemente per Tab erreicht werden?
   - Ist die Fokusreihenfolge logisch (folgt dem visuellen Layout)?
   - Koennen Modals/Dropdowns mit Escape geschlossen werden?
   - Gibt es einen sichtbaren Fokusindikator auf jedem interaktiven Element?
   - Gibt es Tastaturfallen (Fokus gelangt hinein, aber nicht heraus)?

3. **ARIA-Nutzung**
   - Werden ARIA-Rollen, -Zustaende und -Eigenschaften korrekt (nicht redundant) verwendet?
   - Folgen Custom Widgets den WAI-ARIA Design Patterns?
   - Werden aria-live-Regionen fuer dynamische Inhaltsaktualisierungen verwendet?

4. **Visuelle Barrierefreiheit**
   - Erfuellen Textfarben das Kontrastverhaeltnis 4.5:1 (3:1 fuer grossen Text)?
   - Wird Information durch mehr als nur Farbe vermittelt?
   - Kann die Seite auf 200% gezoomt werden ohne Inhaltsverlust?
   - Sind Touch-Targets mindestens 44x44px?

5. **Formulare**
   - Hat jedes Input ein sichtbares, zugeordnetes Label?
   - Sind Pflichtfelder programmatisch gekennzeichnet (aria-required)?
   - Sind Fehlermeldungen mit Inputs verknuepft (aria-describedby)?

6. **Medien und Bilder**
   - Haben Bilder aussagekraeftige Alt-Texte?
   - Haben dekorative Bilder alt="" oder role="presentation"?

Fuer jedes Problem liefere:
- **WCAG-Kriterium**: z.B. 2.1.1 Tastatur, 4.1.2 Name Rolle Wert
- **Schweregrad**: Kritisch (blockiert Zugang) / Schwerwiegend / Moderat / Minor
- **Betroffene Nutzer**: Screenreader, Tastatur, Sehbeeintraechtigung, Motorik
- **Fix**: Korrigierter Code

Beispielausgabe

## Barrierefreiheits-Review: 6 Probleme gefunden

### Kritisch — WCAG 2.1.1: Nicht per Tastatur bedienbares Dropdown
Ort: src/components/Dropdown.tsx:8
Problem: Custom Dropdown verwendet div mit onClick — nicht per Tastatur erreichbar.
Betroffene: Alle Tastatur- und Screenreader-Nutzer.
Fix:
  <button aria-haspopup="listbox" aria-expanded={isOpen} onClick={toggle}>
    Option waehlen
  </button>
  <ul role="listbox" aria-label="Optionen">
    {options.map(opt => (
      <li role="option" aria-selected={opt === selected} tabIndex={0}>{opt}</li>
    ))}
  </ul>

### Schwerwiegend — WCAG 1.3.1: Fehlende Formular-Labels
Ort: src/components/SearchBar.tsx:5
Problem: Input hat Placeholder aber kein <label>-Element.
Fix: <label htmlFor="search" className="sr-only">Suche</label>
     <input id="search" placeholder="Suchen..." />

Wann verwenden

Bei jeder UI-Komponente vor dem Merge ausfuehren — besonders bei Formularen, Navigation, Modals und interaktiven Widgets. Kritisch vor dem Launch oeffentlicher Websites mit Barrierefreiheitsvorgaben (BFSG 2025, EU EAA). Als Shift-Left-Barrierefreiheitsgate einsetzen, das Probleme findet, bevor sie QA erreichen.

Profi-Tipps

• Einzelne Komponenten testen — Barrierefreiheitsprobleme summieren sich im Seitenkontext. Erst einzelne Komponenten reviewen, dann vollstaendige Seiten.
• Screenreader-Narration anfordern — nachfragen: “Gehe diese Komponente durch, wie ein Screenreader sie vorlesen wuerde, Schritt fuer Schritt.”
• Mit automatisierten Tools kombinieren — dieses Review findet, was axe/Lighthouse uebersehen: logische Fokusreihenfolge, aussagekraeftige Alt-Texte und korrekte ARIA-Patterns.