Für wen die Pflicht gilt — und für wen nicht
Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, setzt den European Accessibility Act in deutsches Recht um und gilt seit dem 28. Juni 2025. Betroffen sind Dienstleistungen im elektronischen Geschäftsverkehr, die sich an Verbraucherinnen und Verbraucher richten: der klassische B2C-Onlineshop, Buchungs- und Terminstrecken, Bankdienstleistungen für Privatkunden, Personenbeförderung im Fern- und Luftverkehr, Telekommunikation und E-Books. Entscheidend ist nicht, ob Sie sich als Shop verstehen, sondern ob jemand bei Ihnen online einen Vertrag abschließen kann. Wer betroffen ist und die Anforderungen nicht erfüllt, muss mit Beanstandungen der Marktüberwachungsbehörden rechnen. Daneben kursieren wettbewerbsrechtliche Abmahnungen, die BFSG-Verstöße über § 3a UWG angreifen; ob das trägt, ist gerichtlich noch nicht entschieden.
Zwei Gruppen bleiben außen vor. Reine B2B-Angebote fallen grundsätzlich nicht darunter, weil das Gesetz auf Verbraucher zielt. Für Dienstleistungen gilt zusätzlich eine Ausnahme für Kleinstunternehmen: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Für Produkte greift diese Ausnahme nicht. Öffentliche Stellen des Bundes sind ohnehin seit Jahren über die BITV 2.0 verpflichtet, Länder und Kommunen über entsprechendes Landesrecht — ein anderer Rechtsrahmen. Ob Ihr Angebot im Einzelfall betroffen ist, bewertet verbindlich eine Anwältin oder ein Anwalt; wir setzen die technischen Anforderungen um. Und ein verbreitetes Missverständnis gleich mit: § 38 BFSG enthält Übergangsfristen, die aber Produkte und Selbstbedienungsterminals betreffen — nicht Websites und Onlineshops. Für die gilt der 28. Juni 2025 ohne Schonfrist.
Der Maßstab: EN 301 549 und WCAG 2.1 AA
Der praktische Prüfmaßstab ist die europäische Norm EN 301 549 — sie beschreibt den anerkannten Stand der Technik; rechtlich verbindlich sind BFSG und BFSGV. Die derzeit im EU-Amtsblatt zitierte Fassung verweist für Webinhalte auf die Web Content Accessibility Guidelines in Version 2.1, Konformitätsstufe AA; die Nachfolgefassung mit WCAG 2.2 AA ist angekündigt. Wir prüfen deshalb bereits gegen 2.2 — die zusätzlichen Kriterien sind überschaubar und ersparen eine zweite Runde. Das ist kein Katalog von Meinungen, sondern eine Liste prüfbarer Kriterien.
Konkret heißt das: ausreichende Farbkontraste, für normalen Text mindestens 4,5:1. Vollständige Bedienbarkeit per Tastatur, mit sichtbarem Fokus an jeder Station. Alternativtexte, die den Inhalt eines Bildes wiedergeben statt den Dateinamen. Korrekte HTML-Semantik und eine Überschriftenhierarchie, die nicht dem Layout folgt, sondern der Struktur. Beschriftete Formularfelder mit Fehlermeldungen, die sagen, was zu tun ist. Information nie allein über Farbe. Zoom bis 200 Prozent ohne Informationsverlust. Untertitel bei Videos. ARIA nur dort, wo natives HTML nicht ausreicht. Eine Erklärung zur Barrierefreiheit verlangen WCAG und EN 301 549 übrigens nicht — das ist eine Pflicht öffentlicher Stellen aus der BITV 2.0. Wer unter das BFSG fällt, schuldet die Angaben nach § 14 Abs. 1 Nr. 2 BFSG, üblicherweise in den AGB.
Warum Overlays nichts lösen — und wie geprüft wird
Ein Accessibility-Overlay — oft als „Barrierefreiheits-Widget“ verkauft — ist ein Skript, das sich über eine Website legt und Schriftgrößen, Kontraste oder eine Vorlesefunktion anbietet. Es repariert nicht, was darunter liegt. Fehlt einem Button die Beschriftung, fehlt sie auch mit Widget; ist die Überschriftenstruktur falsch, bleibt sie falsch. Barrierefreiheit entsteht im Markup, nicht in einem eingebundenen Skript. Nutzerinnen und Nutzer von Screenreadern arbeiten außerdem längst mit ihren eigenen Hilfsmitteln — ein Overlay kommt diesen eher in die Quere, statt zu helfen.
Auch bei der Prüfung hilft kein Knopfdruck. Automatische Werkzeuge wie axe, Lighthouse oder WAVE finden zuverlässig, was maschinell entscheidbar ist: fehlende Alternativtexte, zu geringe Kontraste, kaputte Labels. Ob ein Alternativtext den Inhalt trifft, ob die Tastaturreihenfolge einem Sinn folgt, ob ein Dialog den Fokus hält — das sieht man erst beim manuellen Test. Wir prüfen deshalb zweistufig: automatisiert über den gesamten Seitenbestand, manuell mit Tastatur und Screenreader an den Strecken, die wirklich zählen.
Umsetzung im Bestand und im Neubau
Bestehende Systeme fangen wir mit einem Audit an: repräsentative Seiten und die vollständigen Kaufs-, Buchungs- und Kontaktstrecken, geprüft gegen WCAG 2.1 AA. Daraus wird ein priorisierter Maßnahmenplan — zuerst die Blocker, die eine Bestellung unmöglich machen, dann die Mängel, die sie erschweren, zuletzt die Feinheiten. Sie sehen, was Aufwand kostet und was in einem Nachmittag erledigt ist. Umgesetzt wird in TYPO3, WordPress und Shopware 6, im Theme und in den Templates.
Bei neuen Projekten ist Barrierefreiheit kein Nachtrag, sondern Teil von Konzept, Design und Frontend. Kontraste werden im Farbsystem festgelegt, Komponenten von Anfang an tastaturbedienbar gebaut, Redakteurinnen und Redakteure lernen, wie Alternativtexte und Überschriften gepflegt werden. Ein Nebeneffekt, den wir nicht zum Hauptargument machen: Was für einen Screenreader sauber strukturiert ist, lesen Suchmaschinen und KI-Assistenten ebenfalls besser. Semantik zahlt doppelt. Fragen zum Stand Ihrer Website beantworten wir Mo–Fr von 9:00 bis 16:00 Uhr unter 0441 21 21 63 0 oder info@sharpness.de.