Zwischenbemerkung: Bevor wir uns mit dem Thema befassen, sollten Sie vielleicht meinen ersten Blogbeitrag zum Thema Barrierefreiheit in agilen Transformationsprozessen lesen. Darin haben wir kulturelle Praktiken zur Barrierefreiheit behandelt, die Ihre agilen Teams dazu befähigen, barrierefreie Inhalte und Anwendungen auf nachhaltige Weise zu erstellen.
In diesem Beitrag beschäftigen wir uns eingehend mit Barrierefreiheit in agilen Teampraktiken, die eine nachhaltige und effektive Barrierefreiheit während des gesamten Softwareentwicklungszyklus fördern.
Barrierefreiheit beginnt letztendlich beim Design
Barrierefreiheit beginnt beim Design. Eine Möglichkeit für Designteams, barrierefreie Designs zu entwickeln, besteht darin, Personas zu verwenden, in deren Eigenschaften Merkmale von Behinderungen integriert sind. Es ist wichtig, die Erstellung von Personas zu vermeiden, die ausschließlich Menschen mit Behinderungen darstellen; stattdessen sollten Sie Behinderungen in die bereits vorhandenen Personas integrieren. Wenn Designer Entwürfe und Wireframes erstellen, können sie dann darüber nachdenken, welche zusätzlichen Schritte die Persona möglicherweise unternehmen muss, falls eine App oder Website nicht barrierefrei ist.
Barrierefreiheit steht oft im Mittelpunkt der Benutzerfreundlichkeit und kann zu besseren Designs für alle führen – nicht nur für Menschen mit Behinderungen. So hat beispielsweise die Stadt Ottawa eine Online-Karte erstellt, um die neuen Stadtgrenzen zu veranschaulichen. Im Rahmen einer Nutzerbefragung, an der auch blinde Menschen teilnahmen, wurden diese gefragt, warum sie diese Karte nutzen möchten.
Ihre Antwort lautete, dass sie die Möglichkeit haben wollten, eine Adresse zu suchen und festzustellen, ob diese innerhalb der neuen Grenzen liegt. Die Stadt hat daraufhin die Karte um diese Suchfunktion erweitert und damit benutzerfreundlicher gestaltet, sodass diejenigen, die die Karte einsehen können, nicht mehr manuell heranzoomen und mühsam herausfinden müssen, was innerhalb der neu vorgeschlagenen Grenzen liegt und was nicht.
Wenn Designer ein barrierefreies Design entwerfen, haben sie sich bereits intensiv mit Benutzerfreundlichkeit und Barrierefreiheit auseinandergesetzt. Es ist entscheidend, dass Designer den Entwicklern die Absicht hinter diesem Design effektiv vermitteln. Agile Teams kommunizieren auf vielfältige Weise. Manche Teams nutzen Whiteboards mit Anmerkungen, andere erstellen detaillierte Designentwürfe mit Anmerkungen.
Es spielt keine Rolle, wie Sie dabei vorgehen, aber es ist sehr wichtig, die Absicht über Annotationen zu vermitteln. Nachfolgend finden Sie beispielsweise Widget-Annotationen für den Entwurf eines Media-Players:
Selbst etwas so Einfaches wie eine Medien-Symbolleiste kann viele verschiedene Interaktionen, Interaktionen in alternativen Zuständen und Anmerkungen zur minimalen Steuerelementgröße aufweisen. Diese Anmerkungen sollten vermitteln, was einem Screenreader vorgelesen werden soll, wie Screenreader die Widgets steuern sollen, wie die Rolle in ARIA kodiert werden soll usw.
Es gibt noch viele weitere Anmerkungen zur Barrierefreiheit zu beachten, doch am wichtigsten ist, dass die Kommunikation und die Absicht vom Designer an den Entwickler weitergegeben werden, denn Barrierefreiheit beginnt letztendlich bereits beim Design.
Mythen rund um die Barrierefreiheit entlarven
Um in agilen Teams eine Kultur der Barrierefreiheit zu etablieren, müssen einige Mythen rund um das Thema Barrierefreiheit ausgeräumt werden. Erstens glauben agile Teams, dass Barrierefreiheitstests nicht automatisiert werden können. Zweitens glauben agile Teams, dass Barrierefreiheitstests gleichbedeutend mit Usability-Tests sind.
Wir bei Deque wissen, dass diese beiden Mythen nicht der Wahrheit entsprechen. Barrierefreiheitstests müssen nicht ausschließlich manuell durchgeführt werden – tatsächlich haben wir weiter oben in diesem Beitrag bereits das automatisierte Testverfahren „Axe Clean“ für agile Teams angesprochen. Die Nutzung einer Browser-Erweiterung oder die Integration dieses Tools in einen automatisierten Test ist ganz einfach.
Tatsächlich gilt es als bewährte Vorgehensweise, dass Teams keinen Code in ein Repository committen oder Pull-Anfragen abschließen sollten, wenn dieser nicht „axe-clean“ ist. Durch unsere umfangreichen Untersuchungen im Rahmen von Audits haben wir festgestellt, dass die automatisierte Barrierefreiheit etwa 25 % der Erfolgskriterien gemäß WCAG und etwa 50 % der Barrierefreiheitsprobleme nach Anzahl abdeckt.
Auch wenn einige Aspekte der Barrierefreiheit manuell überprüft werden müssen, wie beispielsweise Alt-Text, können Sie dennoch einfache Unit- oder Integrationstests schreiben, um das Vorhandensein von Alt-Text zu überprüfen und Entwickler daran zu erinnern. Wenn Sie zudem über die zuvor besprochenen Designinformationen verfügen, lassen sich Barrierefreiheitsanforderungen leicht in einen Test integrieren. Der folgende Code testet beispielsweise das „ Deque “-Logo und das dazugehörige Alt-Attribut:
<// Check the Deque Logo
ok(img.src.indexOf('logo.png' !== -1, 'image is the Deque logo image'));
equal(img.getAttribute('alt'), 'Deque Logo');>
Beim Testen geht es letztendlich um Risikominimierung, daher müssen Sie entscheiden, wie oft Sie die Tests wiederholen möchten. In der Regel geschieht dies, wenn ein größeres Update für Screenreader veröffentlicht wird.
Barrierefreie Musterbibliotheken
Die Verwendung einer Musterbibliothek mag auf den ersten Blick wie eine anti-agile Methodik erscheinen, da man Code entwirft, bevor man ihn tatsächlich benötigt. Es gibt jedoch verschiedene Ebenen, auf denen eine Musterbibliothek tatsächlich hilfreich sein kann. Eine Bibliothek, die zeigt, wie eine barrierefreie Komponente oder ein Widget in verschiedenen Zuständen aussieht, ist sehr wertvoll. Diese Elemente können Sie unabhängig davon wiederverwenden, welches Framework Sie verwenden. Wenn Sie sehen möchten, wie eine Barrierefreiheits-Musterbibliothek aussieht, schauen Sie sich „Cauldron“ an, die Barrierefreiheits-Musterbibliothek von „ Deque“.
TLDR: Zusammenfassung zur Barrierefreiheit in agilen Teampraktiken
Agilität und Barrierefreiheit schließen sich nicht gegenseitig aus. Wenn Ihre agilen Teams die oben genannten Vorgehensweisen umsetzen, können sie ihre gewohnten Arbeitsabläufe beibehalten und gleichzeitig barrierefreie und konforme Software und Websites entwickeln, die letztendlich für alle Nutzer benutzerfreundlicher sind. Zur Erinnerung: Diese Team-Vorgehensweisen sind:
- Wir räumen mit den Mythen über Barrierefreiheit auf, wonach Barrierefreiheit nicht automatisiert werden könne und sich ausschließlich auf die Benutzerfreundlichkeit beziehe.
- Da Barrierefreiheit bereits bei der Gestaltung beginnt, müssen Designer ihre Anmerkungen zur Barrierefreiheit bewusst formulieren.
- Wiederverwendung einer barrierefreien Musterbibliothek, die frameworkunabhängig ist.
