Mobile Accessibility: Making Your Website Inclusive for Smartphone Users

Trapped by a cookie banner

Someone with arthritis once described being unable to use a retail site on her phone. The cookie banner had a close button about 12 pixels wide, in the corner. She tapped it four times, hit the banner's own "accept all" button twice by accident, and eventually closed the tab.

The site was probably tested by a developer with a mouse and a 27-inch monitor, where that button is a comfortable target.

Mobile accessibility failures like this are rarely dramatic. They're a series of small precision requirements that a person with tremor, low vision, or one hand occupied cannot meet, in a sequence, until the task becomes impossible.

Why mobile needs its own review

Mobile accessibility isn't desktop accessibility on a smaller screen. The interaction model is different in ways that change the answers:

• Input is a finger, not a pointer. Precision drops badly, and the target size rules exist because of it.
• Navigation is sequential swipes, not a keyboard and a mouse. VoiceOver and TalkBack move through elements in document order, so the DOM order is the interface.
• The screen is small and attention is split. Someone on a train, in a queue, holding a child.
• Zoom and text scaling are common, not edge cases. A large proportion of mobile users run enlarged text as a default.
• Orientation is fixed for some people. Phone mounted on a wheelchair, in landscape.
• Motion gestures are unavailable to some users. Shake, tilt, and complex multi-finger gestures.

Add it up and a site that passes a desktop audit can still be unusable on a phone. That's the gap worth closing.

The one number people get wrong

The 44-by-44-pixel figure is quoted everywhere as "the WCAG requirement". It's worth being precise, because precision changes what you fix.

WCAG 2.2 Success Criterion 2.5.8 (Target Size, Minimum) is Level AA and requires 24 by 24 CSS pixels, with exceptions for spacing, inline links, and equivalent controls.

Success Criterion 2.5.5 (Target Size, Enhanced) is Level AAA and asks for 44 by 44.

So 24 is the AA bar, and 44 is the better default. I'd still build to 44 for anything primary: the phone button, the form submit, the close on a modal. Where 24 is technically compliant, 44 is what actually works for someone with tremors, and the difference costs nothing but padding.

Test on a real phone with your thumb.

Screen readers behave differently here

VoiceOver on iOS and TalkBack on Android are gesture-driven, and they expose problems that desktop testing won't:

• Document order is the reading order. If your visual layout puts the phone number first but the DOM puts it after a decorative carousel, a screen reader user hears the carousel first.
• Labels must be real labels. A placeholder is not a label. An icon-only button with no accessible name is announced as "button", which tells the user nothing.
• Dynamic changes need announcing. A form error, a cart update, a filter result change: without a live region, a screen reader user has no idea anything happened.
• Focus has to move when content changes. Modals, single-page navigation, expanding accordions. If focus stays behind the modal, the user is trapped in an invisible layer.
• Custom gestures conflict. A swipe-based component can collide with the screen reader's own swipe navigation.

Testing takes ten minutes and is unglamorous: turn VoiceOver on, close your eyes, try to book an appointment. Note where you get stuck.

Text sizing and reflow

WCAG requires text to be resizable up to 200 percent without loss of content or function, and content to reflow at a narrow width without horizontal scrolling.

On mobile, that means:

• Relative units for type. Rem values, not fixed pixels, so the operating system text size setting and browser zoom both work.
• No fixed-width containers. A 360-pixel-wide element on a 320-pixel screen causes horizontal scroll.
• No maximum-scale=1 or user-scalable=no in the viewport meta tag. Both block pinch zoom and count as failures. If you added them to stop an iOS input from zooming, fix the input's font size instead, at 16 pixels minimum.
• Text in images replaced with real text. Logo images with taglines, price graphics, opening-hours banners.

Orientation and motion

Don't lock the screen to portrait. Content should work in both orientations unless a specific orientation is essential. That exception is narrower than most people assume: a piano app qualifies, a marketing site doesn't.

Don't require device motion. Anything using shake or tilt needs a button alternative.

Respect the reduced-motion preference. If you're animating a hero or a carousel, honour the operating system setting. For people with vestibular disorders, a parallax scroll can cause genuine nausea.

The practical fixes, in order of impact

1. Kill the precision traps

Close buttons, quantity steppers, tab targets, filter chips, star ratings, social icons. Give each a minimum 44-by-44 hit area using padding, and keep the visual size if you like. Overlapping hit areas are almost as bad as small ones: two adjacent links that both claim the gap between them produce mis-taps.

2. Sticky elements that don't eat the screen

A sticky header plus a sticky cookie bar plus a chat bubble on a 640-pixel-tall phone screen can leave almost no content visible. On small screens, collapse or dismiss.

3. Forms that a screen reader can complete

Every input needs a persistent visible label, associated properly. Errors stated in text, announced in a live region, and linked to the field. No reliance on colour alone to show a required field. No CAPTCHA that requires precise dragging.

4. Fix the reading order

Check the DOM order matches the visual order. Use landmark regions and headings so a screen reader user can jump rather than swipe through sixty items to reach the phone number.

5. Announce changes

Add live regions for form errors, cart counts, and filter results. One line of markup, and it converts a silent screen into a working interface.

6. Give links real names

"Read more" repeated eight times is indistinguishable when read as a list. "Read more about our emergency callout" is not.

What automated tools miss

Automated scanners catch a useful minority of issues, mostly the mechanical ones: missing alt text, contrast ratios, form labels, landmarks. They cannot tell you that the reading order makes no sense, that the modal traps focus, that the button is unreachable by thumb, or that the flow is confusing.

Which is why the review that matters is manual and takes an afternoon: VoiceOver on, thumb only, airplane mode for the slow connection, and a genuine attempt to complete your most important task.

Where to start

Open your site on a phone, turn on a screen reader, and try to contact yourself. Then check the three things that break most often: touch target sizes, zoom being disabled in the viewport tag, and the close button on whatever popup you're running.

A free digital presence audit on Webcheckhub includes website health checks and flags accessibility basics alongside conversion readiness and SEO, so you can see mobile problems in context. When you want a proper WCAG audit with fixes implemented, Solutions Elites handles accessibility remediation for small businesses.