Mobile Barrierefreiheit testen: Warum Desktop-Scanner nicht ausreichen

Die meisten automatisierten Barrierefreiheits-Scanner prüfen Ihre Website ausschließlich in der Desktop-Ansicht. Das Problem: Viele Accessibility-Issues treten nur bei bestimmten Bildschirmgrößen auf. Wenn Sie nur den Desktop testen, übersehen Sie einen erheblichen Teil der Barrieren, die Ihre mobilen Nutzer täglich erleben.

Das blinde Auge der Branche: Desktop-only-Scanning

Schauen Sie sich die gängigen Tools an — WAVE, Lighthouse, Pa11y, die meisten Browser-Extensions — sie alle scannen genau ein Viewport: das aktuelle Browserfenster. Auch viele Enterprise-Lösungen fokussieren primär auf Desktop-Rendering.

Das war vielleicht 2018 vertretbar. Heute kommen in Deutschland rund 45 % des Web-Traffics von mobilen Geräten (StatCounter, 2025–2026), weltweit sind es über 60 %. Und mit dem BFSG (Barrierefreiheitsstärkungsgesetz), das seit Juni 2025 gilt, müssen digitale Produkte für alle Nutzer barrierefrei sein — egal ob am Desktop, Tablet oder Smartphone.

Welche Probleme nur mobil auftreten

Zu kleine Tipp-Zielgrößen

WCAG 2.2 fordert in Erfolgskriterium 2.5.8 (Target Size Minimum) eine Mindestgröße von 24×24 CSS-Pixeln für interaktive Elemente. Buttons, die am Desktop komfortabel per Maus erreichbar sind, können auf einem Touchscreen zu klein und zu nah beieinander sein.

Ein Desktop-Scanner erkennt dieses Problem nicht, weil die Elemente im Desktop-Layout ausreichend Platz haben — erst im mobilen Layout werden sie zusammengeschoben.

Hover-abhängige Interaktionen

Tooltips, Dropdown-Menüs und Hover-Effekte funktionieren auf Touch-Geräten grundsätzlich anders — oder gar nicht. WCAG 2.1 Erfolgskriterium 1.4.13 (Content on Hover or Focus) verlangt, dass hover-basierte Inhalte auch ohne Maus zugänglich sind.

Wenn Ihr Scanner nur die Desktop-Version prüft, meldet er keine Fehler bei Hover-Interaktionen, die auf Mobilgeräten komplett versagen.

Responsive Layouts mit Accessibility-Problemen

Responsive Design ist Standard — aber nicht jedes responsive Layout bleibt barrierefrei:

• Hamburger-Menüs ohne korrektes aria-expanded
• Überlaufende Texte mit overflow: hidden die Inhalte abschneiden
• Gestapelte Elemente mit falscher Tab-Reihenfolge
• Ausgeblendete Skip-Links die auf Mobile nicht funktionieren
• Touch-Gesten ohne Tastatur-Alternative

Diese Probleme existieren nur im mobilen/Tablet-Viewport und bleiben bei Desktop-Scans unsichtbar.

Fehlende Viewport-Meta-Tags

Ohne korrekt konfiguriertes <meta name="viewport"> können mobile Nutzer nicht zoomen — ein direkter Verstoß gegen WCAG 2.1 Erfolgskriterium 1.4.4 (Resize Text). Desktop-Scanner interessiert das nicht, weil Zoom am Desktop über den Browser gesteuert wird.

Was WCAG 2.2 für Mobile bedeutet

Mit WCAG 2.2 (veröffentlicht am 5. Oktober 2023 als W3C Recommendation) kamen 9 neue Erfolgskriterien hinzu, viele davon gezielt für mobile Nutzung:

• ✔ 2.5.7 Dragging Movements — Drag-Interaktionen brauchen eine Alternative
• ✔ 2.5.8 Target Size (Minimum) — 24×24px Mindestgröße
• ✔ 3.2.6 Consistent Help — Hilfe immer an gleicher Stelle
• ✔ 3.3.7 Redundant Entry — Keine doppelte Eingabe verlangen
• ✔ 3.3.8 Accessible Authentication — Login ohne kognitive Tests

Diese Kriterien sind besonders auf mobilen Geräten relevant, wo Bildschirmfläche begrenzt und Touch die primäre Eingabemethode ist.

So testet navable: Multi-Device Viewport-Audits

navable löst dieses Problem mit simultanen Multi-Device-Audits: Eine URL wird gleichzeitig in Desktop-, Tablet- und Mobile-Viewports geprüft.

Wie es funktioniert

1. URL eingeben — Eine einzige Seite reicht
2. Drei Viewports parallel — Desktop (1920px), Tablet (768px), Mobile (375px)
3. Viewport-spezifische Issues — Jeder Fund wird dem Gerät zugeordnet
4. Dev-ready Fix-Prompts — Mit DOM-Selektoren und konkreten Codevorschlägen

Was navable dabei erkennt

• ✔ Zu kleine Tipp-Zielgrößen auf Touch-Geräten
• ✔ Hover-abhängige Interaktionen ohne Touch-Alternative
• ✔ Responsive Layouts mit Accessibility-Brüchen
• ✔ Viewport-spezifische ARIA-Probleme (z.B. aria-hidden nur auf Mobile)
• ✔ Verlorene Fokus-Reihenfolge nach Responsive-Umbrüchen

Der Unterschied zu anderen Tools

Praxisbeispiel: E-Commerce Checkout

Ein typischer Online-Shop-Checkout zeigt das Problem deutlich:

Desktop: Alle Formularfelder nebeneinander, Buttons groß genug, Tooltips per Hover erreichbar.

Mobile: Felder werden gestapelt, der „Weiter"-Button rutscht unter ein Eingabefeld und wird nur 20×20px groß, die Tooltip-Hilfe zu den Kreditkarten-Feldern verschwindet komplett.

Ein Desktop-Scanner meldet: 0 Issues. navable meldet: 3 kritische Issues — Tipp-Zielgröße, fehlende Hover-Alternative, Tab-Reihenfolge nach Responsive-Umbruch.

BFSG und die Mobile-Pflicht

Das BFSG macht keinen Unterschied zwischen Desktop und Mobile. § 3 definiert die Barrierefreiheitsanforderungen für digitale Produkte und Dienstleistungen — unabhängig vom Endgerät.

Wer nur den Desktop scannt, hat keine vollständige Dokumentation seiner Compliance-Bemühungen. Für eine fundierte §17-Bewertung (unverhältnismäßige Belastung) brauchen Sie den Nachweis, dass Sie alle Zugangswege geprüft haben.

Fazit: Mobile-Testing ist kein Nice-to-have

• Viele Barrierefreiheitsprobleme erscheinen nur auf bestimmten Bildschirmgrößen
• ~45 % des deutschen Traffics kommt über Mobile (StatCounter)
• WCAG 2.2 hat gezielt mobile Kriterien ergänzt
• BFSG unterscheidet nicht zwischen Geräten
• Desktop-only Scanner übersehen systematisch Barrieren, die nur auf mobilen Viewports auftreten

Wenn Sie Ihre Website ernsthaft barrierefrei machen wollen — und das BFSG ernst nehmen — brauchen Sie einen Scanner, der alle Geräte abdeckt.

Jetzt Multi-Device-Audit starten: navable Audit Tool kostenlos testen — Desktop, Tablet und Mobile in einem Scan.

Quellen

1. WCAG 2.2 — W3C Recommendation, 5. Oktober 2023
2. What's New in WCAG 2.2 — W3C WAI
3. WCAG 2.2 SC 2.5.8 Target Size (Minimum)
4. WCAG 2.2 SC 1.4.13 Content on Hover or Focus
5. Desktop vs Mobile vs Tablet Market Share Germany — StatCounter
6. WCAG 2.2 Conformance §5.2.2 Full Pages — "A full page includes each variation of the page that is automatically presented by the page for various screen sizes."
7. BFSG — Barrierefreiheitsstärkungsgesetz