Accessibility-Audit für Komponente

Audit this component for accessibility. Target: WCAG 2.2 AA.

Evaluate:
1. SEMANTIC HTML - is the element choice correct (button vs div, nav, landmark)?
2. KEYBOARD - can every interaction be done with keyboard? Focus order logical? Trap cases?
3. FOCUS STATES - visible, not hidden by `outline: none` without replacement
4. ARIA - only if needed. Misuse > missing. Check role/name/value trio.
5. CONTRAST - any hard-coded color pair obviously below 4.5:1 (or 3:1 for large text / UI)
6. MEDIA - images alt text, video captions, no color-only meaning
7. LIVE REGIONS / DYNAMIC - announced changes use aria-live / role=status
8. FORMS - labels tied to inputs, error messaging associated, required marked both visually and for AT

For each finding:
- Severity: BLOCKER / HIGH / MEDIUM / LOW
- Line reference
- Why it matters (user impact, not compliance jargon)
- Concrete fix snippet

Rules:
- Do not over-recommend ARIA. Semantic HTML first.
- No "add role=button to a div" - just use `<button>`
- If the component is inherently problematic (e.g. custom dropdown where native select would do), say so
- Do not bikeshed if the component is clearly fine

Component:
[PASTE]

Wann nutzen

Bevor eine Komponente ins Design-System geht. A11y-Probleme skalieren sonst über jede Nutzung.

Use-Cases

• Neue Custom-Dropdown / Modal / Datepicker.
• Legacy-Komponente, die in einem A11y-Audit auffiel.
• Self-Check vor einem externen Accessibility-Test.

Getestet mit

• Claude Opus 4.7