Adaptive Barrierefreiheit: Warum statische Checklisten nicht reichen

Compliance erledigt, Barrierefreiheit nicht

Wir alle haben es schon zigmal gelesen oder gehört: Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz. Im DACH-Raum tut sich gerade eine ganze Menge in Sachen Barrierefreiheit: Viele Teams haben seitdem Audits durchgeführt, Scanner eingerichtet und ihre Frontends überarbeitet. Die Awareness ist da, die ersten Umsetzungsrunden laufen.

Und genau an diesem Punkt zeigt sich ein Muster: Die meisten Organisationen behandeln Barrierefreiheit als einmaliges Projekt. Einmal prüfen, Findings abarbeiten, Haken setzen. Häufig kommt ein Overlay-Widget zum Einsatz oder ein automatisierter WCAG-Scanner. Beides erzeugt ein Gefühl von Fortschritt, ohne die eigentlichen Barrieren zu beseitigen.

Ein WCAG-2.2-Audit prüft 86 Erfolgskriterien. Das Ergebnis ist eine Momentaufnahme: konform oder nicht, an genau diesem Tag, mit genau dieser Konfiguration. Eure Nutzer:innen interagieren aber jeden Tag mit dem Interface. Bei Sonnenlicht auf dem Balkon, mit einer Hand in der Bahn, mit Screenreader am Arbeitsplatz.

Die Checkliste sagt: bestanden. Die Person am Screenreader sagt: Ich komme hier trotzdem nicht weiter.

Hier setzt adaptive Barrierefreiheit an. Sie fragt nicht nur, ob ein Interface konform ist. Sie fragt, ob es für die Person funktioniert, die es gerade nutzt. Nicht als Ersatz für WCAG, sondern als nächster Schritt für Teams, die den ersten bereits gemacht haben.

Warum statische Checklisten an echten Nutzer:innen scheitern

1,3 Milliarden Menschen weltweit leben mit einer Behinderung. Das sind 16 % der Weltbevölkerung [2]. Hinter dieser Zahl steckt eine enorme Vielfalt: visuell, motorisch, kognitiv, auditiv. Und dazu kommen situative Einschränkungen, die jede:n von uns treffen. Der gebrochene Arm, das grelle Display in der Sonne, die laute Umgebung im Großraumbüro.

WCAG deckt diese Vielfalt mit einem einheitlichen Regelwerk ab. Das ist die Stärke des Standards: klare, testbare Kriterien für wahrnehmbare, bedienbare, verständliche und robuste Interfaces. Und zugleich die Grenze. Denn WCAG prüft Konformität, nicht Nutzbarkeit. Ein Kontrastverhältnis von 4,5:1 besteht den AA-Test. Für eine Person mit Makuladegeneration reicht es trotzdem nicht.

Kurz: WCAG ist der Boden, auf dem barrierefreie Interfaces stehen. Adaptive Barrierefreiheit hebt die Decke an [3].

Das Konzept ist nicht neu, aber die technischen Voraussetzungen sind es. Dulanjala Aluthge beschreibt in „Intelligent Accessibility“ vier Bausteine adaptiver Interfaces [4]: Context Awareness erkennt die aktuelle Nutzungssituation (Gerät, Bandbreite, Eingabemethode). Real-Time Personalization passt das Interface daraufhin in Echtzeit an, etwa durch vergrößerte Touch-Targets oder erhöhten Kontrast. Pattern Recognition identifiziert wiederkehrende Nutzungsmuster und leitet Präferenzen ab. Und Predictive Automation trifft auf Basis dieser Muster proaktive Anpassungen, bevor die Person selbst eingreift.

Ein konkretes Beispiel: ChartAccessMobile kombiniert Computer Vision mit Large Language Models, um Diagramme automatisch in barrierefreie Textbeschreibungen zu übersetzen. Zehn blinde und sehbehinderte Testpersonen bewerteten die Ergebnisse als signifikant hilfreicher als herkömmliche Alt-Texte [4].

Die Forschungsbasis wächst schnell. Kristić et al. haben 2025 in einer systematischen Übersichtsarbeit 57 Studien ausgewertet, die Machine Learning für adaptive Benutzeroberflächen einsetzen [5]. Das Ergebnis: ML-basierte Ansätze verbessern nachweislich die Usability für Menschen mit unterschiedlichen Einschränkungen.

Wusstest du schon? Die meisten adaptiven Technologien setzen keine Spezial-Hardware voraus. Moderne Browser liefern über CSS Media Queries bereits Signale wie prefers-reduced-motion, prefers-contrast und prefers-color-scheme. Die Grundlage für die ersten beiden Stufen adaptiver Barrierefreiheit ist damit schon vorhanden.

225 Findings, 3 Plattformen: Was ein Audit wirklich aufdeckt

Wie groß der Gap zwischen Compliance-Gefühl und tatsächlicher Barrierefreiheit ausfällt, zeigt ein Blick in die Praxis: das Accessibility-Audit für JAM Software.

JAM Software entwickelt Tools für Netzwerk- und Systemadministration und betreibt drei zentrale Web-Plattformen: die Unternehmenswebsite, eine Knowledge Base und ein Customer Portal. Alle drei wurden im Rahmen eines umfassenden Audits nach WCAG 2.2 und BITV 2.0 geprüft.

Das Ergebnis: 225 Findings. Im Schnitt 70 getestete WCAG-Kriterien pro Domain, 48 % initiale Konformität und durchschnittlich 16 Findings pro geprüfter Seite.

Spannend sind dabei weniger die Zahlen als die Muster, die ein manuelles Audit aufdeckt:

Focus-Indikatoren in der Lizenzverwaltung fehlten auf zentralen Bedienelementen. Wer ausschließlich mit Tastatur navigiert, verliert an diesen Stellen die Orientierung und erreicht zentrale Funktionen nicht.

Icons ohne Labels tauchten plattformübergreifend auf. Buttons mit reinem Icon-Symbol, ohne hinterlegtes aria-label, sind für Screenreader-Nutzer:innen unsichtbar. Die Funktion ist da, der Zugang fehlt.

Checkout-Formulare enthielten Eingabefelder ohne programmatische Labels und Radiobuttons ohne Gruppierung. Assistive Technologien ordnen solche Felder keinem Kontext zu. Wer auf sie angewiesen ist, rät bei jedem Eingabeschritt.

Zoom bei 200 % führte dazu, dass ein Chat-Widget Inhalte verdeckte. Ganze Seitenbereiche waren damit für Nutzer:innen mit Vergrößerungsbedarf nicht erreichbar.

Keiner dieser Fälle ist ein Randproblem. Es sind alltägliche Interaktionen auf einer ganz normalen Business-Website. Und genau deshalb findet sie kein automatisierter Scanner: Sie entstehen erst im Zusammenspiel von Layout, Interaktion und Nutzungskontext.

JAM Software hat 60 % der als Priorität 1 eingestuften Findings bereits umgesetzt. Das Team nutzt dafür den Jira-Import der Lösungsvorschläge direkt aus dem Audit-Report. Bastian Lütge-Traut von JAM Software:

„Die formulierten Findings und der Jira-Import mit den Lösungsvorschlägen waren ideal, um die Barrieren effektiv zu entfernen. Wir hatten eine reibungslose, unkomplizierte Kommunikation.“

Vom Finding zum messbaren Impact

Ein Audit deckt auf. Aber was passiert, wenn die Findings systematisch umgesetzt werden?

Die BMG FohlenApp zeigt, wie sich Barrierefreiheit in harten Zahlen niederschlägt. 52 Findings aus 74 geprüften Kriterien nach WCAG 2.2, BITV 2.0 und EN 301 549. Sechs Monate nach der Umsetzung:

• −17 % Support-Anfragen: Klare Navigation und verständliche Labels reduzieren Rückfragen.
• +25 % Interaktionsrate: Barrierefreie Touch-Targets und Kontraste verbessern die Bedienbarkeit für alle.
• +36 % Retention: Nutzer:innen bleiben länger, weil sie das Produkt ohne Hürden nutzen.
• 2× Checkout-Conversion: Formulare mit sauberer Struktur und Labels führen direkt zu höheren Abschlussraten.

Wichtig: Diese Zahlen stammen aus einem App-Kontext. Aber das Muster lässt sich 1:1 auf Web-Plattformen übertragen. Support-Kosten sinken, wenn Nutzer:innen sich selbst zurechtfinden. Conversion steigt, wenn Formulare für alle funktionieren. Und Retention wächst, wenn die Nutzung nicht an vermeidbaren Barrieren scheitert.

Adaptive Barrierefreiheit: Drei Stufen, die heute funktionieren

Adaptive Barrierefreiheit klingt nach Zukunftsmusik. Tatsächlich lässt sich ein großer Teil schon heute mit Standard-Webtechnologien umsetzen. accessible.org beschreibt drei Implementierungsstufen [3]:

Stufe 1: Persistente Nutzereinstellungen

Die einfachste Stufe: Nutzer:innen wählen Schriftgröße, Farbschema oder reduzierte Animationen selbst aus. Die Einstellungen bleiben über Sessions hinweg erhalten. Das ist kein neues Konzept, viele Plattformen bieten es bereits im Rahmen ihrer Account-Einstellungen an. Wichtig dabei: Diese Präferenzen fließen aktiv ins Interface-Design ein, statt in einem versteckten Menü zu verschwinden.

Stufe 2: OS-Level-Signale

Moderne Betriebssysteme und Browser liefern Informationen über die Nutzungspräferenzen direkt mit. Die CSS Media Queries prefers-reduced-motion, prefers-contrast und prefers-color-scheme sind breit unterstützt und einfach implementierbar. Ein Interface, das auf diese Signale reagiert, passt sich ohne zusätzlichen Konfigurationsaufwand an die individuellen Einstellungen an.

Stufe 2 ist die Low-Hanging Fruit. Wenig Aufwand, große Wirkung, keine Abhängigkeit von User Accounts.

Stufe 3: Kontextbasierte Anpassung

Die anspruchsvollste Stufe: ML-Modelle erkennen Nutzungsmuster und passen das Interface proaktiv an. Navigiert eine Person ausschließlich per Tastatur, hebt das Interface Focus-States stärker hervor und blendet Tastaturkürzel ein. Verlängern sich die Verweildauern auf Textpassagen, vergrößert sich der Zeilenabstand dynamisch.

Stufe 3 ist noch überwiegend in der Forschung verankert. Aber die 57 von Kristić et al. ausgewerteten Studien zeigen, dass die Grundlagen funktionieren [5]. Die Frage ist nicht ob, sondern wann diese Ansätze produktionsreif sind.

Unser Tipp: Startet mit Stufe 1 und 2. Sie erfordern keinen ML-Stack und verbessern die Erfahrung für eine große Nutzergruppe sofort. Stufe 3 kommt dazu, sobald die Daten und die Architektur dafür bereit sind.

WCAG 3.0 denkt adaptive Barrierefreiheit schon mit

WCAG 3.0 befindet sich als Working Draft in aktiver Entwicklung. Das letzte große Update stammt vom März 2026 [6]. Die früheste Verabschiedung liegt voraussichtlich bei 2028. Aber die Richtung ist bereits klar.

Das auffälligste Signal: das neue Bewertungsmodell. WCAG 2.x arbeitet mit einem binären System: A, AA oder AAA. Ein Kriterium ist erfüllt oder nicht. WCAG 3.0 führt eine Bronze/Silver/Gold-Abstufung ein, die den Grad der Barrierefreiheit differenzierter abbildet.

Für adaptive Barrierefreiheit ist das ein wichtiger Shift. Das neue Modell bewertet nicht nur, ob ein Element konform ist. Es bewertet, wie gut eine Erfahrung über verschiedene Kontexte hinweg funktioniert. Genau das ist der Kern adaptiver Ansätze.

Dazu kommt ein stark erweiterter Fokus auf kognitive Barrierefreiheit. WCAG 2.2 deckt kognitive Einschränkungen nur rudimentär ab. WCAG 3.0 bringt hier deutlich mehr Tiefe: vereinfachte Sprache, vorhersehbare Navigation, reduzierte kognitive Last.

Was heißt das für euch? Ihr braucht nicht auf 2028 zu warten. Die Prinzipien hinter WCAG 3.0 lassen sich schon heute in eure Produkte einbauen: ein differenziertes Bewertungsmodell, ein stärkerer Fokus auf kognitive Zugänglichkeit und die Erfahrung über verschiedene Kontexte hinweg. Wer jetzt in adaptive Barrierefreiheit investiert, ist vorbereitet.

Fazit

Statische Checklisten sind der Startpunkt, nicht das Ziel. Echte Barrierefreiheit beginnt dort, wo Konformität aufhört: bei Interfaces, die sich an echte Menschen anpassen. Wer in adaptive Ansätze investiert, investiert in Nutzbarkeit, Reichweite und Zukunftsfähigkeit gleichzeitig.

Die technische Grundlage ist da: Browser-Signale, ML-Forschung, WCAG 3.0 in Sicht. Die Design-Grundlage steht ebenfalls: Ein gründliches Audit zeigt euch exakt, wo eure Interfaces an echten Bedürfnissen vorbeigehen und wo adaptive Ansätze den Unterschied machen.

Barrierefreiheit ist eine Designdisziplin. Und sie braucht eure Aufmerksamkeit über den ersten Audit-Report hinaus.

Eure Interfaces passen sich nicht an? Dann lass uns sprechen.

Kostenlosen Discovery Call mit Christian buchen

Quellen

1. Die mit Ausrufezeichen. (2026). Zwei Abmahnwellen laufen und die häufigste BFSG-Maßnahme in Deutschland bringt gar nichts.

2. World Health Organization. (2023, 7. März). Disability and health [Fact Sheet].

3. accessible.org. (o. D.). Adaptive Personalization Engines: AI That Learns Individual Accessibility Needs (vs. WCAG).

4. Aluthge, D. (2026, 30. September). Intelligent accessibility — what if accessibility could adapt to you? UX Collective.

5. Kristić, M., et al. (2025). Machine Learning for Adaptive Accessible User Interfaces: Overview and Applications. Applied Sciences, 15(23), 12538.

6. World Wide Web Consortium. (2026, März). W3C Accessibility Guidelines (WCAG) 3.0 [Working Draft].