You Fixed Desktop. Now Mobile Is Getting Complaints

ClearPath Team · 2026-08-08 · 7 min read

You spent weeks on the desktop version. Color contrast fixed, headings cleaned up, forms labeled properly. Then a customer emails to say they couldn't check out on their phone. Nothing you tested was wrong, because you tested on a laptop with a mouse.

Mobile accessibility isn't a smaller version of desktop accessibility. It has its own set of failures tied to touch, screen size, and orientation, and most of them never show up in a desktop review. That matters more than it used to, because mobile now makes up the majority of web traffic worldwide, and auditors and testers increasingly start there instead of treating it as an afterthought. Given that most visits now happen on a phone, a site that only passes on desktop is failing the majority of people who actually show up.

Tap targets that are too small or too close

WCAG 2.2 added Success Criterion 2.5.8, Target Size (Minimum), a Level AA rule that didn't exist before. It requires interactive targets to be at least 24 by 24 CSS pixels, with five exceptions. That includes buttons, icon links, checkboxes, and menu items, anything someone taps with a finger instead of clicking with a precise mouse pointer.

The rule exists because it helps people with limited fine motor control and touchscreen users avoid accidentally activating the wrong control. If your "delete" and "cancel" buttons sit right next to each other at 16 pixels tall, someone with a tremor, arthritis, or just a bus jostling their hand is going to tap the wrong one. Best practice goes further than the legal floor: aim for 24 pixels everywhere and closer to 44 pixels on your primary buttons, which lines up with what Apple's Human Interface Guidelines recommend 44x44 points, and Google's Material Design suggests 48x48dp for touch targets. This is one spot where ClearPath can offer a partial, in-the-moment fix, since a visitor who turns on one of its profiles can enlarge clickable areas and spacing themselves, though that doesn't replace fixing the actual button sizes in your CSS.

Pinch zoom disabled with a maximum-scale viewport tag

A lot of sites still ship a viewport meta tag with maximum-scale=1 or user-scalable=no. Someone added it years ago to stop accidental double-tap zoom on a form, and it's been quietly blocking every low-vision visitor since. WCAG's resize and reflow requirements assume people can zoom in to read content or enlarge controls. Locking pinch zoom removes that option entirely, and it's one of the easiest failures to reproduce: open the site on a real phone and try to pinch in on a paragraph of text.

Hamburger menus that trap focus or won't close

Mobile nav menus are usually built as an overlay that opens on tap. A shocking number of them don't manage focus correctly. Keyboard and switch-device users get pulled into the menu and can't tab back out, or the close button doesn't actually receive focus so pressing "escape" does nothing. This is a keyboard trap, one of the oldest WCAG failures on the books, but it shows up constantly in mobile hamburger menus because developers build and test them with a mouse and never try tabbing through with a keyboard or switch.

Sticky headers and bottom bars covering the focused element

This one's new to WCAG 2.2 as well. Focus Not Obscured (Minimum) ensures that when someone navigates your site with a keyboard, they can always see at least part of the focused element, even when sticky headers, cookie banners, or chat widgets are present, a Level AA criterion new in WCAG 2.2. On mobile this is especially common because sites stack a sticky header at the top and a sticky "buy now" or app-download bar at the bottom, squeezing the visible content into a thin strip in the middle. Any sticky content that moves with the viewport can potentially obscure other elements on the page, and a sticky footer tall enough can completely cover the element in focus as a user tabs down the page. The fix is usually scroll-padding in CSS, but somebody has to notice the problem first, and it's nearly invisible unless you're tabbing through on the actual device.

Forms that fire the wrong keyboard

Tap a phone number field and get the full alphabet keyboard instead of a number pad. Tap an email field and get no "@" key shortcut. This happens when input types and inputmode attributes aren't set correctly in the markup. It's not a dramatic failure, but it adds friction for every single visitor on a touchscreen, and it disproportionately slows down people who already navigate slowly due to a motor or cognitive disability.

Content that only works in one orientation

WCAG's orientation requirement says content shouldn't be locked to portrait or landscape unless that orientation is essential to the function, like a piano app. Plenty of sites still have a data table, a video player, or a form that becomes unusable if the phone is rotated, because nobody built or tested the responsive layout for both states. Anyone with their phone mounted in a fixed position, whether on a wheelchair, a bike, or a stand, is stuck.

Drag interactions with no tap alternative

Image sliders, "swipe to compare" widgets, drag-to-reorder lists, custom range sliders built from scratch instead of a native input. WCAG 2.2's dragging movements rule addresses exactly this. Anything operated by dragging must also be operable with a single pointer, without dragging, for example a tap or click on a button. The reasoning is straightforward: it helps people with tremor or limited dexterity, and people using a head pointer, eye-tracker, trackball, or switch, for whom pressing, holding, and moving in one motion is hard. If your only way to reorder a cart or scrub a video is a drag gesture, you've locked out anyone who can tap but can't drag precisely. This is a real code fix, not something a widget like ClearPath can add on its own, since a tap alternative has to be built into the interaction itself.

Test your own site on a real phone in under an hour

1. Use an actual phone, not a resized browser window. Emulators miss real touch behavior and keyboard type.
2. Connect a bluetooth keyboard. Tab through every menu, form, and modal. Watch for traps and for focus disappearing under sticky bars.
3. Try to pinch-zoom on three different pages. If it doesn't work anywhere, check the viewport meta tag in your page source.
4. Tap every button with your thumb, not your fingertip. Note anything you miss or double-tap by mistake.
5. Turn on VoiceOver (iOS) or TalkBack (Android) for ten minutes and try to complete your main conversion path, like a checkout or a contact form.
6. Rotate the phone on every major page template and see what breaks.
7. Find every drag interaction on the site and ask whether there's a tap-only way to do the same thing.

You can genuinely get through all seven steps on a five-page site in under an hour. The point isn't a full audit, it's catching the failures that only exist on a touchscreen before a visitor finds them for you.