Werden unsere Apps durch künstliche Intelligenz unzugänglicher? Im heutigen Video werfe ich einen Blick auf ein wachsendes Problem in der Softwareentwicklung: Warum Code aus LLMs standardmäßig selten barrierefrei ist – und wie wir das Tooling nutzen können, um genau das zu ändern.
Hinweis: Das Video selbst ist auf Englisch, aber für alle, die lieber lesen oder die deutsche Fassung bevorzugen, findet ihr das vollständige Transkript direkt darunter!
Transkript des Videos aufklappen
[00:00] Gregor: We're in May, 2026, and it is safe to say that a significant portion of the code written today is in some form assisted by large language models. The trend is rising.
[00:19] Gregor: But do those models actually generate software that is accessible? It turns out they don't. At least, not by default.
[00:29] Gregor: Why is that? It is a training data problem. The way large language models work is that they lean toward whatever was most common in their training data. And in this training data, accessible user interfaces are underrepresented. So by default, they generate UIs that are not accessible.
[00:57] Gregor: But it does not have to be this way. We do have influence over what they produce. How? We can add rules to the model's context — rules that tell it how it should do things.
[01:15] Gregor: So for example, we could tell it to always use semantic HTML elements for their intended purpose, and never use a div or span for anything interactive. That's a start.
[01:33] Gregor: But rules only work to some degree. What works much better is successive refinement. This means that you continuously review its output for accessibility, and whenever you find issues, you fix them early and often. You can even have coding agents review the code and make it more accessible.
[02:04] Gregor: And if you don't know how, don't worry. There are already people building open-source tools for this — accessibility-focused agent skills and review agents that you can use. Find the links to those in the comments.
[02:28] Gregor: I am Gregor Riegler, Technical Coach. I hope I could help.
Übersetzung des Transkripts ins Deutsche
Wir befinden uns im Mai 2026, und man kann mit Sicherheit sagen, dass ein erheblicher Teil des heute geschriebenen Codes in irgendeiner Form von einem Large Language Model unterstützt wird. Der Trend ist steigend.
Aber generieren diese Modelle tatsächlich Software, die barrierefrei ist? Es stellt sich heraus: Nein, das tun sie nicht. Zumindest nicht standardmäßig.
Woran liegt das? Es ist ein Problem der Trainingsdaten. Large Language Models funktionieren so, dass sie sich an dem orientieren, was in ihren Trainingsdaten am häufigsten vorkam. Und in diesen Trainingsdaten sind barrierefreie Benutzeroberflächen unterrepräsentiert. Standardmäßig generieren sie also UIs, die nicht barrierefrei sind.
Aber das muss nicht so bleiben. Wir haben Einfluss darauf, was sie produzieren. Wie? Wir können dem Kontext des Modells Regeln hinzufügen – Regeln, die ihm sagen, wie es die Dinge tun soll.
Wir könnten dem Modell beispielsweise sagen, dass es semantische HTML-Elemente immer für ihren vorgesehenen Zweck verwenden und niemals ein <div> oder <span> für interaktive Elemente nutzen soll. Das ist ein Anfang.
Regeln funktionieren jedoch nur bis zu einem gewissen Grad. Was viel besser funktioniert, ist die schrittweise Verfeinerung. Das bedeutet, dass Sie die Ausgabe kontinuierlich auf Barrierefreiheit überprüfen und Fehler frühzeitig und häufig beheben, wann immer Sie welche finden. Sie können sogar Coding-Agents einsetzen, die den Code überprüfen und barrierefreier machen.
Und wenn Sie nicht wissen, wie das geht, keine Sorge. Es gibt bereits Leute, die Open-Source-Tools dafür entwickeln – auf Barrierefreiheit ausgerichtete Agenten-Skills und Review-Agents, die Sie nutzen können. Die Links dazu finden Sie in den Kommentaren.
Ich bin Gregor Riegler, Technical Coach. Ich hoffe, ich konnte helfen.
