GitHub testet Accessibility-Agent: Lessons Learned

GitHub pilotiert einen experimentellen Agenten für Barrierefreiheit. Das Ergebnis: 3.535 überprüfte Pull Requests mit einer automatischen Lösungsrate von 68%. Was hat das Team gelernt?

Zwei Ziele

Der Accessibility-Agent verfolgt zwei Hauptziele. Erstens: Entwicklern rechtzeitige Antworten auf Barrierefreiheitsfragen geben, direkt in GitHub Copilot CLI und VS Code. Zweitens: Einfache, objektive Barrierefreiheitsprobleme automatisch beheben bevor sie ins Produktionssystem gelangen.

Die Top-5-Probleme, die der Agent fand: Struktur und Beziehungen für assistive Technologien klären, interaktive Controls klar benennen, wichtige Ankündigungen sichtbar machen, Textalternativen für Nicht-Text-Inhalte bereitstellen und die Tastaturfokus-Reihenfolge logisch halten.

Was funktioniert hat

Der Agent nutzt LLM-basierte Code-Analyse, um Pull Requests automatisch auf WCAG-Verstöße zu prüfen. Bei der Hälfte der Kommentare konnten Entwickler die Vorschläge direkt übernehmen. Das Ziel war explizit nicht, Accessibility zu “lösen”, sondern die Bemühungen der Kollegen zu verstärken.

Besonders effektiv: Der Agent kommentiert direkt an der Codestelle mit konkreten Fixes. Ein Beispiel zeigt eine CSS-Änderung, die die Lesereihenfolge für Screenreader korrigiert, indem flex-direction: row-reverse durch korrekte DOM-Reihenfolge ersetzt wird.

Lessons Learned

Accessibility ist menschlich, nicht techn. Der Agent kann objektive Probleme finden, aber nicht entscheiden, ob ein UI “verwirrend” ist. Er kann syntaktische Fehler beheben, aber keine Designentscheidungen treffen. DasTeambetont, dass der Agent als Werkzeug für Barrierefreiheitsexperten gedacht ist, nicht als Ersatz.

Die größte Überraschung war die Akzeptanz. Entwickler nahmen die automatischen Vorschläge an, weil sie konkret und umsetzbar waren. Vage Ratschläge wie “verbessere die Barrierefreiheit” funktionieren nicht - spezifische Code-Fixes schon.