Barrierefreiheit - Vorbereitung auf 2025

Digitale Barrierefreiheit bedeutet, dass Websites und digitale Produkte unabhängig von Einschränkungen oder Behinderungen einfach und unkompliziert nutzbar sind. Ab dem 28. Juli 2025 verpflichtet das deutsche Barrierefreiheitsstärkungsgesetz (BFSG) private Unternehmen zur Einhaltung dieser Standards im B2C-Bereich. Verstöße können Strafzahlungen bis 100.000 Euro, Vertriebsverbote oder Produktrückrufe nach sich ziehen.

Das Wichtigste in Kürze

• Ab dem 28. Juli 2025 müssen private Unternehmen in Deutschland erstmals Barrierefreiheitsstandards einhalten, bei Verstößen drohen Strafzahlungen bis 100.000 Euro sowie Vertriebsverbote und Produktrückrufe.
• Barrierefreiheits-Normen wie die WCAG sind als Prüfkriterien für Tester formuliert, nicht als Handlungsanweisungen für Designer und Entwickler, was deren Umsetzung im Alltag unnötig erschwert.
• Wer Barrierefreiheit erst nach Fertigstellung einer Website prüft und nachbessert, zahlt deutlich mehr, weil Korrekturen im Nachhinein oft einen kompletten Neuaufbau erfordern.
• Barrierefreiheit ist keine reine Entwickleraufgabe: Tastaturnavigation etwa braucht zuerst eine Budget-Entscheidung des Product Owners, dann eine Navigationsstruktur vom UX-Designer und erst dann die Implementierung durch den Entwickler.
• Zu den häufigsten und schnell umsetzbaren Anforderungen gehören ausreichende Farbkontraste, Tastatursteuerung, Alternativtexte für Grafiken und Untertitel für Videos.

Was das BFSG ab 2025 von Unternehmen verlangt

Ab dem 28. Juni 2025 müssen erstmals auch viele private Unternehmen in Deutschland Barrierefreiheitsstandards einhalten. Grundlage ist das Barrierefreiheitsstärkungsgesetz, kurz BFSG. Bis dahin galten solche Vorgaben in Deutschland nicht für die Privatwirtschaft, weshalb viele Firmen das Thema noch nicht auf dem Schirm haben.

Die Konsequenzen bei Nichteinhaltung sind kein Randrisiko. Es drohen Strafzahlungen bis zu 100.000 Euro, Vertriebsverbote und der Rückruf von Produkten und Dienstleistungen.

Betroffen ist vor allem der elektronische Geschäftsverkehr, also alles, wo Geld fließt und Endkunden im Spiel sind. Der Fokus liegt auf B2C, nicht auf B2B. Darunter fallen nicht nur Webseiten, sondern auch E-Books, Fahrkartenautomaten, Parkautomaten und die Software, die solche Geräte steuert.

Was Barrierefreiheit konkret bedeutet

Barrierefreiheit heißt, dass eine Website oder ein digitales Produkt einfach und unkompliziert zu benutzen sein muss, unabhängig davon, welche Einschränkung oder Behinderung jemand hat. Das ist das Grundprinzip.

Eine typische Barriere ist sehr kleiner Text auf einer Webseite. Wer Sehschwierigkeiten hat, kann ihn nicht gut lesen, und damit ist die Seite nicht mehr barrierefrei. Vergleichbar wirken zu schwache Farbkontraste oder Inhalte, die sich nur mit der Maus bedienen lassen.

Zu den gängigsten Anforderungen zählen mehrere konkrete Punkte:

• Bedienbarkeit per Tastatur und per Screenreader, damit auch blinde Menschen navigieren können
• ausreichend hohe Farbkontraste für Menschen mit Farbfehlsichtigkeit oder Sehschwäche
• eine Textgröße, die groß genug zum Lesen ist
• Untertitel und Alternativtexte für alles, was nicht Text ist, also Videos und Grafiken
• die Möglichkeit, Videos anzuhalten

Für Inhalte, die keine textuelle Alternative bekommen können, gibt es Ausnahmen. Diese müssen aber gesondert deklariert werden, damit ein Screenreader weiß, wie er damit umgehen soll.

Warum Prüfkriterien Entwickler und Designer im Stich lassen

Die maßgeblichen Standards sind als Prüfkriterien formuliert, und genau das ist das Problem für alle, die Barrierefreiheit umsetzen müssen. Erfolgs- und Prüfkriterien helfen Testern. Sie sagen aber Designern und Entwicklern nicht, welche Aufgaben sie zu erledigen haben.

Relevant sind vor allem die WCAG-Kriterien, dazu die europäische Norm EN 301549 und eine ISO-Norm, die in Deutschland nicht gesetzlich bindend ist, in UK aber schon. Zusammen ergeben sie Hunderte von Kriterien, verteilt über Hunderte Seiten.

UX- und UI-Designer brauchen eine Möglichkeit, Barrierefreiheit von Beginn an in ihre Designs einzubeziehen. Die Kriterien sind darauf nicht ausgelegt. Sie beschreiben einen Soll-Zustand zum Prüfen, nicht die Schritte zur Umsetzung.

Entwickler stehen oft als alleinige Verantwortliche da und fühlen sich handlungsunfähig. Sie sitzen am Ende des Prozesses und sind von den vorherigen Schritten abhängig. Wenn Barrierefreiheit am Anfang vernachlässigt wurde, kann sie der Entwickler am Schluss meist nicht mehr herausreißen.

Wie aus Prüfkriterien Aufgaben für konkrete Rollen werden

Der Ansatz von Franziska Kroneck und Andrea Nutsi dreht die Perspektive um: Sie leiten aus den Prüf- und Erfolgskriterien konkrete Aufgaben ab, also echte To-dos für Designer, Entwickler und Product Owner. Ziel ist kein neuer Prozess, sondern Arbeitsschritte, die sich in den bestehenden Entwicklungsablauf integrieren lassen.

Ein einzelnes Erfolgskriterium kann dabei in mehrere Aufgaben für verschiedene Rollen zerfallen. Das Beispiel Tastaturbedienung zeigt das gut. Eine Website muss sich vollständig mit der Tastatur bedienen lassen, und daraus ergeben sich drei aufeinander aufbauende Aufgaben:

Diese drei Aufgaben stecken in einem einzigen Kriterium. Erst die Aufteilung macht sichtbar, wer wann was tun muss.

Weniger Aufgaben als Kriterien, weil sich Vorgaben überschneiden

Aus Hunderten Kriterien werden überraschend wenige Aufgaben. Aktuell sind es 29, und die Einschätzung lautet, dass es im Bereich von 30 bis 40 bleibt und kaum über 50 steigt. Ein Mörder-Umfang ist das nicht.

Der Grund ist die Überschneidung. Eine Guideline aus den WCAG und eine verwandte aus der europäischen Norm ergeben oft zusammen eine einzige Aufgabe für den Designer. Statt jedes Kriterium einzeln abzuarbeiten, bündelt der Aufgaben-Ansatz, was inhaltlich zusammengehört.

Erste Tests mit UX-Designern verliefen positiv. Sie hatten endlich eine To-do-Liste und wussten, was von ihnen erwartet wird und wie es sich in ihren Arbeitsalltag übertragen lässt. Mit Entwicklern steht die Erprobung noch aus.

Der Aufwand pro Aufgabe schwankt stark

Wie viel Arbeit eine Aufgabe macht, hängt vom Kontext ab, lässt sich aber grob einschätzen. Die aufwendigsten Aufgaben liegen bei etwa zwei Wochen, andere sind in ein bis drei Tagen erledigt.

Alternativtexte für Grafiken zu formulieren, gehört zu den schnellen Aufgaben. Der eigentliche Lernaufwand liegt darin, zu verstehen, für welche Bilder ein Alternativtext nötig ist und welcher Informationsgehalt hineingehört. Das ist in ein bis drei Tagen machbar.

Aufwendig wird es, wenn am Anfang echte Nutzerforschung ansteht. Wer fünf bis zehn Menschen mit unterschiedlichen Einschränkungen interviewen will, um deren Bedürfnisse abzuleiten, muss recruiten, vorbereiten und auswerten. Dafür sind eher zwei bis drei Wochen realistisch.

Wo Barrierefreiheit an Corporate Identity und vorgegebene Komponenten stößt

Nicht jede Anforderung liegt in der Hand des Teams, das die Software baut. Farbkontraste sind dafür das deutlichste Beispiel. Eine blasse Pastellfarbe im Corporate Design erreicht die geforderten Kontraste womöglich gar nicht.

Designer kämpfen hier mit zwei Sorgen. Die eine ist die Befürchtung, dass strenge Standards im gestalterischen Bereich die Ästhetik mindern. Die andere sind vordefinierte Komponenten und CI-Vorgaben, die nicht barrierefrei sind.

Bekommt ein Designer oder Entwickler eine vordefinierte Komponente, bleibt ihm oft nur, darüber zu informieren, dass sie nicht barrierefrei ist. Den Einfluss, das zu ändern, hat er nicht. An dieser Stelle müssen die Standards in der Firma selbst angepasst werden.

KI hilft bei Sprache, ersetzt aber kein etabliertes Werkzeug

Large Language Models lassen sich sinnvoll für leichte und verständliche Sprache einsetzen. Komplizierte Texte, etwa auf Behördenseiten, lassen sich damit in eine Version umschreiben, die ohne Fachbegriffe und englische Wörter auskommt. Verständliche Sprache ist ein eigenes Barrierefreiheits-Kriterium, gedacht für Menschen mit Konzentrationsschwierigkeiten.

Bei automatisch generierten Alternativtexten ist das Ergebnis gemischt. Ein KI-Generator, der ein Bild analysiert und einen Alternativtext formuliert, liefert mal brauchbare, mal unbrauchbare Resultate. Verlassen kann man sich darauf nicht. Ein etabliertes Tool, das die Umsetzung von Barrierefreiheit zuverlässig übernimmt, ist bisher nicht in Sicht.

Je später Barrierefreiheit kommt, desto teurer wird sie

Barrierefreiheit von Anfang an einzuplanen spart am Ende Geld. Wer eine Website erst fertigstellt und dann einen Test machen lässt, riskiert eine lange Mängelliste und teure Nacharbeit.

Oft lässt sich eine fertige Anwendung im Nachhinein gar nicht mehr einfach barrierefrei machen. Dann muss sie neu aufgesetzt werden. Das Muster ist aus anderen nicht-funktionalen Themen bekannt.

Je später ich Barrierefreiheit integriere, desto teurer wird es. Wenn ich das von Anfang an einplane, spare ich mir am Ende einen Haufen Geld. Franziska Kroneck

Wer am Ende erst die Performance testet und merkt, dass die Architektur nicht darauf ausgelegt ist, kennt das Problem. Dasselbe gilt für Security. Barrierefreiheit reiht sich in diese Dinge ein, die früh mitgedacht gehören, weil späte Korrekturen teuer und manchmal unmöglich sind. Für Entwickler bedeutet das eine weitere Anforderung, die sie früh berücksichtigen müssen.