Digitale Barrierefreiheit bedeutet, dass Webseiten, Apps und Software für alle Menschen nutzbar sind, auch für Menschen mit Einschränkungen. Fünf Nutzergruppen stehen dabei im Fokus: blinde, sehbeeinträchtigte, motorisch beeinträchtigte, kognitiv beeinträchtigte und auditiv beeinträchtigte Nutzer. Als internationaler Standard gelten die WCAG, die Web Content Accessibility Guidelines.
Das Wichtigste in Kürze
- Automatisierte Barrierefreiheitstests decken laut einer Studie von Deque, dem Hersteller von axe-core, rund 57 Prozent der gefundenen Barrieren ab, der Rest erfordert zwingend manuelle Prüfung durch erfahrene Tester.
- Seit Juni 2025 verpflichtet der European Accessibility Act auch Privatunternehmen zur digitalen Barrierefreiheit, spätestens 2030 gilt das für alle bestehenden Produkte.
- Barrierefreiheit früh im Entwicklungsprozess zu verankern, also im Styleguide und in der Pattern Library, verhindert teure Nachbesserungen nach einem hundertseitigen Testreport am Ende.
- Ausreichend starke Kontraste, korrekte HTML-Syntax und Tastaturbedienbarkeit sind Anforderungen, die mehreren Nutzergruppen gleichzeitig zugutekommen und die allgemeine Usability messbar verbessern.
Was digitale Barrierefreiheit konkret bedeutet
Digitale Barrierefreiheit überträgt das Prinzip der baulichen Zugänglichkeit auf Webseiten, Software und Apps. So wie eine Rampe neben der Treppe einen Rollstuhl in ein Gebäude lässt, sorgt digitale Barrierefreiheit dafür, dass ein digitales Produkt für alle Menschen nutzbar ist, auch für Menschen mit Einschränkungen.
Der Begriff ist weniger bekannt als seine bauliche Schwester, meint aber dieselbe Sache. Eine Webseite oder Anwendung soll so gebaut sein, dass sie ein blinder Nutzer ebenso bedienen kann wie jemand mit einer visuellen Einschränkung.
Wichtig ist eine Grundannahme: Menschen mit Behinderung sind keine homogene Gruppe. Ein blinder Nutzer ist nicht gleich ein anderer blinder Nutzer. Behinderungen haben verschiedene Ausprägungen, und die genutzten Hilfstechnologien unterscheiden sich.
Fünf Nutzergruppen strukturieren die Anforderungen
Für die praktische Arbeit lässt sich digitale Barrierefreiheit in fünf grobe Nutzergruppen gliedern. Diese Einteilung gibt einem Entwicklungsteam einen Rahmen, an dem es seine Anforderungen aufhängen kann.
- Blinde Nutzer: bedienen die Anwendung per Screenreader und Tastatur.
- Sehbeeinträchtigte Nutzer: brauchen unter anderem ausreichende Kontraste.
- Motorisch beeinträchtigte Nutzer: navigieren oft ohne Maus, allein per Tastatur.
- Kognitiv beeinträchtigte Nutzer: profitieren von Verständlichkeit und klarer Struktur.
- Auditiv beeinträchtigte Nutzer: brauchen Untertitel und Transkripte für Audio- und Videoinhalte.
Jede Gruppe bringt eigene Anforderungen mit. Ein Screenreader liest die Inhalte einer Seite vor, deshalb muss die Seite so programmiert sein, dass er sie wiedergeben kann. Dafür ist vor allem eine korrekte HTML-Syntax nötig.
Die Tastatur-Bedienbarkeit verbindet zwei Gruppen. Screenreader-Nutzer navigieren per Tastatur, motorisch beeinträchtigte Nutzer ebenfalls. Funktioniert eine Seite nur mit der Maus, sperrt sie beide aus.
Woher die Anforderungen kommen
Die maßgeblichen Vorgaben stehen in den Web Content Accessibility Guidelines (WCAG), dem internationalen Standard für barrierefreie digitale Anwendungen. Daneben steht die Norm EN 301 549. Wer prüfen will, ob ein Produkt zugänglich ist, misst es an diesen Kriterien.
Den Anstoß für barrierefreie Entwicklung gibt in Deutschland bislang meist das Gesetz. Öffentliche Stellen des Bundes sind seit 2021 verpflichtet, ihre digitalen Produkte barrierefrei anzubieten.
Seit Juni 2025 gilt diese Pflicht breiter. Über den European Accessibility Act, in Deutschland umgesetzt im Barrierefreiheitsstärkungsgesetz, müssen auch Privatunternehmen digitale Barrierefreiheit umsetzen. Für bestehende Produkte greift die Pflicht spätestens 2030.
Das Ziel sollte über die Pflicht hinausgehen. Barrierefreiheit als selbstverständlicher Standard, von Anfang an mitgedacht, ist die bessere Haltung als die Reaktion auf eine gesetzliche Vorgabe.
Barrierefreiheit gehört in den Prozess, nicht ans Ende
Der häufigste Fehler: die Anwendung fertig entwickeln und sie dann zum Barrierefreiheitstest geben. Das Ergebnis ist im schlimmsten Fall ein hundertseitiger Testreport, und große Teile müssen neu gebaut werden. So sollte man es nicht machen.
Der bessere Weg setzt früh an. Ein Styleguide gibt Farben und Farbkombinationen vor, und schon hier lässt sich prüfen, ob die Kontraste ausreichen. Eine Pattern Library mit Buttons, Dropdowns und Select-Elementen kann so aufgebaut sein, dass die einzelnen Komponenten bereits barrierefrei sind.
Setzen Entwickler dann diese Patterns ein, tragen sie die Barrierefreiheit von selbst weiter. Der Aufwand verteilt sich über den Prozess, statt sich am Ende zu einem unbezahlbaren Berg zu türmen.
Was sich automatisiert testen lässt, und was nicht
Testautomatisierung ist ein gutes Mittel für einen schnellen Effekt, deckt aber nur einen Teil der Kriterien ab. Eine Studie von Deque zu über 13.000 manuell und automatisiert geprüften Seiten kam darauf, dass sich etwa 57 Prozent der gefundenen Barrieren automatisiert erkennen lassen. Mehr als die Hälfte, aber eben nicht alles.
Gut automatisierbar sind Prüfungen mit klarem Soll-Wert:
- Kontrastverhältnis zwischen Schrift und Hintergrund
- Vorhandensein von Alternativtexten
- korrekte Überschriften-Hierarchie (H1, H2, H3 sauber verschachtelt)
- ob die Rolle eines Elements zum Elementtyp passt
- korrekte HTML-Syntax
An seine Grenze stößt die Automatisierung beim Sinn. Ob ein Alternativtext überhaupt vorhanden ist, lässt sich leicht prüfen. Ob der Text zum Bild passt und für einen blinden Nutzer aussagekräftig genug ist, lässt sich automatisiert kaum beurteilen. Hier braucht es den Menschen.
Eine automatisierte Testregel deckt zudem oft nur einen Teil eines WCAG-Kriteriums ab. Für die finale Bewertung bleibt das menschliche Auge nötig. Als Einstieg eignet sich ein Open-Source-Tool wie axe-core, das sich mit geringem Aufwand in die Pipeline einbinden lässt.
Die Grauzonen brauchen Erfahrung statt Messwert
Viele Anforderungen kennen kein simples Bestanden oder Nicht-Bestanden. Eine sinnvolle Lesereihenfolge oder eine einfache Navigation sind Beispiele, über die sich diskutieren lässt.
Testen zwei erfahrene Prüfer dasselbe Objekt, kann der eine eine Navigation für stimmig halten, während der andere zwei, drei Schritte tauschen würde. Das ist kein Mangel, sondern Folge der Sache. Es gibt hier keinen festen Maßstab, der sagt: bis hierher reicht es.
Der Grund liegt in der Vielfalt der Nutzer. Was für den einen einfach ist, empfindet der andere als umständlich. Eine Anwendung jedem einzelnen Nutzer zu hundert Prozent recht zu machen, ist nicht möglich.
Echte Nutzer ersetzt kein Tester
Bei der Usability führt kein Weg an den Betroffenen vorbei. Screenreader-Nutzer sind die Profis im Umgang mit ihrem Werkzeug. Ein Screenreader ist mächtig, und alle Bedienmöglichkeiten sicher zu beherrschen, erfordert eine umfangreiche Ausbildung.
Tester können grobe Probleme erkennen und vieles vorab bewerten. Geht es aber um die tatsächliche Bedienbarkeit, lohnt es sich, einen blinden Nutzer einzubeziehen und konkret zu fragen: Funktioniert das so, oder wäre es anders besser? So entsteht die tragfähigste Lösung.
Tests folgen dem klassischen Muster
Barrierefreiheitstests lassen sich auswerten wie ein fachlicher Test. Die Anforderungen aus WCAG und EN 301 549 werden in Testfälle übersetzt, die sich durchführen und als bestanden oder nicht bestanden bewerten lassen.
Wo ein Testfall durchfällt, ist eine Barriere vorhanden. Diese wird dokumentiert und am Ende in einem Testbericht zusammengefasst. Die einzige Besonderheit sind die genannten Grautöne: Steht im Testfall die Frage nach einer sinnvollen Lesereihenfolge, entscheidet das Urteil des Testers.
Barrierefreiheit ist ein Wettbewerbsvorteil, nicht nur Pflicht
Teams begegnen dem Thema oft mit dem Gefühl, eine lästige Pflicht abzuarbeiten. Es kostet Budget, Zeit und Mitarbeiterkraft, und Mitarbeiter müssen sich erst einarbeiten. Die Argumente dagegen liegen jedoch in den Vorteilen.
Barrierefreiheit erhöht die allgemeine Usability. Das Kontrast-Beispiel zeigt es gut: Einen Text mit ausreichendem Kontrast liest jeder leichter und schneller als einen, bei dem man die Augen zusammenkneifen muss.
Jeder von uns liest einen Text mit ausreichendem Kontrast deutlich einfacher, leichter und lieber als einen, bei dem man die Augen zusammenkneifen muss, um gerade so zu lesen, was da steht.
Myria Pflaum
Die weiteren Vorteile reichen über die einzelne Nutzergruppe hinaus:
- Mehr erreichte Nutzer und damit am Ende mehr Umsatz.
- Positives Image, weil ein Unternehmen alle Nutzer einlädt, die Anwendung zu verwenden.
- Bessere Suchmaschinenoptimierung als Nebeneffekt zugänglicher Inhalte.
- Zugang zu Ausschreibungen: Öffentliche Stellen müssen barrierefreie Produkte anbieten und sind verpflichtet, dies auch bei eingekaufter Software zu fordern. Wer schon ein barrierefreies Produkt hat, kann direkt mitbieten und hat höhere Chancen.
Wo du anfängst, wenn alles zu viel wirkt
Die WCAG ist umfangreich. Mit der WCAG 2.2 sind es 86 Erfolgskriterien, jeweils ausführlich beschrieben. Alles auf einmal durchzulesen, erschlägt mehr, als es hilft. Es gibt leichtere Einstiege.
Ein Stichprobentest verschafft ein erstes Gefühl für den Stand. Bei einem großen Webauftritt lässt man zwei, drei Seiten von Experten durchtesten. Der Aufwand ist überschaubar, und die Grundprobleme sind schnell identifiziert und behebbar.
Parallel hilft der interne Einstieg über automatisierte Tests. Sie decken zwar nicht alles ab, geben aber ein erstes Feedback. Sind die automatisiert erkennbaren Barrieren einmal behoben, ist ein guter Schritt in die richtige Richtung getan.
Der dritte Baustein ist die Schulung: Entwickler, Designer und Tester nach und nach befähigen, damit sie wissen, was barrierefreie Umsetzung verlangt. So wandert das Thema langsam in den normalen Entwicklungsprozess.
Wohin sich das Feld bewegt
Zwei Entwicklungen prägen die nächsten Jahre. Der European Accessibility Act greift seit Juni 2025 für Neuentwicklungen und spätestens 2030 für bestehende Produkte. Das schärft das Bewusstsein und dürfte auch die Privatwirtschaft erreichen, die den Wettbewerbsvorteil erkennt, sobald Gebrauchstauglichkeit und Sichtbarkeit messbar besser werden.
Die zweite Bewegung kommt aus der KI. Sie könnte mehr Erfolgskriterien automatisiert prüfbar machen und bestehende besser interpretieren. Das Alternativtext-Beispiel zeigt die Richtung: Eine KI könnte künftig beurteilen, ob ein Text zum Bild passt, ohne dass ein manueller Test darüberlaufen muss.
Häufig gestellte Fragen
Warum genügt es nicht, digitale Barrierefreiheit an einer einzelnen Behinderungsart auszurichten?
Menschen mit Behinderung sind keine homogene Gruppe: Behinderungen haben verschiedene Ausprägungen, und die genutzten Hilfstechnologien unterscheiden sich. Für die Praxis hilft die Gliederung in fünf Nutzergruppen: blinde, sehbeeinträchtigte, motorisch, kognitiv und auditiv beeinträchtigte Nutzer. Manche Anforderungen wirken gruppenübergreifend. Tastaturbedienbarkeit betrifft Screenreader-Nutzer und motorisch beeinträchtigte Nutzer gleichzeitig. Funktioniert eine Seite nur mit der Maus, sperrt sie beide aus.
Wer ist in Deutschland gesetzlich zur digitalen Barrierefreiheit verpflichtet?
Öffentliche Stellen des Bundes müssen ihre digitalen Produkte seit 2021 barrierefrei anbieten. Seit Juni 2025 erfasst der European Accessibility Act, in Deutschland umgesetzt im Barrierefreiheitsstärkungsgesetz, auch Privatunternehmen. Für bereits bestehende Produkte greift die Pflicht spätestens 2030. Der Anstoß für barrierefreie Entwicklung kommt damit meist vom Gesetz, obwohl Barrierefreiheit als selbstverständlicher Standard die bessere Haltung wäre.
Reichen automatisierte Tests aus, um digitale Barrierefreiheit nachzuweisen?
Nein. Eine Studie von Deque zu über 13.000 manuell und automatisiert geprüften Seiten kam darauf, dass sich etwa 57 Prozent der gefundenen Barrieren automatisiert erkennen lassen. Gut messbar sind Prüfungen mit klarem Soll-Wert: Kontrastverhältnis, Vorhandensein von Alternativtexten, Überschriften-Hierarchie, korrekte HTML-Syntax. Ob ein Alternativtext inhaltlich zum Bild passt und für einen blinden Nutzer aussagekräftig ist, beurteilt die Automatisierung kaum.
Wann im Entwicklungsprozess sollte Barrierefreiheit berücksichtigt werden?
So früh wie möglich. Der häufigste Fehler ist, die Anwendung fertig zu entwickeln und sie erst dann zum Barrierefreiheitstest zu geben. Am Ende steht im schlimmsten Fall ein hundertseitiger Testreport, und große Teile müssen neu gebaut werden. Besser: im Styleguide Farbkombinationen auf ausreichende Kontraste prüfen und eine Pattern Library aufbauen, deren Buttons, Dropdowns und Select-Elemente bereits barrierefrei sind.
Warum bewerten zwei erfahrene Prüfer dieselbe Anwendung unterschiedlich?
Viele Anforderungen kennen kein simples Bestanden oder Nicht-Bestanden. Eine sinnvolle Lesereihenfolge oder eine einfache Navigation sind Beispiele, über die sich diskutieren lässt: Der eine Prüfer hält eine Navigation für stimmig, der andere würde zwei, drei Schritte tauschen. Das ist kein Mangel der Methode, sondern folgt aus der Vielfalt der Nutzer. Einen festen Maßstab gibt es hier nicht.
Können erfahrene Tester die Einbeziehung betroffener Nutzer ersetzen?
Nein, bei der Usability nicht. Screenreader-Nutzer sind die Profis im Umgang mit ihrem Werkzeug, denn alle Bedienmöglichkeiten sicher zu beherrschen, erfordert eine umfangreiche Ausbildung. Tester erkennen grobe Probleme und können vieles vorab bewerten. Geht es um die tatsächliche Bedienbarkeit, lohnt die konkrete Rückfrage an einen blinden Nutzer: Funktioniert das so, oder wäre es anders besser?
Welchen Nutzen hat Barrierefreiheit jenseits der gesetzlichen Pflicht?
Sie erhöht die allgemeine Usability: Einen Text mit ausreichendem Kontrast liest jeder leichter als einen, bei dem man die Augen zusammenkneift. Dazu kommen mehr erreichte Nutzer und damit Umsatz, ein positives Image, bessere Suchmaschinenoptimierung als Nebeneffekt und der Zugang zu Ausschreibungen. Öffentliche Stellen müssen Barrierefreiheit auch bei eingekaufter Software fordern, wer sie schon bietet, kann direkt mitbieten.
Womit fängt ein Team an, das noch keine Erfahrung mit Barrierefreiheit hat?
Nicht mit dem vollständigen Durchlesen der WCAG: Die WCAG 2.2 umfasst 86 ausführlich beschriebene Erfolgskriterien. Sinnvoller sind drei Bausteine. Ein Stichprobentest, bei dem Experten zwei, drei Seiten eines großen Webauftritts prüfen, macht die Grundprobleme schnell sichtbar. Automatisierte Tests geben intern ein erstes Feedback. Schulungen befähigen Entwickler, Designer und Tester nach und nach.
