In der Webentwickler-Community hat Barrierefreiheit den schlechten Ruf, den Entwicklungsprozess mit zusätzlichem Aufwand und Zeitaufwand zu belasten. Da fast die gesamte Entwicklerwelt agil arbeitet, wurde Barrierefreiheit aus dem „Minimum Viable Product“ (MVP) ausgeklammert und als „Fehler“ oder „Nice-to-have“ abgetan. Einige Unternehmen haben sich sogar damit abgefunden, dass Barrierefreiheit NIEMALS Teil ihres Entwicklungsprozesses sein wird, und beschlossen, ein Overlay zu verwenden, um zu versuchen, ihre Website „barrierefrei“ zu machen.
Um es mit den Worten von Obi-Wan Kenobi zu sagen: „Nur ein Sith denkt in Absolutheiten“. Das Gleiche gilt für Entwicklungsteams und Barrierefreiheit. Es gibt keine absolute Lösung, mit der sich Barrierefreiheit in einem einzigen Sprint in den Entwicklungsprozess integrieren lässt. Es gibt keine einzige Codezeile, die alle Ihre Probleme im Bereich Barrierefreiheit behebt. Sie können Barrierefreiheit jedoch schrittweise in den Entwicklungsprozess integrieren, was letztendlich zu einem gut eingespielten und agilen Barrierefreiheitsprozess in Ihrem Entwicklungsteam führen wird!
Barrierefreiheit in den Entwicklungsprozess integrieren
Barrierefreiheit ist ein fortlaufender Prozess. Die Einbindung in die tägliche Entwicklungsarbeit erfordert Zeit und Mühe, ist aber letztendlich der effektivste Weg, um eine barrierefreie Benutzeroberfläche zu schaffen.
Der beste Weg, um die Barrierefreiheit vollständig in den Webentwicklungsprozess zu integrieren, ist ein schrittweises Vorgehen. Durch die schrittweise Einführung von Barrierefreiheit können Sie langsam, aber sicher effizient und effektiv die erforderlichen Automatisierungsmaßnahmen, Schulungen und Standards für barrierefreies Programmieren einführen, die notwendig sind, um sicherzustellen, dass Ihre Inhalte barrierefrei sind, wenn sie in eine Testumgebung oder in die Produktion übernommen werden.
Phase 1: Fangen Sie klein an mit der Automatisierung
Eine einfache Möglichkeit, täglich Ergebnisse im Hinblick auf die Barrierefreiheit zu erzielen, ist der Einsatz von Automatisierung. Zwar deckt die Automatisierung zwar nur etwa 57 % aller Barrierefreiheitsprobleme ab, doch ist sie auch eine hervorragende Methode, um Ihre Webentwickler dazu anzuregen, bei der Erstellung von Inhalten auf Barrierefreiheit zu achten.
Durch die Verwendung des kostenlosen axe-Linters für VS Code in Verbindung mit Tools, die auf axe-core und axe-core basieren – wie beispielsweise die axe DevTools-Browsererweiterung zum Testen –, erhalten Ihre Entwickler sowohl während der Entwicklung als auch nach der vollständigen Darstellung des Inhalts (Unit-Tests oder Integrationstests) sofortiges Feedback zur Barrierefreiheit. Das Ziel von axe-linter und axe-coreist es, Entwicklern nicht nur die Mittel zur Identifizierung von Problemen an die Hand zu geben, sondern ihnen auch Anleitungen zur Behebung dieser Probleme zu bieten und ihnen beizubringen, wie sie diese in Zukunft vermeiden können. So werden Entwickler für Barrierefreiheit sensibilisiert.
Entwickler können „axe-linter“ nutzen, um Fehler bei der Barrierefreiheit bereits während der Entwicklung in Visual Studio Code zu erkennen. „axe-linter“ erkennt die einfachsten Probleme bei der Barrierefreiheit und gibt sofortiges Feedback, wie diese innerhalb der integrierten Entwicklungsumgebung (IDE) behoben werden können. Es sind keine gerenderten Inhalte erforderlich – es reicht eine JSX-, HTML- oder Vue-Datei, und schon können Sie diese vollständig auf Probleme bei der Barrierefreiheit überprüfen lassen.
Zusätzlich zum Linting können Sie in Ihren automatisierten UI-Tests die „ axe-core “-Integration oder die Browser-Erweiterung „axe DevTools“ nutzen. So können Sie eine vollständige Testumgebung aufbauen und die Inhalte auf Barrierefreiheitsprobleme prüfen. Beide Methoden können bis zu 57,6 % der Barrierefreiheitsprobleme nach Umfang erkennen (SIEHE STUDIE) und gehen damit weit über das reine Linting der Inhalte hinaus. Nun kann ein Entwickler neue Inhalte erstellen und seinen Code einchecken. Anschließend kann ein Teamkollege die neuesten Änderungen abrufen, die UI-Testfälle beim Build ausführen (oder den Inhalt mit der „axe DevTools“-Erweiterung scannen) und im Rahmen der Tests die Ergebnisse zur Barrierefreiheit abrufen.
Es kann ein oder zwei Sprints dauern, bis diese Phase eingerichtet ist und voll funktionsfähig ist. Sobald diese Elemente jedoch eingerichtet sind, wird Ihr Entwicklungsteam schnell und effizient Ergebnisse im Bereich Barrierefreiheit erzielen und gleichzeitig lernen, wie es seine Inhalte barrierefrei gestalten kann!
Phase 2: Schulung zur Barrierefreiheit
Sobald Sie die Automatisierung eingerichtet haben und diese erfolgreich eingesetzt wird und Ihre Entwickler beginnen, die ganz einfachen Barrierefreiheitsprobleme zu erkennen, die sie aufspüren, können Sie nun damit beginnen, entsprechende Schulungen anzubieten.
Schulungen zum Thema Barrierefreiheit sind erforderlich, damit Entwickler und Tester ein besseres Verständnis für digitale Barrierefreiheit entwickeln können. Die Automatisierung hat ihre Grenzen, und die Erstellung barrierefreier Inhalte umfasst noch so viel mehr.
Schulungen zum Thema Barrierefreiheit im Web können Ihnen dabei helfen, ein tieferes Verständnis dafür zu entwickeln, wie Menschen mit Behinderungen Ihre Webanwendung nutzen und mit ihr interagieren, und Ihnen zudem ein besseres Verständnis der Standards für digitale Barrierefreiheit vermitteln. Durch entsprechende Schulungen erhalten Ihre Entwickler einen umfassenderen Einblick darin, warum Inhalte barrierefrei gestaltet werden müssen, welche verschiedenen Muster es für die Erstellung barrierefreier Widgets gibt und wie sie verschiedene assistive Technologien in ihrer täglichen Entwicklungsarbeit einsetzen können.
Diese Schulung muss nicht stundenlang täglich oder gar stundenlang wöchentlich stattfinden. Schon wenn Entwickler und Tester täglich 30 Minuten einplanen, um ein paar Schulungsabschnitte durchzuarbeiten, lässt sich ihr Wissensstand erheblich verbessern, ohne dass dadurch ein großer zusätzlicher Aufwand für ihre tägliche Arbeit entsteht! Selbst die geringste tägliche Lernzeit kann sich am Ende sehr auszahlen.
Deque bietet über die „ Deque University“ eine große Auswahl an Online-Kursen an, die Sie in Ihrem eigenen Tempo absolvieren können. Diese finden Sie hier: https://dequeuniversity.com/.
Phase 3: Barrierefreie Programmierstandards einführen
Eine Möglichkeit, das in Ihren Entwicklungsteams vermittelte Wissen zu festigen, besteht darin, leicht zugängliche Programmierrichtlinien festzulegen. Diese Programmierrichtlinien tragen dazu bei, dass Inhalte, die in Pull-Requests erstellt und bei Code-Reviews geprüft werden, den von Ihrem Team festgelegten Kriterien für Ihre Webkomponenten oder Seiten entsprechen.
Viele Entwicklungsteams arbeiten derzeit mit einem „Ehrensystem“ für automatisierte Tests und manuelle Barrierefreiheitstests, bei dem der Entwickler versichert, die notwendigen Schritte zur Gewährleistung der Barrierefreiheit seines Codes durchgeführt zu haben. Es kann jedoch vorkommen, dass dieser Entwickler ARIA in seinem Widget falsch eingesetzt hat, obwohl einfaches semantisches HTML das Problem hätte beheben können. Dies ist ein immer wiederkehrendes Beispiel dafür, warum Entwickler weiterhin mit Problemen zu kämpfen haben und sich die Gesamtzahl der Barrierefreiheitsprobleme nicht verringert.
An example of an accessible coding standard would be simply instead of creating a button with <div> and <span>, making it required that they use a semantic <button>.
Example using ARIA and <div>:
<div role="button" onClick={this.handleClick}
onKeyPress={this.handleClick} tabindex="0">Click me!</div>
Example using semantic HTML <button>
<button onClick={this.handleClick}>Click me!</button>
Ein weiteres Beispiel ist die Fokusverwaltung bei Modalfenstern. Wenn sich ein Modalfenster öffnet, wohin wandert der Fokus? Auf den Haupttext des Modalfensters, die Überschrift oder die Schaltfläche? Es scheint, als gäbe es heutzutage auf jeder Website mehrere verschiedene Vorgehensweisen hierfür. Die Erstellung eines einheitlichen Musters für Ihre Komponenten kann dazu beitragen, dass die Barrierefreiheit Ihrer Inhalte in Ihrer gesamten Anwendung auf einem einheitlichen Niveau bleibt.
Phase 4: Tests mit Tastatur und Bildschirmleseprogramm hinzufügen
Der letzte Schritt besteht darin, für jede Webkomponente oder Seite, die Ihr Entwicklungsteam erstellt, Tests mit der Tastatur und einem Screenreader durchzuführen. Durch die Einbindung geeigneter Tastatur- und Screenreader-Tests kann Ihr Team sicherstellen, dass Ihre Inhalte so barrierefrei wie möglich sind.
Ja, das wird zunächst mehr Zeit in Anspruch nehmen, als Ihnen lieb ist. Deshalb empfehle ich immer, diesen Schritt als letzten in der Phase der Integration von Barrierefreiheit in Ihren Entwicklungsprozess durchzuführen. Das ordnungsgemäße Testen mit Tastatur und Screenreader kann einige Zeit in Anspruch nehmen, bis es perfekt funktioniert, und erfordert anfangs in der Regel einen höheren Zeitaufwand. Wenn es jedoch Ihr Ziel als Entwicklungsteam ist, sicherzustellen, dass Ihre Inhalte so barrierefrei wie möglich sind, dann ist diese Phase ein Muss!
Das ideale Szenario für die Einbindung von Tastatur- und Screenreader-Tests besteht darin, eine Checkliste mit den verschiedenen Testarten zu erstellen, die das Team für seine Inhalte durchführen muss, bevor diese zusammengeführt und ein Pull Request erstellt werden kann. Ich habe auch schon erlebt, dass diese Überprüfungen vom Teamleiter im Rahmen des PR/Code-Reviews durchgeführt wurden; dies ist jedoch etwas weniger effizient, als wenn ein Entwickler die Tests bereits während der Erstellung der Inhalte durchführt.
Das Erstellen einer Prüfliste kann dabei helfen, die mühsame Frage zu klären, was bei jeder Seite oder Komponente, die der Entwickler erstellt, alles getestet werden muss, und trägt somit auch dazu bei, den Prozess zu beschleunigen!
Weitere Informationen zum Testen mit Screenreadern finden Sie unter folgenden Links:
- https://dequeuniversity.com/curriculum/courses/screenreaders
- https://accessibility.deque.com/live-webinar-introduction-to-screen-readers
Weitere Informationen zum Testen von Tastaturen finden Sie unter:
- https://dequeuniversity.com/tips/keyboard-accessible
- https://dequeuniversity.com/mac/keyboard-access-mac
- https://accessibility.deque.com/website-accessibility-checklist-download
Zusammenfassung
Die Einbindung der Barrierefreiheit in den Entwicklungsprozess ist kein „Alles-oder-nichts“-Schalter, den man einfach umlegen kann. Sie muss schrittweise erfolgen, um sicherzustellen, dass Ihr Entwicklungsteam die Barrierefreiheit ordnungsgemäß in den Entwicklungszyklus integrieren kann und dass es dadurch nicht überfordert wird.
Braucht das Zeit und Geduld? Um es mit den Worten von Meister Yoda zu sagen: „Geduld musst du haben, mein junger Padawan.“ Muss es unbedingt in der oben genannten Reihenfolge sein? Auf keinen Fall! Du und dein Entwicklungsteam könnt die Phasen in der Reihenfolge auswählen, die am besten zu eurem Team passt. Aber der Lohn für die Umsetzung der oben genannten Schritte sind Entwickler, die nun den Wert der Barrierefreiheit erkennen, für eine bessere HTML-Codierung sorgen und sich tatsächlich für die von ihnen erstellten Inhalte interessieren!
