Es gibt Aussagen, die mir im Beratungsalltag immer wieder begegnen. Mal aus Unwissen, mal aus Bequemlichkeit, mal weil jemand sie irgendwo gelesen hat und sie seither für wahr hält. Ich habe nichts gegen Fehler – Fehler sind Ausgangspunkte. Aber manche dieser Annahmen blockieren Projekte, bevor sie richtig angefangen haben.

Hier sind fünf davon – und warum sie nicht stimmen.

Mythos 1: „Barrierefreiheit ist nur für Blinde”

Das ist die häufigste Vereinfachung. Und sie führt dazu, dass Teams Barrierefreiheit auf Screenreader-Unterstützung reduzieren – und dann überrascht sind, wenn das nicht reicht.

Digitale Barrierefreiheit umfasst ein breites Spektrum an Behinderungen und Einschränkungen:

  • Motorisch: Nutzer, die keine Maus verwenden können und auf Tastaturnavigation, Switch-Access oder Sprachsteuerung angewiesen sind
  • Kognitiv: Menschen mit Lernschwächen, ADHS oder Gedächtnisproblemen, die klare Strukturen, einfache Sprache und konsistente Interfaces brauchen
  • Auditiv: Gehörlose oder schwerhörige Nutzer, für die Videos ohne Untertitel unzugänglich sind
  • Situativ: Jeder, der gerade ein gebrochenes Handgelenk hat, sein Gerät in der Sonne benutzt oder in einem lauten Umfeld unterwegs ist

Nach der sogenannten 10-30-100-Regel sind bis zu 10 % der Bevölkerung dauerhaft beeinträchtigt, 30 % temporär – und 100 % profitieren von zugänglichem Design. Wer Barrierefreiheit nur als Nischenthema betrachtet, übersieht die Mehrheit.

Mythos 2: „Automatische Tests reichen aus”

Tools wie axe, WAVE oder Lighthouse sind nützlich. Sie finden echte Probleme schnell und zuverlässig. Aber sie haben eine klare Grenze: Sie finden nur das, was sich automatisch prüfen lässt.

Studien – unter anderem von WebAIM – zeigen konsistent, dass automatisierte Tests nur zwischen 20 und 30 % aller WCAG-Verstöße aufdecken. Was sie nicht können:

  • Beurteilen, ob ein Alt-Text sinnvoll ist oder nur formal vorhanden
  • Prüfen, ob die Fokus-Reihenfolge logisch ist
  • Feststellen, ob ein Formular tatsächlich per Tastatur bedienbar ist
  • Testen, wie sich ein Screenreader auf einer dynamisch geladenen Seite verhält

Automatisch + manuell = notwendig

Automatisierte Tests sind ein guter Einstieg und ein sinnvoller Teil der CI/CD-Pipeline. Sie sind kein Ersatz für manuelle Tests und Tests mit echten Nutzerinnen und Nutzern. Beides braucht es.

Wer nur automatisch testet, hat eine technische Mindestabsicherung. Wer daraus schließt, die Seite sei barrierefrei, liegt falsch.

Mythos 3: „Barrierefreiheit macht Seiten hässlich”

Das Gegenteil ist wahr – wenn man es richtig macht.

Guter Kontrast verbessert die Lesbarkeit für alle. Klare Überschriftenstrukturen erleichtern die Navigation – auch für Nutzer ohne Behinderung, die schnell scannen. Logische Fokus-Reihenfolge macht Formulare benutzerfreundlicher. Verständliche Fehlermeldungen sind besser für alle.

Die Annahme, dass Barrierefreiheit auf Kosten des Designs geht, stammt meist aus Projekten, in denen Barrierefreiheit als Nacharbeit behandelt wurde – und dann tatsächlich als Einschränkung erlebt wird. Wer das Thema von Anfang an mitdenkt, merkt schnell: Die meisten Anforderungen sind einfach gutes Design.

Ein konkretes Beispiel: Das Mindestverhältnis von 4,5:1 zwischen Textfarbe und Hintergrund (WCAG 1.4.3) klingt nach Einschränkung. In der Praxis bedeutet es meistens, dass der Text gut lesbar ist – auch auf günstigen Displays, bei schlechtem Licht und für ältere Nutzer.

Mythos 4: „Das kostet uns zu viel”

Barrierefreiheit ist am teuersten, wenn sie nachträglich kommt. Das ist das eigentliche Problem – nicht das Thema selbst.

Ein Audit, der nach einem Relaunch durchgeführt wird, findet Probleme, die strukturell verankert sind: Komponenten ohne Tastaturunterstützung, ein Design-System ohne Kontrasttokens, Formulare ohne semantische Labels. Diese Probleme zu beheben kostet mehr als sie von Anfang an richtig zu bauen.

Barrierefreiheit im Prozess dagegen – in den Design-Entscheidungen, in den Entwicklungsstandards, in der Redaktionsschulung – ist ein einmaliger Aufwand, der sich amortisiert. Und: Seit dem 28. Juni 2025 ist das für viele Unternehmen keine freiwillige Entscheidung mehr, sondern durch das BFSG gesetzlich vorgeschrieben.

Die teure Alternative

Wer Barrierefreiheit aufschiebt, zahlt später mehr – in Entwicklungszeit, in Nachbesserungskosten und im Zweifel in rechtlichen Auseinandersetzungen. Das BFSG sieht für Verstöße Bußgelder vor; erste Klagen in Deutschland laufen bereits.

Mythos 5: „Ein Overlay reicht aus”

Dieser Mythos hat einen eigenen Artikel verdient – und er existiert bereits. Aber der Kern lässt sich in einem Satz zusammenfassen:

Kein automatisches Skript kann strukturelle Barrierefreiheitsprobleme lösen, weil es nicht das Fundament des Codes verändern kann. Ein Overlay kann in manchen Fällen einzelne Symptome lindern. Es kann keine Barrierefreiheit herstellen – und in einigen Fällen verschlechtert es die Nutzungserfahrung aktiv.

Wichtig: Die Nutzung eines Overlays entbindet auch rechtlich nicht von der Pflicht zur Barrierefreiheit. Das haben Gerichte in mehreren Ländern bereits bestätigt.

Was wirklich stimmt

Barrierefreiheit ist kein Add-on und keine Pflichtübung. Es ist eine Designentscheidung – über Inklusion, über Qualität und darüber, für wen ein Produkt gebaut wird.

Die gute Nachricht: Die meisten Anforderungen sind keine Raketenwissenschaft. Semantisches HTML, ordentliche Farbkontraste, sinnvolle Überschriften, Tastaturunterstützung – das sind keine Sonderwünsche. Das ist die Basis guter Frontend-Entwicklung.

Wer das früh im Prozess verankert, hat weniger Aufwand, bessere Produkte und ist gesetzlich auf der richteren Seite. Der Rest ist Übung.