Mobile and desktop AT interaction models differ
Aliases: mobile reader · desktop reader · swipe vs shortcuts
What it is
On desktop, reader users jump among objects with a keyboard and call a class of elements by shortcut. On a phone, the same family of reader becomes a swipe along objects, a rotor to pick a type, and explore-by-touch for whatever sits under the finger. Both are called “screen readers.” The interaction model is not the same. A desktop pass is not a mobile pass.
Why it happens
Different input hardware, different commands. Desktop has a row of keys: jump heading, jump landmark, open an element list. Mobile does not have those keys. The main move is a linear swipe, type filtering is the rotor, aiming is a finger on the glass. The same tree is therefore walked as different paths: desktop can “name the third heading directly”; mobile often has to swipe through the objects in between, or twist the rotor and then swipe.
Failures follow the model. Skip-nav, focus order, and shortcut clashes on desktop become swipe order, explore-by-touch hit testing, and gestures stolen by the app on mobile. The same engine name (both VoiceOver) does not let a macOS pass be copied onto iOS — command set, touch layer, and system gestures all differ.
Studying it
Same site or corresponding app screen: desktop completes the primary task by keyboard; mobile completes it with VoiceOver or TalkBack using only system gestures. Do not plug an external keyboard into the phone to reuse the desktop script.
Independent variables: device class (desktop / phone), navigation method (shortcuts / swipe / explore-by-touch). Dependent variables: steps to target, whether another gesture had to be substituted, how often an app gesture intercepted.
Record the commands people actually use. Do not assume they will hunt for desktop-shortcut equivalents on a phone.
Where it stops holding
Tablets sit between: some people attach a keyboard and act desktop, some swipe as on a large phone; both models have to work. A desktop-only product has no mobile model to test; a mobile-only product is not helped by a desktop reader’s keyboard script. Once an external keyboard is attached to a phone, the model leans desktop, and the test is no longer the default mobile model. Do not write the difference as how a reader internally switches modes — that is another layer. Here the question is whether the commands in the user’s hands are the same set.
Applying it
- Write two primary-task scripts: desktop keyboard, mobile system gestures. Do not share a single “Tab over.”
- On mobile, confirm the swipe order can finish the task, the rotor can find headings or form controls, and explore-by-touch can hit a visible target.
- How to check: reader on, phone, no keyboard, swipe and rotor only through checkout or posting. An entry that only exists as a desktop shortcut, and cannot be found in the swipe, means the mobile model has not been tested.