Barrierefreie Softwareentwicklung: WCAG 2.2, EN 301 549 und BFSG

WCAG 2.2 und BFSG — Technik und gesetzlicher Anwendungsbereich

Seit dem 28. Juni 2025 gilt das BFSG für bestimmte Produkte und verbraucherbezogene Dienstleistungen, darunter je nach Ausgestaltung Online-Shops, digitale Bank- und Telekommunikationsdienste. Wir verwenden WCAG 2.2 Level AA als aktuellen technischen Prüf- und Entwicklungsstandard. Gesetzlicher Anwendungsbereich und anwendbare Normen — etwa EN 301 549, BFSG oder BITV im öffentlichen Sektor — werden separat betrachtet. Übergangsregelungen bis 2030 betreffen nur bestimmte Konstellationen und gelten nicht pauschal für jede Bestandssoftware.

Primärquellen für die Einordnung sind der WCAG-Überblick des W3C sowie der amtliche BFSG-Anwendungsbereich und die Übergangsbestimmungen in § 1 BFSG und § 38 BFSG.

Barrierefreiheit macht Software für Menschen mit Seh-, Hör-, motorischen oder kognitiven Einschränkungen nutzbar und verbessert zugleich die Bedienbarkeit in vielen Alltagssituationen. Wir unterstützen bei Audit, Umsetzung und CI/CD-Integration. Für die technische Absicherung verbinden wir risikobasierte Softwaretests mit zugänglichem UX-Design; Datenschutzanforderungen werden in der DSGVO-konformen Softwareentwicklung separat betrachtet.

Unsere Leistungen für barrierefreie Software

Häufige Fragen (FAQ)

• Was ist das BFSG und wen betrifft es?
  Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act (EAA) in Deutschland um und gilt seit dem 28. Juni 2025 für bestimmte Produkte und verbraucherbezogene Dienstleistungen. Dazu können unter anderem Online-Shops, digitale Bankdienstleistungen, Telekommunikationsdienste, E-Books und Teile der Personenbeförderung gehören. Übergangsregelungen gelten nicht pauschal für jedes bestehende System bis 2030, sondern nur für bestimmte Konstellationen. Auch Ausnahmen, etwa für bestimmte Dienstleistungen von Kleinstunternehmen, müssen am konkreten Angebot geprüft werden. Wir analysieren den technischen Anwendungsbereich; eine verbindliche rechtliche Einordnung ersetzt das nicht.
• Was bedeutet WCAG 2.2 AA für Software-Entwickler?
  WCAG 2.2 Level AA ist unser aktueller Prüf- und Entwicklungsstandard für barrierefreie Webanwendungen. Er baut auf WCAG 2.1 auf und umfasst die Prinzipien wahrnehmbar, bedienbar, verständlich und robust: unter anderem Alt-Texte, Untertitel, ausreichende Kontraste, Tastaturbedienung, sichtbaren Fokus, klare Formulare und kompatibles Markup. Für React/Next.js bedeutet das semantische HTML-Elemente, gezielte ARIA-Attribute, Fokus-Management bei Modals und Navigation sowie Tests mit NVDA oder VoiceOver. Welche Norm oder gesetzliche Vorgabe verbindlich ist, etwa EN 301 549, BITV oder BFSG, wird davon getrennt geprüft.
• Wie wird Barrierefreiheit in React-Anwendungen umgesetzt?
  Barrierefreiheit in React-Anwendungen erfordert mehrere Ebenen: Erstens semantisches HTML – die richtigen HTML-Elemente für Buttons, Überschriften, Listen und Formulare verwenden statt alles in Divs zu packen. Zweitens ARIA-Attribute – aria-label, aria-expanded, aria-live-Regions für dynamische Inhalte und aria-describedby für Hilfetexte. Drittens Fokus-Management – bei modalen Dialogen, SPA-Navigation und Benachrichtigungen muss der Fokus korrekt gesetzt werden. Viertens Tastaturnavigation – alle interaktiven Elemente müssen per Tab erreichbar und per Enter/Space bedienbar sein. Tools wie axe-core, Lighthouse und manuelle Screenreader-Tests (NVDA/Windows, VoiceOver/Mac) ergänzen die Entwicklungszeit. Wir integrieren axe-core in CI/CD-Pipelines, damit Barrierefreiheits-Regressionen automatisch erkannt werden.
• Was kostet ein Barrierefreiheits-Audit und die anschließende Umsetzung?
  Der Barrierefreiheits-Kostenrechner weist 2.856 – 82.334 € zzgl. MwSt. als unverbindliche Gesamtspanne aus. Darin werden automatisierte Tests mit axe-core und Lighthouse, manuelle Prüfungen mit Screenreader, Tastaturnavigation und Kontrast-Check sowie ein priorisierter Mängelbericht berücksichtigt. Der konkrete Wert hängt von Anwendungsgröße, bestehender technischer Schuld und Nachbesserungsumfang ab. Bei Neuentwicklungen planen wir Barrierefreiheit von Anfang an als feste Qualitätskategorie in der Definition of Done ein.
• Kann Barrierefreiheit nachträglich eingebaut werden?
  Ja, aber es ist teurer als von Anfang an einzuplanen. Nachträgliche Barrierefreiheit kostet typisch 2–5× mehr als 'built-in'. Wir führen WCAG-Audits bestehender Software durch und priorisieren Maßnahmen nach Aufwand und Compliance-Risiko.
• Welche Tools prüfen Barrierefreiheit automatisch?
  axe DevTools, WAVE und Lighthouse prüfen bekannte maschinell erkennbare Fehler. Je nach Anwendung erfassen automatisierte Tests nur einen Teil der Barrieren; deshalb ergänzen wir Screenreader-Tests mit NVDA und VoiceOver, Tastaturtests und fachliche Sichtprüfung. Das liefert einen nachvollziehbaren Findings-Report, ist aber keine automatische Garantie vollständiger Compliance oder ein behördliches Zertifikat.
• Wie lange dauert die barrierefreie Neuentwicklung einer App?
  Barrierefreie Entwicklung dauert ca. 10–15 Prozent länger als Standard-Entwicklung. Grund: zusätzliche Testschritte, ARIA-Attribute und Designentscheidungen für Barrierefreiheit. Der Mehraufwand amortisiert sich durch fehlende Nacharbeit und Compliance-Sicherheit.