WCAG-Verstöße bei responsiven Websites erkennt man durch eine Kombination aus automatisierten Scans und manuellen Tests, die über verschiedene Bildschirmgrößen und Gerätetypen hinweg durchgeführt werden. Responsive Layouts verändern Struktur, Reihenfolge und Sichtbarkeit von Elementen je nach Viewport, was dazu führt, dass Barrierefreiheitsprobleme auf dem Desktop unsichtbar bleiben, auf dem Smartphone jedoch deutlich auftreten. Dieser Artikel beantwortet die häufigsten Fragen rund um die WCAG-Prüfung responsiver Websites, von typischen Fehlermustern bis hin zu rechtlichen Konsequenzen nach dem Barrierefreiheitsstärkungsgesetz (BFSG).
Welche WCAG-Verstöße treten bei responsiven Websites besonders häufig auf?
Bei responsiven Websites treten WCAG-Verstöße besonders häufig in den Bereichen Farbkontrast, Tastaturnavigation, Textskalierung und fehlende Alt-Texte auf. Hinzu kommen layoutbedingte Probleme, die erst bei kleinen Bildschirmbreiten sichtbar werden, etwa überlagernde Elemente, nicht erreichbare Schaltflächen oder kollabierte Navigationsbereiche ohne korrekte ARIA-Auszeichnung.
Konkret gehören folgende Fehlertypen zu den häufigsten Befunden bei responsiven Seiten:
- Unzureichende Farbkontraste: Texte, die auf dem Desktop gut lesbar erscheinen, werden in mobilen Layouts auf andersfarbigen Hintergründen dargestellt und unterschreiten dann den WCAG-Mindestkontrastwert von 4,5:1 (WCAG 2.1, Erfolgskriterium 1.4.3).
- Fehlende oder fehlerhafte Alt-Texte: Bilder, die per CSS oder JavaScript je nach Viewport ausgetauscht werden, verlieren dabei häufig ihre Textalternative.
- Hamburger-Menüs ohne Tastaturzugang: Mobil eingeklappte Navigationen sind oft nicht per Tastatur bedienbar oder geben dem Screenreader keine Auskunft über ihren Zustand (geöffnet/geschlossen).
- Touch-Ziele zu klein: Schaltflächen und Links, die auf dem Desktop ausreichend groß sind, schrumpfen in mobilen Ansichten unter die empfohlene Mindestgröße von 44×44 Pixeln.
- Falsche DOM-Reihenfolge: Wenn visuelle Reihenfolge und die Reihenfolge im Quellcode auseinanderfallen, navigieren Screenreader-Nutzer durch eine inhaltlich verwirrende Struktur.
- Fehlende Fokusindikatoren: Sichtbare Fokusrahmen werden in mobilen Stylesheets häufig per
outline: noneentfernt, was die Tastaturbedienbarkeit erheblich einschränkt.
Diese Probleme entstehen oft nicht durch Nachlässigkeit, sondern weil responsive Layouts dynamisch sind: Ein Element, das in einem Viewport korrekt ausgezeichnet ist, kann in einem anderen Kontext seine Barrierefreiheitseigenschaften verlieren.
Warum sind responsive Websites schwieriger auf WCAG-Konformität zu prüfen?
Responsive Websites sind schwieriger auf WCAG-Konformität zu prüfen, weil sich Layout, Sichtbarkeit und Interaktionsverhalten von Elementen je nach Bildschirmgröße grundlegend verändern. Ein automatisierter Scan, der nur einen Viewport testet, kann Verstöße übersehen, die ausschließlich in der mobilen oder der Tablet-Ansicht auftreten.
Der Kern des Problems liegt in der Natur responsiver Designs: CSS-Medienabfragen, JavaScript-basierte Komponentenwechsel und flexible Grid-Systeme erzeugen technisch unterschiedliche Seiten, die denselben HTML-Quellcode teilen. Das bedeutet:
- Ein Navigationselement kann auf dem Desktop sichtbar und korrekt ausgezeichnet sein, auf dem Smartphone jedoch hinter einem Hamburger-Icon verschwinden und dabei seinen ARIA-Status verlieren.
- Bilder können per CSS-Hintergrundbild in bestimmten Viewports ausgetauscht werden, ohne dass eine Textalternative vorhanden ist.
- Interaktive Elemente wie Akkordeons oder Tabs verhalten sich auf Touch-Geräten anders als mit Maus und Tastatur.
Erschwerend kommt hinzu, dass viele automatisierte Barrierefreiheitstests nur einen einzigen Viewport simulieren, in der Regel die Desktop-Ansicht. Manuelle Tests müssen deshalb gezielt auf verschiedenen Bildschirmgrößen durchgeführt werden. Schätzungen, unter anderem aus einer Übersicht der Universität Bielefeld, gehen davon aus, dass automatisierte Tests nur etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme erfassen. Bei responsiven Seiten kann diese Quote je nach Komplexität des Layouts noch niedriger ausfallen.
Wie testet man WCAG-Konformität über verschiedene Bildschirmgrößen hinweg?
Um WCAG-Konformität über verschiedene Bildschirmgrößen hinweg zu testen, kombiniert man automatisierte Scans auf mehreren Viewport-Größen mit gezielten manuellen Tests auf realen Geräten oder Browser-Emulatoren. Nur diese Kombination deckt sowohl technische Fehler im HTML-Code als auch nutzungsbezogene Barrieren zuverlässig auf.
Automatisierte Tests als Ausgangspunkt
Automatisierte Tools prüfen den HTML-Code auf strukturelle Fehler, die Barrierefreiheit unmöglich machen oder erheblich behindern: fehlende Landmark-Bereiche, falsch verwendete Überschriftenhierarchien, fehlende Beschriftungen von Bildern und Links sowie fehlerhafte ARIA-Attribute. Führen Sie Scans mindestens in zwei Viewport-Konfigurationen durch, einem Desktop-Viewport (ab 1280 Pixel Breite) und einem mobilen Viewport (360 bis 414 Pixel Breite), um layoutbedingte Unterschiede zu erfassen.
Manuelle Tests für nicht automatisierbar prüfbare Kriterien
Viele WCAG-Anforderungen lassen sich nur manuell überprüfen. Dazu gehören:
- Tastaturbedienbarkeit: Navigieren Sie die gesamte Website ausschließlich mit der Tabulatortaste, den Pfeiltasten und der Eingabetaste. Prüfen Sie, ob alle interaktiven Elemente erreichbar sind und ob der Fokusindikator stets sichtbar bleibt.
- Screenreader-Test: Testen Sie mit NVDA (Windows) oder VoiceOver (macOS/iOS), ob Inhalte in einer sinnvollen Reihenfolge vorgelesen werden und ob Statusänderungen, etwa beim Öffnen eines Menüs, korrekt angekündigt werden.
- Textskalierung: Vergrößern Sie die Browserdarstellung auf 200 Prozent und prüfen Sie, ob Inhalte noch lesbar und bedienbar sind, ohne dass horizontales Scrollen notwendig wird (WCAG 1.4.4).
- Touch-Bedienbarkeit: Testen Sie auf einem realen Smartphone, ob alle Schaltflächen und Links leicht tippbar sind und ob keine Elemente unbeabsichtigt überlagert werden.
Die Web Accessibility Initiative (WAI) stellt eine Anleitung für einen manuellen Schnelltest mit einer Checkliste der wichtigsten Punkte zur Verfügung. Diese eignet sich gut als Einstieg, bevor ein umfassender Expertentest durchgeführt wird. Wichtig: Ein gutes Ergebnis im automatisierten Scan bedeutet nicht, dass keine Barrieren vorhanden sind. Es zeigt lediglich, dass die automatisiert prüfbaren Kriterien erfüllt wurden.
Welche Tools helfen beim Erkennen von Barrierefreiheitsverstößen auf responsiven Seiten?
Beim Barrierefreiheit testen auf responsiven Seiten helfen automatisierte Scan-Tools, Browser-Erweiterungen und manuelle Hilfsmittel. Kein einzelnes Tool deckt alle Probleme ab, weshalb eine Kombination aus mehreren Werkzeugen empfehlenswert ist.
- Automatisierte Scan-Plattformen: Tools, die auf der Open-Source-Bibliothek axe-core basieren, prüfen den HTML-Code systematisch auf WCAG-Konformität. Sie erkennen strukturelle Fehler wie fehlende Alt-Texte, fehlerhafte ARIA-Attribute und Kontrastprobleme. Solche Plattformen können Unterseiten in einem Durchgang scannen und Ergebnisse nach Schweregrad priorisieren.
- Browser-Erweiterungen: axe DevTools, WAVE oder Lighthouse (in Chrome DevTools integriert) ermöglichen schnelle Einzelseitentests direkt im Browser. Mit den Entwicklerwerkzeugen lässt sich der Viewport auf mobile Größen umschalten, um responsive Ansichten zu testen.
- Kontrast-Checker: Spezialisierte Tools wie der WebAIM Contrast Checker oder der APCA-Rechner prüfen, ob Vordergrund- und Hintergrundfarben ausreichend kontrastieren, auch für Texte in verschiedenen Schriftgrößen.
- Screenreader: NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) und VoiceOver (macOS/iOS, integriert) sind unverzichtbar für manuelle Tests der Screenreader-Kompatibilität.
- Browser-Entwicklerwerkzeuge: Die Accessibility-Panels in Chrome und Firefox zeigen den Accessibility Tree an und helfen dabei, ARIA-Rollen und -Zustände zu überprüfen.
Für eine vollständige BITV-Prüfung nach dem anerkannten BITV-Test-Prüfverfahren sind zertifizierte Prüforganisationen zuständig, die im BITV-Test-Prüfverbund organisiert sind. Automatisierte Tools sind dabei als Vorstufe sinnvoll: Offensichtliche Fehler sollten vor einem kostenpflichtigen Expertentest bereits behoben sein.
Was sind die rechtlichen Folgen von WCAG-Verstößen nach dem BFSG?
Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet Unternehmen, die bestimmte digitale Produkte und Dienstleistungen anbieten, zur Einhaltung von Barrierefreiheitsanforderungen, die sich an den WCAG-Standards orientieren. Bei Verstößen drohen behördliche Maßnahmen sowie wettbewerbsrechtliche Konsequenzen. Spezifische Rechtsfolgen im Einzelfall sollten stets mit einer qualifizierten Rechtsberatung geklärt werden.
Das BFSG setzt den European Accessibility Act (EAA) in deutsches Recht um und gilt seit Juni 2025 für eine Vielzahl von Produkten und Dienstleistungen, darunter E-Commerce-Websites, Banking-Apps und Telekommunikationsdienste. Die wichtigsten rechtlichen Konsequenzen im Überblick:
- Behördliche Durchsetzung: Marktüberwachungsbehörden können Verstöße feststellen und Abhilfemaßnahmen anordnen. Unternehmen, die keine Barrierefreiheitserklärung veröffentlichen oder nachweislich keine Maßnahmen ergreifen, setzen sich einem erhöhten Risiko aus.
- Wettbewerbsrechtliche Abmahnungen: Verstöße gegen das BFSG können als unlautere Wettbewerbshandlungen gewertet werden, was Abmahnungen durch Mitbewerber oder Verbraucherschutzverbände ermöglicht.
- Reputationsrisiko: Fehlende Barrierefreiheit kann öffentlich sichtbar werden, insbesondere wenn Beschwerden über die im BFSG vorgesehene Schlichtungsstelle eingereicht werden.
Für viele Unternehmen ist die Barrierefreiheitserklärung eine der ersten konkreten Pflichten: Sie muss den Stand der WCAG-Konformität, bekannte Unvereinbarkeiten und Kontaktinformationen ausweisen. Automatisierte Scans können dabei helfen, den Ist-Zustand zu dokumentieren und als Grundlage für diese Erklärung zu dienen. Sie ersetzen jedoch keine rechtliche Bewertung durch einen Fachanwalt oder qualifizierten Barrierefreiheitsberater.
Wie lassen sich WCAG-Prüfungen bei vielen Websites effizient skalieren?
WCAG-Prüfungen lassen sich bei vielen Websites effizient skalieren, indem automatisierte Scan-Plattformen eingesetzt werden, die mehrere Websites gleichzeitig überwachen, Ergebnisse zentral zusammenführen und bei Änderungen automatisch benachrichtigen. Manuelle Tests werden dabei auf kritische Seiten und Funktionen konzentriert, die automatisiert nicht vollständig prüfbar sind.
Für Agenturen, externe Berater und Compliance-Teams, die regelmäßig viele Websites betreuen, ist ein rein manueller Ansatz wirtschaftlich nicht tragfähig. Eine skalierbare Prüfstrategie umfasst typischerweise folgende Bausteine:
- Zentrales Monitoring: Eine Plattform überwacht alle betreuten Websites dauerhaft und löst Benachrichtigungen aus, sobald neue Barrieren erkannt werden, etwa nach einem Website-Update.
- Priorisierung nach Schweregrad: Gefundene Probleme werden nach ihrer Auswirkung auf Nutzer mit Behinderungen eingestuft. So können Teams zuerst die kritischsten Barrieren beheben, anstatt alle Befunde gleichrangig zu behandeln.
- Standardisierte Reports: Einheitliche Berichte, die nach WCAG-Erfolgskriterien strukturiert sind und konkrete Handlungsempfehlungen enthalten, ermöglichen es, Ergebnisse effizient an Kunden oder Entwicklungsteams zu kommunizieren.
- Dokumentation des Fortschritts: Ein Verlauf der Scan-Ergebnisse macht sichtbar, ob ergriffene Maßnahmen den gewünschten Effekt haben, was für regelmäßige Reportings an Kunden oder interne Stakeholder unerlässlich ist.
- Integration manueller Befunde: Da automatisierte Tests nur einen Teil der WCAG-Kriterien abdecken, sollte die Plattform auch die Dokumentation manuell festgestellter Probleme ermöglichen, um ein vollständiges Bild zu erhalten.
Besonders für Agenturen, die nach dem BFSG nun aktiv Barrierefreiheitsdienstleistungen anbieten müssen, ist eine Accessibility Software mit Monitoring-Funktion ein entscheidender Faktor, um das eigene Angebot wirtschaftlich skalierbar zu gestalten.
Wie decareto Sie bei der WCAG-Prüfung responsiver Websites unterstützt
Wir bei decareto haben eine SaaS-Plattform entwickelt, die genau an den Punkten ansetzt, die WCAG-Prüfungen bei responsiven Websites komplex und aufwendig machen. Unsere Software unterstützt Agenturen, Compliance-Teams und externe Berater dabei, Barrierefreiheitsprüfungen strukturiert, nachvollziehbar und skalierbar durchzuführen:
- Automatisierter Accessibility-Scan: Wir setzen die bewährte Open-Source-Bibliothek axe-core ein, um Websites inklusive Unterseiten und passwortgeschützter Bereiche auf WCAG-Konformität zu prüfen. Scans, die manuell Stunden dauern würden, sind bei uns in Minuten abgeschlossen.
- Priorisierung nach Schweregrad: Jedes gefundene Problem wird nach seiner Kritikalität eingestuft und mit einem WCAG-Erfolgskriterium verknüpft. So sehen Sie auf einen Blick, wo der dringendste Handlungsbedarf besteht.
- Konkrete Handlungsempfehlungen: Zu jedem Befund liefern wir klare Hinweise zur Behebung, inklusive HTML-Kontext und Screenshot des betroffenen Elements. Das macht unsere Reports zu einem praktischen Maßnahmenplan für Entwicklungsteams.
- Dauerhaftes Monitoring: Wir überwachen Ihre Websites kontinuierlich und benachrichtigen Sie automatisch, wenn nach einem Update neue Barrieren auftreten. So bleibt der Compliance-Status stets dokumentiert.
- Whitelabel-Reports: Externe Dienstleister können Berichte unter eigenem Logo an ihre Kunden weitergeben, was den professionellen Auftritt stärkt.
- Kombinierte Prüfung: Barrierefreiheit und Datenschutz werden in einem einzigen Scan-Durchgang geprüft, was den Gesamtaufwand für Website-Audits erheblich reduziert.
Wichtig: Unsere automatisierten Scans erfassen typischerweise einen wesentlichen Teil der prüfbaren WCAG-Kriterien, ersetzen jedoch keine vollständige manuelle Prüfung und keine Rechtsberatung. Ein gutes Scan-Ergebnis bedeutet, dass keine automatisiert erkennbaren Fehler gefunden wurden, nicht, dass die Website vollständig barrierefrei im rechtlichen Sinne ist.
Möchten Sie sehen, wie viele WCAG-Verstöße Ihre Websites oder die Ihrer Kunden aufweisen? Jetzt kostenlos starten und in wenigen Minuten einen vollständigen Accessibility-Report erhalten.
Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.
Ähnliche Artikel
- Wie laufen Crawling, Analyse und Reporting bei einem DSGVO-Website-Scan technisch ab?
- Wie setzt man Cookies und Tracker DSGVO-konform ein und wie prüft man die technische Umsetzung?
- Wie erkenne ich DSGVO-Verstöße durch eingebettete Social-Media-Plugins?
- Wie lässt sich ein Barrierefreiheits-Report für Kunden aufbereiten?
- Welche DSGVO-Anforderungen gelten für internationale Websites mit deutschsprachigem Publikum?


