Der Nutzungskontext nach ISO 9241-210 umfasst Nutzergruppen, Aufgaben, Betriebsmittel und Umgebung. Assistive Technologien sind Betriebsmittel. Wer sie in der Beschreibung des Nutzungskontexts weglässt, formuliert Anforderungen für eine Nutzergruppe, die es so nicht gibt. Der Beitrag zeigt, wie Screenreader, Vergrößerung und Sprachsteuerung in die Kontextbeschreibung aufgenommen werden und was daraus für Personas, Szenarien und Anforderungen folgt.
Ausgangslage
In vielen Projekten beschreibt die Kontextanalyse die Nutzergruppen nach Rolle, Aufgabe und Erfahrung, die Betriebsmittel nach Gerät, Browser und Netz, die Umgebung nach Ort und Störungen. Assistive Technologien kommen darin nicht vor. Sie tauchen später auf, als Prüfpunkt vor dem Release oder als Beschwerde danach. Zu diesem Zeitpunkt sind Informationsarchitektur, Interaktionsmuster und Komponenten festgelegt, und die Korrektur ist teuer.
ISO 9241-210 legt fest, dass die Nutzungsanforderungen aus dem Nutzungskontext abgeleitet werden. Ein Betriebsmittel, das im Kontext fehlt, erzeugt keine Anforderung. Deshalb ist die Kontextbeschreibung der Ort, an dem Zugänglichkeit gestaltbar wird.
Assistive Technologien als Betriebsmittel erheben
Wir erheben die Betriebsmittel je Nutzergruppe in der Kontextanalyse, mit denselben Methoden wie Gerät und Browser: Interviews, Beobachtung im Nutzungskontext, Auswertung von Support-Anfragen und Beschwerden über den Feedback-Mechanismus der Barrierefreiheitserklärung. Für jede Nutzergruppe halten wir fest, welche assistiven Technologien vorkommen, in welcher Kombination mit Gerät und Betriebssystem, und in welcher Routine: ob jemand den Screenreader seit Jahren benutzt und Umwege kennt, oder ob die Vergrößerung neu ist, weil das Sehvermögen nachgelassen hat.
Die Erhebung nennt Screenreader, Vergrößerung und Sprachsteuerung als Kern, weil diese drei Technologien unterschiedliche Anforderungen an die Struktur eines Produkts stellen: der Screenreader an Reihenfolge, Rollen und Namen, die Vergrößerung an Layout und Fokusführung bei Ausschnittsdarstellung, die Sprachsteuerung an sichtbare und zugängliche Bezeichner, die übereinstimmen. Weitere Technologien wie Schaltersteuerung oder Braillezeile nehmen wir auf, wenn die Nutzergruppe sie zeigt.
Personas erweitern
Eine Persona beschreibt eine Nutzergruppe mit Zielen, Aufgaben, Kenntnissen und Betriebsmitteln. Assistive Technologien gehören in den Abschnitt Betriebsmittel, mit derselben Konkretheit wie das Gerät: welche Technologie, welche Einstellungen, welche Routine. Wir legen keine gesonderte Persona für Menschen mit Behinderung an, weil sie das Merkmal von der Aufgabe trennt. Eine Kundin, die ihren Versicherungsbescheid prüft, ist dieselbe Persona, ob sie mit den Augen liest oder mit Sprachausgabe; das Betriebsmittel steht in ihrem Profil, und es steht dort mit einer Häufigkeit, die aus der Erhebung stammt.
Szenarien schreiben
Ein Szenario beschreibt, wie eine Persona eine Aufgabe in ihrem Kontext erledigt. Mit assistiven Technologien als Betriebsmittel entstehen Szenarien, die den Weg durch das Produkt anders beschreiben: Die Kundin öffnet den Bescheid im Portal, lässt sich die Überschriften vorlesen, springt zur Tabelle, liest die Zeile mit dem erstatteten Betrag und die Frist im Schlussabsatz. Das Szenario macht sichtbar, welche Strukturmerkmale die Aufgabe braucht, ohne dass an dieser Stelle über Technik entschieden wird.
Diese Szenarien sind auch die Aufgaben für die spätere Evaluation. Wer sie in der Kontextanalyse schreibt, hat den Testplan für die Prüfung mit Nutzenden assistiver Technologien bereits angelegt.
Anforderungen ableiten
Aus den Szenarien werden Nutzungsanforderungen: Nutzergruppe, Aufgabe, erwartetes Ergebnis, Bedingung. Eine Anforderung, die aus einem Szenario mit Screenreader stammt, lautet etwa: Eine Kundin, die einen Screenreader benutzt, erkennt im Bescheid den erstatteten Betrag und die Widerspruchsfrist in der Lesereihenfolge des Dokuments. Sie ist prüfbar, weil sie sagt, wer, was und woran. Wie solche Anforderungen im Detail formuliert und mit einem Prüfverfahren versehen werden, beschreibt `nutzungsanforderungen-pruefbar-formulieren`.
Die Anforderungen gehen in dieselbe Liste wie alle anderen Nutzungsanforderungen und werden mit ihnen priorisiert. Sie erhalten keinen eigenen Status, weil ein eigener Status die erste Kandidatin für den Schnitt bei Terminkonflikten ist.
Grenzen
Die Kontextanalyse beschreibt, was in der Nutzergruppe vorkommt, mit der Genauigkeit der Erhebung. Wer nur Support-Tickets auswertet, sieht die Menschen, die sich beschweren, und übersieht die, die kompensieren. Deshalb gehören Interviews und Beobachtung mit Menschen, die assistive Technologien benutzen, in die Erhebung; die Rekrutierung dafür beschreibt TG-07. Die Kontextanalyse ersetzt keine Evaluation: Ob die abgeleiteten Anforderungen erfüllt sind, zeigt der Test mit Nutzenden. Und sie gibt keine Rechtsauskunft: Ob und wie das BFSG für Ihr Angebot gilt, klärt die Rechtsabteilung.
Was danach vorliegt
Nach der Kontextanalyse liegen vor: eine Beschreibung der Nutzergruppen mit assistiven Technologien als Betriebsmittel, Personas mit diesem Merkmal im Profil, Szenarien je Aufgabe und Technologie, daraus abgeleitete Nutzungsanforderungen in der gemeinsamen Anforderungsliste und ein Aufgabenplan für die spätere Evaluation. Ihr Team hat damit die Grundlage, Zugänglichkeit in Design und Entwicklung zu entscheiden, statt sie am Ende zu prüfen.