Zum Inhalt springen

Automatische Tests während der Entwicklung

Hintergrundwissen Automatische Tests während der Entwicklung

Artikel - Info:
  • Anspruch: vertiefen
  • Aufwand: 5 bis 15 Minuten
  • Zielgruppe: Entwicklung
Foto eines Monitors auf dem ein Ausschnitt einer Entwicklungsumgebung mit Quelltext zu erkennen ist.

Bei einem Softwareprojekt muss die Barrierefreiheit von Anfang an berücksichtigt werden. Dies beginnt bereits bei der visuellen Gestaltung, bei der auf ausreichende Kontraste und Schriftgrößen geachtet werden muss. Ebenso wichtig ist es, dass die Navigationsmechanismen und die funktionalen Komponenten der entwickelten Software den Standards der Barrierefreiheit entsprechen.

Um dies zu gewährleisten, sollten natürlich in erster Linie die Entwickler*innen entsprechend geschult sein und über das notwendige Know-how verfügen. Darüber hinaus ist es hilfreich, Barrierefreiheit in die internen Entwicklungsstandards und -prozesse zu integrieren. Zur Unterstützung gibt es für verschiedene Entwicklungsphasen technische Werkzeuge, die einen Teil der Barrieren im Code automatisch erkennen.

Da nicht alle Barrieren automatisch erkannt werden können, sind manuelle Tests weiterhin unerlässlich.

Echtzeit-Hinweise

Für die meisten Entwicklungsumgebungen und Programmiersprachen existieren sogenannte Linter, die den statischen Code auf Fehler überprüfen und auf Probleme hinweisen. Einige dieser Linter prüfen explizit auf Probleme bei der Barrierefreiheit. In Projekten, die React (JSX), React Native, Angular, Vue, HTML oder Markdown nutzen, unterstützt der axe-Linter für VSCode, indem problematische Stellen markiert und Hinweise zum jeweiligen Problem gegeben werden. Alternativ gibt es für viele Programmiersprachen und Frameworks auch Plugins für den Linter ESLint.

Unit-Tests

Wenn im Projekt Unit-Tests verwendet werden, kann die Barrierefreiheit von Komponenten auch in diesen getestet werden. Hier können auch die Regeln aus dem Axe-Core genutzt werden. Beispiele für unterschiedliche Test-Frameworks finden Sie auf Github.

End zu End Tests

Eine weitere Möglichkeit automatisierte Barrierefreiheitstests in den Entwicklungsprozess zu integrieren, ist die Einbindung des Axe-Plugins in das End zu End Testframework Cypress.

Einbindung in die Quelltext-Verwaltung (Continuous-Integration)

Die Cypress End zu End Tests können auch in der Quelltext-Verwaltung eingesetzt werden, um problematische Code-Änderungen zu blockieren. Das Vorgehen wird auf der Lernplattform von Cypress beschrieben. Alternativ kann auch die Open-Source-Software Pa11y benutzt oder der kostenpflichtige Linter von Deque benutzt werden.

Die automatische Erkennung von Barrieren basiert bei den meisten Tools auf Regeln, die offiziell beim W3C durch die Accessibility Conformance Testing (ACT) Task Force der Accessibility Guidelines Working Group (AG WG) veröffentlicht werden. Diese Regeln werden von der ACT Rules Community Group erstellt und vor der Veröffentlichung durch die ACT-TF bestätigt. Ziel der Regeln ist es, zwischen verschiedenen Testwerkzeugen und -methoden eine einheitliche Interpretation hinsichtlich der technischen Umsetzung der Barrierefreiheit im Internet zu fördern.