Barrierefreiheit auf Websites scheitert selten an bösem Willen, sondern an Lücken, die niemand sieht. Ein Erfahrungsbericht der US-Agentur Infinity Interactive zeigt, wie erst die Zusammenarbeit mit einer blinden Kundin die versteckten Schwachstellen einer Microsoft-Plattform sichtbar machte. Für Website-Betreiber im DACH-Raum ist das Thema seit dem Barrierefreiheitsstärkungsgesetz keine Kür mehr, sondern Pflicht mit Bußgeldrisiko.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenEin Entwickler von Infinity Interactive sollte einen Genehmigungs-Workflow in Microsoft Power Automate bauen. Die Kundin hatte Barrierefreiheit vertraglich festgeschrieben, ihre interne Fachfrau prüfte selbst mit dem Screenreader, weil sie blind ist und den Workflow später täglich nutzen würde. Aus der geplanten kurzen Abnahme wurden 18 Stunden Arbeit.
Das Wichtigste in Kürze
- Automatische Prüftools bestehen zwar den Struktur-Check, übersehen aber praktische Screenreader-Fallen wie doppelte H1-Überschriften oder redundante Feld-Labels.
- Erst echte Nutzerinnen mit Behinderung deckten auf, dass Microsofts Genehmigungs-App in Teams von Screenreadern gar nicht erkannt wurde.
- Das Barrierefreiheitsstärkungsgesetz verpflichtet seit dem 28. Juni 2025 viele Unternehmen zu barrierefreien Websites, Prüfmaßstab sind EN 301 549 und WCAG 2.1 auf Stufe AA.
- Bei Verstößen drohen Abmahnungen, Vertriebsverbote und Bußgelder bis zu 100.000 €.
Welche Barrierefreiheits-Lücken bleiben unsichtbar?
Unsichtbar bleiben genau die Fehler, die sehende Menschen unbewusst wegfiltern: doppelte H1-Überschriften, redundante Feld-Labels und Bedienelemente, die ein Screenreader schlicht nicht vorliest.
Im geschilderten Projekt hängte SharePoint an jedes Feld einer Tracking-Seite den Zusatz „(schreibgeschützt)“. Sehende Nutzer überlesen das, für die blinde Prüferin las der Screenreader die Floskel bei jedem Sprung vor. „Jedes überflüssige Wort ist etwas, das Sie durchhören müssen, bevor Sie zu dem kommen, was Sie eigentlich suchen“, schrieb der Entwickler. Dazu standen mehrere H1-Überschriften auf einer einzigen SharePoint-Seite und zerstörten so die Orientierungspunkte, an denen sich Screenreader entlanghangeln.
Noch gravierender war der Ausfall ganzer Funktionen. Die browserbasierten Power-Automate-Apps harmonierten schlecht mit Screenreadern, die native Genehmigungs-App in Teams wurde von der Software überhaupt nicht erkannt. Als Notlösung blieb ein Umweg über vier bis fünf E-Mails pro Vorgang.
Diese Fehler bestehen den Tool-Check und scheitern in der Praxis
Mehrere H1-Überschriften auf einer Seite zerstören die Screenreader-NavigationRedundante Feld-Labels wie „(schreibgeschützt)“ verlängern jede BedienungNative Bedien-Apps werden vom Screenreader gar nicht erkanntTechnisch valide ARIA-Rollen, die Elemente stummschaltenWarum übersehen automatische Tests diese Fehler?
Automatische Prüftools messen Struktur, nicht Erlebnis: Sie erkennen ein fehlendes Alt-Attribut oder falschen Kontrast, aber nicht, ob eine korrekt ausgezeichnete Seite tatsächlich bedienbar ist.
Ein Tool bestätigt, dass ein Bild ein Alt-Attribut trägt. Ob der hinterlegte Text den Inhalt sinnvoll beschreibt, entzieht sich der Prüfung. Genauso passieren technisch valide ARIA-Rollen den Check, selbst wenn sie eine Schaltfläche für den Screenreader stummschalten. Fokus-Reihenfolge, verschachtelte Landmarken und vorgelesene Reihenfolge lassen sich maschinell kaum bewerten.
Der Kern des Problems liegt in der Testpraxis: Software wird überwiegend von Menschen gebaut und geprüft, die sehen und hören. „Das Internet, das ich kenne, ist für jemanden, der es über einen Screenreader erlebt, ein fast völlig anderer Ort“, so der Entwickler. Die Lücken bleiben verborgen, bis jemand auftaucht, der sie täglich erlebt.
Barrierefreiheit ist kein Häkchen für die Compliance-Liste, sondern eine Designentscheidung. Betroffene früh einzubinden kostet Stunden, ein späterer Umbau kostet Vertrauen und im Zweifel fünfstellige Bußgelder.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet das BFSG konkret für Website-Betreiber?
Seit dem 28. Juni 2025 müssen viele Unternehmen ihre Websites, Onlineshops und Apps barrierefrei gestalten. Prüfmaßstab sind die EN 301 549 und die WCAG 2.1 auf Konformitätsstufe AA.
Betroffen sind vor allem Anbieter im Endkundengeschäft, etwa Onlineshops sowie Buchungs- und Bankdienste. Eine Ausnahme greift für Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen € Jahresumsatz, allerdings nur bei Dienstleistungen, nicht bei allen Produkten. Bleibt Ihr Fall unklar, lassen Sie ihn rechtlich prüfen, statt sich auf die Ausnahme zu verlassen.
Für die Praxis heißt das: Setzen Sie auf semantisches HTML mit genau einer H1 pro Seite, testen Sie mit echten Screenreadern wie NVDA oder JAWS und beziehen Sie Menschen mit Behinderung in die Abnahme ein. Verlassen Sie sich nie allein auf ein Prüftool. Wie unterschiedlich Browser und Hilfstechnik dabei zusammenspielen, zeigt der Blick auf die gängigen Programme im Unternehmenseinsatz.
Mehr Newshunger?
- Was geht verloren, wenn kleine Web-Foren verschwinden?
- Bewegtbild im B2B-Marketing: echter Film schlägt KI-Clip
- AI-Commerce: Wie sich die Otto Group auf KI-Suche einstellt
- US-Supreme-Court stärkt Datenschutz bei Standortdaten
- PeerTube als YouTube-Alternative: Was bringt Föderation?
- Browser-Vergleich für Unternehmen im DACH-Raum
