Die zwölf häufigsten Barrierefreiheits-Fehler

56,1Barrierefreiheits-Fehler hat eine durchschnittliche Startseite (WebAIM Million, Februar 2026) [1]

Sechs Fehlertypen erklären 96 % aller automatisch messbaren Verstöße. Wer Kontrast, Alt-Texte, Labels, Links, Buttons und Sprachangabe sauber hat, löst den Großteil der Beanstandungen.

7 Min. Lesezeit · Stand

Woher die Zahlen kommen

Die kurze Antwort: Die meisten Barrieren auf Websites sind keine exotischen Spezialfälle, sondern immer dieselben wenigen Fehler. Das zeigt die WebAIM Million, eine automatische Prüfung der Startseiten der eine Million meistbesuchten Websites, die 2026 zum achten Mal in Folge erschienen ist [1]. Die Daten stammen vom Februar 2026 und messen Verstöße gegen WCAG 2.2 auf den Stufen A und AA [1]. Dieser Artikel ist eine Orientierung, keine Rechtsberatung.

Das Ergebnis ist 2026 erstmals wieder schlechter geworden: 95,9 % der Startseiten hatten erkennbare WCAG-Fehler, nach 94,8 % im Jahr davor; damit endet eine Serie kleiner Verbesserungen über sechs Jahre [1]. Je Seite wurden im Schnitt 56,1 Fehler gezählt, 10,1 % mehr als 2025 [1]. WebAIM nennt als wahrscheinliche Gründe die wachsende Komplexität der Seiten, deutlich mehr ARIA-Code und automatisiertes oder KI-gestütztes Programmieren [1]. Die Startseiten sind heute fast doppelt so umfangreich wie 2019 [1].

Entscheidend für Ihre Arbeit: 96 % aller gefundenen Fehler verteilen sich auf nur sechs Typen, und diese sechs sind seit sieben Jahren dieselben [1]. Wer sie im Griff hat, hat den messbaren Teil der Barrierefreiheit weitgehend erledigt. Zwei Einschränkungen gehören dazu. Erstens findet ein automatischer Test nur, was sich automatisch erkennen lässt; WebAIM schreibt selbst, dass das Fehlen gemeldeter Fehler nicht bedeutet, dass eine Seite barrierefrei oder konform ist [1]. Zweitens zählt die Studie Startseiten, nicht Bestellstrecken, Buchungsformulare oder Logins, in denen das Gesetz am meisten verlangt. Die zwölf Fehler unten decken deshalb die sechs großen Typen ab und ergänzen sechs weitere, die WebAIM ebenfalls misst und die in Prüfberichten regelmäßig auftauchen.

Eine Startseite in Zahlen

56,1erkannte Fehler je Startseite im Februar 2026, nach 51 im Jahr 2025. [1]
1.437HTML-Elemente je Startseite, 14,3 % mehr als ein Jahr zuvor. [1]
1 von26Elementen trägt einen Fehler. Wer auf Hilfstechnik angewiesen ist, stößt alle 26 Elemente auf eine Barriere. [1]
133ARIA-Attribute je Startseite, 27 % mehr als 2025 und sechsmal so viele wie 2019. [1]

Zwölf Fehler, Anteil, Kriterium, Behebung

KriteriumAnteil der StartseitenWCAG 2.2Behebung
1 Zu wenig Kontrast83,9 %, im Schnitt 34 Stellen je Seite [1]1.4.3 Kontrast (Minimum), AA [3]Farbpaare im Design-System festlegen und jede Kombination prüfen: Text mindestens 4,5:1, große Schrift 3:1 [2].
2 Fehlender Alt-Text53,1 % [1]1.1.1 Nicht-Text-Inhalt, A [3]Informative Bilder beschreiben, dekorative mit leerem alt-Attribut markieren; bei verlinkten Bildern nennt der Alt-Text das Linkziel.
3 Formularfeld ohne Label51 % der Seiten, 33,1 % aller Felder [1]1.3.1 Info und Beziehungen und 3.3.2 Beschriftungen, A [3]Jedes Feld bekommt ein sichtbares, im Code verknüpftes Label. Ein Platzhalter ersetzt es nicht.
4 Leerer Link46,3 % [1]2.4.4 Linkzweck, A [3]Icon-Links bekommen einen Textinhalt oder ein aria-label, Bild-Links einen Alt-Text. Leere Anker ohne Ziel löschen.
5 Leerer Button30,6 % [1]4.1.2 Name, Rolle, Wert, A [3]Jeder Button hat einen zugänglichen Namen: sichtbaren Text, ein aria-label oder ein beschriftetes SVG.
6 Fehlende Sprachangabe13,5 % [1]3.1.1 Sprache der Seite, A [3]Das html-Element trägt lang="de". In den meisten Baukästen ist das eine Einstellung, keine Programmierung.
7 Übersprungene Überschriftenebenen41,8 %, jede 25. Überschrift [1]1.3.1 Info und Beziehungen, A [3]Ebenen nach Struktur vergeben, nicht nach Optik. Die Schriftgröße regelt eine Klasse, nicht die Wahl zwischen H2 und H4.
8 Mehr als eine H118,1 % [1]kein eigenes Kriterium; erschwert die Orientierung nach 2.4.6 Überschriften und Beschriftungen, AA [3]Eine H1 je Seite, die den Inhalt benennt. Logo und Seitentitel nicht beide als H1 auszeichnen.
9 Unklare Linktexte15,2 %, dort 5,3 Links je Seite [1]2.4.4 Linkzweck, A [3]Der Linktext nennt das Ziel: „Preisliste 2026 als PDF“ statt „mehr“ oder „hier klicken“.
10 Fehlendes main-Landmarknur 46,1 % haben eines [1]1.3.1 Info und Beziehungen, A [3]Hauptinhalt in ein main-Element, Kopf, Navigation und Fußzeile in header, nav und footer. Screenreader springen dann direkt dorthin.
11 Kaputter Skip-Linkjeder zehnte Skip-Link; nur 17,1 % der Seiten haben einen [1]2.4.1 Blöcke umgehen, A [3]Link „Zum Inhalt“ als erstes fokussierbares Element, bei Fokus sichtbar, und die Ziel-ID existiert tatsächlich.
12 ARIA-Menü ohne Tastaturlogik22 % der ARIA-Menüs; 5,7 % der Seiten nutzen role="menu" [1]2.1.1 Tastatur und 4.1.2 Name, Rolle, Wert, A [3]role="menu" nur mit vollständiger Pfeiltasten-Bedienung. Für eine Website-Navigation reicht eine Liste mit Links.

Anteile aus der WebAIM Million 2026 (Februar 2026, eine Million Startseiten). Die Zahlen in eckigen Klammern verweisen auf die Quellenliste am Ende des Artikels.

Warum mehr ARIA nicht hilft

ARIA ist die Technik, mit der Entwickler Screenreadern zusätzliche Informationen über Rollen, Namen und Zustände geben. Sie wird so stark genutzt wie nie: 133 Attribute je Startseite, 27 % mehr in einem Jahr, sechsmal so viele wie 2019 [1]. 82,7 % der Startseiten setzen ARIA ein [1]. Man könnte erwarten, dass diese Seiten besser abschneiden. Das Gegenteil ist der Fall: Seiten mit ARIA hatten im Schnitt 59,1 Fehler, Seiten ohne 42 [1]. Je mehr ARIA, desto mehr Fehler wurden gefunden [1].

WebAIM betont, dass das keine Kausalität beweist, weil ARIA-lastige Seiten auch komplexer sind [1]. Für die Praxis ist die Lehre trotzdem eindeutig: Natives HTML zuerst. Ein button ist von Haus aus fokussierbar, per Enter und Leertaste bedienbar und hat seine Rolle; ein div mit role="button" braucht das alles per Hand und geht in der Regel schief. Ein Link ist ein a mit href, ein Dialog ein dialog, eine Tabelle eine table. ARIA kommt erst dort ins Spiel, wo HTML kein Element kennt, etwa bei Tabs oder Autovervollständigung, und dann vollständig mit Tastaturlogik.

Die Zahlen zeigen auch, wo Baukästen und Bibliotheken schummeln: 23,3 Attribute aria-hidden="true" je Seite (plus 30 % in einem Jahr), 4,8 role="button" und 30,4 tabindex-Angaben im Schnitt [1]. Jedes davon ist ein Ort, an dem ein Screenreader etwas anderes vorgesetzt bekommt als der Bildschirm zeigt. Bei der Abnahme eines Projekts lohnt deshalb eine Suche nach genau diesen Attributen. Wie Sie Fehler systematisch durchgehen, steht in der Checkliste barrierefreie Website; die Farbfrage im Detail behandelt der Artikel zu Kontrast, Farben und Schrift.

Home pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average).

ÜbersetzungStartseiten mit ARIA hatten deutlich mehr Fehler (im Schnitt 59,1) als Seiten ohne ARIA (im Schnitt 42).

WebAIM, The WebAIM Million 2026 [1]

Reihenfolge der Behebung

  1. Kontrast-Tokens im Design-System · 1 Tag

    Alle Text- und Hintergrundfarben als Paare festlegen und jedes Paar gegen 4,5:1 beziehungsweise 3:1 prüfen [2]. Das löst den häufigsten Fehler an der Wurzel statt Seite für Seite; auf 83,9 % der Startseiten wäre das der erste Punkt [1].

  2. Alt-Texte und Redaktionsregel · 1–3 Tage

    Bestehende Bilder durchgehen: 16,2 % aller Bilder auf Startseiten haben keinen Alt-Text, bei verlinkten Bildern ist es jedes vierte [1]. Danach eine Regel für die Redaktion: Pflichtfeld im CMS, dekorative Bilder ausdrücklich leer.

  3. Labels und Fehlermeldungen · 1–2 Tage

    Jedes Formularfeld bekommt ein sichtbares Label, jede Fehlermeldung einen Text am Feld. Das betrifft die Hälfte aller Startseiten und ist im Bestell- oder Buchungsweg der Punkt, an dem das Gesetz greift [1]. Details im Artikel zu Formularen und Cookie-Bannern.

  4. Links und Buttons mit Namen · 1 Tag

    Leere Links, leere Buttons und „mehr“-Links in einem Durchgang beheben. Meist sind es wenige Vorlagen (Karten, Slider, Social-Icons), die sich hundertfach wiederholen.

  5. Überschriften und Landmarken · 1 Tag

    Eine H1, keine übersprungenen Ebenen, main, header, nav und footer gesetzt. Prüfen lässt sich das mit der Gliederungsansicht des Browsers oder einem Überschriften-Add-on.

  6. Sprache und Skip-Link · 1 Stunde

    lang-Attribut setzen, Skip-Link einbauen und testen, ob er bei Tab sichtbar wird und sein Ziel existiert. Der kleinste Aufwand auf dieser Liste, trotzdem auf 13,5 % der Seiten offen [1].

  7. Re-Test · je Deployment

    Automatischer Test im Build oder vor jedem Livegang, danach zehn Minuten mit der Tastatur durch die wichtigste Strecke. Nur so bleibt das Ergebnis stabil, wenn Redaktion und Updates weiterarbeiten.

Fragen zu den häufigsten Fehlern

Welche Fehler findet ein automatischer Test nicht?

Alles, was ein Urteil verlangt. Ein Werkzeug erkennt, ob ein Bild einen Alt-Text hat, aber nicht, ob er das Bild sinnvoll beschreibt; es sieht, ob ein Label existiert, aber nicht, ob es das richtige Wort enthält. Ob ein Dialog mit der Tastatur wieder verlassen werden kann, ob die Fokus-Reihenfolge logisch ist und ob eine Fehlermeldung verständlich ist, merkt erst, wer die Seite ohne Maus oder ohne Bildschirm bedient. WebAIM schreibt selbst, dass das Fehlen gemeldeter Fehler nicht bedeutet, dass eine Seite barrierefrei ist. Deshalb gehört zu jeder Prüfung ein Tastatur- und ein Screenreader-Durchlauf.

Warum ist die Sprachangabe im Code wichtig?

Weil der Screenreader danach die Aussprache wählt. Fehlt das lang-Attribut am html-Element, liest eine deutsche Seite mit englischer Stimme und wird unverständlich; auch Browser-Übersetzung und Silbentrennung richten sich danach. Im Februar 2026 fehlte die Angabe noch auf 13,5 % der Startseiten, obwohl es ein einziges Attribut ist, in den meisten Baukästen eine Einstellung. Fremdsprachige Passagen innerhalb der Seite bekommen zusätzlich ein eigenes lang-Attribut.

Wie schreibe ich einen guten Alt-Text?

Beschreiben Sie den Zweck des Bildes an dieser Stelle, nicht jedes Detail. Ein bis zwei Sätze reichen, ohne „Bild von“ oder „Foto:“, denn das sagt der Screenreader ohnehin. Dekorative Bilder bekommen ein leeres alt-Attribut, damit sie übersprungen werden; verlinkte Bilder beschreiben das Linkziel, nicht das Motiv. Für komplexe Grafiken wie Diagramme gehört die Aussage als Text neben das Bild. Legen Sie das im CMS als Redaktionsregel fest, sonst füllt sich die Lücke nach dem Livegang wieder.

Wie viele Fehler sind noch in Ordnung?

Rechtlich gibt es keine Toleranzquote: WCAG-Konformität gilt je Seite und je Kriterium, ein einziger blockierender Fehler im Bestellweg reicht für eine Beschwerde. Praktisch zählt die Reihenfolge: Zuerst alles, was Kauf, Buchung oder Kontakt verhindert, dann Struktur, Kontraste und Bilder. Zur Einordnung: 20,5 % der Startseiten kamen im Februar 2026 mit höchstens fünf automatisch erkannten Fehlern aus. Ziel sollte null messbare Fehler sein, danach beginnt die manuelle Prüfung. Orientierung, keine Rechtsberatung.

Alle Fragen 

Für Agenturen

Wir prüfen die Website Ihres Kunden white-label auf genau diese Fehler und auf alles, was kein Werkzeug findet. Bericht mit Fundstellen in Ihrem Branding, Umsetzung zum Fixpreis.

Website prüfen lassen

Sie sind ein Unternehmen? Rückruf vereinbaren

Weiterlesen

  1. Arztpraxen und Terminbuchung: Wann das Gesetz greiftMit Online-Terminbuchung wird die Praxis-Website zur Dienstleistung im elektronischen Geschäftsverkehr. Einzelordinationen sind meist als Kleinstunternehmen ausgenommen, größere Strukturen oft nicht.
  2. Das Barrierefreiheitsgesetz (BaFG) einfach erklärtSeit 28. Juni 2025 müssen Websites und Shops, über die Verbraucher Verträge schließen, in Österreich barrierefrei sein. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen anbieten.
  3. Barrierefreiheit dauerhaft halten: Warum die Pflicht nach dem Livegang weitergehtBarrierefreiheit ist kein Zustand, den man einmal erreicht. Jede neue Seite, jedes Bild und jedes Update kann neue Barrieren bringen, und das Gesetz verlangt, dass die Anforderungen dauerhaft erfüllt bleiben.

Quellen

  1. WebAIM, The WebAIM Million 2026: An annual accessibility analysis of the top 1,000,000 home pages (Februar 2026) · abgerufen am 28.10.2026
  2. W3C WAI, Understanding Success Criterion 1.4.3 Contrast (Minimum) · abgerufen am 28.10.2026
  3. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation (Nummern, Titel und Stufen der Erfolgskriterien) · abgerufen am 28.10.2026

Recherchiert mit KI-Unterstützung, mit Quellen belegt und inhaltlich geprüft von Mike Joerihsen am .

Diese Inhalte sind eine Orientierung und keine Rechtsberatung. Bei konkreten Fragen zu Ihrer Situation wenden Sie sich an eine Rechtsberatung oder die zuständige Behörde.

Lieber direkt? mike@mjoe.me · +43 680 22 12 987