Accessibility wird in digitalen Projekten häufig erst spät berücksichtigt:
- kurz vor dem Release
- im Audit
- nach Beschwerden
- als technisches „Extra“
Dadurch entstehen oft unnötige Nacharbeiten, Kompromisse und Barrieren.
Ein deutlich besserer Ansatz ist:
Accessibility bereits in der Anforderungsdefinition mitzudenken.
Genau hier kommen User Stories ins Spiel.
Gut formulierte Accessibility User Stories helfen Teams dabei, Barrierefreiheit frühzeitig in Design, Entwicklung und Testing zu integrieren – statt sie später „nachzurüsten“.
Warum Accessibility in User Stories wichtig ist
Viele Accessibility-Probleme entstehen nicht durch fehlendes Wissen, sondern durch fehlende Anforderungen.
Wenn Accessibility nie Teil der Story war:
- wird sie oft vergessen
- falsch priorisiert
- nicht getestet
- oder nur oberflächlich umgesetzt
Deshalb gilt:
Was nicht beschrieben wird, wird häufig auch nicht gebaut.
Was ist eine User Story?
Eine klassische User Story beschreibt:
- wer etwas benötigt
- was erreicht werden soll
- warum es wichtig ist
Typischer Aufbau:
Als [Nutzergruppe] möchte ich [Ziel], damit [Nutzen].
Beispiel:
Als Nutzer möchte ich ein Formular absenden können, damit ich Kontakt aufnehmen kann.
Das Problem vieler User Stories
Viele Stories sind zu technisch oder zu allgemein.
Zum Beispiel:
- „Button implementieren“
- „Formular bauen“
- „Accessibility beachten“
Solche Anforderungen helfen Teams kaum dabei, konkrete Accessibility-Bedürfnisse zu verstehen.
Gute Accessibility User Stories sind menschenzentriert
Accessibility Stories sollten reale Nutzungssituationen beschreiben.
Nicht:
„WCAG erfüllen“
Sondern:
Welche Menschen brauchen was – und warum?
Beispiel: Schlechte vs. gute Story
❌ Schlecht
Die Seite soll barrierefrei sein.
Zu ungenau.
Keine konkrete Erwartung.
Keine prüfbare Anforderung.
✅ Besser
Als Screenreader-Nutzer möchte ich Formularfelder verständlich vorgelesen bekommen, damit ich das Formular selbstständig ausfüllen kann.
Diese Story beschreibt:
- Nutzergruppe
- Ziel
- Nutzen
- konkrete Accessibility-Anforderung
Accessibility bedeutet unterschiedliche Bedürfnisse
Nicht jede Story betrifft dieselbe Personengruppe.
Zum Beispiel:
- Tastaturnutzer
- Menschen mit Sehbehinderungen
- Menschen mit motorischen Einschränkungen
- Menschen mit kognitiven Einschränkungen
- Menschen mit geringer technischer Erfahrung
- Menschen mit Konzentrationsschwierigkeiten
Deshalb helfen konkrete Perspektiven enorm.
Gute Accessibility Stories beschreiben echte Nutzung
Beispiel: Tastaturbedienung
Als Nutzer ohne Maus möchte ich alle interaktiven Elemente per Tastatur erreichen können, damit ich die Anwendung vollständig bedienen kann.
Beispiel: Verständliche Fehlermeldungen
Als Nutzer möchte ich verständliche Fehlermeldungen erhalten, damit ich Eingabefehler schnell korrigieren kann.
Beispiel: Zoom und Responsive Design
Als Nutzer mit vergrößerter Ansicht möchte ich Inhalte ohne horizontales Scrollen nutzen können, damit die Seite lesbar bleibt.
Beispiel: Videos
Als gehörloser Nutzer möchte ich Untertitel für Videos erhalten, damit ich die Inhalte verstehen kann.
Accessibility Stories sind keine Sonderstories
Ein häufiger Fehler:
Accessibility wird als separater Zusatz behandelt.
Besser:
Accessibility direkt in normale Produktanforderungen integrieren.
Denn:
- jede Funktion betrifft Menschen unterschiedlich
- jede Interaktion kann Barrieren erzeugen
- jede UX-Entscheidung beeinflusst Zugänglichkeit
Akzeptanzkriterien sind entscheidend
User Stories allein reichen nicht aus.
Wichtig sind konkrete Akzeptanzkriterien.
Beispiel:
Story
Als Tastaturnutzer möchte ich Dialoge vollständig bedienen können.
Akzeptanzkriterien
- Fokus springt beim Öffnen in den Dialog
- Dialog kann per ESC geschlossen werden
- Fokus kehrt zum auslösenden Element zurück
- Inhalte hinter dem Dialog sind nicht fokussierbar
Dadurch werden Anforderungen überprüfbar.
Gute Stories beschreiben Nutzen – nicht nur Technik
Menschen interessieren sich nicht für:
- ARIA-Attribute
- HTML-Semantik
- technische Spezifikationen
Sie interessieren sich dafür:
- ob etwas funktioniert
- verständlich ist
- Orientierung bietet
- selbstständig nutzbar bleibt
Deshalb sollten Stories möglichst aus Nutzersicht formuliert werden.
Accessibility verbessert oft die UX insgesamt
Viele Accessibility Stories helfen nicht nur einzelnen Gruppen.
Zum Beispiel:
- klare Fehlermeldungen
- gute Fokusführung
- verständliche Sprache
- konsistente Navigation
- ausreichend große Klickflächen
Davon profitieren fast alle Menschen.
Accessibility Stories helfen Teams beim Perspektivwechsel
Gut formulierte Stories verändern oft die Diskussion im Team.
Statt:
„Brauchen wir das wirklich?“
entsteht eher:
„Wie stellen wir sicher, dass Menschen das nutzen können?“
Das macht Accessibility greifbarer und menschlicher.
Häufige Fehler
❌ Zu technische Formulierungen
„ARIA korrekt implementieren.“
Das beschreibt keine Nutzerperspektive.
❌ Accessibility als Nachgedanke
„Am Ende noch Accessibility prüfen.“
Dann entstehen meist hohe Nachbesserungsaufwände.
❌ Keine konkreten Nutzergruppen
Wenn unklar bleibt, für wen die Story relevant ist, fehlen oft wichtige Details.
Ein hilfreicher Ansatz
Frage bei neuen Features:
Wer könnte Schwierigkeiten mit dieser Funktion haben?
Und direkt danach:
Was braucht diese Person, um die Funktion selbstständig nutzen zu können?
Genau daraus entstehen gute Accessibility User Stories.
Fazit
Gute Accessibility beginnt nicht erst im Audit oder Testing.
Sie beginnt bereits bei den Anforderungen.
Gut formulierte User Stories helfen Teams dabei:
- menschlicher zu denken
- Barrieren frühzeitig zu erkennen
- bessere UX zu schaffen
- Accessibility selbstverständlich mitzudenken
Denn Accessibility ist keine Zusatzfunktion.
Sie ist ein wesentlicher Bestandteil guter User Experience.
