Barrierefreiheit ist für mich kein Extra-Feature. Es ist ein Teil guter Webentwicklung. Punkt. Auf der Konferenz Axe-con 2026 wurde das für mich nochmal richtig deutlich: Accessibility passiert nicht in einzelnen Bugfixes, sondern in unseren Design-Systemen, Workflows und Prioritäten im Team. (Spoiler: Ein einzelner Sprint rettet da auch nichts.)
Zwei Tage lang ging es um skalierbare Lösungen, menschzentrierte KI und den European Accessibility Act. Dabei ging es oft weniger um neue Technik sondern um Haltung, Organisation und Zusammenarbeit. Barrierefreiheit ist strategisch, regulatorisch relevant, technisch machbar – und vor allem menschlich entscheidend. Wenn wir saubere Komponenten bauen, profitieren Tausende Nutzer:innen davon.
Zentrales Motto: Barrierefreiheit wird durch Menschen verwirklicht – nicht nur durch Technik.
Die Konferenz war international stark geprägt: Teilnehmende aus fast 100 Ländern – darunter Deutschland, Frankreich, Spanien, Polen, Neuseeland und viele weitere – machten deutlich, wie vernetzt und aktiv die globale Accessibility-Community ist. Barrierefreiheit entsteht im Austausch und im gemeinsamen Lernen.
Menschen, Gemeinschaft und Workflow
In der Eröffnungsrede betonte Preety Kumar (Gründerin und CEO von Deque, neues Fenster), dass Veränderung geschieht, wenn Menschen aktiv werden und nicht nur darüber reden.
In der Keynote „Human-Centric AI für digitale Barrierefreiheit“ zeigte Dr. Rana el Kaliouby (neues Fenster) wie KI gestaltet werden kann, damit sie Barrierefreiheit wirklich unterstützt, statt bestehende Probleme nur schneller zu reproduzieren, mit dem Fokus darauf, Empathie und emotionale Intelligenz in digitale Produkte zu integrieren.
Ein weiterer Schwerpunkt des ersten Tages lag darauf, wie sich Barrierefreiheit systematisch skalieren lässt, indem Teams barrierefreie Prozesse und eine passende Infrastruktur von Anfang an etablieren. Ebenso wurde intensiv über neue regulatorische Entwicklungen gesprochen, insbesondere über den European Accessibility Act (EAA) und die praktischen Auswirkungen dieses Gesetzes auf digitale Produkte in Europa.
Konkrete Praxis, skalierbare Strategien und Empowerment
Auch Tag zwei ging über reine Technik hinaus – und war für mich als Entwickler:in trotzdem hochrelevant.
In der Session „Accessible by Default: Scaling Design Systems with AI-Assisted Development“ wurde gezeigt, wie ein größeres Team Accessibility-Fixes automatisieren konnte. Der entscheidende Punkt: Automatisierung funktioniert super, wenn vorher klare Patterns, saubere Komponenten und verbindliche Regeln existieren. KI beschleunigt – aber sie braucht Struktur.
Stark im Fokus stand außerdem die organisatorische und soziale Dimension von Accessibility. Es ging darum, wie Menschen Barrierefreiheit im Alltag leben, vermitteln und im Unternehmen verankern. Die Session „How to Convince People to Care and Invest in Accessibility“ machte deutlich, dass Accessibility interne Fürsprecher:innen mit klaren Argumenten braucht, wenn sie kein Randthema bleiben soll.
Besonders bewegend war die Keynote von Haben Girma (neues Fenster). Sie machte klar, dass der größte Barriereabbau oft nicht im Code stattfindet, sondern im Kopf. Es geht darum, Vorurteile und Ableismus* abzubauen – also die Abwertung und Diskriminierung von Menschen mit Behinderungen. Technik kann viel lösen, aber Haltung entscheidet, ob sie eingesetzt wird.
*Ableismus bezeichnet die Diskriminierung und ungleiche Behandlung von Menschen mit Behinderungen, bei der sie auf ihre Beeinträchtigungen reduziert und von der vermeintlichen Norm abgewertet werden.
In vielen Talks wurde betont, dass Accessibility Team-Verantwortung ist – nicht die Aufgabe einzelner Spezialist:innen. Die meisten Barrieren sind vorhersehbar und damit präventiv vermeidbar, wenn Accessibility früh in Prozesse integriert wird. Außerdem reicht eine einzige Kommunikationsebene nicht aus: Informationen müssen über mehrere Kanäle zugänglich sein – nicht nur über Farbe und Text.
Meine zentrale Erkenntnis von Tag 2: Accessibility ist kein Spezialwissen für wenige. Sie ist eine gemeinsame Aufgabe – kulturell, organisatorisch und technisch.
Konkrete Take-aways für Entwickler:innen
1. Accessibility ist Architektur.
Sie gehört in die Definition of Done, ins CI und ins Design-System. Wer erst im QA-Sprint reagiert, zahlt doppelt.
2. Baue Systeme, nicht Einzel-Fixes.
Komponenten einmal richtig barrierefrei entwickeln, sauber dokumentieren und testen (Keyboard, Screenreader, Zoom, Kontrast). Fehler in der Library multiplizieren sich im ganzen Produkt.
3. Automatisiere ist klug, wennn sie klug eingestezt wird.
KI und Tools wie axe beschleunigen repetitive Checks. Sie ersetzen kein Review, kein Verständnis für Nutzer:innen und keine sauberen Patterns.
4. Natives HTML vor ARIA.
Semantik zuerst. ARIA nur, wenn es wirklich nötig ist.
5. EAA & WCAG sind Compliance, kein Extra.
WCAG 2.1 AA ist Mindeststandard. Dokumentation und Nachweisbarkeit werden wichtiger. Accessibility-Debt wird zum Risiko.
6. Accessibility ist Team-Verantwortung.
Nicht Aufgabe einzelner Spezialist:innen. Sie früh in den Prozess zu integrieren, ist wesentlich effizienter als sie im Nachhinein zu implementieren.
7. Wenn alle verstehen, warum Accessibility wichtig und gut ist, wird es einfacher.
Erkläre im Team nicht nur wie etwas funktioniert, sondern warum es wichtig ist. Verständnis schafft Priorität.
8. Vernetzung beschleunigt Qualität.
Mit echten Nutzer:innen sprechen, Feedback-Loops einbauen, Community-Wissen nutzen. Isolation bremst.
9. Low-Effort, High-Impact sofort umsetzbar:
Teste komplett mit Keyboard.
Prüfe Fokus und Semantik.
Checke Kontrast mit echten Tools.
Nutze entsprechende Tools vor jedem Merge.
Gutes Gelingen beim Umsetzen!