WebAIM Million 2026: Barrierefreiheit im Netz kippt, 56 Fehler pro Startseite und KI-Coding als Mitursache

Die neue Ausgabe des jährlichen WebAIM Million ist da, und die Zahl darin macht die Runde: 56,1 automatisch erkannte Barrierefreiheits-Fehler stecken im Schnitt in einer der eine Million meistbesuchten Startseiten des Netzes. 2025 waren es noch 51. Der Zuwachs von 10,1 Prozent kippt einen Trend, den die Auswerter zuletzt vorsichtig positiv beschrieben hatten. Auf 95,9 Prozent aller getesteten Startseiten fand das Werkzeug mindestens einen WCAG-2-Verstoß. Insgesamt kommt der Report auf 56.114.377 einzelne Fehler.

Der zweite große Trend im Bericht ist der Wuchs der Seiten selbst. Eine durchschnittliche Startseite bringt jetzt 1.437 HTML-Elemente auf den Bildschirm, ein Plus von 22,5 Prozent innerhalb eines Jahres. Mehr Elemente heißt mehr Angriffsfläche für Fehler, und WebAIM benennt zwei konkrete Verdächtige: Dritt-Frameworks samt der ARIA-Attribute, die sie unter der Haube schreiben, und automatisiertes oder KI-gestütztes Codieren, im Bericht als „Vibe Coding“ bezeichnet.

Warum das Monitoring der meisten Frontends das nicht sieht

Genau an diesem Punkt hakt eine parallele Analyse ein, die Software-Engineerin Niharika Pujari am 10. September in InfoWorld veröffentlicht hat. Ihre These: Frontend-Observability, also all die Dashboards für Ladezeiten, Fehlerraten und Deployment-Health, hat einen strukturellen blinden Fleck bei Barrierefreiheit. Der Grund ist simpel. Ein Icon-Button ohne zugänglichen Namen wirft keinen JavaScript-Fehler. Ein klickbares Div, das einen semantischen Button ersetzt, taucht in keiner Latency-Kurve auf. Screen-Reader-Nutzerinnen und Tastatur-Bediener stehen dann vor einer Anwendung, die für das Monitoring grün ist und für sie geschlossen.

Pujaris Vorschlag lässt sich in einem Satz zusammenfassen: Barrierefreiheit gehört in die Release-Health, nicht in ein einmaliges CI-Audit vor dem Launch. Konkret heißt das synthetische Journeys mit Tastatur-Navigation, Fokus-Management und semantischer Auszeichnung als Dauer-Test, dazu Prüfungen auf Komponenten-Ebene für die Bausteine des Design-Systems. So werden Regressionen sichtbar, sobald jemand einen Baustein anfasst, nicht erst wenn eine Nutzerin sich beschwert.

Für den deutschen Markt ist der Zeitpunkt heikel

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz für viele privatwirtschaftlich betriebene Websites. Genau in dem Jahr, in dem Kundinnen und Kunden zum ersten Mal offiziell auf barrierefreie Seiten pochen können, meldet der größte öffentliche Report zum Zustand des Webs also mehr Fehler statt weniger. Für Agenturen, die Relaunches verkaufen, wird das entweder ein Verkaufsgrund oder ein Haftungsproblem, je nachdem, auf welcher Seite des Tischs sie sitzen.

Was heute konkret zu tun ist

Kurzfassung für die Werkbank:

• Automatisches Prüfen im Continuous-Integration-Setup ist ein Anfang, kein Abschluss. WCAG-Regeln lassen sich nicht komplett automatisiert prüfen, WebAIM fängt nur, was klar messbar ist.
• Kritische Nutzer-Pfade brauchen synthetische Tests mit Tastatur allein: Anmelden, Kaufen, Kontakt aufnehmen. Wenn das nicht ohne Maus geht, ist die Seite kaputt für einen Teil der Zielgruppe.
• Design-System-Komponenten wie Buttons, Dialoge und Menüs bekommen eigene Barrierefreiheits-Tests, weil sie überall verbaut sind und jede Regression multipliziert wird.
• ARIA sparsam einsetzen. Falsche oder überflüssige Rollen sind laut WebAIM eine der Hauptursachen für die neuen Fehler.
• KI-Assistenten liefern schnellen Markup-Code, aber ohne Prüfung schleppen sie klickbare Divs, fehlende Alt-Texte und lose ARIA-Attribute in Produktion. Reviews nicht überspringen.

Wer noch keine Pipeline für neue Aufträge aus dem Thema hat: Genau diese verschlechterten Zahlen sind ein sauberer Aufhänger für die kalte Ansprache. Wie sich Barrierefreiheits-Argumente in reproduzierbare Anfragen übersetzen, zeigt der findflix-Leitfaden zur Kundengewinnung für Webdesigner.