Häufige Fragen
Häufig gestellte Fragen zur digitalen Barrierefreiheit
Von den rechtlichen Grundlagen des BFSG über technische WCAG-Details bis zu Kosten und Projektablauf: Hier finden Sie fundierte Antworten auf die Fragen, die uns am häufigsten gestellt werden.
Rechtliche Fragen zum BFSG
- Was ist das Barrierefreiheitsstärkungsgesetz (BFSG)? Das BFSG setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um und verpflichtet Unternehmen seit dem 28. Juni 2025, ihre digitalen Produkte und Dienstleistungen barrierefrei zu gestalten. Anders als die frühere BITV 2.0, die nur öffentliche Stellen betraf, adressiert das BFSG erstmals auch private Wirtschaftsakteure. Betroffen sind unter anderem Online-Shops, Banking, Telekommunikation, E-Books, Ticketsysteme und Personenbeförderungsdienste. Die technischen Anforderungen ergeben sich aus der harmonisierten Norm EN 301 549, die für Webinhalte auf die WCAG verweist. Konkret heißt das: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein, also auch per Tastatur und Screenreader nutzbar. Welche Pflichten daraus für Ihr konkretes Angebot folgen, ordnen wir auf der BFSG-Anforderungsseite im Detail ein. In über 50+ Projekten (Projekterfahrung) hat sich gezeigt, dass die meisten Unternehmen den Umfang anfangs unterschätzen.
- Ist mein Unternehmen vom BFSG betroffen? Wenn Sie Produkte oder Dienstleistungen online an Verbraucher (B2C) anbieten, sind Sie in der Regel betroffen. Die wichtigste Erleichterung betrifft Kleinstunternehmen bei Dienstleistungen: Wer weniger als zehn Beschäftigte hat und einen Jahresumsatz beziehungsweise eine Bilanzsumme von höchstens zwei Millionen Euro aufweist, kann ausgenommen sein. Achtung: Bei Produkten gilt diese Ausnahme nicht. Reine B2B-Angebote fallen nicht unter das BFSG. Schwierig wird es bei Mischformen, etwa einem Shop, der sowohl an Geschäftskunden als auch an Verbraucher verkauft, oder bei Plattformen mit verbraucherrelevanten Funktionen. Hier lohnt eine genaue Einzelfallprüfung. Wir klären die Betroffenheit gemeinsam mit Ihnen im kostenlosen Erstgespräch und ordnen sie anhand der Kriterien auf der BFSG-Anforderungsseite ein. So vermeiden Sie sowohl unnötigen Aufwand als auch eine teure Fehleinschätzung.
- Welche Strafen drohen bei Verstößen gegen das BFSG? Die zuständigen Marktüberwachungsbehörden können Bußgelder von bis zu 100.000 Euro verhängen (BFSG, §37). Bevor es dazu kommt, fordern die Behörden in der Regel jedoch zunächst zur Mängelbeseitigung innerhalb einer Frist auf. Reagiert ein Unternehmen nicht, kann im schwerwiegenden Fall sogar die Bereitstellung der nicht-konformen Dienstleistung oder des Produkts untersagt werden. Mindestens ebenso relevant ist das Abmahnrisiko: Verbraucherschutz- und Behindertenverbände sind klagebefugt und können Unterlassungsansprüche geltend machen. Hinzu kommt der Reputationsschaden, wenn ein Online-Angebot öffentlich als nicht barrierefrei kritisiert wird. Der beste Schutz ist ein dokumentierter Konformitätsnachweis. Mit einem strukturierten WCAG-Audit und einer fundierten Barrierefreiheitserklärung weisen Sie nach, dass Sie Ihren Pflichten ernsthaft nachkommen, was Behörden bei der Bewertung berücksichtigen.
- Gibt es Übergangsfristen für bestehende Websites? Ja, das BFSG sieht eine begrenzte Übergangsregelung vor. Dienstleistungen, die bereits vor dem 28. Juni 2025 erbracht wurden, dürfen unter bestimmten Voraussetzungen bis zum 28. Juni 2030 in der bisherigen Form weiterlaufen. Diese Frist wird oft missverstanden: Sie ist kein genereller Aufschub für alle bestehenden Websites. Neue Dienstleistungsverträge, die nach dem Stichtag geschlossen werden, müssen sofort konform sein. Ebenso muss jede wesentliche Änderung oder ein Relaunch nach dem 28. Juni 2025 die Anforderungen erfüllen. Wer also seine Website ohnehin überarbeitet, kann sich nicht auf die Übergangsfrist berufen. In der Praxis empfehlen wir, nicht auf 2030 zu warten. Eine frühzeitige barrierefreie Optimierung verteilt den Aufwand, vermeidet Zeitdruck und sichert Sie rechtlich besser ab.
- Muss mein Newsletter barrierefrei sein? Ein rein werblicher Marketing-Newsletter fällt nicht unmittelbar unter das BFSG. Anders sieht es bei transaktionalen E-Mails aus: Bestellbestätigungen, Versandbenachrichtigungen, Rechnungen oder Vertragsunterlagen sind Teil der digitalen Dienstleistung und sollten daher barrierefrei gestaltet sein, damit auch Screenreader-Nutzer Bestellungen nachvollziehen können. Unabhängig von der rechtlichen Pflicht ist barrierefreies E-Mail-Design ein Qualitätsmerkmal: ausreichende Kontraste, sinnvolle Alt-Texte, eine logische Lesereihenfolge und nicht zu kleine Schriftgrößen verbessern die Lesbarkeit für alle Empfänger und reduzieren Spam-Einstufungen. Gern beziehen wir Ihre Transaktionsmails in ein Audit ein und geben praxistaugliche Empfehlungen für Ihr E-Mail-Template. Sprechen Sie uns dazu im Erstgespräch an.
- Brauche ich eine formale Zertifizierung? Nein, das BFSG schreibt keine staatliche Zertifizierung oder behördliche Abnahme vor. Es gibt kein offizielles Prüfsiegel, das Sie vor Behörden vorlegen müssen. Entscheidend ist vielmehr, dass Sie die Konformität selbst dokumentieren und auf Anforderung nachweisen können. Konkret verlangt das Gesetz eine Barrierefreiheitserklärung auf Ihrer Website, die den Konformitätsstatus, die zugrunde gelegten Standards und einen Feedback-Mechanismus enthält. Diese Erklärung sollte ehrlich und überprüfbar sein, da unzutreffende Angaben das Abmahnrisiko eher erhöhen. Die belastbarste Grundlage dafür ist ein dokumentierter WCAG-Audit mit nachvollziehbarem Prüfbericht. Auf Wunsch erstellen wir daraus auch die Textbausteine für Ihre Barrierefreiheitserklärung.
Technische Fragen zu WCAG und Barrierefreiheit
- Was sind die WCAG und welche Version gilt? Die Web Content Accessibility Guidelines (WCAG) sind der international maßgebliche Standard für barrierefreie Webinhalte, herausgegeben vom World Wide Web Consortium (W3C). Sie sind um vier Prinzipien organisiert: wahrnehmbar, bedienbar, verständlich und robust. Die aktuelle Version ist WCAG 2.2, veröffentlicht im Oktober 2023. Die EN 301 549, auf die das BFSG verweist, nennt WCAG 2.1 AA als Mindeststandard. Wir empfehlen jedoch durchgängig WCAG 2.2 AA, weil diese Version neue Kriterien etwa zu Fokus-Sichtbarkeit, Zielgrößen für Touch-Bedienung und vereinfachter Authentifizierung ergänzt und damit dem aktuellen Stand der Technik entspricht. Wer heute auf 2.2 setzt, ist gegen die absehbare Aktualisierung der EN-Norm gut abgesichert. Wie wir diese Kriterien praktisch umsetzen, zeigen wir auf der Seite zur barrierefreien Webentwicklung.
- Was bedeutet WCAG 2.2 AA Konformität? WCAG definiert Erfolgskriterien auf drei Konformitätsstufen: A (Grundniveau), AA (empfohlener Standard) und AAA (höchste Stufe, oft nicht für alle Inhalte erreichbar). Konformität auf Stufe AA bedeutet, dass alle A- und alle AA-Kriterien erfüllt sind, etwa 4,5:1 Textkontrast, vollständige Tastaturbedienbarkeit, sinnvolle Alternativtexte und konsistente Navigation. AA ist die für die Praxis entscheidende Zielmarke: Sie wird von der EN 301 549 als Mindestanforderung referenziert und gilt international als anerkannter Standard. AAA wird selten vollständig verlangt, weil einzelne Kriterien für bestimmte Inhaltsarten nicht umsetzbar sind. Wichtig ist, dass Konformität seitenweit gilt: Schon ein nicht erreichbares Element kann die Konformität einer Seite kippen. Genau diese Vollständigkeit prüfen wir in unserem WCAG-Audit systematisch ab.
- Reichen automatisierte Barrierefreiheitstools aus? Nein, automatisierte Tests sind ein wichtiger Baustein, aber kein vollständiger Nachweis. Werkzeuge wie axe-core oder Lighthouse erkennen je nach Quelle nur etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme (Quelle: WebAIM). Sie finden zuverlässig technische Fehler wie fehlende Alt-Attribute oder unzureichende Kontraste, können aber Bedeutung und Kontext nicht beurteilen. Ob ein Alt-Text inhaltlich sinnvoll ist, ob die Lesereihenfolge eines Screenreaders logisch bleibt, ob Fehlermeldungen verständlich sind oder ob ein komplexes Widget per Tastatur bedienbar ist, lässt sich nur manuell prüfen, idealerweise mit echten assistiven Technologien. Deshalb kombinieren wir in unserem WCAG-Audit automatisierte Scans mit manueller Expertenbewertung und Screenreader-Tests. Erst diese Mischung liefert einen belastbaren Konformitätsnachweis.
- Was ist der Unterschied zwischen ARIA und semantischem HTML? Semantisches HTML transportiert Bedeutung direkt über native Elemente: Eine ` ist für den Screenreader ein Button, eine eine Navigation, eine eine Überschrift der zweiten Ebene. Diese Elemente bringen Rolle, Zustand und Tastaturverhalten von Haus aus mit, ganz ohne Zusatzcode. ARIA (Accessible Rich Internet Applications) ist eine Ergänzung für Fälle, in denen natives HTML nicht ausreicht, etwa bei komplexen Widgets wie Tabs, Akkordeons, Dropdowns oder Live-Regionen. ARIA fügt nur Semantik hinzu, ändert aber kein Verhalten: Eine mit role="button" ausgezeichnete ` muss Tastaturbedienung und Fokus weiterhin selbst implementieren. Die erste Regel von ARIA lautet daher: Kein ARIA verwenden, wenn ein natives Element die Aufgabe erfüllt (Quelle: W3C WAI). Wie wir das in der Praxis umsetzen, zeigen wir bei der barrierefreien Webentwicklung.
- Funktioniert Barrierefreiheit mit JavaScript-Frameworks? Ja, React, Vue, Angular und Svelte sind vollständig kompatibel mit barrierefreier Entwicklung. Ein Framework ist weder Hindernis noch automatische Lösung, es kommt auf die Umsetzung an. Statische Inhalte funktionieren meist problemlos, die typischen Stolpersteine entstehen durch die Dynamik moderner Single-Page-Anwendungen. Drei Bereiche brauchen besondere Aufmerksamkeit: das Fokusmanagement beim clientseitigen Routing (der Fokus muss nach einem Seitenwechsel sinnvoll gesetzt werden), die Ankündigung dynamischer Inhalte über ARIA-Live-Regionen sowie die korrekte Semantik selbstgebauter Komponenten. Werden diese Punkte ignoriert, erleben Tastatur- und Screenreader-Nutzer eine deutlich schlechtere Bedienung. Mit erprobten Patterns, getesteten Komponentenbibliotheken und automatisierten Tests im Build-Prozess lassen sich diese Herausforderungen zuverlässig adressieren. Details dazu auf unserer Seite zur barrierefreien Webentwicklung.
- Was sind Accessibility Overlays und warum funktionieren sie nicht? Accessibility Overlays sind JavaScript-Widgets, die per Code-Snippet eingebunden werden und versprechen, eine Website automatisch und nachträglich barrierefrei zu machen, oft kombiniert mit einem Bedienfeld für Schriftgröße oder Kontrast. Die Vorstellung, Compliance auf Knopfdruck zu erreichen, ist verlockend, hält aber der Praxis nicht stand. Führende Barrierefreiheitsexperten und Behindertenverbände warnen ausdrücklich vor diesen Tools (Quelle: W3C WAI, Overlay Fact Sheet). Sie beheben die strukturellen Ursachen im Quellcode nicht, kollidieren häufig mit den eigenen assistiven Technologien der Nutzer und können die Bedienung dadurch sogar verschlechtern. Es existieren bereits Klagen gegen Websites, die trotz Overlay nicht nutzbar waren. Das BFSG verlangt echte, strukturelle Barrierefreiheit im Quellcode. Statt Symptome zu kaschieren, beheben wir die Ursachen, nachhaltig und prüfbar. Wie wir dabei vorgehen, lesen Sie unter Leistungen.
Fragen zu Kosten und Projektablauf
- Was kostet ein Barrierefreiheitsaudit? Die Kosten richten sich nach dem Umfang, genauer: nach der Zahl unterschiedlicher Seitentypen und der Komplexität der Interaktionen, nicht nach der Gesamtzahl der URLs. Geprüft wird je ein repräsentatives Beispiel pro Template (Startseite, Kategorie, Produkt, Formular, Checkout und so weiter), da gleichartige Seiten meist dieselben Barrieren teilen. Ein Audit für eine mittelgroße Unternehmenswebsite mit etwa 15 bis 30 Seitentypen beginnt im niedrigen vierstelligen Bereich. Komplexe Online-Shops mit Checkout, Filtern und Kundenportal liegen entsprechend höher, weil dynamische Funktionen aufwendiger manuell zu testen sind. Eine seriöse Schätzung ist erst nach Sichtung Ihrer Seite möglich. Im kostenlosen Erstgespräch definieren wir den Scope und nennen einen verbindlichen Festpreis, damit Sie volle Kostentransparenz haben.
- Wie lange dauert die barrierefreie Optimierung? Ein Projekt durchläuft drei Phasen: Audit, Remediation (Behebung) und Nachprüfung. Für eine typische Unternehmenswebsite kalkulieren wir zwei bis drei Wochen Audit, zwei bis vier Wochen Remediation und etwa eine Woche Nachprüfung, also insgesamt rund fünf bis acht Wochen. Bei einem barrierefreien Shop mit Checkout, Filtern und Kundenkonto ist der Aufwand höher: drei bis fünf Wochen Audit, vier bis acht Wochen Remediation und ein bis zwei Wochen Nachprüfung, in Summe etwa acht bis fünfzehn Wochen. Die Remediation-Dauer hängt stark davon ab, ob Sie diese intern umsetzen oder an uns vergeben. Diese Zeiträume sind Erfahrungswerte (Projekterfahrung); der reale Verlauf hängt von Codequalität und Abstimmungstempo ab. Im Erstgespräch erstellen wir einen konkreten Zeitplan für Ihr Vorhaben.
- Ist eine nachträgliche Optimierung günstiger als ein Relaunch? In den meisten Fällen ja. Eine gezielte nachträgliche Optimierung ist in der Regel deutlich günstiger als ein kompletter Relaunch, weil Layout, Design und Inhalte erhalten bleiben und nur die im Audit identifizierten Barrieren behoben werden. Sie sparen damit auch die Kosten für Redesign, Migration und erneutes Testen aller Funktionen. Es gibt allerdings einen Kipppunkt: Wenn die Codebasis grundlegend problematisch ist, etwa veraltetes Markup, kaum semantische Struktur oder ein Theme ohne Erweiterbarkeit, kann punktuelle Reparatur teurer werden als eine barrierefreie Neuentwicklung. Dann zahlt sich der Relaunch langfristig aus. Welcher Weg für Sie wirtschaftlicher ist, lässt sich erst nach einem Blick in den Code seriös beurteilen. Genau diese Einschätzung liefert unser Audit, bevor Budget gebunden wird.
- Bieten Sie laufende Wartungsverträge an? Ja. Barrierefreiheit ist kein einmaliger Zustand: Jeder neue Inhalt, jedes Plugin-Update und jede Designänderung kann neue Barrieren einführen. Genau deshalb bieten wir Compliance-Monitoring als laufenden Service an, der den erreichten Stand absichert, statt ihn schleichend zu verlieren. Monatliche oder quartalsweise Pakete umfassen automatisierte Scans, manuelle Stichprobenprüfungen kritischer Funktionen, die Aktualisierung Ihrer Barrierefreiheitserklärung und ein festes Kontingent zur Behebung neu auftretender Barrieren. So bleibt Ihr Konformitätsnachweis dauerhaft belastbar. Den passenden Umfang stimmen wir auf Ihre Update-Frequenz ab, eine selten geänderte Website braucht weniger Betreuung als ein aktiver Shop. Sprechen Sie uns über die Leistungen oder direkt im Kontakt an.
- Können wir die Remediation auch intern durchführen? Ja, das ist ein häufig gewählter und oft wirtschaftlicher Weg. Viele Kunden setzen die Behebung mit dem eigenen Entwicklungsteam um, weil sie ihre Codebasis am besten kennen. Unser Audit-Bericht ist genau darauf ausgelegt: Er listet jede Barriere mit Verweis auf das verletzte WCAG-Kriterium, Schweregrad und einem konkreten, umsetzbaren Lösungsvorschlag. Damit das gelingt, empfehlen wir zwei flankierende Maßnahmen. Eine begleitende Schulung versetzt Ihr Team in die Lage, Lösungen korrekt umzusetzen und künftige Barrieren von vornherein zu vermeiden. Und eine abschließende Nachprüfung durch uns stellt sicher, dass die Korrekturen tatsächlich greifen und keine neuen Probleme entstanden sind. So behalten Sie Wissen und Kontrolle im Haus, profitieren aber von externer Prüfqualität, die für den Konformitätsnachweis entscheidend ist.
- Wie werden die Kosten kalkuliert: Festpreis oder nach Aufwand? Audits rechnen wir grundsätzlich als Festpreis ab, basierend auf dem zuvor gemeinsam definierten Scope. Da der Prüfumfang im Voraus klar abgrenzbar ist, gibt es hier keine Überraschungen, Sie wissen vorab genau, was die Analyse kostet. Bei der Remediation hängt das Modell vom Ergebnis des Audits ab. Grenzt der Bericht den Aufwand klar ein, bieten wir ebenfalls einen Festpreis an. Ist die Komplexität schwer vorhersehbar, etwa bei verschachtelten Drittanbieter-Integrationen, ist die Abrechnung nach Aufwand transparenter und meist günstiger für Sie. Monitoring läuft über feste monatliche oder quartalsweise Pauschalen. Welche Variante zu Ihrem Projekt passt, legen wir vor Beginn schriftlich fest. Eine erste Einordnung erhalten Sie im kostenlosen Erstgespräch.
Fragen zu spezifischen Website-Typen
- Welche Shop-Plattformen können Sie barrierefrei optimieren? Wir arbeiten plattformübergreifend, unter anderem mit Shopware Community Edition, CMS-basierten Shops, individuellen Lösungen auf Basis moderner JavaScript-Frameworks und Headless-Commerce-Architekturen. Die WCAG-Prinzipien gelten unabhängig von der Technik; was sich unterscheidet, ist der Weg, sie umzusetzen. Bei Standard-Plattformen liegt der Fokus häufig auf Theme-Anpassungen, der Konfiguration von Erweiterungen und der Anbindung an einen barrierefreien Checkout. Bei individuellen oder Headless-Lösungen können wir direkt im Quellcode ansetzen, was meist die saubersten Ergebnisse erlaubt. Kritische Bereiche eines Shops sind stets gleich: Produktfilter, Warenkorb, Checkout und Formulare. Genau diese prüfen und optimieren wir prioritär, mehr dazu auf der Seite zum barrierefreien Shop.
- Müssen auch Produktbilder barrierefrei beschrieben werden? Ja. Informative Produktbilder benötigen aussagekräftige Alt-Texte, die das Produkt und kaufrelevante Merkmale beschreiben, etwa Farbe, Material oder Variante. Ein guter Alt-Text bildet das ab, was sehende Nutzer dem Bild entnehmen, nicht mehr und nicht weniger. Rein dekorative Bilder erhalten dagegen ein leeres Alt-Attribut (alt=""), damit Screenreader sie überspringen und den Lesefluss nicht stören. Bei umfangreichen Katalogen mit Tausenden Artikeln ist eine manuelle Pflege kaum leistbar. Hier entwickeln wir eine systematische Alt-Text-Strategie, die etwa Produktdaten aus dem PIM oder Shop-Backend strukturiert in sinnvolle Bildbeschreibungen überführt. Wichtig ist die Abgrenzung: Der Produktname allein als Alt-Text reicht selten, redundante oder leere Beschreibungen ebenso wenig. Diese Feinheiten prüfen wir im WCAG-Audit konkret an Ihrem Sortiment.
- Wie barrierefrei sind CMS-Standardthemes? Das variiert stark, und man sollte sich nicht auf das Versprechen verlassen, ein Theme sei pauschal barrierefrei. Selbst gut gemeinte Themes weisen in der Praxis häufig grundlegende Mängel auf: fehlende Landmark-Strukturen, unzureichende Farbkontraste, nicht per Tastatur bedienbare Mega-Menüs, schlecht ausgezeichnete Slider oder fehlende Fokus-Indikatoren. Hinzu kommt, dass Konformität immer vom Gesamtbild abhängt: Auch ein solides Basis-Theme kann durch eigene Anpassungen, Page-Builder-Elemente oder eingebundene Module Barrieren bekommen. Der ausgelieferte Zustand Ihrer Live-Seite ist entscheidend, nicht der Demo-Stand des Themes. Ein Audit zeigt präzise, welche Anpassungen Ihr konkretes Theme braucht, und ob sich diese gezielt umsetzen lassen oder ein Wechsel sinnvoller ist. Mehr dazu unter barrierefreie Webentwicklung.
- Können Drittanbieter-Plugins und -Widgets Barrieren verursachen? Ja, und sie zählen zu den häufigsten und unangenehmsten Problemquellen, weil sie sich Ihrer direkten Kontrolle teilweise entziehen. Cookie-Banner, Chat-Widgets, Social-Media-Einbindungen, Bewertungs-Widgets und externe Zahlungsformulare weisen regelmäßig erhebliche Mängel auf: Fokus-Fallen, fehlende Tastaturbedienung oder unzugängliche Dialoge. Besonders kritisch sind dabei Cookie-Banner und Checkout-Schritte: Wenn schon das einwilligungspflichtige Overlay nicht mit der Tastatur schließbar ist, blockiert es im Zweifel die gesamte Seite für betroffene Nutzer. Deshalb beziehen wir alle eingebundenen Drittanbieter-Komponenten in unser WCAG-Audit ein. Wo ein Anbieter keine barrierefreie Lösung bietet, empfehlen wir Konfigurationsanpassungen oder eine zugängliche Alternative.
- Was ist mit PDFs und herunterladbaren Dokumenten? PDFs, die Teil Ihrer Dienstleistung sind, etwa Rechnungen, Vertragsdokumente, Anleitungen oder Formulare zum Download, sollten ebenfalls barrierefrei sein. Maßgeblich ist hier das Tagged-PDF-Format mit strukturierten Überschriften, Alt-Texten für Bilder, einer korrekten Lesereihenfolge, ausgezeichneten Tabellen und einer durchsuchbaren Textebene (kein reiner Scan). Viele PDFs entstehen durch Export aus Textverarbeitung oder Layout-Programmen und sind dabei nicht automatisch zugänglich. Gescannte Dokumente ohne Texterkennung sind für Screenreader sogar völlig unbrauchbar. Wir prüfen bestehende Dokumente auf Konformität und beraten, wie Sie barrierefreie PDFs künftig direkt im Erstellungsprozess erzeugen, häufig die nachhaltigere Lösung als nachträgliche Reparatur. Eine begleitende Schulung für Ihr Redaktionsteam ergänzt das sinnvoll.
- Muss auch mein Intranet barrierefrei sein? Aus Sicht des BFSG nicht unmittelbar: Das Gesetz adressiert Produkte und Dienstleistungen für Verbraucher, rein interne Systeme wie ein Mitarbeiter-Intranet fallen nicht in seinen Anwendungsbereich. Damit ist das Thema aber nicht erledigt. Arbeitgeber können nach dem Allgemeinen Gleichbehandlungsgesetz (AGG) und arbeitsrechtlichen Vorgaben verpflichtet sein, Beschäftigten mit Behinderung barrierefreie Arbeitsmittel bereitzustellen, ein unzugängliches Intranet kann hier zum Problem werden. Hinzu kommt: Wer barrierefreies Arbeiten ermöglicht, vergrößert den Bewerberpool und stärkt die Inklusion im Unternehmen. Wir prüfen auf Wunsch auch interne Anwendungen nach denselben WCAG-Maßstäben. Ob und in welchem Umfang das für Sie sinnvoll ist, klären wir gern im Erstgespräch.
Fragen zu Schulungen und Teamaufbau
- Welche Vorkenntnisse brauchen Teilnehmer Ihrer Schulungen? Das hängt vom Format ab. Für Entwickler-Schulungen genügen solide Grundkenntnisse in HTML, CSS und JavaScript. Für Designer-Schulungen ist Erfahrung mit gängigen Design-Werkzeugen hilfreich, für Content-Schulungen die routinierte Arbeit mit Ihrem CMS. Spezielles Barrierefreiheits-Vorwissen ist bei keinem Format Voraussetzung, genau das vermitteln wir ja. Wichtiger als Vorkenntnisse ist die Rollenorientierung: Eine Schulung trifft nur dann ins Schwarze, wenn sie an den realen Aufgaben der Teilnehmer ansetzt. Deshalb stimmen wir Inhalte und Tiefe vorab mit Ihnen ab. Wir passen das Niveau flexibel an den Wissensstand Ihres Teams an, vom ersten Überblick bis zur vertieften Praxis. Eine Übersicht der Formate finden Sie auf der Seite zu unseren Schulungen.
- Finden Schulungen vor Ort oder remote statt? Beides ist möglich, und beide Formate funktionieren in der Praxis sehr gut. Remote-Schulungen per Videokonferenz nutzen Screensharing, gemeinsame Code-Editoren und Live-Übungen und stehen Präsenzformaten inhaltlich in nichts nach. Sie sparen Reisezeit und lassen sich leichter über verteilte Teams hinweg organisieren. Für Remote-Formate empfehlen wir kürzere Blöcke von drei bis vier Stunden, verteilt über mehrere Tage, statt eines langen Ganztags. Das hält die Konzentration hoch und gibt den Teilnehmern Zeit, das Gelernte zwischendurch im eigenen Projekt auszuprobieren. Vor-Ort-Workshops sind dann sinnvoll, wenn intensive gemeinsame Arbeit am Code oder Design gewünscht ist. Was für Ihr Team passt, klären wir bei der Planung Ihrer Schulung.
- Wie nachhaltig sind die Schulungseffekte? Nachhaltigkeit entsteht nicht im Seminarraum, sondern durch Anwendung im Alltag. Eine reine Wissensvermittlung verpufft, wenn sie nicht in konkrete Arbeitsabläufe übergeht. Deshalb sind unsere Schulungen bewusst praxisorientiert und arbeiten mit Ihren realen Projekten und Komponenten statt mit abstrakten Beispielen. Damit der Effekt bleibt, empfehlen wir drei Dinge: die Integration automatisierter Barrierefreiheitstests in die Entwicklungspipeline (damit Regeln greifen, nicht nur gute Vorsätze), klare Verantwortlichkeiten und Auffrischungen nach sechs bis zwölf Monaten, auch weil sich Standards weiterentwickeln. Auf Wunsch verbinden wir die Schulung mit einem späteren Audit, das objektiv zeigt, wie sich die Barrierefreiheit Ihrer Projekte nach der Qualifizierung entwickelt hat.
- Können verschiedene Rollen gemeinsam geschult werden? Ja, in Teilen ist das sogar ausdrücklich sinnvoll. Für die Grundlagen, also den WCAG-Überblick, die vier Prinzipien und das Verständnis dafür, warum Barrierefreiheit zählt, profitieren alle Rollen von einer gemeinsamen Session. Ein geteiltes Grundverständnis verbessert die spätere Zusammenarbeit zwischen Design, Entwicklung und Redaktion erheblich. Für die vertiefenden Module empfehlen wir dagegen rollenspezifische Gruppen. Entwickler arbeiten an semantischem Code und ARIA, Designer an Kontrasten, Fokus-Zuständen und Komponenten, Redakteure an verständlichen Texten, Alt-Texten und korrekter Struktur im CMS. Werkzeuge und Übungen unterscheiden sich hier zu stark für ein gemeinsames Format. Diese Kombination aus gemeinsamem Fundament und rollenspezifischer Vertiefung hat sich bewährt. Den passenden Zuschnitt planen wir mit Ihnen über die Schulungen.
- Bieten Sie auch Einzel-Coachings für Entwickler an? Ja. Neben Gruppenschulungen bieten wir Einzel-Coachings an, die sich besonders für kleine Teams oder für die gezielte Vertiefung einzelner Entwickler eignen. Der große Vorteil: Wir arbeiten direkt an Ihrem realen Code und Ihren konkreten Problemstellungen, nicht an Beispielprojekten. Besonders wirksam ist dieses Format, wenn jemand aktuell eine schwierige Komponente umsetzt, etwa ein komplexes Formular, ein modales Dialogsystem oder ein eigenes Widget, und unmittelbare, praxisnahe Unterstützung braucht. So entsteht Wissen genau dort, wo es gebraucht wird. Viele Kunden kombinieren ein Coaching mit einem vorausgehenden WCAG-Audit, sodass die Sitzungen sich gezielt auf die identifizierten Schwachstellen konzentrieren.
- Erhalten die Teilnehmer Schulungsmaterialien? Ja. Jeder Teilnehmer erhält begleitende Unterlagen, praxistaugliche Checklisten und kompakte Referenzkarten, die im Arbeitsalltag als Nachschlagewerk dienen. Gerade diese Materialien sorgen dafür, dass das Gelernte abrufbar bleibt, wenn die Schulung Wochen zurückliegt. Remote-Schulungen können auf Wunsch aufgezeichnet werden, sodass Inhalte später erneut angesehen oder an Kollegen weitergegeben werden können, die nicht teilnehmen konnten. Das erhöht die Reichweite einer einzelnen Schulung im Team spürbar. Zusätzlich beantworten wir Follow-up-Fragen in den 30 Tagen nach der Schulung kostenfrei, weil die meisten praktischen Fragen erst beim Anwenden auftauchen. Details zu Inhalten und Ablauf finden Sie unter Schulungen.
Fragen zur langfristigen Barrierefreiheitsstrategie
- Wie verändert sich die Barrierefreiheitslandschaft in den kommenden Jahren? Die Standards entwickeln sich weiter, aber nicht sprunghaft. Das W3C arbeitet an WCAG 3.0, die einen grundlegend neuen Bewertungsansatz verfolgt: Statt binärer Pass/Fail-Prüfung pro Kriterium soll ein abgestuftes, ergebnisorientiertes Scoring-Modell treten, das die tatsächliche Nutzbarkeit stärker gewichtet. Wichtig für die Planung: WCAG 3.0 befindet sich im Draft-Stadium, eine Verabschiedung wird nicht vor 2027 erwartet, und selbst danach folgt eine lange Übergangszeit. Die für das BFSG relevante EN 301 549 dürfte zunächst auf WCAG 2.2 nachziehen. Das bedeutet: Wer heute auf WCAG 2.2 AA setzt, investiert nicht in eine Sackgasse, sondern baut ein solides Fundament. Eine sauber umgesetzte Barrierefreiheit überträgt sich weitgehend auf künftige Standards. Wie wir das praktisch verankern, lesen Sie unter Leistungen.
- Wie integrieren wir Barrierefreiheit dauerhaft in unsere Entwicklungsprozesse? Der Schlüssel ist, Barrierefreiheit als festen Bestandteil des Prozesses zu verankern, nicht als nachgelagerte Kür. In der Praxis tragen drei Maßnahmen den größten Teil dazu bei. Erstens Schulungen für alle relevanten Rollen, damit Barrierefreiheit schon beim Entwurf mitgedacht wird statt erst beim Testen. Zweitens automatisierte Barrierefreiheitstests in der CI/CD-Pipeline, die bei jedem Commit grobe Regressionen abfangen, bevor sie in Produktion gehen. Drittens regelmäßige manuelle Audits, mindestens jährlich, für all jene Aspekte, die kein automatisiertes Werkzeug zuverlässig beurteilen kann. Ergänzend hilft, Akzeptanzkriterien für Barrierefreiheit in die Definition-of-Done aufzunehmen. So wird sie zur Routine. Bei der Einführung dieser Prozesse unterstützen wir Sie konkret, mehr dazu unter Leistungen.
- Lohnt sich Barrierefreiheit auch für Websites mit wenig Traffic? Ja, und zwar aus mehreren Gründen. Der wichtigste ist rechtlich: Die Pflicht nach BFSG bemisst sich nicht an der Besucherzahl, sondern an Art und Anbieter der Dienstleistung. Eine wenig besuchte Seite ist also nicht automatisch ausgenommen, das Abmahn- und Bußgeldrisiko besteht unabhängig vom Traffic. Hinzu kommen handfeste Sekundäreffekte: Barrierefreie Strukturen, sauberes semantisches Markup und gute Bedienbarkeit verbessern auch die allgemeine Nutzererfahrung und wirken sich positiv auf die SEO-Performance aus, was mittelfristig sogar Traffic gewinnen kann. Gleichzeitig ist der Aufwand bei kleinen Seiten mit wenigen Seitentypen meist überschaubar, weil wenige Templates geprüft und behoben werden müssen. Eine realistische Einschätzung für Ihre Seite geben wir im Erstgespräch.
- Was passiert, wenn wir nur teilweise konform sind? Teilkonformität ist in der Realität der Normalfall, gerade bei großen, gewachsenen Websites, und sie ist deutlich besser als Untätigkeit. Entscheidend ist, wie Sie damit umgehen: Transparenz und ein erkennbarer Plan sind hier Ihr bester Schutz. In der Barrierefreiheitserklärung können Sie den Status offen als teilweise konform ausweisen, die noch nicht zugänglichen Bereiche konkret benennen und einen realistischen Zeitrahmen für deren Behebung darstellen. Wichtig ist, dass dieser Plan dann auch eingehalten wird. Marktüberwachungsbehörden berücksichtigen voraussichtlich, ob ein Unternehmen ernsthafte, nachweisbare Anstrengungen unternimmt. Wir helfen, die Behebung sinnvoll zu priorisieren, zuerst die Barrieren, die Kernfunktionen blockieren. Diese Roadmap leiten wir direkt aus dem WCAG-Audit ab.
- Wie messen wir den Fortschritt unserer Barrierefreiheitsbemühungen? Fortschritt sollte mit mehreren, sich ergänzenden Kennzahlen gemessen werden, denn eine einzelne Zahl kann täuschen. Wir empfehlen drei Metriken: den WCAG-Konformitätsgrad (Anteil erfüllter Erfolgskriterien), die Anzahl kritischer Barrieren im Zeitverlauf und den automatisierten Accessibility-Score als schnellen Frühindikator. Wichtig ist die richtige Gewichtung: Automatisierte Scores eignen sich, um Regressionen früh zu erkennen, sagen aber wenig über die tatsächliche Nutzbarkeit aus, dafür zählt der Trend der kritischen, manuell verifizierten Barrieren. Ein hoher Tool-Score bei gleichzeitig unbedienbarem Checkout wäre trügerisch. Unser Compliance-Monitoring liefert diese Werte regelmäßig und macht den Fortschritt nachvollziehbar dokumentierbar, was zugleich Ihren Konformitätsnachweis stützt. Mehr dazu unter Leistungen.
- Können wir Barrierefreiheit als Marketingvorteil nutzen? Ja, allerdings mit Augenmaß und der nötigen Ehrlichkeit. Barrierefreiheit erreicht eine relevante und oft unterschätzte Zielgruppe: Menschen mit dauerhaften oder situativen Einschränkungen sowie ältere Nutzer. Die dafür nötige Klarheit und Bedienbarkeit verbessert die Erfahrung für alle Besucher und stärkt damit Konversion und Markenwahrnehmung. Ganz konkret kann Barrierefreiheit auch ein Vergabekriterium sein: In Ausschreibungen öffentlicher Auftraggeber wird BITV-2.0-Konformität häufig vorausgesetzt, wer sie nachweisen kann, ist im Vorteil. Entscheidend ist Maß: Vermeiden Sie übertriebene oder absolute Versprechen, denn Barrierefreiheit ist ein fortlaufender Prozess, kein einmal erreichter Endzustand. Glaubwürdiger als Werbeslogans ist eine ehrliche Barrierefreiheitserklärung, gestützt auf ein echtes WCAG-Audit.
Frage nicht dabei?
Schreiben Sie uns — wir antworten persönlich und unverbindlich.