Barrierefreiheit überwachen: WCAG-Regressionen nach Deploy

Was eine WCAG-Regression ist

Eine WCAG-Regression ist die ungewollte Verschlechterung der Barrierefreiheit einer Seite gegenüber einem früheren, geprüften Stand. Der Begriff stammt aus dem Software-Testing: Eine Regression ist ein Fehler, der eine zuvor funktionierende Eigenschaft wieder kaputt macht. Übertragen auf Barrierefreiheit heißt das – ein Element, das gestern noch den Web Content Accessibility Guidelines (WCAG) entsprach, verletzt nach dem nächsten Release ein Erfolgskriterium. Die WCAG sind der international anerkannte Standard des World Wide Web Consortium; in Europa verweist die harmonisierte Norm EN 301 549 auf WCAG 2.1 Level AA als Mindeststandard (Level Access 2025).

Das Tückische an Regressionen ist, dass sie selten als Fehler auffallen. Die Seite lädt, das Layout steht, die Funktion bleibt erhalten – nur eine messbare Eigenschaft hat sich verschlechtert. Ein Kontrastverhältnis sinkt von 4,8:1 auf 3,9:1 und unterschreitet damit die WCAG-Schwelle von 4,5:1 für normalen Text. Ein dekoratives Icon erhält versehentlich einen sichtbaren Fokusrahmen, ein interaktives Element verliert ihn. Für das Auge bleibt vieles unsichtbar, für Screenreader und Tastaturnutzer wird es zum Hindernis. Genau diese Lücke zwischen sichtbarer Funktion und tatsächlicher Bedienbarkeit macht das Thema für manuelle Sichtprüfungen so schwer greifbar.

Die häufigsten Fehlerarten sind dabei erstaunlich konstant. Sechs wiederkehrende Probleme – angeführt von zu geringem Textkontrast und fehlenden Alternativtexten – verursachen rund 96 % aller erkannten Verstöße (WebAIM Million 2025). Zu geringer Textkontrast allein findet sich auf 79,1 % der geprüften Startseiten (WebAIM Million 2025). Das ist eine gute Nachricht für die Überwachung: Gerade diese dominanten Fehlerklassen lassen sich automatisiert und reproduzierbar messen – und damit auch nach jedem Deploy gegen einen Sollwert prüfen.

Warum Deploys die häufigste Ursache sind

Moderne Web-Teams releasen häufig – und genau das ist die Crux. Jeder Deploy verändert das DOM, lädt neue Komponenten, aktualisiert Abhängigkeiten oder passt Stile an. Jede dieser Änderungen kann ein Erfolgskriterium kippen, ohne dass es jemand bemerkt. Eine einmalige Barrierefreiheits-Prüfung beim Launch wird damit zur Momentaufnahme, die schon beim nächsten Release veraltet sein kann. Die Ursachen sind selten böswillig – meist sind sie banal.

Hinzu kommt die schiere Komplexität moderner Seiten. Die durchschnittliche Startseite enthält inzwischen 1.257 HTML-Elemente, ein Plus von 7,1 % binnen eines Jahres (WebAIM Million 2025). Auffallend ist auch der Umgang mit ARIA: Im Schnitt finden sich 106 ARIA-Attribute pro Seite, doch Seiten mit ARIA wiesen im Mittel 57 Fehler auf – mehr als doppelt so viele wie Seiten ohne ARIA (WebAIM Million 2025). Falsch eingesetzte ARIA-Rollen sind also selbst eine häufige Regressionsquelle. Bei dieser Dichte ist die Wahrscheinlichkeit hoch, dass irgendein Deploy ein Detail kippt. Dasselbe Muster – ein Release ändert unbemerkt das Verhalten – beschreibt auch der Beitrag zum JavaScript-Fehler-Monitoring im Frontend.

Erschwerend kommt hinzu, dass an einem modernen Release selten nur ein Team beteiligt ist. Entwicklung, Design und Marketing greifen oft unabhängig voneinander in dieselbe Seite ein – die einen über Komponenten, die anderen über Inhalte oder den Seiten-Builder. Keiner dieser Beteiligten hat den vollständigen Überblick über den finalen, gerenderten Zustand im Browser. Eine objektive, von außen messende Kontrolle nach jedem Release ist deshalb der verlässlichste Weg, den realen Stand festzustellen, statt sich auf Annahmen zu verlassen.

Der gesetzliche Rahmen: BFSG, EAA und WCAG 2.1 AA

Barrierefreiheit ist seit 2025 nicht mehr nur eine Frage guter Praxis, sondern für viele Anbieter eine rechtliche Pflicht. Das Barrierefreiheitsstärkungsgesetz (BFSG) ist am 28. Juni 2025 in Kraft getreten und setzt den European Accessibility Act (EAA) in deutsches Recht um (IHK Region Stuttgart 2025). Für Websites und Online-Shops gibt es dabei keine Übergangsfrist – die Anforderungen gelten seit diesem Datum (IHK Region Stuttgart 2025). Der EAA selbst wurde EU-weit zum 28. Juni 2025 anwendbar (Level Access 2025).

Technisch verweisen beide Regelwerke auf dieselbe Grundlage: die harmonisierte Norm EN 301 549, die WCAG 2.1 Level AA als Mindeststandard inkorporiert (Level Access 2025). Auch wenn WCAG 2.2 bereits existiert, bleibt 2.1 AA der maßgebliche Referenzpunkt für die Konformitätsvermutung (Level Access 2025). Wer also seine Seite gegen WCAG 2.1 AA überwacht, misst genau gegen den Maßstab, der auch rechtlich herangezogen wird.

Die Kosten unentdeckter Regressionen

Barrierefreiheit ist kein theoretisches Risiko mehr, sondern ein aktiver Klagegrund. In den USA wurden 2024 über 4.000 Klagen wegen digitaler Barrierefreiheit eingereicht, genauer 4.187 Verfahren bis Jahresende (UsableNet 2024). Für 2025 zeichnet sich ein weiterer Anstieg ab: Allein im ersten Halbjahr wurden über 2.000 Verfahren registriert (UsableNet 2025). In Deutschland kommt das Risiko wettbewerbsrechtlicher Abmahnungen hinzu – ein vor Gericht leicht nachweisbarer WCAG-Verstoß bietet dafür einen technisch belegbaren Anknüpfungspunkt.

Hinter den rechtlichen Zahlen steht ein großer Personenkreis. In der EU berichteten 2024 rund 23,9 % der Menschen ab 16 Jahren von einer länger andauernden Aktivitätseinschränkung – etwa jeder vierte Erwachsene (Eurostat 2024). Eine Seite mit WCAG-Regression schließt genau diese Nutzergruppe ganz oder teilweise aus, was sich unmittelbar auf Conversion und Reichweite auswirkt. Barrierefreiheit ist damit nicht nur Compliance, sondern auch ein Faktor für erreichbare Zielgruppen.

WCAG-Regressionen technisch erkennen

Die zuverlässigste Prüfung beobachtet die gerenderte Seite in einem echten Browser. Eine kopflose Browser-Instanz lädt die Seite vollständig mit JavaScript und lässt eine etablierte Prüf-Engine wie das quelloffene axe-core darüber laufen. Wichtig ist die realistische Einordnung: Automatisierte Tests erfassen in der Praxis im Schnitt rund 57 % der vorhandenen Barrierefreiheits-Probleme nach Volumen – ein über dem oft genannten Branchen-Richtwert liegender Anteil, aber kein Ersatz für manuelle Prüfung (Deque 2021). Gerade die dominierenden Fehlerklassen wie Kontrast, fehlende Alternativtexte und Labels lassen sich jedoch verlässlich und reproduzierbar automatisiert messen.

Genau hier liegt die Stärke des kontinuierlichen Monitorings: Es geht nicht darum, jeden denkbaren Verstoß zu finden, sondern eine Verschlechterung gegenüber dem letzten geprüften Stand zu erkennen. Der aktuelle Scan wird gegen eine freigegebene Baseline verglichen – alarmiert wird nur, wenn neue Verstöße auftauchen oder ihre Zahl über eine definierte Schwelle steigt. Das hält das Rauschen niedrig und macht echte Regressionen sichtbar.

Baseline (Soll, freigegeben bei v144):
  Verstöße gesamt:        6
  Kontrast (1.4.3 AA):      4,8:1   ok
  Bilder mit alt-Text:      100 %   ok
  Formularfelder mit Label: 100 %   ok

Beobachtet nach Deploy v145:
  Verstöße gesamt:        40   (+34)
+ Kontrast (1.4.3 AA):      3,9:1   VERSTOSS
+ 12 Bilder ohne alt-Text           NEU
+ Suchfeld ohne Label               NEU

=> Regression erkannt: Schwelle (8) überschritten

• Vollständiges Rendering – die Seite wird in einem echten Browser mit JavaScript geladen, nicht nur als HTML abgerufen
• Standard-konforme Prüfung – Erfolgskriterien werden gegen WCAG 2.1 Level AA und EN 301 549 abgeglichen
• Fehler-Klassifizierung – Verstöße werden nach Kategorie sortiert: Kontrast, Alternativtexte, Labels, ARIA, Struktur, Sprache
• Baseline-Diff – der aktuelle Zustand wird gegen den letzten freigegebenen Stand verglichen, sodass nur echte Änderungen alarmieren
• Schwellenwert – erst ab einer definierten Zahl neuer Verstöße wird gemeldet, um Rauschen zu vermeiden

Was XICTRAQ kontinuierlich überwacht

Das XICTRAQ Barrierefreiheits-Monitoring rendert Ihre Seiten regelmäßig in einem echten Browser, prüft sie gegen WCAG 2.1 AA und vergleicht das Ergebnis mit der zuletzt freigegebenen Baseline. Statt einer jährlichen Prüfung, die zwischen zwei Terminen blind ist, entsteht eine laufende Kontrolle, die genau dann anschlägt, wenn sich nach einem Release etwas Relevantes verschlechtert.

Weicht der aktuelle Zustand ab – taucht ein neuer Verstoß auf oder steigt ihre Zahl über die Schwelle – löst das eine Benachrichtigung per E-Mail, Slack, Discord oder Telegram aus. So erfahren Sie von der Regression, während sie noch wenige Stunden alt ist, statt erst durch eine Nutzerbeschwerde oder eine Abmahnung. Dasselbe Prinzip der kontinuierlichen Soll-Ist-Prüfung liegt auch der Überwachung von Broken Links und 404-Fehlern zugrunde – ein Deploy ändert den Zustand, das Monitoring fängt die Abweichung ab.

Accessibility-Monitoring als Teil der Qualitätssicherung

WCAG-Regressionen sind nur ein Baustein eines belastbaren Qualitäts- und Compliance-Setups. Das BFSG verlangt, dass Barrierefreiheit über die Zeit erhalten bleibt – ein dokumentiertes, kontinuierliches Monitoring der tatsächlichen Konformität ist ein nachweisbarer Beleg dafür. Wer regelmäßig prüft, kann im Prüfungsfall belegen, dass Verschlechterungen erkannt und behoben wurden, statt monatelang unbemerkt zu bestehen.

Wichtig ist die Abgrenzung zur reinen Bestandsaufnahme. Ein klassisches Accessibility-Audit hält fest, wie die Seite zu einem Zeitpunkt aussah – es sagt nichts darüber aus, was beim nächsten Deploy passiert. Regressions-Monitoring dreht diese Logik um: Nicht der Zustand zählt, sondern die Veränderung gegenüber dem freigegebenen Stand. Damit wird die Überwachung anschlussfähig an moderne Entwicklungsprozesse, in denen sich die Seite ohnehin ständig verändert. Verwandte technische Driften – etwa bei DNS – behandelt der Beitrag zur DNSSEC-Validierung im DNS-Monitoring; das Muster bleibt dasselbe.

Der praktische Wert liegt im Zeitfaktor. Ohne Monitoring fällt eine Regression erfahrungsgemäß erst auf, wenn ein externer Hinweis kommt – eine Nutzerbeschwerde, eine Abmahnung oder eine Behördenanfrage. Mit kontinuierlicher Überwachung wird dieselbe Abweichung innerhalb von Stunden sichtbar, oft noch bevor sie nennenswert viele Besucher beeinträchtigt hat. Ein Deploy lässt sich nicht verhindern – und das soll er auch nicht. Was sich verhindern lässt, ist, dass eine ungewollte WCAG-Regression wochenlang unbemerkt bleibt.

Sinnvoll ist es zudem, die Überwachung nicht nur auf die Startseite zu beschränken. Eine Regression entsteht oft genau dort, wo geändert wurde – im Checkout, in einem neuen Formular oder auf einer Landingpage. Da gerade Conversion-relevante Strecken wie Warenkorb und Bezahlvorgang häufig die meisten interaktiven Elemente bündeln, treffen Barrieren dort wirtschaftlich am härtesten. Eine durchdachte Auswahl repräsentativer Vorlagen – Startseite, Kategorie, Produkt, Formular, Checkout – deckt einen Großteil der wiederkehrenden Muster ab, ohne jede einzelne URL prüfen zu müssen. So bleibt der Prüfaufwand beherrschbar und die Aussagekraft hoch.

Nicht zuletzt schafft kontinuierliches Monitoring auch eine gemeinsame Faktenbasis zwischen Entwicklung, Design und Marketing. Statt darüber zu diskutieren, ob ein bestimmtes Update die Barrierefreiheit verschlechtert hat, zeigt der Baseline-Diff objektiv, welcher Verstoß seit welchem Release neu ist. Das verkürzt die Ursachensuche, weil sich die Abweichung einem konkreten Deploy zuordnen lässt, und nimmt der Diskussion die Schärfe. Aus einer schwer greifbaren Qualitätsfrage wird ein konkretes, behebbares Ticket mit klarer Herkunft.

Häufig gestellte Fragen zu WCAG-Regressionen