Barrierefreiheit als Geschäftsentscheidung

Der European Accessibility Act (EAA) ist seit dem 28. Juni 2025 in allen EU-Mitgliedstaaten geltendes Recht. Er verpflichtet Unternehmen, ihre digitalen Produkte und Dienstleistungen für Menschen mit Behinderungen zugänglich zu gestalten.

Der Geltungsbereich ist breit:

• E-Commerce: Online-Shops müssen vollständig per Tastatur bedienbar sein, Produktinformationen maschinenlesbar bereitstellen und barrierefreie Bezahlprozesse anbieten
• Finanzdienstleistungen: Online-Banking, Versicherungsportale und Anlagetools fallen unter die Regelung
• Kommunikationsdienste: Messenger, Videokonferenz-Tools und E-Mail-Plattformen müssen zugänglich sein
• Transportdienstleistungen: Buchungsplattformen, Fahrplaninformationen und Check-in-Systeme sind betroffen
• E-Books und digitale Medien: Inhalte müssen in zugänglichen Formaten bereitgestellt werden

Der technische Referenzstandard ist die EN 301 549, die inhaltlich auf den Web Content Accessibility Guidelines (WCAG) 2.1 aufbaut. In der Praxis orientieren sich die meisten Unternehmen bereits an WCAG 2.2, da dieser Standard aktueller und umfassender ist.

Verstösse sind keine Kavaliersdelikte. Die nationale Umsetzung sieht Marktüberwachungsbehörden, Beschwerdeverfahren und Sanktionen vor. Unternehmen, die den EAA ignorieren, riskieren neben Bussgeldern auch Abmahnungen und Reputationsschäden.

Die Web Content Accessibility Guidelines definieren vier Prinzipien, die jede barrierefreie Anwendung erfüllen muss: wahrnehmbar, bedienbar, verständlich und robust. Hinter diesen Prinzipien stehen konkrete, testbare Erfolgskriterien.

Wahrnehmbar

Alle Inhalte müssen auch ohne einen bestimmten Sinneskanal zugänglich sein. Bilder benötigen Alternativtexte, Videos Untertitel und Audiodeskriptionen. Texte müssen ausreichenden Kontrast zum Hintergrund aufweisen – mindestens 4.5:1 für normalen Text, 3:1 für grossen Text.

Bedienbar

Jede Funktion muss per Tastatur erreichbar sein. Fokusreihenfolge und Fokusindikator müssen sichtbar und logisch sein. Zeitlimits müssen verlängerbar sein. Animationen müssen pausierbar sein. Neue WCAG-2.2-Kriterien wie Minimum Target Size stellen sicher, dass interaktive Elemente gross genug für motorisch eingeschränkte Nutzer sind.

Verständlich

Formulare brauchen beschriftete Felder, verständliche Fehlermeldungen und Korrekturvorschläge. Navigation muss konsistent sein. Fachbegriffe müssen erklärt werden.

Robust

Der Code muss so geschrieben sein, dass assistive Technologien – Screenreader, Braillezeilen, Sprachsteuerung – ihn korrekt interpretieren können. Semantisches HTML, korrekte ARIA-Attribute und valider Code sind die Grundlage.

WCAG definiert drei Konformitätsstufen: A, AA und AAA. Stufe AA ist der Standard, den der EAA faktisch voraussetzt. Stufe AAA ist in den meisten Fällen weder erforderlich noch vollständig umsetzbar, kann aber für einzelne Kriterien sinnvoll sein.

Die meisten Barrierefreiheits-Defizite fallen in eine überschaubare Anzahl von Kategorien. Wer diese systematisch adressiert, beseitigt den Grossteil der Probleme:

Fehlende oder unzureichende Alternativtexte: Bilder ohne Alt-Attribut sind für Screenreader-Nutzer unsichtbar. Dekorative Bilder, die keinen Alt-Text benötigen, müssen explizit als solche gekennzeichnet werden (leeres Alt-Attribut oder role="presentation").

Mangelhafter Farbkontrast: Heller Text auf hellem Hintergrund, subtile Grautöne für wichtige Informationen, farbcodierte Statusanzeigen ohne textuelle Alternative – diese Muster schliessen Menschen mit Sehbeeinträchtigungen systematisch aus.

Nicht-tastaturzugängliche Interaktionen: Custom-Dropdowns, Slider, Modals und Drag-and-Drop-Interfaces, die nur per Maus bedienbar sind, sind für Tastaturnutzer und Screenreader unzugänglich. Jede Interaktion, die per Maus möglich ist, muss auch per Tastatur erreichbar sein.

Fehlende Formularvalidierung: Fehlermeldungen, die nur durch Farbe signalisiert werden, Pflichtfelder ohne Kennzeichnung und Validierungsfeedback, das nicht programmatisch mit dem Eingabefeld verknüpft ist, machen Formulare für assistive Technologien unbrauchbar.

Fehlende Seitenstruktur: Überschriftenhierarchien, die Ebenen überspringen, fehlende Landmarks und undifferenzierte div-Strukturen machen es Screenreader-Nutzern unmöglich, sich auf der Seite zu orientieren.

Dynamische Inhalte ohne ARIA-Live-Regions: Wenn ein Ajax-Request neue Inhalte auf die Seite lädt, bekommt ein Screenreader-Nutzer davon nichts mit – es sei denn, die Region ist als aria-live markiert.

Diese Barrieren sind nicht das Ergebnis bewusster Entscheidungen. Sie entstehen, weil Barrierefreiheit im Entwicklungsprozess nicht systematisch berücksichtigt wird.

Barrierefreiheit nachträglich in ein fertiges Produkt einzubauen, ist teuer und frustrierend. Der effiziente Weg ist, Accessibility von Anfang an als Qualitätskriterium zu behandeln – gleichwertig mit Performance, Sicherheit und funktionaler Korrektheit.

Design: Barrierefreiheit beginnt im Design, nicht im Code. Farbpaletten werden auf ausreichenden Kontrast geprüft. Interaktionsmuster werden auf Tastaturbedienbarkeit entworfen. Informationen werden nicht ausschliesslich über Farbe, Form oder Position vermittelt. Design Systems integrieren Accessibility-Anforderungen in jede Komponente.

Entwicklung: Semantisches HTML bildet die Grundlage. Wer ein Navigationsmenü als nav-Element statt als div implementiert, spart sich nachträgliche ARIA-Attribute. Automatisierte Accessibility-Linting-Regeln in der IDE fangen einfache Fehler beim Schreiben ab, nicht erst im Review.

Testing: Automatisierte Tools wie axe-core oder Lighthouse erkennen rund 30 Prozent aller Accessibility-Probleme zuverlässig. Die restlichen 70 Prozent erfordern manuelle Tests: Kann die Seite vollständig per Tastatur bedient werden? Sind alle Informationen im Screenreader zugänglich? Ist die Reihenfolge logisch?

Code Review: Accessibility wird Teil der Review-Checkliste. Jeder Pull Request wird auf semantisches HTML, korrekte ARIA-Attribute und Tastaturbedienbarkeit geprüft. Nicht als zusätzlicher Aufwand, sondern als Teil der Definition of Done.

CI/CD: Automatisierte Accessibility-Tests laufen in der Pipeline. Ein Kontrastverstoss oder ein fehlendes Alt-Attribut bricht den Build – genau wie ein fehlschlagender Unit Test.

Der Mehraufwand für barrierefreie Entwicklung liegt bei geschätzten 5 bis 10 Prozent der Entwicklungszeit – wenn Accessibility von Beginn an berücksichtigt wird. Nachträgliche Sanierung kann ein Vielfaches kosten.

Automatisierte Tests und manuelle Prüfungen durch das Entwicklungsteam decken die technische Konformität ab. Ob eine Anwendung tatsächlich nutzbar ist, zeigt sich erst im Test mit Menschen, die auf assistive Technologien angewiesen sind.

Screenreader-Tests: Ein sehender Entwickler, der einen Screenreader einschaltet, prüft die technische Korrektheit. Ein blinder Nutzer, der täglich mit einem Screenreader arbeitet, prüft die tatsächliche Nutzbarkeit. Der Unterschied ist erheblich. Erfahrene Screenreader-Nutzer navigieren anders, nutzen andere Shortcuts und stossen auf Probleme, die ein sehender Tester nicht bemerkt.

Kognitive Zugänglichkeit: Menschen mit Lernschwierigkeiten oder kognitiven Einschränkungen bewerten, ob Texte verständlich, Abläufe nachvollziehbar und Fehlermeldungen hilfreich sind. Diese Dimension der Barrierefreiheit wird in technischen Audits regelmässig übersehen.

Motorische Tests: Nutzer mit eingeschränkter Feinmotorik testen, ob Schaltflächen gross genug sind, ob Drag-and-Drop-Alternativen funktionieren und ob Zeitlimits ausreichend bemessen sind.

Der Aufwand für Nutzertests mit Betroffenen ist überschaubar. Fünf bis acht Testpersonen mit unterschiedlichen Einschränkungen decken den Grossteil der relevanten Nutzungsszenarien ab. Organisationen wie die Stiftung Pfennigparade, der DBSV oder Appt Foundation vermitteln erfahrene Tester.

Entscheidend ist, dass diese Tests nicht einmalig stattfinden, sondern in den Release-Zyklus integriert werden. Barrierefreiheit ist kein Zustand, den man erreicht und dann abhakt. Sie ist ein Qualitätsmerkmal, das bei jeder Änderung erneut validiert werden muss.

Barrierefreiheit wird in vielen Organisationen als Kostenfaktor wahrgenommen. Die Datenlage zeichnet ein anderes Bild.

Marktgrösse: In der EU leben 87 Millionen Menschen mit einer Behinderung. Weltweit sind es 1,3 Milliarden. Mit alternder Bevölkerung wächst diese Zahl kontinuierlich. Wer diese Nutzer durch unzugängliche Produkte ausschliesst, verzichtet auf einen erheblichen Marktanteil.

SEO-Effekte: Barrierefreie Websites werden von Suchmaschinen besser indexiert. Semantisches HTML, strukturierte Überschriften, Alternativtexte und schnelle Ladezeiten sind gleichzeitig Ranking-Faktoren. Unternehmen, die in Barrierefreiheit investieren, verbessern häufig auch ihre Suchsichtbarkeit.

Support-Reduktion: Klare Formulare, verständliche Fehlermeldungen und konsistente Navigation reduzieren Support-Anfragen – nicht nur von Nutzern mit Behinderungen, sondern von allen Nutzern. Die Curb-Cut-Analogie gilt: Bordsteinabsenkungen wurden für Rollstuhlfahrer gebaut, genutzt werden sie von Eltern mit Kinderwagen, Lieferanten mit Rollwagen und Reisenden mit Koffer.

Rechtsrisiko-Minimierung: In den USA sind ADA-Klagen gegen nicht-barrierefreie Websites in den letzten fünf Jahren um über 300 Prozent gestiegen. Der EAA wird einen ähnlichen Effekt in Europa haben. Die Kosten einer nachträglichen Sanierung unter Zeitdruck übersteigen die einer vorausschauenden Integration bei Weitem.

Employer Branding: Unternehmen, die Barrierefreiheit ernst nehmen, signalisieren Inklusivität – gegenüber Kunden, Partnern und potenziellen Mitarbeitern. In einem Arbeitsmarkt, in dem Fachkräfte ihre Arbeitgeber wählen können, ist das ein relevanter Faktor.

Barrierefreiheit ist keine Sondermassnahme für eine Minderheit. Sie ist gutes Produktdesign, das zufällig auch regulatorisch vorgeschrieben ist.