Mobile Accessibility Testing: Why Desktop Scanners Aren't Enough

Most automated accessibility scanners only test your website in a desktop viewport. The problem: many accessibility issues only appear at specific screen sizes. If you only scan the desktop view, you're missing a significant share of the barriers your mobile users face every day.

The Industry's Blind Spot: Desktop-Only Scanning

Look at the most common tools — WAVE, Lighthouse, Pa11y, most browser extensions — they all scan exactly one viewport: the current browser window. Even enterprise solutions primarily focus on desktop rendering.

That might have been acceptable in 2018. Today, over 60% of global web traffic comes from mobile devices, and in Germany alone it's around 45% (StatCounter, 2025–2026). And with regulations like the BFSG (German Accessibility Strengthening Act) and the European Accessibility Act (EAA) now in effect, digital products must be accessible for all users — regardless of whether they're on a desktop, tablet, or phone.

Issues That Only Appear on Mobile

Insufficient Tap Target Sizes

WCAG 2.2 introduced Success Criterion 2.5.8 (Target Size Minimum) requiring a minimum size of 24×24 CSS pixels for interactive elements. Buttons that are comfortably clickable with a mouse on desktop can be too small and too close together on a touchscreen.

A desktop scanner won't flag this because the elements have sufficient spacing in the desktop layout — only in the mobile layout do they get compressed.

Hover-Dependent Interactions

Tooltips, dropdown menus, and hover effects work fundamentally differently on touch devices — or not at all. WCAG 2.1 Success Criterion 1.4.13 (Content on Hover or Focus) requires that hover-based content is also accessible without a mouse.

If your scanner only checks the desktop version, it won't report hover interactions that completely fail on mobile.

Responsive Layouts Breaking Accessibility

Responsive design is standard — but not every responsive layout remains accessible:

• Hamburger menus missing aria-expanded attributes
• Overflowing text hidden by overflow: hidden cutting off content
• Stacked elements with incorrect tab order
• Hidden skip links that don't function on mobile
• Touch gestures without keyboard alternatives

These issues only exist in the mobile/tablet viewport and remain invisible to desktop scans.

Missing Viewport Meta Tags

Without a correctly configured <meta name="viewport">, mobile users can't zoom — a direct violation of WCAG 2.1 Success Criterion 1.4.4 (Resize Text). Desktop scanners don't care because zoom is handled by the browser on desktop.

What WCAG 2.2 Means for Mobile

WCAG 2.2 (published 5 October 2023 as a W3C Recommendation) introduced 9 new success criteria, many specifically targeting mobile use:

• ✔ 2.5.7 Dragging Movements — Drag interactions need an alternative
• ✔ 2.5.8 Target Size (Minimum) — 24×24px minimum size
• ✔ 3.2.6 Consistent Help — Help always in the same location
• ✔ 3.3.7 Redundant Entry — Don't require duplicate input
• ✔ 3.3.8 Accessible Authentication — Login without cognitive function tests

These criteria are especially relevant on mobile devices where screen space is limited and touch is the primary input method.

How navable Tests: Multi-Device Viewport Audits

navable solves this with simultaneous multi-device audits: one URL is scanned across desktop, tablet, and mobile viewports at the same time.

How It Works

1. Enter a URL — A single page is all you need
2. Three viewports in parallel — Desktop (1920px), Tablet (768px), Mobile (375px)
3. Viewport-specific issues — Each finding is tagged to its device
4. Dev-ready fix prompts — With DOM selectors and concrete code suggestions

What navable Detects

• ✔ Insufficient tap target sizes on touch devices
• ✔ Hover-dependent interactions without touch alternatives
• ✔ Responsive layouts with accessibility breakdowns
• ✔ Viewport-specific ARIA issues (e.g., aria-hidden only on mobile)
• ✔ Lost focus order after responsive reflows

How It Compares

Real-World Example: E-Commerce Checkout

A typical online shop checkout illustrates the problem clearly:

Desktop: All form fields side by side, buttons adequately sized, tooltips accessible via hover.

Mobile: Fields stack vertically, the "Continue" button slides under an input field and shrinks to 20×20px, the tooltip help for credit card fields disappears entirely.

A desktop scanner reports: 0 issues. navable reports: 3 critical issues — tap target size, missing hover alternative, tab order after responsive reflow.

Regulatory Requirements Don't Distinguish Devices

The BFSG and European Accessibility Act make no distinction between desktop and mobile. They define accessibility requirements for digital products and services — regardless of the end device.

If you only scan the desktop, you don't have complete documentation of your compliance efforts. For a proper §17 BFSG assessment (disproportionate burden), you need evidence that you've tested all access paths.

The Bottom Line

• Many accessibility issues only surface at specific screen sizes
• ~45% of German traffic is mobile (StatCounter), 60%+ globally
• WCAG 2.2 added criteria specifically targeting mobile use
• BFSG/EAA doesn't distinguish between devices
• Desktop-only scanners systematically miss barriers that only appear on mobile viewports

If you're serious about making your website accessible — and about regulatory compliance — you need a scanner that covers all devices.

Start your multi-device audit now: Try the navable Audit Tool for free — desktop, tablet, and mobile in one scan.

Sources

1. WCAG 2.2 — W3C Recommendation, 5 October 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