Als Entwickler schätzen wir kostenlose Tools. Wir nutzen sie ständig. Und wenn wir ein neues Projekt in Angriff nehmen, prüfen wir oft als Erstes, ob unsere vorhandenen kostenlosen Tools den Anforderungen gerecht werden. Manchmal ist das der Fall. Wenn dies jedoch nicht zutrifft, muss man sich nach kostenpflichtigen und Premium-Tools umsehen.
Im Bereich der Barrierefreiheit kommt das ständig vor. Man stößt auf Herausforderungen und erkennt, dass man eine umfassendere Testabdeckung, mehr Stabilität, eine insgesamt bessere Funktionalität und eine optimierte Methode zur Aufdeckung von Verstößen gegen die Barrierefreiheit benötigt.
Leichter gesagt als getan, oder? In Wirklichkeit kann der Sprung von der kostenlosen zur kostenpflichtigen Version knifflig sein, und Sie werden sich wahrscheinlich fragen:
- Was würde ich von kostenpflichtigen Tools zusätzlich erhalten, was kostenlose Tools nicht bieten?
- Wird eine kostenpflichtige Werkzeuganfertigung tatsächlich dazu beitragen, dass mein Produkt zugänglicher wird?
- Wie begründe ich das Budget dafür?
Das sind alles Fragen, mit denen ich mich auseinandersetzen musste, und ich werde sie in diesem Beitrag gemeinsam mit euch einzeln durchgehen.
Wir werden sowohl die quantitativen als auch die qualitativen Aspekte der einzelnen Tools betrachten – was diese Barrierefreiheits-Tools konkret leisten, inwiefern sie dazu beitragen, Anwendungen barrierefreier zu gestalten, und wie Sie der Geschäftsleitung verdeutlichen können, dass der Einsatz solcher Tools Vorteile für das Team und das Unternehmen mit sich bringt.
Wenn Sie bereits bereit sind, den Sprung zu wagen, dann fordern Sie noch heute eine Demo unserer Tools an.
Was gibt es da draußen eigentlich?
Wenn Sie bereits Anwendungen unter Berücksichtigung der Barrierefreiheit entwickelt haben, haben Sie wahrscheinlich schon von axe-coregehört. Es wurde von Deque entwickelt Deque anschließend als Open-Source-Software veröffentlicht. Als führende Test-Engine für Barrierefreiheit bei Websites und Benutzeroberflächen kann sie rund 57 % der gängigen WCAG-Verstöße erkennen (ohne Fehlalarme!). Das ist eine solide Grundlage, aber wenn Sie produktionsreife Software entwickeln, benötigen Sie mehr als nur diese Basis. Open-Source-Tools können nur einige Barrierefreiheitsprobleme identifizieren, und es fehlen ihnen teamweite Richtlinien und Sicherheitsvorkehrungen. Sie können keine teamübergreifenden Standards festlegen, lassen sich nicht problemlos in CI/CD-Prozesse integrieren, können nicht automatisch barriereunfähigen Code unterbinden und keine Probleme nachverfolgen. Hier kommen kostenpflichtige Tools ins Spiel, die die Funktionen von axe-core erweitern axe-core eine umfassendere Abdeckung axe-core fortgeschrittenere Funktionen bieten.
Welche verschiedenen Werkzeuge gibt es?
Bei der Festlegung der benötigten Tools besprechen wir in der Regel einige verschiedene Punkte: Welche Tools funktionieren beim Schreiben von Code und beim lokalen Testen im Browser, und welche Tools lassen sich in unser Versionskontrollsystem integrieren? Aus Sicht der Barrierefreiheit werden all diese Punkte durch die axe DevTools for Web-Toolsuite abgedeckt. Schon während ich Code schreibe, erhalte ich sofortiges Feedback durch den axe DevTools Linter, der den Code statisch analysiert, während ich ihn schreibe. Er zeigt häufige Barrierefreiheitsverstöße an, wie beispielsweise fehlenden Alternativtext für Bilder oder falsche ARIA-Rollen.
Da ich während der Arbeit gerne einen weiteren Bildschirm geöffnet habe, kann ich mein Projekt mit LocalHost ausführen und Probleme bei der Darstellung der Webseite mithilfe der Axe DevTools-Erweiterung erkennen. Da der Browser den von mir geschriebenen Code über das Document Object Model (DOM) rendert, werden nach dem Rendern der Seite auch andere Probleme, wie beispielsweise ein unzureichender Farbkontrast, erkannt.
Während ich meine Fähigkeiten im Bereich der testgetriebenen Entwicklung vertieft habe, konnte ich axe Watcher in einige Cypress-Tests integrieren und die Ergebnisse im axe Developer Hub einsehen. Das Tool überwacht die Ausführung meiner Tests und analysiert mein Projekt während des Build-Vorgangs, ohne dass ich jeden Schritt manuell anweisen muss. Ich kann ein paar Zeilen Code in meine Testsuite einfügen, und das Tool wird automatisch aufgerufen, sobald meine regulären Tests ausgeführt werden.
Was können diese Tools noch?
Die „axe DevTools for Web“-Suite bietet Ihnen die APIs, GitHub-Integrationen und Pre-Commit-Hooks, die erforderlich sind, um Probleme frühzeitig zu erkennen und Barrierefreiheitsstandards während des gesamten Softwareentwicklungszyklus (SDLC) durchzusetzen.
Die „axe DevTools“-Erweiterung umfasst außerdem „Intelligent Guided Tests“ (IGTs). Dabei handelt es sich um interaktive Testabläufe, die nur minimalen Aufwand erfordern – in der Regel einige „Ja“- oder „Nein“-Fragen –, und die Ihnen helfen, komplexe Barrierefreiheitsprobleme aufzudecken, die durch Automatisierung nicht zuverlässig erkannt werden können, wie beispielsweise Tastaturfallen, Probleme bei der Beschriftung von Formularfeldern oder fehlerhaftes Modal-Verhalten.
Ich habe bereits erwähnt, dass sich der axe Developer Hub in Ihre Testsuite integrieren lässt, aber Sie können diese Barrierefreiheitsprüfungen mithilfe einer REST-API auch in Ihre bestehenden CI-Systeme (wie GitHub Actions, GitLab oder Bitbucket) einbinden. Außerdem kann ich den axe DevTools Linter ausführen, um bereits in einer früheren Phase meiner Pipeline eine ähnliche Abdeckung zu erzielen. Er lässt sich direkt in einem GitHub-Pull-Request oder sogar in einem Pre-Commit-Hook ausführen, um Verstöße gegen die Barrierefreiheit direkt im Code zu kennzeichnen – genau wie ein herkömmlicher Linter.
Was machen diese Tools möglich?
Mit den richtigen Tools ist Barrierefreiheit nicht mehr nur eine Reihe von vereinzelten Stichproben, sondern wird zu einem Bestandteil, den ich in meinen gesamten Entwicklungsprozess einbinden und mit anderen Entwicklern in meinem Team teilen kann. So können wir die Barrierefreiheit bereits während des Programmierens überprüfen, sie im Browser weiter kontrollieren und sicher sein, dass dieselben Prüfungen auch in unseren automatisierten Tests durchgeführt werden, sobald alles in unseren CI-Pipelines eingerichtet ist. Das bedeutet, dass ich meiner App nicht nur auf statischen Seiten vertrauen kann, sondern auch in dynamischen Zuständen und Benutzerabläufen. Außerdem ermöglicht dies eine bessere Zusammenarbeit, da Probleme nicht ausschließlich auf meinem Rechner verbleiben. Sie sind vollständig sichtbar, können geteilt werden und lassen sich mit Code-Commits verknüpfen, auf die das gesamte Team reagieren kann. Hier ist ein Beispielbericht, der nur ein Beispiel aus der axe DevTools-Erweiterung zeigt.
Welche positiven Ergebnisse kann ich erwarten, wenn ich diese Tools nutze?
Ich würde sagen, das wichtigste Ergebnis ist, dass die Barrierefreiheit konsistent wird. Anstatt nach der Produktion oder nach einer Veröffentlichung hastig Probleme zu beheben, kann ich diese früher erkennen, wenn Korrekturen noch kostengünstiger und mit weniger Beeinträchtigungen verbunden sind. Das führt zu einer schnelleren Bereitstellung, weniger Produktionsstörungen und weniger Nacharbeiten, die Sprintzeit verschlingen. Diese Konsistenz wird sich in den Trendkurven widerspiegeln: Teams können Verbesserungen messen, ihre Konformität nachweisen und ihrer Führung messbare Fortschritte vorweisen. Indem wir Barrierefreiheit zu einem normalen, verlässlichen Bestandteil der Produktentwicklung machen, können wir qualitativ hochwertige Produkte auf den Markt bringen, die für mehr Menschen funktional nutzbar sind.
Werden diese Tools tatsächlich helfen, und wie bekomme ich die Mittel dafür?
Aus quantitativer Sicht lautet die Antwort „Ja “. Kostenpflichtige Tools verbessern die Genauigkeit , da sie über oberflächliche Überprüfungen hinausgehen und Barrierefreiheitsprobleme in dynamischen Zuständen und Benutzerabläufen erkennen. Dies sind Aspekte, die kostenlose Tools regelmäßig übersehen. Kostenpflichtige Tools sorgen zudem für mehr Geschwindigkeit , wenn wir mithilfe von künstlicher Intelligenz und Automatisierung Prüfungen einführen, die automatisch im Editor, im Browser und in der Pipeline ablaufen, wodurch sich der Arbeitsaufwand für manuelle Tester verringert.
Auch in qualitativer Hinsicht sind die Vorteile ebenso bedeutend. Die Zusammenarbeit im Bereich Barrierefreiheit wird vereinfacht – die Ergebnisse sind teamübergreifend sichtbar, lassen sich mit Code-Commits verknüpfen und können exportiert oder direkt in Issue-Tracker wie Jira übertragen werden. Dies steigert wiederum die Effizienz, da Korrekturen bereits im Verlauf der Entwicklung vorgenommen werden und nicht erst nach der Produktionsfreigabe.
Und genau hier kommt die Budgetdiskussion ins Spiel. Der ROI ist klar: Jedes frühzeitig erkannte Problem bedeutet, dass stundenlange Nacharbeiten vermieden, Funktionen schneller bereitgestellt und Produktionsstörungen verhindert werden. Multipliziert man das auf die gesamte Codebasis, ist der ROI weitaus höher als die Kosten für das Tool. Kostenpflichtige Tools helfen Teams, Geld und Zeit zu sparen, indem sie die Fehlererkennung von der Qualitätssicherung in die Entwicklung verlagern, wo Korrekturen kostengünstiger sind. Sie steigern die Effizienz und die Zusammenarbeit, indem sie die Transparenz zentralisieren und die Ergebnisse standardisieren. Vor allem aber helfen sie uns, bessere Produkte zu entwickeln, die von mehr Menschen genutzt werden können, und gleichzeitig das Risiko von Barrierefreiheitslücken zu verringern, die zu rechtlichen Risiken oder Kundenfrustration führen können.
Wie geht es weiter?
Wir haben gesehen, was passiert, wenn kostenlose Tools an ihre Grenzen stoßen und den Anforderungen realer Projekte nicht mehr gerecht werden. Wir haben uns die verfügbaren Premium-Tools genauer angesehen und untersucht, wie sie sich in den Arbeitsablauf eines Entwicklers einfügen, welche Möglichkeiten sie bieten und welche Ergebnisse sie ermöglichen. Außerdem haben wir den ROI betrachtet: Wie diese Tools Zeit sparen, Nacharbeiten reduzieren, die Zusammenarbeit verbessern und uns letztendlich dabei helfen, bessere Produkte für mehr Menschen auf den Markt zu bringen.
An dieser Stelle ist der nächste Schritt ganz einfach: Wählen Sie die Tools aus, die zu Ihrem Team passen, begründen Sie Ihre Entscheidung und widmen Sie sich dann wieder der eigentlichen Arbeit, nämlich der Entwicklung von Software, die für alle zugänglich ist.
Fordern Sie noch heute eine Demo an, um zu sehen, wie diese Tools in Ihren Umgebungen funktionieren!
