accessibility
Rotor
also called VoiceOver rotor (hig), gestures rotor (hig), element list (community), quick nav (community), landmark rotor (community)
VoiceOver's dial for choosing what a swipe or flick moves between: headings, links, landmarks, form controls, or characters.
The rotor is a dial, and on iOS it is drawn as one: two fingers on the glass, turned as if you were turning a knob, and VoiceOver announces each setting as it comes round. On the Mac the same dial is reached by holding Control and Option and pressing the left and right arrows. Whatever setting is showing decides what the next flick or arrow press means. On Headings, a flick down lands on the next heading. On Links, the same flick lands on the next link. The page has not changed and the gesture has not changed. Only the unit of travel has.
That makes the rotor a direct readout of the structure you shipped, because its list of
settings is generated from the document rather than configured by the user. Headings, links,
form controls, tables, lists and landmarks each appear as a setting only when
the page contains some, which is why a page built out of styled div elements offers a
screen reader user a rotor with almost nothing on it. On iOS the settings
are populated from the accessibility traits a view declares, so a
custom control drawn to look like a heading, announced correctly, and reachable by swipe can
still be missing from the Headings rotor because it never claimed the .header trait. The
landmark rotor is the clearest case of the payoff: mark the regions and the reader gets a
table of contents nobody had to write.
Every screen reader has this idea under another name. NVDA and JAWS spell it as quick
navigation, where single letter keys jump by type (h for heading, f for form field, k
for link) and a separate elements list dialog shows them all at once. The mechanic differs,
the design consequence does not. It is worth keeping the rotor distinct from
browse mode, which is often confused with it: browse mode is the mode the
walking happens in, where the reader claims the keyboard and moves a virtual cursor, and the
rotor is what chooses which kind of element that walk visits.
The practical reading is that the rotor rewards real semantics and quietly punishes visual
hierarchy alone. Large bold text is not a heading, a div with a click handler is not a
link, and a fieldset drawn with a border and no element behind it is not a group. None of
those failures show up in a screenshot, and all of them show up the moment somebody spins
the dial looking for a way to skim.
Which word?
| If you want | say |
|---|---|
| naming the VoiceOver dial that picks a navigation unit | rotor |
| a reader inspects content without leaving the field | review cursor |
| explaining why a key press never reached your widget | browse mode |
Related
See also: Heading hierarchy · Landmark