Eine Anforderung wie „barrierefrei umsetzen" lässt sich nicht abnehmen, weil sie weder sagt, für wen, noch woran. Der Beitrag zeigt Schritt für Schritt, wie eine Nutzungsanforderung für Zugänglichkeit nach ISO 9241-210 formuliert wird: mit Nutzergruppe, Aufgabe, erwartetem Ergebnis und einem Prüfverfahren, das die Abnahme möglich macht.
Voraussetzungen
Eine Beschreibung des Nutzungskontexts liegt vor, in der assistive Technologien als Betriebsmittel je Nutzergruppe erfasst sind, siehe `assistive-technologien-im-nutzungskontext`. Es gibt Szenarien je Aufgabe. Und es gibt eine Anforderungsliste oder ein Backlog, in das die Anforderungen aufgenommen werden, mit derselben Priorisierung wie alle anderen.
Schritte
Nutzergruppe benennen. Was: die Gruppe mit ihrem Betriebsmittel, zum Beispiel „eine Kundin, die einen Screenreader benutzt" oder „ein Sachbearbeiter, der mit Vergrößerung arbeitet". Warum: Ohne Nutzergruppe gilt die Anforderung für alle und wird von niemandem geprüft. Ergebnis: ein Subjekt in der Anforderung.
Aufgabe benennen. Was: die Aufgabe aus dem Szenario, in der Sprache der Nutzenden, zum Beispiel „den Leistungsbescheid prüfen" oder „den Tarifwechsel beantragen". Warum: Nach ISO 9241-11 wird Gebrauchstauglichkeit an Aufgaben gemessen; eine Anforderung ohne Aufgabe hat keinen Maßstab. Ergebnis: ein Ziel, an dem Effektivität messbar ist.
Erwartetes Ergebnis formulieren. Was: was am Ende der Aufgabe erreicht ist, beobachtbar, zum Beispiel „erkennt den erstatteten Betrag und die Widerspruchsfrist" oder „hat alle Pflichtfelder ausgefüllt und die Bestätigung erhalten". Warum: Das Ergebnis ist das Abnahmekriterium; ohne Ergebnis lässt sich die Anforderung nicht als erfüllt oder nicht erfüllt beurteilen. Ergebnis: ein Prädikat, das in einer Sitzung beobachtet werden kann.
Bedingung ergänzen. Was: die Bedingung, unter der das Ergebnis gilt, zum Beispiel „ohne die Tabellennavigation zu verlassen", „über die sichtbaren Bezeichnungen per Sprachbefehl" oder „bei Vergrößerung, ohne horizontal zu scrollen". Warum: Die Bedingung erfasst die Effizienz; sie unterscheidet die Aufgabe, die gelingt, von der Aufgabe, die mit Umweg gelingt. Ergebnis: eine Anforderung, die Kompensationsverhalten als Nichterfüllung erkennt.
Prüfverfahren zuordnen. Was: je Anforderung das Verfahren, mit dem sie geprüft wird: Werkzeugprüfung für technische Merkmale, Selbsttest mit Screenreader oder Tastatur durch das Team für Struktur und Beschriftung, Test mit Nutzenden assistiver Technologien für Aufgaben, bei denen Aufwand und Umwege zu beobachten sind. Warum: Ein Kriterium ohne Prüfverfahren wird abgehakt. Ergebnis: eine Spalte „geprüft durch" in der Anforderungsliste.
Abnahmekriterium ins Backlog schreiben. Was: die Anforderung als Akzeptanzkriterium an der Story oder dem Epic, mit dem Prüfverfahren. Warum: Die Anforderung wirkt dort, wo Entwicklung und Product Owner über „fertig" entscheiden. Ergebnis: eine Story, die ohne erfüllte Anforderung nicht abgenommen wird.
Mit allen anderen Anforderungen priorisieren. Was: die Anforderung geht in dieselbe Priorisierung wie Anforderungen ohne Bezug zu assistiven Technologien. Warum: Ein eigener Status ist die erste Kandidatin für den Schnitt bei Terminkonflikten. Ergebnis: eine Anforderungsliste ohne Sonderkategorie.
Formulierungen im Vergleich
Vorher: „Das Formular ist barrierefrei." Nachher: „Ein Kunde, der Sprachsteuerung benutzt, füllt alle Pflichtfelder des Wechselformulars über ihre sichtbaren Bezeichnungen aus und sendet es ab. Geprüft im Test mit Nutzenden assistiver Technologien."
Vorher: „Screenreader-Kompatibilität sicherstellen." Nachher: „Eine Kundin, die einen Screenreader benutzt, erkennt im Leistungsbescheid den erstatteten Betrag und die Widerspruchsfrist in der Lesereihenfolge des Dokuments, ohne das Dokument mehrfach zu lesen. Geprüft im Selbsttest am erzeugten PDF und im Test mit Nutzenden."
Vorher: „Browservergrößerung unterstützen." Nachher: „Eine Sachbearbeiterin, die mit Vergrößerung arbeitet, findet in der Vorgangsübersicht den nächsten offenen Vorgang, ohne horizontal zu scrollen. Geprüft im Selbsttest mit Browservergrößerung."
Typische Fehler
Die Anforderung nennt eine Technik statt eines Ergebnisses („ARIA-Attribute setzen"), und die Abnahme prüft die Technik, während die Aufgabe scheitert. Die Anforderung nennt eine Norm oder ein Konformitätsniveau als Ergebnis; welche Norm gilt, klärt die Rechtsabteilung, und das Konformitätsniveau sagt nichts über die Aufgabe. Die Anforderung fehlt in der Priorisierung und steht in einer gesonderten Liste, die im Release nicht auftaucht. Die Bedingung fehlt, und die Aufgabe gilt als erfüllt, obwohl sie nur mit Umweg gelingt.
Ergebnis
Am Ende liegen Nutzungsanforderungen vor, die je Zeile Nutzergruppe, Aufgabe, erwartetes Ergebnis, Bedingung und Prüfverfahren nennen und im Backlog als Akzeptanzkriterien stehen. Ihr Team kann diese Anforderungen selbst abnehmen, und der Test mit Nutzenden assistiver Technologien hat einen Aufgabenplan, bevor die erste Zeile Code entsteht.
