GAAD wird 15: Barrierefreiheit eingebaut, nicht nachgerüstet
Verfasst von
DevAlly-Team


Die meisten Gespräche über Barrierefreiheit verlaufen auf eine von zwei Arten. Entweder bleiben sie auf der Ebene des moralischen Imperativs – „das Richtige tun“ – oder sie verkommen zum Compliance-Theater: eine Liste von Vorschriften, drohende Bußgelder, ein einmaliges Audit, abgehakt und vergessen.
Keine der beiden Varianten hilft einem Produktteam weiter.
Deshalb haben wir zum diesjährigen Global Accessibility Awareness Day (öffnet in einem neuen Tab) etwas anders gemacht. Wir haben zwei Personen auf den heißen Stuhl gesetzt – Cian Dowling, Accessibility Lead bei Synthesia, und Darren Britton, unseren CTO und Mitgründer – und sie gebeten, ehrlich darüber zu sprechen, wie diese Arbeit von innen tatsächlich aussieht. Keine Folien. Keine geschliffenen Antworten. Eine offene Runde.
Das haben Sie verpasst:
Der Hochwasserschutz, den niemand vor der Flut baut
Cian hat einen Denkrahmen für Barrierefreiheit, der die üblichen Diskussionen schneller abkürzt als jede regulatorische Drohung.
„Wenn Sie den perfektesten Hochwasserschutz haben und keine Flut kommt, wer klopft Ihnen dann auf die Schulter? Niemand. Aber wenn Sie keinen haben? Dann geht es Ihnen an den Kragen.
Erst wenn der Ernstfall eintritt, spürt man es im Geldbeutel. Was passiert, wenn jemand sagt: ‚Ich lehne Sie für den größten Auftrag ab, den Sie je hatten, weil Sie kein VPAT haben‘? Dann verlieren alle, nicht nur die Engineers.“
Genau diesem Gespräch weichen die meisten Produktteams aus. Nicht, weil ihnen Barrierefreiheit egal ist, sondern weil der Business Case noch nicht angekommen ist. Barrierefreiheit gehört in dieselbe Kategorie wie Disaster Recovery: unsichtbar, wenn sie funktioniert, katastrophal, wenn nicht.
Der Unterschied heute: Die Flut ist näher, als die meisten Teams denken.
Compliance interessiert niemanden – bis es zu spät ist
Cians erster Anruf nach seinem Einstieg bei Synthesia ging nicht an die Barrierefreiheits-Community. Sondern an den Head of Infosec.
„Ich habe ihn gefragt: Erzähl mir, was vor zehn Jahren mit der DSGVO passiert ist. Wie habt ihr es geschafft, dass sich die Leute dafür interessieren, bevor es zu spät war? Er hat mir viele gute Ratschläge gegeben.“
Die DSGVO-Analogie ist für ein gemischtes Publikum die hilfreichste von allen. Die meisten Produktteams haben schon einen Compliance-Zyklus durchlaufen – SOC 2, DSGVO, ISO 27001. Sie kennen das Muster: Erst wirkt es optional, dann dringend, und dann ist es Voraussetzung, um mit irgendjemandem Geschäfte zu machen, der zählt. Oder man geht leer aus.
Barrierefreiheit befindet sich im selben Zyklus, nur zwei oder drei Jahre zurück. Die Unternehmen, die sie jetzt als Infrastruktur behandeln, werden 2026 und 2027 die Enterprise-Deals abschließen. Wer wartet, wird unter Druck nachrüsten müssen (und das ist teuer).
„Ich unternehme viel lieber proaktive Schritte und bringe für das nächste Quartal etwas in die Roadmap, das 20 % davon abdeckt, als herumzusitzen und mich zu beklagen, dass wir keine 100 % erreicht haben.“
Fortschritt vor Perfektion.
Das Audit ist keine TÜV-Prüfung
Das ist die Falle, in die die meisten Teams tappen. Sie geben ein Audit in Auftrag. Sie bekommen einen Bericht. Sie halten den Bericht für die eigentliche Arbeit. Und vergessen ihn.
Cians Sicht darauf ist klar: Das Audit zeigt Ihnen, was zu einem Zeitpunkt vor einigen Monaten falsch war. Für ein Unternehmen, das über tausend Dinge pro Monat ausliefert, ist dieses Bild veraltet, bevor Sie es zu Ende gelesen haben.
„Mich interessiert viel mehr, wie wir die Menge an nicht barrierefreien Dingen, die wir Monat für Monat ausliefern, reduzieren können, als einen Backlog abzuarbeiten. Das Audit ist nicht wie der TÜV für Ihr Auto – Sie gehen nicht einmal im Jahr hin und haken es ab. Die Frage ist: Was hat dazu geführt, dass diese Probleme überhaupt entstanden sind, damit das nächste Audit weniger findet?“
Das ist eine Frage der Definition of Done. Keine Frage für einen Behebungssprint.
Die Teams, die bei der Barrierefreiheit echte Fortschritte machen, sind die, die aufgehört haben, sie als Projekt zu behandeln, und begonnen haben, sie als gelebte Praxis zu verstehen. Barrierefreiheit in der Verantwortung eines Champions (oder mehrerer), der im Produkt- oder Engineering-Team sitzt. Ins Designsystem integriert, damit sie von vornherein stimmt.
KI wird das nicht lösen. Vielleicht macht sie es sogar schlimmer.
Die Frage, die wir derzeit am häufigsten von Produktteams hören: Kann KI das nicht einfach automatisch beheben? Können wir unsere Codebasis nicht durch Claude oder GPT laufen lassen und so unsere Barrierefreiheitsprobleme lösen?
Cian hat selbst versucht, ein KI-Tool für Barrierefreiheit zu entwickeln, bevor er zu Synthesia kam. Hier erklärt er, warum das nicht so funktioniert, wie die meisten annehmen.
„Wenn Sie Ihre gesamte Codebasis durch ein LLM jagen, geben Sie das Tafelsilber aus der Hand. Ihren proprietären Code wollen Sie eigentlich nicht in das Modell eines Drittanbieters stecken.“
Das tiefere Problem ist jedoch, womit KI trainiert wurde.
„LLMs werden mit allem trainiert, was es bis heute gibt. 97 % des Internets sind nicht barrierefrei. Das heißt, KI wurde überwiegend mit nicht barrierefreiem Code trainiert. Und genau das spiegelt sich im Ergebnis wider.“
KI-generierte React-Komponenten lassen ARIA und semantisches HTML regelmäßig weg. Zur Laufzeit generierte Oberflächen lassen sich nicht vorab auditieren. Weil Teams dank KI so schnell ausliefern, kommen Barrierefreiheits-Regressionen an, bevor jemand sie prüft. Die Tools, die Teams schnelleres Arbeiten versprechen, schreiben bei vielen Teams unbemerkt Compliance-Schulden in jedes Release.
Das heißt nicht, dass KI keine Rolle spielt. Es heißt, dass ihre Rolle eine andere ist, als die meisten annehmen.
„Das Volumen und die Skalierung nutzen, die KI bietet, aber menschliches Urteilsvermögen und Kontext ergänzen, um die Arbeit zu reduzieren – das ist es, was Sie brauchen. Mit einem Tool wie DevAlly schaffen Fachleute für Barrierefreiheit oder Engineers mit Sinn für Barrierefreiheit 5-mal so viel wie sonst. Das bekommen Sie nicht von einem generischen LLM von der Stange.“
Der Aspekt, über den noch niemand spricht
In Engineering-Gesprächen zeichnet sich gerade ein Thema ab, das Barrierefreiheit für die Führungsetage neu einordnet – und zwar so, dass sie komplett aus der Compliance-Spalte verschwindet.
KI-Agenten werden zunehmend selbst zu Nutzern von Software. Und genau die strukturellen Eigenschaften, die ein Produkt für Screenreader-Nutzende barrierefrei machen – semantisches HTML, korrekte Labels, eine vorhersehbare Komponentenarchitektur, richtige ARIA-Rollen –, sind die Eigenschaften, die ein Produkt für KI-Agenten navigierbar machen.
Teams, die jetzt in Barrierefreiheit investieren, legen ganz nebenbei das Fundament für Agentenkompatibilität.
Wenn Ihr Produkt den Screenreader-Test nicht besteht, besteht es wahrscheinlich auch den Agenten-Test nicht.
Barrierefreiheit ist dann kein reiner Compliance-Kostenfaktor mehr. Sie wird Teil Ihrer KI-Readiness-Story.
Was Sie diese Woche tun können
Das Publikum beim GAAD bat beide Gäste um je eine konkrete Maßnahme. Das haben unsere Speaker empfohlen.
Darren Britton, CTO und Mitgründer, DevAlly: Beginnen Sie mit Ihren drei wichtigsten User Journeys. Kein vollständiges Audit. Automatisieren Sie, was möglich ist, und markieren Sie, was ein menschlicher Blick prüfen muss. Machen Sie noch in diesem Sprint etwas für das Engineering-Team sichtbar.
Cian Dowling, Accessibility Lead, Synthesia: Sprechen Sie nicht zuerst mit der Barrierefreiheits-Community. Sprechen Sie mit Ihrem Head of Infosec. Fragen Sie, was vor zehn Jahren mit der DSGVO passiert ist. Fragen Sie, wie es gelungen ist, die Leute für das Thema zu gewinnen, bevor es zu spät war. Genau dieses Gespräch müssen Sie wiederholen – und dann den Hebel finden, mit dem Sie in die Planung des Engineering-Teams kommen.
Und von beiden: Geben Sie keinen Bericht in Auftrag, um ihn dann für die eigentliche Arbeit zu halten. Der Bericht ist erst der Anfang der Arbeit.

Die ehrliche Version dieser Geschichte
Cian sagte früh im Gespräch etwas, über das es sich nachzudenken lohnt.
„Wenn es um Compliance geht, ist das eine undankbare Aufgabe. Niemand interessiert sich dafür, bis es zu spät ist. Aber ich finde, es reicht nicht, herumzusitzen und zu sagen, dass wir das tun sollten. Wir liefern schnell aus. Wie bei vielen der besten Dinge im Leben sieht man die Chance, und dann muss man zugreifen und es anpacken.“
Barrierefreiheit, die von Anfang an eingebaut ist, ist nicht nur die verantwortungsvolle Wahl. Bei einem KI-Unternehmen im Wert von 4 Mrd. $, das jeden Monat mehr als tausend Produktänderungen ausliefert, ist sie die einzige Wahl, die wirtschaftlich sinnvoll ist.
So sieht „von Anfang an eingebaut statt nachträglich angeschraubt“ in der Praxis aus.
DevAlly ist eine Plattform für Konformität bei der Barrierefreiheit mit Sitz in Dublin. Wir helfen Produkt- und Engineering-Teams, Barrierefreiheitsprobleme früh zu erkennen, priorisierte Backlogs zur Behebung zu verwalten und die Konformitätsdokumentation zu erstellen, die der Einkauf in Unternehmen heute verlangt.
Möchten Sie wissen, wo Ihr Produkt steht? Führen Sie einen kostenlosen Scan auf devally.com durch


