User Stories – ein guter Weg zu einer barrierefreien Lösung

Die Sicherstellung einer barrierefreien Lösung ist häufig eine Art von „Zusatzleistung“ in einem Projekt. Barrierefreiheit wird nicht als grundsätzlicher Bestandteil einer Lösung gedacht, sondern als gesonderte Anforderung und die steht im Plan ganz am Ende. Das führt zu vermeidbaren Problemen. Entweder zu einem durchaus nennenswerten Zusatzaufwand oder zu einer nicht barrierefreien Lösung.
Dabei könnte es so einfach sein. Barrierefreiheit muss von Anfang an berücksichtigt werden. Dieses „Shift Left“ im Prozess spart Nerven und Budget. Ein Werkzeug kann dabei helfen, das Thema Barrierefreiheit verständlich und recht einfach in die Prozessschritte zu integrieren. Da sich eine deutsche Übersetzung in der Praxis nicht durchsetzen konnte, bleibe ich für dieses Werkzeug bei dem Begriff der User Stories. „Nutzer:innen Geschichten“ hört sich wirklich nicht so toll an.

Barrierefreiheit im Web ist keine Zusatzfunktion, sondern eine Grundvoraussetzung für inklusive, digitale Teilhabe. Dennoch wird sie in agilen Entwicklungsprozessen oft nur am Rande berücksichtigt. User Stories sind ein effektives Mittel, um Barrierefreiheit von Beginn an strukturiert in den Entwicklungsprozess einzubinden.

User Stories beschreiben Anforderungen aus Sicht der Benutzerinnen und Benutzer. Sie folgen häufig dem Muster:

Als [Rolle] möchte ich [Anforderung], damit [Nutzen/Ziel]

Diese Formulierung hilft Teams, sich auf die tatsächlichen Bedürfnisse der Menschen zu konzentrieren. Für barrierefreie Websites oder Apps bedeutet das: Wir beschreiben Anforderungen aus Sicht von Personen mit unterschiedlichen Fähigkeiten, Bedienweisen und Hilfstechnologien.

• Rolle: Identifizieren Sie eindeutig einen Benutzer mit einem bestimmten Barrierefreiheitsbedarf, z. B. einen Benutzer, der ausschließlich eine Tastatur verwendet.
• Anforderung: Geben Sie an, was der Benutzer tun möchte. Das könnte zum Beispiel das Ausfüllen eines Formulars sein.
• Nutzen/Ziel: Erläutern Sie, warum dies wichtig ist, z. B. um eine Aufgabe selbstständig zu erledigen.
• Akzeptanzkriterien: Definieren Sie, wann die User Story abgeschlossen ist. Dies kann die Erfüllung von Kontrastanforderungen, die Unterstützung von Bildschirmleseprogrammen oder die Sicherstellung der Tastaturfunktionalität umfassen.

Nicht die User Story selbst ist barrierefrei, sondern sie beschreibt eine barrierefreie Benutzerschnittstelle. Der Einfachheit haber, spreche ich hier weiter von barrierefreien User Stories.

Diese barrierefreien User Stories verknüpfen Nutzerbedürfnisse mit den technischen Anforderungen, die in den Web Content Accessibility Guidelines öffnet sich in einem neuen Tab (WCAG) hinterlegt wurden. Sie schaffen eine Brücke zwischen Nutzererfahrung, Design und technischer Umsetzung. Statt „Accessibility-Checklisten“ am Ende eines Projekts einzusetzen, fließen Zugänglichkeitskriterien mit den User Stories frühzeitig und kontinuierlich in den Entwicklungsprozess ein.
Außerdem sind User Stories verständlich. Alle beteiligten Parteien, ob Fachseite, Designer oder Entwickler, können diese Anforderungen nutzen. Ob der finale Abnahmeprozess ebenfalls auf den Akzeptanzkriterien der User Stories aufbaut, ist dabei in erster Linie eine formale Frage. Das möchte ich an dieser Stelle nicht weiter vertiefen und lieber praktische Beispiele vorstellen.

User Story: Als reiner Tastaturbenutzer möchte ich auf alle interaktiven Inhalte wie Formularfelder, Schaltflächen und Links zugreifen und diese aktivieren können, damit ich Formulare erfolgreich ausfüllen kann.

Akzeptanzkriterien:

• Alle Funktionen sind über die Tastatur bedienbar, ohne dass zeitgesteuerte Tasteneingaben erforderlich sind. [WCAG 2.1.1]
• Es gibt keine Tastaturfallen, d. h. der Fokus lässt sich jederzeit von einem Element wegbewegen. [WCAG 2.1.2]

User Story: Als Tastaturnutzer*in möchte ich Inhalte in der korrekten Lesereihenfolge navigieren können, damit ich den Inhalt sinnvoll erfassen kann.

Akzeptanzkriterien:

• Bei sequentieller Navigation erhalten fokussierbare Komponenten Fokus in einer Reihenfolge, die Bedeutung und Bedienbarkeit erhält. [WCAG 2.4.3]

User Story: Als Screenreader-Nutzer*in möchte ich Formularfelder ausfüllen und Fehler beheben können, damit ich Aufgaben eigenständig erledigen kann.

Akzeptanzkriterien:

• Formularfelder haben eine zugängliche Benennung und Beschreibung, die Zweck und alle Anweisungen umfasst (z. B. Pflichtfelder, Datenformat). [WCAG 1.1.1, 1.3.1, 2.4.6, 4.1.2]
• Beim Verlassen eines Feldes wird der Kontext nicht unerwartet verändert, außer die Nutzer*innen sind vorab darüber informiert. [WCAG 3.2.2]
• Fehlermeldungen werden an Screenreader kommuniziert, z. B. durch Fokuswechsel oder Live-Regionen. [WCAG 3.3.1]
• Fehlermeldungen werden textlich beschrieben. [WCAG 3.3.1]
• Fehlermeldungen identifizieren das fehlerhafte Feld. [WCAG 3.3.1]
• Fehlermeldungen enthalten Hinweise zur Korrektur, sofern dadurch die Sicherheit oder der Zweck des Inhalts nicht gefährdet werden. [WCAG 3.3.3]
• Bei rechtlichen oder finanziellen Aktionen im Formular muss die Möglichkeit bestehen, die Eingabe vor dem Absenden zu prüfen, zu bestätigen oder rückgängig zu machen. [WCAG 3.3.4]

Es gibt lange Diskussionen, wie eine User Story richtig formuliert werden muss. Widerspruchsfrei, eindeutig, klar und viele weitere denkbare Adjektive kommen mir da in den Sinn. Dem kann und will dieser Text nicht folgen. Wer tiefer einsteigen will, dem sei ein Blick in das Buch „User Stories“ von Mike Cohn empfohlen.
User Stories können eher grundsätzlich und umfassend formuliert werden. Dieses Beispiel zeigt diesen Ansatz recht gut:

Als sehbehinderter App-Nutzer muss ich in der Lage sein, Informationen über alle Nicht-Text-Elemente wie Bilder, Symbole, CTA-Schaltflächen, Kontrollkästchen oder Optionsfelder zu hören, damit ich die Funktionalität und den Zweck dieser Elemente verstehen kann.

Sie können auch sehr spezifisch sein und sich auf einzelne Bestandteile der Benutzerschnittstelle beziehen:

Als Nutzer mit einer Sehbehinderung möchte ich, dass die Warenkorb- und Favoriten-Symbole deutlich sichtbar sind und das Profil-Symbol auch dann korrekt angezeigt wird, wenn die Ansicht im Browser auf 200 % vergrößert wurde, damit ich den Warenkorb ohne Einbußen bei der Funktionalität oder visuellen Konsistenz nutzen kann.

Im zweiten Fall können die Akzeptanzkriterien dann durchaus Vorgaben für einzelne Bestandteile des Moduls enthalten.

• Der Nutzer hat die Ansicht im Browser auf 200% gestellt [WCAG 1.4.4, 1.4.10]
• Es ist ein ausreichender Farbkontrast und eine anpassbare Textgröße vorhanden, damit der Nutzer die Inhalte bequem lesen kann. [WCAG 1.4.3, 1.4.4]
• Für das Icon A wird der Text „als Favorit speichern“ vorgelesen und der Nutzer kann das Icon gut erkennen [WCAG 1.1.1, 1.4.11]
• Der Nutzer kann alle Elemente des Warenkorbs mit der Tastatur erreichen [WCAG 2.1.1]

• Als Nutzer:in mit eingeschränktem Sehvermögen möchte ich ausreichend Farbkontrast und skalierbaren Text, damit ich Inhalte komfortabel lesen kann. [WCAG 1.4.3, 1.4.4]
• Als Nutzer:in mit kognitiven Einschränkungen möchte ich eine konsistente Navigation und klare Strukturen, damit ich mich nicht verlaufe. [WCAG 3.2.3, 3.2.4]
• Als gehörlose:r Nutzer:in möchte ich Untertitel für alle Videos, damit ich gesprochene Inhalte verfolgen kann. [WCAG 1.2.2]
• Als Nutzer:in von Sprachsteuerung möchte ich eindeutige und verständliche Bezeichnungen für Links, damit ich sie per Sprachbefehl aktivieren kann. [WCAG 2.4.4]

Die generische Form der User Stories hat den Vorteil, dass man sich ein Set an User Stories für das Thema Barrierefreiheit vorab erstellen kann. Hier bleiben dann aber Details in der Umsetzung der Fantasie aller Beteiligten überlassen. Das kann zu Problemen führen. Was ist eine „klare Struktur“ oder eine „verständliche Bezeichnung“? Individuelle und spezifische User Stories sind da eindeutiger, machen aber viel mehr Arbeit. Ich würde beide Ansätze nutzen und mich sehr nach dem Engagement und dem Vorwissen bei den Beteiligten richten.

Barrierefreie User Stories machen Anforderungen greifbar und umsetzbar. Sie fördern Kooperation im Team und helfen, Designentscheidungen aus Perspektiven zu betrachten, die sonst leicht übersehen werden. Die Kombination aus klar formulierten Zielen und verknüpften WCAG-Kriterien schafft Transparenz – und legt den Grundstein für inklusive Websites. Kurz gesagt: die Dinger machen uns wirklich das Leben leichter.