Article
Accessibilility Agent bei GitHub: 68% Lösungsrate nach 3535 PRs
Was GitHub aus dem Pilotprojekt gelernt hat
GitHub berichtet über den Einsatz eines KI-Agenten zur automatischen Barrierefreiheitsprüfung. Nach 3.535 überprüften Pull Requests und einer automatischen Behebungsrate von 68% zieht das Team erste Lehren.
Die zwei Hauptziele
- Just-in-Time Antworten auf Accessibility-Fragen direkt in CLI und VS Code
- Automatische Behebung objektiver Barrierefreiheitsprobleme vor Production
Der Agent wurde so konfiguriert, dass er bei jedem Frontend-Code-Change automatisch eine Prüfung durchführt und Vorschläge erstellt.
Die häufigsten Problemtypen
Nach WCAG geordnet:
- WCAG 1.3.2: Struktur und Beziehungen für Screenreader unklar
- WCAG 4.1.2: Namen für interaktive Controls fehlen oder sind unklar
- WCAG 4.1.3: Status-Benachrichtigungen nicht anunciierbar
- WCAG 1.1.1: Text-Alternativen für Nicht-Text-Inhalte fehlen
- WCAG 2.4.3: Tastatur-Fokus in illogischer Reihenfolge
Wichtige Erkenntnisse
Kein Silber-Messer. Der Agent löst Accessibility nicht isoliert. Er erweitert die Werkzeuge der Entwickler, ersetzt aber nicht das Verständnis. Die Social Model of Disability-Philosophie durchzieht den Ansatz: Barrieren werden durch schlechtes Design erzeugt, nicht durch Behinderungen.
Dichte Zusammenfassungen. Der Agent muss präzise, korrekte und dichte Meldungen liefern. Confidence-Scores helfen dabei, falsche Vermutungen zu kennzeichnen.
Evaluation-First. Ein eigener Evaluation-Pipeline validiert die Agent-Ergebnisse. Ohne systematische Tests wäre die 68%-Quote nicht erreichbar.
Lessons Learned
- Start mit einem klaren, begrenzten Scope
- Baue Evaluation-Pipelines VOR dem Agent
- Erwarte keine universelle Lösung – fokussiere auf konkrete Problemtypen
- Lasse Menschen die letzte Entscheidung
Link: Original bei GitHub Blog