Barrierefreie Website nach BFSG
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz — und die meisten betroffenen Unternehmen merken erst beim Nachrechnen, wie viel ihres Onlineshops darunter fällt. Wir bringen bestehende Websites, Shops und Apps auf den Stand der WCAG 2.1 AA, den die EN 301 549 als Maßstab heranzieht. Der Weg ist immer derselbe: erst messen, dann priorisieren, dann umsetzen — beginnend bei den Stellen, an denen Barrierefreiheit und Umsatz dasselbe sind, nämlich Formular, Warenkorb und Checkout. Was ein automatischer Test findet, räumen wir in Tagen ab; die Kriterien, die nur manuell prüfbar sind — Tastaturbedienung, Fokusreihenfolge, Screenreader-Ausgabe — testen wir von Hand und dokumentieren sie. Am Ende steht kein Siegel, sondern ein nachvollziehbarer Stand: was konform ist, was nicht, und was bis wann geplant ist. Genau diese Dokumentation ist es, die im Zweifel zählt.
Leistungsumfang
Audit nach WCAG 2.1 AA / EN 301 549: automatisierter Scan plus manuelle Prüfung von Tastaturbedienung, Fokusreihenfolge und Screenreader-Ausgabe
Priorisierter Maßnahmenplan mit Aufwandsschätzung — sortiert nach Wirkung, nicht nach Kriteriennummer
Umsetzung im Code: semantische Struktur, Formularbeschriftungen, Kontraste im Designsystem, Fokusführung, ARIA nur wo nötig
Barrierefreiheitserklärung im geforderten Aufbau und ein Rückmeldemechanismus, über den Nutzer Barrieren melden können
Regressionsschutz: Prüfungen in der CI, damit das nächste Feature den Stand nicht wieder kaputt macht
Warum runIT
Wir verkaufen kein Overlay-Widget. Diese Skripte legen eine Ebene über die Seite, beheben die zugrunde liegenden Fehler nicht und werden von Betroffenenverbänden ausdrücklich kritisiert — die Barriere bleibt, nur schlechter sichtbar.
Wir sagen, was ein automatischer Test nicht abdeckt. Er findet etwa ein Drittel der realen Verstöße; wer Ihnen auf dieser Basis „100 % konform“ bescheinigt, verkauft Ihnen eine Sicherheit, die es nicht gibt. Unseren Schnelltest können Sie selbst laufen lassen — er nennt seine Grenzen auf derselben Seite.
Wir bauen die Korrektur ins Designsystem, nicht auf Einzelseiten. Ein Kontrastfehler, der in der Komponente behoben wird, kommt beim nächsten Release nicht zurück; einer, der auf zwölf Seiten einzeln geflickt wurde, schon.
So glatt wie ein Software-Deploy.
Sprint-fokussiert, transparent und messbar. Sie sehen jeden Schritt.
Brief & Strategie
Wir klären Ziele, Nutzer und technische Rahmenbedingungen. Start ab Tag eins.
Design & Architektur
UX-Flows, Systemarchitektur und Datenmodell entwickeln sich parallel.
Entwicklung & QA
CI/CD-Pipeline ab der ersten Woche. Automatisierte Tests, Code Reviews, Observability — Standard.
Launch & Wachstum
Nach dem Go-Live sorgen SEO, Performance und Analytics für nachhaltiges Wachstum.
Dieses System haben wir schon gebaut.
Pilates Rehberi und Pilates Studios UK sind lebende Beispiele desselben programmatischen lokalen SEO-Systems, das Sie gerade sehen — gebaut, live und im Ranking.
Häufig gestellte Fragen
Reicht ein Accessibility-Overlay, um das BFSG zu erfüllen?
Nein. Overlay-Skripte versprechen Konformität per Zeile JavaScript, ändern aber nichts am Markup darunter — fehlende Formularbeschriftungen, falsche Überschriftenstruktur und unbedienbare Tastaturpfade bleiben bestehen. Betroffenenverbände und Screenreader-Nutzer kritisieren solche Werkzeuge seit Jahren, weil sie die Bedienung teilweise sogar verschlechtern. Konformität entsteht im Quelltext: semantisches HTML, beschriftete Bedienelemente, ausreichende Kontraste, durchgängige Tastaturbedienbarkeit. Das ist mehr Arbeit als ein Skript einzubinden, hält aber einer Prüfung stand.