Barrieretest-Core ist Open Source
Über die Implementierung und Features von barrieretest-core, sowie ein kleiner Ausblick in die Zukunft.
Barrieretest-Core ist Open Source
Seit einem Monat ist der Kern als barrieretest-core in der MIT-Lizenz auf GitHub und NPM offen verfügbar. Dieser beinhaltet neben dem Kern der Test-Logik auch eine minimale CLI, um alle Funktionen direkt im Terminal nutzen zu können.
Nachdem ich vor 2 Monaten im Post Die Zukunft von Barrieretest darüber geschrieben hatte, dass ich Barrieretest nun als Open-Source-Projekt veröffentlichen würde, ist es jetzt so weit. Die Gründe dafür sind im letzten Post bereits angeführt.
Ich möchte hier auf ein paar Details der Implementierung eingehen, und kurz einen Ausblick auf die Zukunft geben.
Implementierungsdetails
Dieser Teil des Texts ist für Entwickler:innen, die etwas mehr über den Workflow wissen möchten.
Das Projekt entstand vor Monaten als Hobby-Projekt, als ich für mich selbst nach einem einfachen Weg suchte, Websites schnell und unkompliziert auf gängige Kriterien zu testen. Ich arbeite also nach meiner eigentlichen Arbeit oder an den Wochenenden daran, hier Verbesserungen zu implementieren. Das ist zum einen großartig, weil es mir in meiner Freizeit ein Projekt gibt, an dem ich mich vollends austoben kann, ohne dass jede Minute zwingend produktiven Output bringen muss. Andererseits limitiert das natürlich die Zeit, die in dieses Projekt fließen kann. Und hier kommt KI ins Spiel.
Hobby-Projekte und Agentic Coding
Offen gesagt, ist meine Einstellung zu KI-generiertem Code sehr zwiegespalten. Ich finde es großartig, was man mit Tools wie Claude und Codex momentan erreichen kann, sehe aber auch Gefahren in der Art und Weise, wie sie uns dazu verleiten, Software in einem absurden Tempo zu schreiben.
Mario Zechner, Entwickler von Pi, hat in einem aktuellen Talk dafür plädiert, beim Entwickeln bewusst langsamer zu werden, um die Qualität nicht der Geschwindigkeit zu opfern.
Für dieses Hobby-Projekt ist dieses “Agentic Coding” dennoch die richtige Wahl für mich. Ich möchte also transparent sein: Ich nutze in diesem Projekt KI zur Code-Generierung, und vor allem als iterativen Entwicklungspartner. Speziell dort, wo viel Boilerplate-Code zu schreiben ist, hilft dies immens.
Feature-Scope
Mein Zugang zum Open-Source-Teil ist eigentlich ganz einfach: Alles, was direkt die Barrierefreiheit einer Seite testet, muss Open Source sein. Dazu gehört die Logik des Tests an sich, die semantische Analyse und die Berechnung des Endergebnisses. Alles, was darüber hinaus geht, bleibt Closed Source und fließt ins Backend von Barrieretest, der Web-App. Später im Text gebe ich noch einen kurzen Ausblick was das für die Zukunft bedeutet.
Barrieretest-Core
Das Herzstück des Projekts ist nun als barrieretest-core auf GitHub und als @barrieretest/core auf NPM veröffentlicht. Neben den Features aus der aktuellen Version von Barrieretest gibt es in diesem Paket nun auch ein paar Neuerungen, die ich während der Migration eingebaut habe.
Zu den Features gehören:
- Automatisierte Tests via
axe-coreals Standard - Optionaler Support von
pa11y - Bewertung der Schwere von Fehlern
- Semantische Audits mit Vision-LLMs (+ Screenshots)
- KI-gestützte Erklärung zu einzelnen Fehlern im Kontext
- Baseline-Unterstützung für automatisierte Regression-Tests in CI/CD-Pipelines
- Logik zum automatisierten Schließen von Cookie-Bannern
Die Umstellung von pa11y auf axe-core bringt hierbei eine Änderung für das Produktiv-System mit sich: pa11y hatte teilweise “false positives” produziert, also Fehler gefunden, wo gar keine waren. Insbesondere dann, wenn Elemente per CSS-Regeln ausgeblendet wurden. Dies habe ich intern bei Barrieretest mit angepassten Regeln korrigiert, aber durch die Umstellung auf axe-core sollte das Problem jetzt gelöst sein. Bei manchen Seiten kann es jedoch durch diese Umstellung zu einer Veränderung des Punktestands kommen.
Ein mir sehr wichtiges Feature im neuen Kern ist vor allem die Möglichkeit, neue semantische Checks einzufügen, indem man einfach per CLI ein Prompt definiert, und dazu angibt, welche Elemente mitgeschickt werden sollen. Diese semantischen Ergebnisse fließen anschließend wieder in die Bewertung und den Punktestand ein, sodass man sich in kurzer Zeit seine eigene Testsuite erweitern kann.
Alle Details zu den Features sowie detaillierte Beschreibungen zu den einzelnen Funktionalitäten, Flags und der API finden sich im Readme auf GitHub.
Barrieretest-Playwright
Neben barrieretest-core gibt es auch eine direkte Integration in Playwright zum automatisierten Testen in CI/CD-Umgebungen: barrieretest-playwright. Dieser Teil ist ebenfalls unter MIT lizenziert. Darauf werde ich in einem eigenen Post näher eingehen.
Wie geht es weiter?
Neben der offenen Zugänglichkeit auf der einen Seite denke ich auf der anderen Seite über eine Möglichkeit der Monetarisierung nach, um das Projekt langfristig weiter betreiben zu können. Unabhängig davon wird sich am Funktionsumfang der kostenlosen Version nichts ändern. Die aktuellen Limits pro Tag und Nutzer funktionieren gut.
Als nächstes plane ich eine Erweiterung in Richtung automatisierter Tests ganzer Webseiten. Also, anstatt per Hand immer nur eine URL zu testen, wird es in Zukunft die Möglichkeit geben, mehrere Seiten parallel zu testen und daraus einen Bericht zu generieren. Dieser Bericht kombiniert dann die strukturellen und semantischen Testergebnisse aller Seiten und gibt konkrete Handlungsempfehlungen. Der exakte Funktionsumfang oder Zeitrahmen ist noch nicht bekannt, aber ich werde in Zukunft wieder hier darüber berichten.
Wer sich aktiv in der Entwicklung beteiligen möchte, kann dies gerne direkt auf GitHub tun oder mich persönlich per Mail kontaktieren.
Mein Ziel bleibt, Barrieretest so offen wie möglich und so kommerziell wie nötig weiterzuentwickeln. Wenn der offene Kern besser wird, profitieren davon am Ende alle.
Ich freue mich besonders über Feedback und Änderungsvorschläge!
Links
Selbst testen
→ Kostenlos testen auf barrieretest.at
Für eine tiefergehende Analyse oder Unterstützung bei der Umsetzung: