Gemeinsame Planung – der vergessene Schritt bei der barrierefreien Gestaltung

Sie möchten barrierefreie Benutzererlebnisse schaffen. Alle Mitglieder des Entwicklungsteams sind sich darüber einig. Aber verstehen alle unter „Erfolg“ dasselbe? Wenn Ihr Team nicht dieselbe Sprache spricht, ist die Wahrscheinlichkeit größer, dass Sie scheitern, als dass Sie die angestrebten Ergebnisse erzielen. Gemeinsame Planung ist der Schlüssel, wird aber allzu oft übersehen. In diesem Beitrag stelle ich einen Ansatz für die gemeinsame Planung vor, der als „Accessibility Behavior Informed Development“ (a11yBID) bezeichnet wird und eine Erweiterung des ursprünglich von Dan North entwickelten „Behavior Driven Development“ (BDD) darstellt. a11yBID kann von agilen Entwicklungsteams genutzt werden, um vor Beginn der Entwicklung hochwertige Barrierefreiheitsanforderungen in Form von Akzeptanzkriterien zu ermitteln und zu dokumentieren. Bevor wir uns damit befassen, was a11yBID ist und wie es funktioniert, sollten wir zunächst untersuchen, wie es dazu gekommen ist.

„Wer sich nicht vorbereitet, bereitet sich auf das Scheitern vor.“ – Benjamin Franklin

Als Barrierefreiheits-Coach arbeite ich mit Kunden zusammen, die ihren Teams das „Fischen“ beibringen möchten – das heißt, sie möchten, dass ihre Teams künftig selbstständig arbeiten können, ohne dass ich (oder andere Fachexperten) mich weiter stark einbringen muss. Bei einem Kunden haben wir kleine Experimente mit alternativen Ansätzen durchgeführt und schnell festgestellt, dass jeder Ansatz seine eigenen Schwachstellen hatte – und dass diese Schwachstellen auch dann noch bestanden, wenn die Ansätze kombiniert wurden. Keiner der Ansätze war optimal, da das Thema Barrierefreiheit zu spät im Entwicklungsprozess berücksichtigt wurde oder eine zu große Belastung für eine einzelne Person darstellte:

Der Einsatz von Checklisten zur Barrierefreiheit während der Entwicklung und des Testens scheitert oft daran, dass sie Punkte enthalten, die für den Umfang einer bestimmten Story nicht relevant sind, und dass die relevanten Punkte oft zu abstrakt sind. Dies erschwert es dem Team, die Entwicklungsarbeit genau zu planen, zu definieren und einzuschätzen. Vielleicht noch wichtiger ist, dass Teams bei einer solchen Verwendung von Checklisten oft Probleme mit dem Design oder den Inhalten entdecken. Dies führt dazu, dass der gesamte Prozess um mehrere Schritte zurückgeworfen wird, während diese Probleme überprüft und behoben werden, was zu erheblichen Verzögerungen führt.
Ebenso ist die Berücksichtigung der Barrierefreiheit in übergeordneten Anforderungsdokumenten wie der „Definition of Done“ oft zu vage, um wirklich nützlich zu sein, und birgt dieselben Fallstricke wie Checklisten.
Entwürfe, die mit Entwicklungshinweisen versehen sind, setzen voraus, dass der Designer sich mit barrierefreiem Design bestens auskennt und über ausreichende Programmierkenntnisse verfügt, um umfassende Anleitungen für Entwickler zu erstellen. Zudem fließen vor der Entwicklung in der Regel keine Fachmeinungen von Entwicklern oder Testern ein.
Die Automatisierung der Barrierefreiheit ist sowohl für die Effizienz als auch zur Vermeidung von Regressionen unerlässlich. So kann unsere Browser-Erweiterung beispielsweise 57 % der Probleme bei der Barrierefreiheit im Web erkennen. Allerdings lassen sich nicht alle Anforderungen an die Barrierefreiheit durch Automatisierung testen. Außerdem kann sie frühestens während der Entwicklung eingesetzt werden. Im Idealfall sollten die Anforderungen bereits vor der Entwicklung ermittelt und dokumentiert werden, nicht erst währenddessen.
Schulungen und Fortbildungen zum Thema Barrierefreiheit für das Team sind unerlässlich, können jedoch für sich genommen keine barrierefreie Software garantieren.

Das soll nicht heißen, dass es für jede dieser Methoden keinen geeigneten Zeitpunkt und keinen geeigneten Rahmen gäbe, und viele davon wären für Teams sicherlich hilfreich. Wir müssen uns jedoch ihrer potenziellen Schwächen bewusst sein. Selbst wenn man sie alle zusammen betrachtet, fehlt ihnen ein sehr wichtiger Schritt im Prozess: die gemeinsame Planung. Damit Teams erfolgreicher und effizienter arbeiten können, sollten sie die abstrakte, übergeordnete Anforderung der Barrierefreiheit aufgreifen und gemeinsam daran arbeiten, sie in die Praxis umzusetzen. Sie sollten vor Beginn der Entwicklung ausdrücklich dokumentieren, wie diese Anforderung in die zu entwickelnde Software integriert werden soll. Mit anderen Worten: Teams müssen zusammenarbeiten, um Barrierefreiheit bereits ab der Entwurfsphase bewusst zu gestalten.

Nachdem ich in einige Teams eingebunden war, stellte ich fest, dass viele ihrer Entwicklungsprozesse Aspekte von BDD enthielten und dass diese Prozesse gut geeignet waren, die von uns entdeckten Lücken zu schließen. Wir probierten aus, wie wir diese Aspekte von BDD nutzen könnten, und kamen schließlich zu dem Ergebnis, das hier beschrieben wird. Ich möchte die Idee nicht als meine eigene ausgeben – sie entstand in gemeinsamer Arbeit mehrerer unserer Barrierefreiheits-Coaches und unserer Kunden. Ich habe dabei geholfen, diese Zusammenarbeit zu fördern, unsere Erkenntnisse zu dokumentieren und ihr einen Namen zu geben.

Was ist BDD?

Um a11yBID zu verstehen, muss man zunächst wissen, was BDD ist und warum es von Vorteil ist.

Aus Wikipedia:

Die verhaltensorientierte Entwicklung (BDD) ist ein agiler Softwareentwicklungsprozess, der die Zusammenarbeit zwischen Entwicklern, Qualitätssicherungstestern und Kundenvertretern in einem Softwareprojekt fördert. Sie regt Teams dazu an, mithilfe von Gesprächen und konkreten Beispielen ein gemeinsames Verständnis darüber zu formulieren, wie sich die Anwendung verhalten soll.

Ein häufiges Problem in der Softwareentwicklung ist, dass Projekte verspätet oder über dem Budget fertiggestellt werden oder nicht alle gewünschten Funktionen und Anforderungen erfüllen. Diese Probleme sind in der Regel auf mangelnde Planung, ein fehlendes gemeinsames Verständnis der Anforderungen und undokumentierte Annahmen zurückzuführen. Um dem entgegenzuwirken, nutzt BDD Gespräche zwischen den Beteiligten und den Mitgliedern funktionsübergreifender Teams, um konkrete Beispiele für das Systemverhalten – auch als Szenarien bezeichnet – zu ermitteln und zu formulieren. Diese Beispiele enthalten Akzeptanzkriterien (AC) und werden in der Regel in einer einfachen, maschinenlesbaren Sprache beschrieben, die als Gherkin bekannt ist.

Szenario: Eine Zusammenfassung des gewünschten Verhaltens.
Vorgaben: Beschreibt etwaige Voraussetzungen und den Kontext; bereitet die Testumgebung vor.
Wann: Beschreibt die Aktion, die getestet wird.
Dann: Beschreibt die erwarteten Ergebnisse.

Das Verfassen von Anforderungen in einem strukturierten, leicht verständlichen Format wie diesem ermöglicht es dem gesamten Team, einschließlich nicht-technischer Stakeholder, die Anforderungen zu verstehen und zu verfeinern. Es beseitigt Unklarheiten, die zu Annahmen über erwartete Verhaltensweisen und Ergebnisse führen würden, was zu einem besseren gemeinsamen Verständnis führt. Die Szenarien und die zugehörigen ACs können zudem sowohl als „lebende Dokumentation“ für die Software als auch als testbare und ausführbare Spezifikation für die Software dienen. Das heißt, die Szenarien im Gherkin-Stil lassen sich in der Regel automatisch als Teil der Testsuite des Projekts über ein Test-Framework wie Cucumber oder JBehave testen.

Wenn Sie sich eingehend mit BDD befassen möchten, lesen Sie das Buch „BDD in Action“ von John Smart.

Barrierefreiheit durch verhaltensorientierte Entwicklung (a11yBID)

Die Barrierefreiheit von Software leidet unter sehr ähnlichen Problemen, erfordert jedoch einen etwas anderen Ansatz. Das Thema Barrierefreiheit wird oft nicht vollständig verstanden, vor Beginn der Entwicklung nicht explizit einplant, und Tests finden – wenn überhaupt – erst kurz vor oder nach der Veröffentlichung statt. Dies führt dazu, dass Projekte verspätet, über dem Budget und ohne die erforderlichen Barrierefreiheitsfunktionen ausgeliefert werden. Das Endergebnis ist nicht barrierefreie Software und unerwartete Kosten für Nachbesserungen.

A11yBID erweitert Aspekte von BDD, um Teams dabei zu unterstützen, Barrierefreiheit explizit einzuplanen. Mit a11yBID nutzen Teams konkrete Beispiele wie Entwürfe und Gespräche zwischen funktionsübergreifenden Teammitgliedern, um zu ermitteln und zu dokumentieren, wie sich die Benutzeroberfläche des Systems unter dem Gesichtspunkt der Barrierefreiheit verhalten sollte. Zur Dokumentation dieser Verhaltensweisen werden Szenarien im Gherkin-Stil und Akzeptanzkriterien (AC) verwendet, die als „Accessibility Acceptance Criteria“ (a11yAC) bezeichnet werden. Diese a11yAC werden dann zusammen mit den übrigen AC, die im Rahmen des BDD-Prozesses (oder eines ähnlichen Verfahrens) ermittelt wurden, in die User Stories aufgenommen. Dies trägt dazu bei, dass sich das gesamte Team vor Beginn der Entwicklung über die Erwartungen einig ist, und ermöglicht es ihm, die Arbeit genauer zu planen, zu definieren und zu schätzen. Das Team nutzt die a11yAC anschließend wie folgt:

Entwickler lesen sie, um zu erfahren, was sie programmieren und wie sie testen sollen.
Die Tester lesen sie, um zu erfahren, was und wie sie testen sollen.
Produktverantwortliche lesen diese durch, um die Auswirkungen auf die Endnutzer zu verstehen, und prüfen, ob die Kriterien erfüllt sind, bevor sie eine Story annehmen.
Neue Teammitglieder nutzen sie, um zu verstehen, welche Entscheidungen hinsichtlich der Barrierefreiheit getroffen wurden. Dies hilft ihnen, die Codebasis besser zu verstehen und Regressionen zu minimieren.

Hier ist ein Überblick über den a11yBID-Prozess aus der Vogelperspektive. Im weiteren Verlauf dieses Beitrags wird der Prozess näher beleuchtet.

Eingabe:
1. Erstellen Sie konkrete Beispiele für die Benutzeroberfläche (z. B. High-Fidelity-Entwürfe).
Prozess: a11yBID
1. Nutzen Sie Gespräche sowie bestehende Richtlinien und Hilfsmittel, um die Beispiele zu prüfen, und erarbeiten Sie anschließend auf der Grundlage dieser Beispiele a11yAC.
Ausgabe
1. Überarbeitete Designs, die barrierefreier sind.
2. A11yAC.

In den meisten Fällen liegen die konkreten Beispiele in Form von High-Fidelity-Entwürfen vor. Diese Entwürfe dokumentieren die Anforderungen an die Barrierefreiheit in Bezug auf die Verwendung von Farben, visuellen Inhalten und Interaktionen sehr gut. Während des a11yBID-Prozesses wird der Entwurf vom Team auf Barrierefreiheit überprüft, während es sich mit den entsprechenden Aspekten auseinandersetzt, und es werden Anpassungen vorgenommen, um den Entwurf barrierefreier zu gestalten. Mit anderen Worten: Die meisten designspezifischen Barrierefreiheitsanforderungen sind in den Entwürfen selbst dokumentiert und nicht in a11yAC. Nachdem die Entwürfe programmiert wurden, überprüfen Tester, ob die Umsetzung mit dem visuellen Design übereinstimmt, und testen so die im visuellen Design dokumentierten Barrierefreiheitsanforderungen.

Visuelle Entwürfe versagen jedoch bei der Beschreibung der Nutzung von assistiver Technologie, wie beispielsweise der Nutzung von Bildschirmleseprogrammen oder der Bedienung über die Tastatur. a11yAC schließen diese Lücke und dienen dazu, die Nutzung von assistiver Technologie im Rahmen des Entwurfs zu dokumentieren. a11yAC können zudem dazu verwendet werden, Anforderungen an das visuelle Design zu dokumentieren, die im Entwurf selbst möglicherweise nicht eindeutig dargestellt sind (wie beispielsweise Seitentitel), oder andere Aspekte der Barrierefreiheit.

For the most part, a11yAC that describes a screen reader experience should be agnostic. They should not be written to include specific screen reader commands or output. This allows the a11yAC to be tested in many screen readers while keeping them simple and easy to understand. For example, say “when I navigate to” instead of “when I press <key>.” Similarly, state the expected semantics such as role, state, or property instead of how a specific screen reader will convey those items. For example, say “then I hear the image role” instead of “then I hear the word ‘graphic’.” Developers that are new to accessibility may see these semantics in the a11yAC and reach directly for ARIA when it is not needed, breaking the first rule of ARIA (if you can use an existing native HTML element or attribute, then do so). If desired, information on screen reader-specific commands and output can be provided in notes. Coding suggestions, further reading, and links to example implementations can also be included in the notes to enhance learning and mitigate ARIA misuse.

Digitale Barrierefreiheit kann ein tiefgreifendes, weitreichendes und subjektives Thema sein. Damit Teams beim Thema bleiben und einen Mehrwert schaffen können, sollten sich die von a11yBID moderierten Gespräche auf die Einhaltung der WCAG, das Feedback von Endnutzern mit Behinderungen und branchenweit anerkannte Best Practices konzentrieren. Um ähnliche Gespräche im Rahmen von BDD zu ermöglichen, nutzen Teams häufig das Konzept eines „3-Amigos“-Meetings (manchmal auch als Pre-Refinement-Meeting bezeichnet), bei dem ein Product Owner, ein Entwickler und ein Tester gemeinsam daran arbeiten, die Anwendungsanforderungen (AC) zu ermitteln und zu formulieren. Ein ähnliches Meeting, das ich als „a11y Amigos“ bezeichnen werde, kann genutzt werden, um a11yBID-Gespräche zu moderieren. An diesem Meeting sollten der Analyst (Story-Autor), ein Entwickler, ein Tester und der Designer teilnehmen. Es ist am besten, dieses Meeting auf die unbedingt notwendigen Personen zu beschränken, damit andere nicht daran gehindert werden, an anderen wichtigen Aufgaben zu arbeiten. Der entscheidende Punkt hierbei ist, dass von keiner einzelnen Person im Team erwartet wird, genug über alle Aspekte der Barrierefreiheit zu wissen, um qualitativ hochwertige Anforderungen zu formulieren. Stattdessen werden dieses Wissen und diese Verantwortung auf verschiedene Teammitglieder verteilt.

A11yBID treibt die Entwicklung auf eine andere Weise voran als BDD. Es ermittelt keine klassischen Geschäftsanforderungen wie BDD. Stattdessen verdeutlicht es die barrierefreiheitsspezifischen Aspekte dieser Geschäftsanforderungen und fließt in deren Entwicklung ein. Deshalb heißt es „Accessibility Behavior Informed Development“ und nicht „Accessibility Behavior Driven Development“. Das soll nicht heißen, dass a11yBID nicht dazu beitragen kann, geschäftliche Anforderungen zu ermitteln – einschließlich solcher, die sich auf Barrierefreiheit konzentrieren –, aber das ist nicht sein Hauptzweck.

Beispiel 1 – Fehlermeldung

Nehmen wir zum Beispiel an, ein Analyst hat die Aufgabe, ein AC für ein Formularvalidierungsszenario zu erstellen, bei dem die Daten zwar gültig sind, der Server jedoch nicht reagiert. Das Team könnte dabei etwa wie folgt vorgehen:

Fordern Sie Beispiele für die Interaktionen und Fehlermeldungen in Form von High-Fidelity-Entwürfen an.
Veranstalte ein „a11y Amigos“-Treffen, bei dem:
1. Die Gruppe prüft die Entwürfe, stellt Fragen und räumt Annahmen aus dem Weg. Beispielsweise könnte sie den Designer fragen, ob und wann ein Ladesymbol angezeigt wird, während der Nutzer auf eine Antwort vom Server wartet. Der Tester könnte Bedenken hinsichtlich der Fokusverwaltung äußern … wohin soll der Tastaturfokus nach dem Klicken auf die Absenden-Schaltfläche springen? Der Entwickler könnte vorschlagen, dass der Tastaturfokus zunächst auf das Ladesymbol und dann auf die Fehlermeldung springt, damit ein Nutzer eines Screenreaders Statusaktualisierungen hört und sichergestellt ist, dass der Tastaturfokus niemals verloren geht.
2. Die Gruppe könnte auf Ressourcen wie die Checklisten und die Testmethodik der „Deque University“ zurückgreifen, um sicherzustellen, dass sie nichts übersehen hat.
3. Der Analyst erstellt auf der Grundlage dieser Gespräche einen a11yAC-Entwurf.
Führen Sie eine umfassendere Besprechung zur Verfeinerung durch, bei der das gesamte Team die Stories (einschließlich a11yAC) durchgeht, um sicherzustellen, dass alle auf dem gleichen Stand sind und keine Anforderungen übersehen wurden. Das Team schätzt den Aufwand, der zur Fertigstellung der Story erforderlich ist, und bezieht dabei auch a11yAC in die Schätzungen mit ein. Sollten Meinungsverschiedenheiten auftreten, kann dies ein Hinweis darauf sein, dass es undokumentierte Anforderungen gibt.

Der a11yAC für dieses Beispiel könnte etwa so aussehen:

A11y AC 1 – Ladeanzeige – informatives Bild wird vermittelt – Benutzererfahrung mit Screenreadern

Szenario: Ein blinder Screenreader-Nutzer kann erkennen, dass Inhalte geladen werden
Angenommen, ich bin ein blinder Screenreader-Nutzer
Und ich habe das Formular abgeschickt
Und während ich auf eine Antwort vom Server warte, ist ein Lade-Symbol sichtbar
Wenn ich zum Bild des Lade-Symbols navigiere
Dann höre ich die Bildrolle
Und ich höre den Alt-Text „Laden“

A11y AC 2 – Schaltfläche – Fokus auf Ladeanzeige verschieben – Benutzererfahrung bei der Tastaturbedienung

Szenario: Der Tastaturfokus springt nach dem Klicken auf die Schaltfläche „Absenden“ auf den Lade-Indikator
Angenommen, ich bin ein sehender Nutzer, der ausschließlich die Tastatur verwendet und eine motorische Behinderung hat
Wenn ich das Formular absende
Und das Formular durch einen Lade-Indikator ersetzt wird
Dann springt mein Tastaturfokus auf den Lade-Indikator
Und ich kann visuell erkennen, wo sich der Fokus auf der Seite befindet

A11y AC 3 – Fokus auf Fehlermeldung verschieben – Benutzererfahrung bei der Tastaturbedienung

Szenario: Der Tastaturfokus springt auf die Fehlermeldung, sobald diese angezeigt wird
Angenommen, ich bin ein sehender Nutzer, der ausschließlich die Tastatur verwendet und eine motorische Behinderung hat
Und ich habe das Formular abgeschickt
Und es wird ein Lade-Symbol angezeigt
Wenn die Fehlermeldung angezeigt wird
Und das Lade-Symbol ausgeblendet wird
Dann springt mein Tastaturfokus auf den Container für die Fehlermeldung
Und ich kann visuell erkennen, wo sich der Fokus auf der Seite befindet

Realistisch betrachtet sollte es für die Fehlermeldung mehr a11yAC geben. Wenn die Fehlermeldung beispielsweise ein Bild, eine Überschrift und vielleicht eine Schaltfläche zum erneuten Absenden enthält, sind alle diese Elemente relevante a11yAC. Um dieses Beispiel kurz zu halten, wurden diese AC jedoch ausgelassen.

In diesem Beispiel entschied sich das Team, a11yAC sowohl für die Benutzererfahrung mit einem Screenreader als auch für die Benutzererfahrung sehender Nutzer bei der Tastaturbedienung hinzuzufügen. Es war klar, dass der Tastaturfokus nach dem Ersetzen des Formulars durch einen Lade-Spinner verwaltet werden musste. Andernfalls würde der Tastaturfokus verloren gehen. Da sich die Benutzererfahrungen teilweise überschneiden – ein Screenreader meldet Änderungen des Tastaturfokus –, beschloss das Team, ACs für die Tastatur nur dort einzubeziehen, wo es Überschneidungen gab, da Anforderungen an die Tastaturbedienung im Allgemeinen auch leichter zu testen sind. Dies trug dazu bei, die Gesamtzahl der ACs zu reduzieren und gleichzeitig alle Anforderungen abzudecken sowie das Ziel klar zu definieren.

a11yBID skalierbarer und effizienter gestalten

„Gebt mir sechs Stunden, um einen Baum zu fällen, und ich werde die ersten vier damit verbringen, die Axt zu schärfen.“ – Abraham Lincoln

Wie Sie vielleicht bereits bemerkt haben, können einige Aspekte des a11yBID-Prozesses zeitaufwendig sein, insbesondere die Erstellung maßgeschneiderter a11yAC. Dieses Problem verschärft sich noch, wenn Recherchen erforderlich sind, um zu verstehen, wie die WCAG-Anforderungen auf ein bestimmtes Design anzuwenden sind oder wie assistive Technologien wie Screenreader unter bestimmten Umständen funktionieren sollten. Glücklicherweise gibt es mehrere Strategien, mit denen sich der a11yBID-Prozess skalierbarer und effizienter gestalten lässt.

Designsystem und Komponentenbibliothek

In erster Linie sind ein barrierefreies Designsystem und eine barrierefreie Komponentenbibliothek von entscheidender Bedeutung. Barrierefreie Designsysteme ermöglichen es Designern, Komponenten wiederzuverwenden, die bereits unter Berücksichtigung der Barrierefreiheit entworfen wurden – beispielsweise wurden bereits Überprüfungen hinsichtlich des Farbkontrasts von Text und Nicht-Text, der Verständlichkeit von Fehlermeldungen und Anweisungen sowie der Vermeidung der alleinigen Vermittlung von Informationen durch Farben durchgeführt. Ein barrierefreies Designsystem für Ihr Unternehmen bedeutet, dass Designer weniger Zeit damit verbringen müssen, sich mit den Auswirkungen gemeinsamer Designmuster auf die Barrierefreiheit auseinanderzusetzen. Ein barrierefreies Designsystem macht die Berücksichtigung der Barrierefreiheit zwar nicht überflüssig, minimiert jedoch den Zeit- und Arbeitsaufwand und trägt dazu bei, Konsistenz für die Endnutzer zu gewährleisten.

Ebenso erleichtert eine barrierefreie Komponentenbibliothek, die mit dem Designsystem verknüpft ist, es Entwicklern erheblich, die Designs schnell und präzise barrierefrei umzusetzen. Eine Bibliothek mit barrierefreien Komponenten verringert das Risiko, dass Entwickler versehentlich Barrierefreiheitsfehler einbauen, und trägt dazu bei, Endnutzern ein einheitliches und vorhersehbares Verhalten sowie vorhersehbare Interaktionen zu bieten. Eine barrierefreie Komponentenbibliothek wie „Cauldron“ vonDeque ermöglicht es zudem, Fehler an einer einzigen Stelle zu beheben und die Korrekturen auf mehrere Implementierungen zu übertragen, wodurch den einzelnen Teams Zeit und Aufwand erspart bleibt, diese Fehler einzeln zu beheben.

Die Kombination aus einem barrierefreien Designsystem und einer Komponentenbibliothek garantiert zwar noch keine absolut fehlerfreie Barrierefreiheit, schafft aber eine solide Grundlage. Designer können nach wie vor Barrierefreiheitsmängel verursachen, indem sie das Designsystem überschreiben oder Muster verwenden, die nicht im Designsystem enthalten sind. Ebenso können Entwickler Barrierefreiheitsmängel verursachen, indem sie gemeinsam genutzte Komponenten überschreiben, diese nicht korrekt verknüpfen oder eigene benutzerdefinierte Komponenten erstellen.

Eine a11yAC-Bibliothek erstellen

Im Laufe des a11yBID-Prozesses werden die Teams schnell feststellen, dass sie häufig dieselben oder ähnliche a11yAC-Dateien erstellen. Hier kann eine a11yAC-Bibliothek äußerst nützlich sein, um:

Erstellen Sie a11yAC-Vorlagen für gängige Komponenten und Muster, die in Ihrem Unternehmen verwendet werden.
Unterstützen Sie Analysten (oder wen auch immer, der Berichte verfasst) bei der Auswahl relevanter a11yAC für gängige Komponenten und Muster.

Dies spart enorm viel Zeit und Aufwand bei der Ermittlung und Ausarbeitung maßgeschneiderter a11yAC-Maßnahmen und sorgt für Einheitlichkeit teamübergreifend. Tatsächlich kann dadurch der Bedarf an A11y-Amigos-Treffen erheblich reduziert werden.

Im Rahmen unseres Coaching-Programms können wir Ihnen dabei helfen, eine a11yAC-Bibliothek zu erstellen.

AIMS verwenden

Der AIMS-Workflow ist eine bewährte Methode für Analysten (oder alle, die Berichte verfassen), um a11yBID auf effiziente und skalierbare Weise anzugehen, vorausgesetzt, Sie verfügen über eine a11yAC-Bibliothek. Eine einfache Eselsbrücke für AIMS lautet: „Unser Team strebt nach soliden Anforderungen, indem es die Barrierefreiheit stets im Blick behält.“ Der Workflow sieht wie folgt aus:

[A] Beurteilen Barrierefreiheit bei der Gestaltung berücksichtigen, Fragen stellen und Vorannahmen hinterfragen.
1. Identifizieren und beheben Sie etwaige Probleme, bevor sie später im Prozess von Entwicklern oder Testern entdeckt werden. Der Analyst muss kein Experte für Design oder Barrierefreiheit sein, sollte jedoch in der Lage sein, eine oberflächliche Überprüfung des Designs durchzuführen, und kann dabei auf Ressourcen wie die „Deque -University“ zurückgreifen. Der Designer sollte seine Entwürfe bereits vor der Übergabe an den Analysten auf Barrierefreiheit überprüfen, doch der Analyst ist gut aufgestellt, um dem Prozess eine zusätzliche Sicherheitsstufe hinzuzufügen.
2. Beseitigen Sie Annahmen hinsichtlich der Funktionalität (Interaktionen, dynamische Inhalte usw.) oder der Inhalte (Seitentitel, Alt-Text usw.), indem Sie Fragen stellen und sich mit dem Designer und dem Autor der Inhalte austauschen.
[I] Identifizieren und Bestand im Entwurf verwendete Muster.
1. Verwenden Sie ein Tool wie Snagit, um das Design mit Anmerkungen zu versehen, alle Muster zu erfassen und erste Lücken zu identifizieren (Unbekannte, die später geklärt werden müssen).
[M] Karte diese Muster mithilfe der Anleitungen aus der AC-Bibliothek in AC zu implementieren.
1. Nutzen Sie die Anleitung, um relevante a11yAC-Vorlagen zu kopieren, und passen Sie diese anschließend so an, dass sie besser zum Kontext der jeweiligen Geschichte passen, in der sie verwendet werden.
[S] Lösen für etwaige verbleibende Lücken, wie beispielsweise offene Fragen oder fehlende AC.
1. In jedem Schritt des Prozesses können Lücken auftreten. Lücken sind beispielsweise Aussagen wie „Ich finde für diesen Teil des Designs keine Muster, keine Leitlinien und keine AC.“ Arbeiten Sie gemeinsam mit Ihrem Team daran, mithilfe des übergreifenden a11yBID-Prozesses Lösungen für diese Lücken zu finden.
2. Deque Die Universität ist eine hervorragende Quelle, die Aufschluss über die Lücken geben kann.

So viel wie möglich automatisieren

Deque bietet eine Vielzahl von Tools, mit denen sich Barrierefreiheitstests so weit wie möglich automatisieren lassen. Durch den Einsatz dieser Tools können Teams Anforderungen aufdecken, die bei der Planung möglicherweise übersehen wurden. Da sich a11yAC-Maßnahmen in der Regel auf entwicklungsbezogene Aspekte konzentrieren, kann diese Art der Automatisierung zudem die Robustheit erhöhen, indem sie auch Designprobleme wie den Farbkontrast überprüft. So kann beispielsweise „ axe-core “ 57 % der Probleme bei der Barrierefreiheit im Web aufdecken. Unsere „Intelligent Guided Tests“ können diese Zahl auf 80 % oder mehr steigern. Darüber hinaus ist die Einbindung dieser Automatisierung in die CI/CD-Pipeline entscheidend, um Barrierefreiheitsrückschritte in Zukunft zu verhindern. Ein einfacher Einstieg wäre die Installation des kostenlosen „axe-linter“ für Visual Studio Code. Dieser prüft Ihre Projekte bereits während der Programmierung auf Barrierefreiheitsprobleme.

Möglicherweise lassen sich auch einige der a11yAC selbst automatisch testen, indem programmgesteuert ein Snapshot des Barrierefreiheitsbaums des Browsers oder der Barrierefreiheits-APIs des Systems überprüft wird. Ebenso könnte es möglich sein, die meisten a11yAC, die sich auf das Tastaturverhalten konzentrieren, mithilfe von Tools wie Puppeteer oder Playwright automatisch zu testen. Im Idealfall könnten a11yAC durch die Automatisierung von Screenreadern selbst getestet werden. Eine solche Automatisierung der a11yAC kann dazu beitragen, Regressionen in Zukunft zu verhindern, den Aufwand für manuelle Tests zu reduzieren und dem Entwicklungsteam sowie den Beteiligten mehr Sicherheit bei der Durchführung von Änderungen zu geben. Beachten Sie, dass eine gewisse Automatisierung von Screenreadern derzeit zwar möglich ist, es sich jedoch um eine noch junge Technologie handelt, die zum Zeitpunkt der Erstellung dieses Artikels wahrscheinlich noch nicht robust genug ist, um sich voll und ganz darauf zu verlassen.

Nutzen Sie das Coaching-Programm von „ Deque“

Nachhaltige Barrierefreiheit erfordert Veränderungen in Bezug auf Fähigkeiten, Bereitschaft und Prozesse. Das Accessibility-Coaching-Programm von „ Deque“ kann Ihren Teams dabei helfen, einen transformativen Weg einzuschlagen, um diese Veränderungen zu erreichen. Jedes Team arbeitet auf seine eigene Weise, und unser Coaching-Programm kann Teams dabei unterstützen, a11yBID und andere Barrierefreiheitspraktiken nahtlos in ihren spezifischen Softwareentwicklungszyklus zu integrieren. Das Verfassen hochwertiger a11yAC erfordert viel Übung und Erfahrung bei der Auslegung der WCAG sowie beim Verständnis von assistiven Technologien – zusätzlich zum Wissen darüber, wie man die gewünschten Ergebnisse entwickelt. Unser Coaching-Programm kann Ihrem Team helfen, schnell auf den neuesten Stand zu kommen.

Fallstricke

A11yBID ist kein Allheilmittel. Es erfordert bewusste, konsequente Umsetzung und das Engagement des gesamten Teams, sich mit Barrierefreiheit auseinanderzusetzen und regelmäßig zusammenzuarbeiten. Ähnlich wie BDD funktioniert es in der Regel besser in Teams, die bereits agil arbeiten, und weniger gut in Wasserfall- oder anderen nicht-agilen Kontexten. Zudem ist a11yBID kein Ersatz für automatisierte Barrierefreiheitstests, manuelle Prüfungen und externe Validierung. Es zielt darauf ab, die Anzahl der Barrierefreiheitsfehler in einem Produkt zu verringern, doch inwieweit dies gelingt, hängt größtenteils vom Wissen und der Erfahrung des Teams ab.

Selbst bei erfahrenen Teams können und werden Anforderungen bei der Planung übersehen. Das Team kann die Funktion „Intelligent Guided Testing“ (IGT) in derBrowser-Erweiterung „axe DevTools“ nutzen, um Fehler aufgrund dieser übersehenen Anforderungen zu minimieren. IGT geht über automatisierte Tests hinaus und führt Entwickler durch manuelle Tests. Es hat sich gezeigt, dass damit 80 % oder mehr der Barrierefreiheitsprobleme erkannt werden, die üblicherweise bei manuellen Prüfungen durch Experten festgestellt werden.

In einer einzelnen Story kann es potenziell viele a11yAC geben. Teams müssen das richtige Gleichgewicht zwischen Ausführlichkeit, Klarheit und Effizienz finden. Es ist wichtig zu bedenken, dass die Anzahl der AC in einer Story nicht unbedingt den Aufwand widerspiegelt, der für die Entwicklung der Story erforderlich ist. Vielmehr hilft die klare Dokumentation der Barrierefreiheitsanforderungen als AC den Teams dabei, den Arbeitsumfang genau zu verstehen, ihn abzuschätzen, zu entwickeln, zu testen und termingerecht zu liefern. Es gibt viele Wege, dieses Gleichgewicht zu erreichen, und unser Coaching-Programm kann dabei helfen.

Das ist nicht nur Theorie

Ben Allen, ehemaliger Digital Product Manager bei PNC, erläutert in seinem Webinar „Agile Accessibility Requirements at Scale: How PNC incorporates accessibility requirements into agile practice“ ( Agile Barrierefreiheitsanforderungen in großem Maßstab: Wie PNC Barrierefreiheitsanforderungen in die agile Praxis integriert) im Rahmen der Webinar-Reihe „ Deque “ die Vorteile von a11yAC und einer AC-Bibliothek sowie die Rolle, die „ Deque “ bei der Entwicklung dieses Ansatzes gespielt hat.

Einige Zitate von einigen unserer Kunden:

Durch Versuch und Irrtum haben wir in diesem Bereich gelernt, dass Konsistenz entscheidend ist. Ohne konsistente, zuverlässige und wiederverwendbare barrierefreie Komponenten fehlte unseren Teams ein wichtiges Puzzleteil. Es reichte uns nicht aus, lediglich über eine Bibliothek für barrierefreie Komponenten und ein Designsystem zu verfügen. Der Aufbau und die Implementierung unserer eigenen Bibliothek für barrierefreie Komponenten in Zusammenarbeit mit unseren „ Deque “-Coaches war ein Durchbruch, auf den wir heute nicht mehr verzichten können. – Kelly (Digital Product Manager)

Sobald Sie verstanden haben, was nötig ist, um ein barrierefreies Produkt zu entwickeln, werden Sie schnell erkennen, dass Sie über spezifische, zielgerichtete Akzeptanzkriterien (AC) verfügen müssen, um diesem Bedarf gerecht zu werden. Die vom „ Deque “-Team bereitgestellte a11y-Bibliothek war für unser Team eine enorme Hilfe. Die Bibliothek enthält nicht nur zahlreiche fundierte Akzeptanzkriterien, sondern auch eine Fülle zusätzlicher Ressourcen.

Als wir begannen, die a11y AC-Bibliothek zu nutzen, konnten wir nicht nur die Barrierefreiheit wesentlich effizienter in unser Produkt integrieren, sondern stellten auch fest, dass wir die Inhalte an ganz spezifische Situationen anpassen konnten. Zusammenfassend lässt sich sagen, dass uns dies nicht nur dabei half, die Barrierefreiheit besser in unser Produkt zu integrieren, sondern dass wir dies auch effizienter umsetzen konnten. – Michael (Analyst)

Die Akzeptanzkriterien für Barrierefreiheit (A11y) werden mit derselben Sorgfalt und größter Ernsthaftigkeit behandelt wie alle anderen Akzeptanzkriterien. Dies hat unserer Entwicklungsarbeit eine menschliche Note verliehen, die erfrischend ist und auf die wir stolz sein können. – Daniel (Entwickler)

Zunächst hatte ich Bedenken, dass sich der zusätzliche Entwicklungsaufwand bei unseren ohnehin schon umfangreichen Lieferverpflichtungen negativ auf die Leistungsfähigkeit meines Teams auswirken würde. Ich dachte, dass mehr Schulungen für mich und meine Teamkollegen sowie Stories mit zahlreichen a11y-Akzeptanzkriterien uns ausbremsen würden. Ich freue mich, berichten zu können, dass ich mich geirrt habe.

Ich habe ein weitaus kompetenteres Team kennengelernt, das der Benutzererfahrung von Menschen mit Behinderungen mehr Aufmerksamkeit schenkt. Die Coaches von Deque haben unseren Übergang zu einem inklusiveren Entwicklungsteam reibungslos gestaltet. Deque bietet maßgeschneiderte Schulungen für jedes einzelne Teammitglied – von Designern über Business-Analysten, Entwickler und Tester bis hin zu Product Ownern –, um sicherzustellen, dass sich jedes Teammitglied seiner Rolle bei der Erstellung eines barrierefreien Produkts bewusst ist. Die Barrierefreiheits-Coaches haben in Zusammenarbeit mit anderen Teams gemeinsame Komponenten entwickelt, die in der gesamten neuen Benutzererfahrung zum Einsatz kommen und barrierefrei, responsiv sowie einfach zu implementieren sind. Die Entwicklung jedes Elements geht mit entsprechenden Aktualisierungen der Bibliothek für a11y-Akzeptanzkriterien einher, um Business-Analysten das Verfassen von Stories zu erleichtern. Um die Arbeit noch weiter zu vereinfachen, arbeiten diese Coaches eng mit unserem Team zusammen, um sicherzustellen, dass alle unsere Fragen zur Barrierefreiheit beantwortet werden, und stehen uns jederzeit zur Verfügung. – Chris (Product Owner)

Der Zugang zur AC-Bibliothek hat die Bemühungen unseres Teams um Barrierefreiheit erheblich erleichtert – sowohl beim Verfassen der Testfälle als auch beim Testen. – Gabe (Qualitätsingenieur)

Zusammenfassung

A11yBID ist ein leistungsstarker, agiler Entwicklungsprozess, der Teams dabei helfen kann, Barrierefreiheit bereits in frühen Phasen zu integrieren und zukünftige Kosten für Nachbesserungen zu senken. Teams können damit effizient hochwertige Anforderungen an die Barrierefreiheit ermitteln und formulieren sowie diese in einem benutzerfreundlichen Format dokumentieren, das bereits vor Beginn der Entwicklung getestet werden kann. Hier sind die nächsten Schritte, die Sie unternehmen können:

Wenn Sie bereits BDD-Praktiken anwenden, überlegen Sie, wie Ihr Team diese bestehenden Praktiken nutzen kann, um a11yBID einzuführen.
Versuchen Sie doch einmal, a11yBID in Ihrem nächsten Sprint auf eine einzelne Story anzuwenden. Schauen Sie sich an, wie es funktioniert. Überlegen Sie sich anschließend, wie Sie Effizienzsteigerungen wie beispielsweise eine a11yAC-Bibliothek umsetzen können.
Falls Sie noch kein barrierefreies Designsystem und keine Komponentenbibliothek haben, überlegen Sie sich, wie Sie diese für Ihr Team erstellen können. Wir können Ihnen dabei helfen.
Nutzen Sie das Barrierefreiheits-Coaching-Programm von „ Deque“, um eine transformative Reise zu beginnen und a11yBID in den Entwicklungsprozess Ihres Teams zu integrieren.