Barrierefreiheit ist seit 2025 Pflicht: was das für Ihre App bedeutet

Viele Geschäftsführer haben vom Barrierefreiheitsstärkungsgesetz gehört und wissen trotzdem nicht, ob es sie trifft. Das ist verständlich, denn das Thema galt lange als Randnotiz für Behörden. Seit dem 28. Juni 2025 ist es das nicht mehr. Wer digitale Dienstleistungen an Verbraucher verkauft, über eine Buchungsstrecke, ein Kundenportal oder eine App, muss seitdem gesetzliche Anforderungen an die Barrierefreiheit erfüllen.

Dieser Beitrag beantwortet die drei Fragen, die in unseren Erstgesprächen am häufigsten kommen: Bin ich betroffen? Was heißt das konkret an meiner Software? Und was kostet es mich, wenn ich es jetzt angehe statt später? Er ordnet den Stand ein und ersetzt keine Rechtsberatung. Die verbindliche Bewertung Ihres Einzelfalls gehört in anwaltliche Hände.

Was seit dem 28. Juni 2025 gilt

Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, setzt die Richtlinie (EU) 2019/882 in deutsches Recht um, bekannt als European Accessibility Act. Es gilt seit dem 28. Juni 2025 und richtet sich an private Anbieter bestimmter Produkte und Dienstleistungen für Verbraucher.

Eine Kategorie ist für unsere Kunden besonders relevant: die Dienstleistungen im elektronischen Geschäftsverkehr. Das Gesetz beschreibt sie als digitale Dienste, die über Webseiten und über Anwendungen auf Mobilgeräten angeboten und elektronisch, auf individuelle Anfrage eines Verbrauchers, im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden. Übersetzt in den Alltag heißt das: alles, worüber ein Endkunde bei Ihnen buchen, bestellen oder abschließen kann. Daneben nennt das Gesetz unter anderem Bankdienstleistungen für Verbraucher, Elemente von Personenbeförderungsdiensten, Telekommunikationsdienste und E-Books.

Öffentliche Stellen sind hier nicht der neue Fall. Für sie gelten über das Behindertengleichstellungsgesetz und die Barrierefreie-Informationstechnik-Verordnung schon deutlich länger eigene Vorgaben. Neu ist der Handlungsdruck vor allem in der Privatwirtschaft, und dort trifft er genau die Strecken, an denen Umsatz entsteht.

Sind Sie betroffen?

Drei Fragen grenzen das für die meisten Unternehmen sauber ein.

Erstens: Richtet sich Ihre Anwendung an Verbraucher? Das BFSG ist am Verbraucher ausgerichtet. Ein Portal, das ausschließlich Geschäftskunden im Rahmen bestehender Lieferverträge nutzen, ist anders zu bewerten als ein öffentlich zugänglicher Buchungsprozess. Sobald Endkunden bei Ihnen abschließen, sollten Sie von Betroffenheit ausgehen.

Zweitens: Kommt über Ihre Software ein Vertrag zustande? Der Ausdruck „im Hinblick auf den Abschluss eines Verbrauchervertrags“ ist der Hebel. Eine reine Imageseite ohne Abschlussfunktion wird anders bewertet als eine Terminbuchung, ein Bestellprozess, ein Patientenportal mit Anmeldestrecke oder eine Sendungsverfolgung mit Kundenkonto. Prüfen Sie das an der Funktion, nicht am Namen des Produkts.

Drittens: Sind Sie ein Kleinstunternehmen? Das Gesetz nimmt Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, von den Anforderungen aus. Als Kleinstunternehmen gilt ein Unternehmen, das weniger als zehn Personen beschäftigt und das entweder höchstens 2 Millionen Euro Jahresumsatz erzielt oder dessen Jahresbilanzsumme höchstens 2 Millionen Euro beträgt. Für Betriebe zwischen zehn und zweihundert Mitarbeitenden, also für den größten Teil unserer Kunden, greift diese Ausnahme damit nicht. Und sie ist auf Dienstleistungen bezogen, nicht auf alles.

Zweimal Ja und einmal Nein ergibt einen klaren Fall. Dazwischen liegen Grenzfälle, und die klärt man nicht in einem Blogbeitrag, sondern mit einem Blick auf die konkrete Anwendung und mit juristischer Begleitung.

Was Barrierefreiheit an einer App konkret bedeutet

Der technische Bezugspunkt ist in der Praxis die europäische Norm EN 301 549. Sie greift für Webinhalte auf die Web Content Accessibility Guidelines zurück, im Kern auf deren Konformitätsstufe AA. Eine förmliche Konformitätsvermutung nach dem BFSG lässt sich daraus derzeit allerdings noch nicht ableiten, denn die Fassung, die dafür im Amtsblatt der Europäischen Union stehen müsste, steht noch aus. Für Ihre Planung ändert das wenig, für ein Häkchen auf einer Liste ändert es alles: Wer heute wissen will, wo er steht, kommt um einen Blick in die eigene Anwendung nicht herum. Eine Kriterienliste hilft Ihnen in Ihrer Rolle nicht weiter. Was Ihnen weiterhilft, ist ein Gefühl dafür, woran Menschen in Ihrer Anwendung tatsächlich hängenbleiben.

Kontrast und Skalierung. Hellgrauer Text auf weißem Grund sieht im Entwurf ruhig aus und ist am Handy in der Sonne unlesbar. Dazu kommt die Vergrößerung: Wer die Schrift größer stellt, darf die Funktion nicht verlieren. Ein Layout, das beim Zoomen auseinanderfällt, ist ein Mangel und keine Geschmacksfrage.

Bedienbarkeit ohne Maus. Jede Funktion muss über die Tastatur erreichbar sein, in einer nachvollziehbaren Reihenfolge und mit sichtbarer Markierung, wo man gerade steht. Diese Fokusreihenfolge ist der Punkt, an dem selbst gepflegte Oberflächen regelmäßig scheitern, weil sie nie jemand getestet hat.

Screenreader und Alternativtexte. Blinde Nutzer lassen sich die Oberfläche vorlesen. Dafür braucht jede Schaltfläche einen sprechenden Namen und jedes inhaltstragende Bild einen Alternativtext, der beschreibt, was zu sehen ist. Ein Formularfeld, das nur über ein Symbol beschriftet ist, existiert für diese Nutzer nicht.

Formulare, die man auch hört. Fehler dürfen nicht allein über Farbe gemeldet werden. Wer nicht sieht, sieht kein Rot. Die Meldung muss im Text sagen, welches Feld betroffen ist und was zu ändern ist, und sie muss dort ausgegeben werden, wo Hilfstechnik sie findet.

Zeit und Bewegung. Automatische Weiterschaltungen, kurze Zeitfenster in Buchungsstrecken und dauerhaft laufende Animationen schließen Menschen aus, die langsamer arbeiten oder auf Bewegung empfindlich reagieren. Ein Sitzungsfenster, das sich verlängern lässt, kostet wenig und rettet den Abschluss.

Warum Mitbauen günstiger ist als Nachrüsten

Hier liegt der eigentliche Grund, warum wir das Thema in Projekte hineintragen, statt es an die Rechtsabteilung zu delegieren.

Barrierefreiheit im Entwurf ist im Wesentlichen Entscheidungsaufwand. Man legt Farbwerte einmal so fest, dass die Kontraste tragen. Man baut die Komponentenbibliothek so, dass Fokus, Beschriftung und Fehlermeldung von Anfang an mitkommen. Man denkt die Reihenfolge der Bedienelemente beim Entwurf des Ablaufs mit. Diese Entscheidungen kosten Aufmerksamkeit, aber sie kosten keinen Umbau.

Nachrüsten ist eine andere Aufgabe. Da liegt die Oberfläche fertig vor, die Farbpalette steckt in jedem Bildschirm, die Formulare sind vervielfältigt, und jede Korrektur zieht eine Kette von Folgeänderungen hinter sich her. Dazu kommt der Test: Was einmal fertig war, muss vollständig neu geprüft werden, nicht nur an der geänderten Stelle. Im Entwurf ändern Sie eine Festlegung. An der fertigen Oberfläche ändern Sie jede Stelle, an der sie sich niedergeschlagen hat.

Es ist derselbe Mechanismus, den wir in unserem Beitrag über technische Schulden für Code beschrieben haben. Eine Abkürzung im Entwurf ist eine Anleihe, und die Zinsen zahlt man später an der fertigen Oberfläche. Der Unterschied ist nur: Bei technischen Schulden bestimmen Sie selbst, wann Sie tilgen. Beim BFSG steht das Datum bereits fest, und es liegt hinter uns.

Ein Selbsttest in zehn Minuten

Sie brauchen kein Werkzeug und keinen Termin, um eine erste Einschätzung zu bekommen. Nehmen Sie Ihre wichtigste Strecke, also den Weg, auf dem bei Ihnen Umsatz entsteht, und gehen Sie diese sechs Punkte durch.

1. Schieben Sie die Maus beiseite. Kommen Sie mit Tabulatortaste und Eingabetaste vom Einstieg bis zum Abschluss, und sehen Sie dabei jederzeit, wo Sie gerade stehen?
2. Stellen Sie den Zoom im Browser auf 200 Prozent oder die Systemschrift auf die größte Stufe. Bleibt alles lesbar und bedienbar, oder überlagern sich Elemente?
3. Provozieren Sie einen Formularfehler. Nennt die Meldung im Klartext das betroffene Feld und den nötigen Schritt, oder leuchtet nur ein Rahmen rot?
4. Schalten Sie VoiceOver unter iOS oder TalkBack unter Android ein. Wird jede Schaltfläche mit einem verständlichen Namen vorgelesen, oder hören Sie nur „Schaltfläche“?
5. Nehmen Sie drei zentrale Bilder. Hat jedes einen Alternativtext, der den Inhalt beschreibt, statt eines Dateinamens?
6. Fragen Sie in Ihrem Projekt nach, wer Barrierefreiheit als Aufgabe hat. Wenn niemand antwortet, haben Sie das Ergebnis bereits.

Wer bei zwei oder drei Punkten hängenbleibt, hat kein Drama vor sich, sondern eine Aufgabenliste. Wer bei allen sechs hängenbleibt, sollte den Umbau planen, bevor die nächste Funktionsrunde die Oberfläche weiter vergrößert.

Fazit

Das BFSG ist kein Grund zur Aufregung und auch kein Thema, das sich aussitzen lässt. Es ist eine Anforderung an Software, die Verbraucher benutzen, und wie jede Anforderung ist sie planbar, sobald man den Ist-Stand kennt. Der teure Weg ist nicht die Umsetzung. Der teure Weg ist, sie so lange zu verschieben, bis sie unter Zeitdruck an einer fertigen Oberfläche stattfinden muss.

Nebenbei bekommen Sie etwas zurück, das sich nicht nur juristisch rechnet. Größere Schrift, klare Fehlermeldungen und eine saubere Bedienreihenfolge helfen nicht nur Menschen mit Behinderung. Sie helfen auch dem Kunden, der die Buchung im Zug auf einem kleinen Bildschirm zu Ende bringen will. Barrierefreie Oberflächen sind in aller Regel schlicht die besser bedienbaren.

Ein erster Schritt lohnt sich, und er ist klein: eine Bestandsaufnahme Ihrer bestehenden App oder Ihres Portals. Wir sehen uns die wichtigste Nutzerstrecke an, prüfen sie gegen die genannten Punkte und sagen Ihnen, was davon Konfiguration ist, was Handarbeit und was in die nächste größere Ausbaustufe gehört. Daraus wird eine Liste mit Aufwänden, keine Drohkulisse.

Sprechen Sie uns an: telefonisch unter +49 177 4644822, per E-Mail an contact@here2buildapps.de oder über here2buildapps.de. Wir sind die Here2Build Apps GmbH aus Penzberg und bauen Apps und Portale für den Mittelstand.

Hinweis: Dieser Beitrag ordnet den rechtlichen Stand ein und ersetzt keine Rechtsberatung.