A fix you verified on a keyboard hasn’t been verified at all on a touchscreen, because the two run on completely different navigation systems.
Imagine this: a developer builds a custom dropdown, tests it on desktop with arrow keys, ships it. Three weeks later a QA engineer opens it on a phone, swipes through the form, and the dropdown does nothing. Neither person made a mistake. They each tested one of the two systems, and assumed it covered both. It’s the same accessibility tree underneath, but the thing reading that tree has changed entirely, and nobody told the dropdown.
Desktop screen readers intercept the keyboard
The screen reader sits between the keyboard and the browser, claiming keystrokes for its own navigation before the page ever sees them. NVDA calls this browse mode. JAWS calls the same idea virtual cursor mode.
A handful of keys carry most of the navigation:
| Key | Moves to |
|---|---|
| H | Next heading |
| B | Next button |
| F | Next form field |
| Tab | Next focusable element |
| Enter | Activate the focused element |
This works well for reading content, and breaks down the moment someone reaches a custom dropdown or date picker. Those components expect arrow keys to move between options. Browse mode has already claimed the arrow keys for navigation, so the component never receives them.
Screen readers solve this with a second mode. Land on a form field or interactive widget, and the screen reader switches automatically into what NVDA calls focus mode and JAWS calls forms mode. Keystrokes now pass through to the page, and the component’s own logic finally runs.
The switch only fires if the component correctly tells the browser it’s interactive, through the right role and state in the markup. Get that wrong, and the screen reader stays in browse mode, with the user pressing arrow keys that do nothing.
Mobile screen readers run on touch, with no keyboard involved
There’s no keyboard to hijack on mobile. VoiceOver and TalkBack, the default screen readers on iOS and Android, both work through gestures instead of keys:
| Gesture | Platform | Moves to |
|---|---|---|
| Swipe right | Both | Next element |
| Swipe left | Both | Previous element |
| Double-tap | Both | Activate the selected element |
| Two-finger rotate | VoiceOver | Open a menu of navigation categories |
| Three-finger swipe up or down | TalkBack | Cycle through reading control categories |
VoiceOver’s rotor and TalkBack’s reading controls solve the same problem differently. Both let you choose a category, headings, links, form controls, landmarks, and then move through only that category. VoiceOver does it with a twisting two-finger gesture; TalkBack does it by swiping with three fingers to cycle settings, then swiping up or down with one finger to move. The underlying idea is the same: pressing H for headings, translated into touch.
There’s no browse mode or focus mode here, because there was never a keyboard to fight over. That bug category doesn’t exist on mobile. A different one takes its place.
The accessibility tree is identical, what reads it isn’t
Both platforms pull from the same accessibility tree, the structured layer screen readers read instead of the visual page. A real button is exposed correctly to both.
A div wearing a button’s styling is invisible to both, for the same reason, but the symptom looks nothing alike. On desktop it’s a key that should do something and doesn’t. On mobile it’s a swipe that lands on the wrong element or triggers an announcement that doesn’t match what’s there.
One root cause, two unrelated-looking symptoms:
| Action | Desktop result if broken | Mobile result if broken |
|---|---|---|
| Move to next heading | Skips past or misreads it | Same |
| Activate a custom button | Nothing happens | Nothing happens, or the wrong element activates |
| Enter a custom dropdown | Arrow keys do nothing | Swipe lands outside the option list |
| Reach a calendar popup | No indication it’s now a dialog | No announcement that anything opened |
Date pickers show the gap clearly
Custom JavaScript date pickers are, by most accessibility audits, close to unusable for keyboard and screen reader users without significant rework. One academic study evaluating fourteen calendar widgets for accessibility found problems with most of them.
On desktop, the typical failure is a calendar popup opening with no signal that it’s now a dialog, so the screen reader stays in browse mode and never registers that the keyboard context shifted. Even when it does, the days inside the calendar are often styled text with a click handler and not real buttons in a real grid as they should be. So arrowing through them reads “clickable” over and over with no day, date, or month attached to it. On mobile, the same popup can open with no announcement at all, because there’s no equivalent cue built for a swipe to pick up on. Same root cause on both: the component never told assistive technology what it had just become.
The native HTML date input avoids this, because browsers already handle the dialog announcement correctly. It isn’t universal; Safari on macOS still doesn’t render it. But where it’s supported, it’s the simpler fix.
Mobile traffic makes this a revenue question
Estimates vary by source, anywhere from roughly 60% to upwards of 75% of e-commerce traffic now comes from mobile, depending on the research and the market. We haven’t measured this for any specific client ourselves, but the range alone makes the point worth raising with a product team. If a checkout flow only gets keyboard-tested, a meaningful share of visitors are hitting a wall on the platform that likely carries most of the traffic. For a product manager building the case to test both, that’s the argument.
—
If a component has only been tested with a keyboard, it’s been tested on one platform and assumed to work on the other. A full screen reader audit checks both, on several different devices, against the flows your users actually complete.
—
FAQ
- Do I need to test my site separately using desktop and mobile screen readers?** Yes. The accessibility tree is the same on both, but the navigation model isn’t: keyboard interception on desktop, touch gestures on mobile. A fix verified on one doesn’t tell you anything about the other.
- Why doesn’t VoiceOver have anything like browse mode or focus mode?** Those modes exist specifically to manage keyboard input. VoiceOver was built around swipe gestures from the start, so there’s no keyboard to intercept and nothing to switch between.
- What does the rotor gesture do in VoiceOver?** It opens a menu of navigation categories, headings, links, form controls. Pick one, and your swipes move through only that category, similar to pressing H for headings on desktop.
- Can an automated scan catch mobile-specific accessibility problems?** Rarely. Scanners check whether the right roles and labels exist in the code. They can’t tell you whether a real gesture, on a real device, lands where it’s supposed to.
—
Written by Kalina Boneva, accessibility QA at Access Drum and a screen reader user with 18 years of hands-on experience with assistive technology.
—
