Tests
Jede Ebene prüft einen Teil des Verhaltens
Core-Tests prüfen Zustandswechsel. Adapter-Tests prüfen DOM und Events. Browser-Tests prüfen Tastatur, Fokus und assistive Technologien.
Barrierefreiheit im Core
Der Core definiert barrierefreies Verhalten.
Er beschreibt Zustände, Fokus und Tastaturregeln an einer Stelle. Jeder Adapter setzt diese Regeln um.
Verhaltensspezifikation
Diese Regeln gelten für jeden Adapter.
Die Regeln gehören zur Komponenten-API. Ein Theme darf ihre Semantik nicht ändern.
| Bereich | Vertrag |
|---|---|
| Fokus | Die Tastaturnavigation zeigt den Fokus sichtbar. Overlays setzen ihn nach dem Schließen auf den Auslöser zurück. |
| Name und Beschreibung | IDs und ARIA-Beziehungen verbinden Labels, Hinweise und Fehler mit dem jeweiligen Element. |
| Zustand | Semantik und Darstellung zeigen checked, selected, expanded, invalid und disabled immer gleich an. |
| Tastatur | Interaktive Patterns folgen den WAI-ARIA Authoring Practices. Native Elemente behalten ihr Browser-Verhalten. |
| Bewegung | Animationen beachten prefers-reduced-motion. Wichtige Informationen bleiben auch ohne Bewegung verständlich. |
Tastaturmodell
Dieselben Tasten in jedem Framework.
Native Elemente behalten ihr Browser-Verhalten. Komplexe Widgets ergänzen die Tasten des jeweiligen ARIA-Patterns.
| Pattern | Tasten | Erwartetes Verhalten |
|---|---|---|
| Button / Checkbox / Switch | Tab, Leertaste, Enter | Fokus setzen und Aktion oder Statuswechsel auslösen. |
| Radio Group | Pfeiltasten | Auswahl und Fokus innerhalb der Gruppe gemeinsam verschieben. |
| Tabs | ←, →, Pos1, Ende | Zwischen Tabs wechseln und den zugehörigen Inhalt anzeigen. |
| Dialog | Tab, Shift + Tab, Escape | Fokus einschließen, Dialog schließen und Trigger wieder fokussieren. |
Ziel
WCAG 2.2 AA für produktive Komponenten
Jede produktive Komponente braucht ausreichenden Kontrast, sichtbaren Fokus, passende Zielgrößen und verständliche Fehlermeldungen.
Grenzen des PoC
Der PoC zeigt die Architektur, aber weist keine Konformität nach.
Vollständige Screenreader-Tests, eine Browser-Matrix und Tests mit Menschen mit Behinderungen fehlen noch. Die Demos zeigen die geplante DOM-Struktur, aber nicht jede endgültige Adapter-API.
Vor dem Einsatz: Automatisierte Tests ergänzen. NVDA mit Firefox, JAWS mit Chrome und VoiceOver mit Safari testen. Rückmeldungen von Nutzern einholen.