Barrierefreiheit von Webanwendungen: was das BFSG verlangt und was sich ohnehin lohnt

Barrierefreiheit bedeutet bei Webanwendungen, dass Menschen sie unabhängig von Sehvermögen, Motorik oder Hörfähigkeit bedienen können: mit Tastatur, Bildschirmleser, Vergrößerung oder Sprachsteuerung, ebenso gut wie alle anderen. Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz das für bestimmte Angebote an Verbraucher, darunter den Online-Handel.

Barrierefreiheit digital: worum es geht

Eine Oberfläche ist barrierefrei, wenn sie wahrnehmbar, bedienbar, verständlich und robust ist. Hinter diesen vier Begriffen stehen konkrete Eigenschaften: Bilder haben Textalternativen, Kontraste reichen auch bei schwacher Sicht, jedes Bedienelement ist ohne Maus erreichbar, Fehlermeldungen erklären, was zu tun ist, und der Code ist so ausgezeichnet, dass Hilfsprogramme ihn richtig vorlesen.

Die Messlatte beschreiben die Web Content Accessibility Guidelines, kurz WCAG, und die harmonisierte europäische Norm für barrierefreie Informations- und Kommunikationstechnik, die sich auf sie stützt. Beide sind keine Stilfragen, sondern prüfbare Kriterien. Das macht sie für Projekte handhabbar: Was prüfbar ist, lässt sich im Angebot beschreiben und bei der Abnahme kontrollieren.

Das BFSG in Kürze

Das Gesetz, abgekürzt BFSG, setzt eine europäische Richtlinie in deutsches Recht um, den European Accessibility Act. Es legt fest, dass bestimmte Produkte und Dienstleistungen, die nach dem Stichtag in Verkehr gebracht oder angeboten werden, barrierefrei sein müssen. Für manche bestehende Angebote gelten Übergangsfristen.

Zu den erfassten Dienstleistungen gehören unter anderem der elektronische Geschäftsverkehr, also Online-Shops und Buchungsstrecken für Verbraucher, Bankdienstleistungen für Verbraucher, E-Books sowie Teile des Personenverkehrs und der Telekommunikation. Die Einhaltung überwachen die Marktüberwachungsbehörden der Länder, die dafür eine gemeinsame Stelle eingerichtet haben.

Wer betroffen ist und wer nicht

Entscheidend ist, wer die Anwendung nutzt. Ein Kundenportal, über das Verbraucher bestellen, buchen oder Verträge abschließen, fällt in aller Regel unter das Gesetz. Ein internes Werkzeug für die eigenen Mitarbeiter oder ein Portal, das sich ausschließlich an Geschäftskunden richtet, fällt nicht darunter. Wer unsicher ist, klärt die Frage vor dem Entwurf, weil sich eine Buchungsstrecke nachträglich nur mit Aufwand umbauen lässt.

Für Kleinstunternehmen, die Dienstleistungen erbringen, sieht das Gesetz eine Ausnahme vor. Ob sie greift und ob ein Angebot im Einzelfall erfasst ist, beantwortet eine rechtliche Prüfung, kein Lexikonartikel. Unabhängig davon gilt: Viele Menschen in Belegschaften und Kundschaft profitieren von klaren Kontrasten und Tastaturbedienung, auch wenn kein Gesetz sie fordert. Und die Arbeitsschutz- und Inklusionsregeln im eigenen Haus können eigene Anforderungen stellen.

Anforderungen an barrierefreie Oberflächen

• Semantischer Aufbau. Überschriften, Listen, Formularfelder und Schaltflächen sind im Code als solche ausgezeichnet, nicht nur optisch gestaltet.
• Tastatur und Fokus. Jede Funktion ist per Tastatur erreichbar, die Reihenfolge ist logisch, und man sieht jederzeit, wo man sich befindet.
• Kontrast und Größe. Text bleibt lesbar, wenn er vergrößert wird, und hebt sich ausreichend vom Hintergrund ab.
• Formulare und Fehler. Jedes Feld hat eine Beschriftung, Pflichtangaben sind erkennbar, Fehlermeldungen stehen beim Feld und sagen, was fehlt.
• Medien und Zeitlimits. Videos haben Untertitel, automatische Abmeldungen lassen sich verlängern.

Wer diese Punkte von Beginn an in die Komponenten einbaut, muss sie nicht bei jedem Bildschirm neu lösen. Eine Schaltfläche, die einmal richtig ausgezeichnet ist, bleibt es überall, wo sie verwendet wird. Deshalb lohnt es sich, eine kleine Bibliothek geprüfter Bausteine zu pflegen, statt jede Oberfläche einzeln nachzubessern. Zum Angebot selbst gehört außerdem eine öffentliche Erklärung, die beschreibt, wie die Anforderungen erfüllt werden.

Häufige Fehler im Projekt

• Am Ende prüfen. Wer die Zugänglichkeit erst nach dem Design testet, baut Farben, Komponenten und Abläufe um. Eingeplant im Lastenheft kostet sie deutlich weniger.
• Nur automatisch testen. Prüfprogramme finden fehlende Beschriftungen und schwache Kontraste, aber nicht, ob ein Bildschirmleser den Ablauf verständlich wiedergibt. Dafür braucht es einen manuellen Durchgang.
• Nachrüst-Overlays. Einblendbare Werkzeugleisten, die Zugänglichkeit auf Knopfdruck versprechen, lösen die Probleme im Code nicht und stören Hilfsprogramme mitunter zusätzlich.
• Nur am Rechner testen. Bildschirmleser auf dem Telefon verhalten sich anders als am Schreibtisch; beide Wege gehören in den Test.
• Kein Kriterium in der Abnahme. Steht nicht im Vertrag, welcher Stand erreicht werden soll, bleibt die Frage bei der Abnahme offen.

Wie wir Barrierefreiheit einplanen

Wir fragen im ersten Gespräch, wer die Anwendung nutzt und ob Verbraucher darüber kaufen oder buchen. Daraus folgt, welcher Stand im Angebot als Abnahmekriterium steht und wie er geprüft wird: automatisch bei jeder Änderung und manuell mit Tastatur und Bildschirmleser vor der Abnahme. Die rechtliche Einordnung Ihres Angebots ersetzt das nicht. Wie die Umsetzung abläuft, beschreibt die Seite App-Entwicklung.