Prozess & Rollen

Definition of Done (A11y-Ergänzung) Muss

Eine User Story gilt erst als erledigt, wenn:

Rollen

Verantwortlichkeiten für Barrierefreiheit
Rolle Verantwortung
A11y-Champion (pro Team) Ansprechperson, Review von A11y-Aspekten, Wissenstransfer
Designer Kontraste, Fokus-Stile, Touch-Targets, Annotationen
Entwickler Semantisches HTML, ARIA, Tastaturnavigation, Tests
Content-Autor Alt-Texte, verständliche Texte, Linktexte, Untertitel
QA / Testing Manuelle Tests, Screenreader-Tests, Testprotokolle
Product Owner A11y-Anforderungen in Stories, Priorisierung von A11y-Bugs

Review-Prozess für neue Komponenten

  1. Design-Review: Kontraste, Fokus, Targets prüfen
  2. Code-Review: Semantik, ARIA, Tastatur prüfen (PR-Checkliste)
  3. A11y-Review: Screenreader-Test durch A11y-Champion
  4. Dokumentation: Komponentenverwendung in MAGS ergänzen

Bug-Priorisierung

A11y-Bug-Prioritäten
Priorität Beschreibung Beispiel
Kritisch Inhalt oder Funktion nicht zugänglich Checkout nicht per Tastatur bedienbar
Hoch Wesentliche Barriere, Workaround möglich Fehlende Formular-Labels
Mittel Eingeschränkte Nutzbarkeit Fokus-Indikator schlecht sichtbar
Niedrig Kosmetisch, Best Practice Redundante ARIA-Attribute

Issue-Tracking & Labels

Barrierefreiheits-Issues werden in GitHub Issues erfasst und mit folgenden Labels gekennzeichnet:

Empfohlene GitHub-Labels für A11y-Issues
Label Farbe Verwendung
a11y Lila (#7B4BBE) Alle Barrierefreiheits-Issues
a11y:critical Rot (#DA2E25) Inhalt/Funktion nicht zugänglich
a11y:audit Blau (#0E95D8) Ergebnis eines A11y-Audits
a11y:screenreader Grün (#52A63F) Screenreader-spezifisches Problem
a11y:keyboard Orange (#FF6600) Tastaturnavigation betroffen

Reporting

Quartalsweise wird ein A11y-Statusbericht pro Plattform erstellt:

  1. Anzahl offene/geschlossene A11y-Issues
  2. Lighthouse-Accessibility-Score (Trend)
  3. Ergebnisse manueller Screenreader-Tests
  4. Status der WCAG 2.2 AA Konformität (Selbsteinschätzung)