Die teuersten Barrieren-Fehler: Wo Unternehmen zuerst ansetzen sollten

Einen Überblick über häufige Barrieren und ihre Lösungen haben wir bereits im Wissensbereich zusammengestellt, inklusive konkreter Beispiele zu Alt-Texten, Tastaturbedienbarkeit, Kontrasten und Formularen. Dieser Beitrag setzt dort an, wo die Übersicht aufhört, und beantwortet die Frage nach der Reihenfolge, gestützt auf konkrete Häufigkeits- und Risikodaten statt auf Bauchgefühl oder die zufällige Reihenfolge einer Checkliste.

Warum Priorisierung überhaupt nötig ist

Nicht jede Barriere wiegt gleich schwer. Manche betreffen nahezu jede Seite einer Website und lassen sich in wenigen Stunden beheben, andere stecken tief in einem individuell programmierten Widget und erfordern eine mehrwöchige Überarbeitung mit Entwicklerkapazität. Ohne Priorisierung passiert in der Praxis häufig das Gegenteil des Gewünschten, Teams arbeiten sich an einer aufwendigen Einzelbarriere ab, während zehn einfach zu behebende Fehler mit deutlich größerer Reichweite liegen bleiben.

Für die gesetzliche Konformität nach BFSG und EAA zählt zudem in erster Linie WCAG-Stufe AA, nicht die freiwillige Stufe AAA. Wer priorisiert, sollte deshalb zuerst alle AA-Kriterien der WCAG 2.2 abdecken, bevor Ressourcen in weiterführende AAA-Maßnahmen fließen, die zwar wünschenswert, aber rechtlich nicht verpflichtend sind.

Die häufigsten Fehler laut WebAIM Million 2026

Der WebAIM Million Report 2026, eine jährliche Analyse von einer Million Startseiten weltweit, liefert eine belastbare Grundlage für die Reihenfolge. 95,9 Prozent der untersuchten Startseiten weisen mindestens einen erkennbaren WCAG-Fehler auf. Sechs Fehlerkategorien stechen dabei besonders heraus und machen zusammen rund 96 Prozent aller erkannten Probleme aus:

• ✓ Unzureichender Kontrast, 83,9 Prozent der Startseiten betroffen
• ✓ Fehlende Alternativtexte, 53,1 Prozent betroffen
• ✓ Fehlende Formularbeschriftungen, 51 Prozent betroffen
• ✓ Leere Links, 46,3 Prozent betroffen
• ✓ Leere Buttons, 30,6 Prozent betroffen

Diese Reihenfolge ist kein Zufall, sie spiegelt in etwa, wie oft ein Fehler technisch übersehen wird, nicht wie schwer er für eine einzelne Nutzerin oder einen einzelnen Nutzer im Einzelfall wiegt. Trotzdem ist sie ein guter Ausgangspunkt, denn was am häufigsten vorkommt, betrifft in der Regel auch die meisten Menschen, die eine Website mit assistiver Technologie nutzen. Auffällig ist zudem, dass die ersten beiden Kategorien, Kontrast und Alt-Texte, sich meist ohne tiefen Eingriff in bestehenden Code beheben lassen, während leere Links und Buttons häufiger auf strukturelle Probleme im Frontend hindeuten und etwas mehr Abstimmung mit der Entwicklung erfordern.

Ein einfaches Prioritätsraster: Reichweite gegen Aufwand

In der Praxis hat sich ein einfaches Raster bewährt, das jede Barriere nach zwei Achsen einordnet, wie viele Seiten und Nutzerinnen und Nutzer betroffen sind, und wie viel Aufwand die Behebung erfordert. Dieses Raster ersetzt keine vollständige Prüfung, hilft aber dabei, aus einer langen Fehlerliste in wenigen Minuten eine sinnvolle Reihenfolge abzuleiten, bevor überhaupt Entwicklerressourcen eingeplant werden.

• ✓ Quick Wins, hohe Reichweite, geringer Aufwand, dazu zählen fast immer Kontrastwerte und fehlende Alt-Texte, oft sitewide über ein zentrales Farbschema oder CMS-Feld behebbar
• ✓ Muss-Projekte, hohe Reichweite, hoher Aufwand, etwa Tastaturbedienbarkeit bei individuell programmierten Menüs oder Formularen, aufwendig, aber wegen der Reichweite unumgänglich
• ✓ Geplante Vorhaben, geringere Reichweite, hoher Aufwand, etwa Untertitel für ein umfangreiches Video-Archiv, sinnvoll eingeplant statt spontan umgesetzt
• ✓ Nebenbei erledigen, geringere Reichweite, geringer Aufwand, etwa das lang-Attribut auf einzelnen fremdsprachigen Textpassagen, lässt sich mit erledigen, wenn ohnehin am Code gearbeitet wird

Ein Blick auf den eigenen Kontrastchecker-Wert reicht oft schon aus, um den ersten Quick Win zu identifizieren, bevor überhaupt ein vollständiger Scan läuft. In der Praxis empfiehlt sich meist eine Reihenfolge von oben nach unten durch das Raster, zuerst die Quick Wins in wenigen Tagen umsetzen, parallel die Muss-Projekte fachlich und zeitlich planen, anschließend die geplanten Vorhaben terminieren, und die Nebenbei-Punkte im Rahmen ohnehin anstehender Code-Änderungen mit erledigen. Diese Abfolge liefert innerhalb kurzer Zeit einen sichtbaren Fortschritt, was intern oft entscheidend dafür ist, dass ein Barrierefreiheitsprojekt Rückhalt behält, statt nach der ersten aufwendigen Baustelle ins Stocken zu geraten.

Wichtig ist dabei, das Raster nicht einmalig anzuwenden und dann zu vergessen. Neue Inhalte, neue Kampagnenseiten oder ein Relaunch einzelner Komponenten bringen erfahrungsgemäß neue Instanzen bekannter Fehler mit sich, meistens wieder Kontrast oder fehlende Alt-Texte. Eine wiederkehrende Prüfung verhindert, dass sich bereits behobene Fehlerkategorien schleichend wieder aufbauen.

Rechtliches Risiko als zusätzlicher Faktor

Reichweite und Aufwand sind nicht die einzigen Kriterien. Manche Barrieren tauchen überproportional häufig in Abmahnungen auf, weil sie sich mit einem einfachen automatisierten Scan eindeutig nachweisen lassen, allen voran fehlender Kontrast und fehlende Alt-Texte. Wer eine Barriere findet, die sowohl häufig vorkommt als auch leicht nachweisbar ist, sollte sie unabhängig vom reinen Aufwand nach oben auf die Liste setzen.

Seit Januar 2026 kommt zur zivilrechtlichen Abmahnung durch Mitbewerber oder Verbände zusätzlich eine behördliche Marktüberwachung hinzu, mit eigenem Bußgeldrisiko unabhängig von privatrechtlichen Schritten. Für die Priorisierung bedeutet das, dass leicht auffindbare und leicht nachweisbare Barrieren nicht mehr nur ein Reputationsrisiko sind, sondern auch ein behördliches.

Wie SiteCockpit bei der Priorisierung hilft

easyMonitoring übernimmt diese Einordnung automatisiert, jede gefundene Barriere wird nach Dringlichkeit sortiert ausgegeben, sodass Teams nicht erst selbst ein Prioritätsraster aufbauen müssen, sondern direkt mit den Quick Wins mit der größten Wirkung starten können. So lässt sich eine Website barrierefrei gestalten, ohne sich in einer unsortierten Liste aus hundert Einzelfehlern zu verlieren, und ohne dass jede Priorisierungsentscheidung manuell getroffen werden muss.

Sobald die Reihenfolge steht, hilft unser Beitrag WCAG-Konformität erreichen, Schritt für Schritt bei der eigentlichen Umsetzung, von der Analyse bis zur Team-Schulung. Wer noch mit dem Argument des vermeintlich hohen Aufwands kämpft, findet in diese 5 Barrierefreiheits-Mythen kosten Ihr Unternehmen bares Geld weitere Argumente dafür, mit den Quick Wins zu starten, statt das gesamte Projekt aus Respekt vor den aufwendigeren Punkten aufzuschieben.