Skip to main content
Accessibility.com, LLC
Category: Assistive Technologies

VoiceOver Rotor

Also known as: Rotor, VoiceOver Rotor gesture, Accessibility Rotor
Simply put

The VoiceOver Rotor is a feature of Apple's built-in VoiceOver screen reader that lets users choose how they move through content, such as jumping between headings, links, or form controls. It works like a virtual dial: turning it selects a navigation option, and only one option is active at a time. It gives blind and low-vision users quick access to many settings and actions, some of which are available only through the Rotor.

Formal definition

The VoiceOver Rotor is a contextual, wheel-based control in Apple's VoiceOver screen reader (available on macOS, iOS, and iPadOS) that exposes a set of navigation options and commands, with a single option active at any given moment. Rotating the wheel changes the active option, allowing the user to navigate content by a chosen unit or category (for example, headings, links, or form controls) or to adjust settings and perform actions. On iOS and iPadOS, the Rotor is invoked with a two-finger rotation gesture on the screen. On macOS, the Rotor is commonly opened using VO-Command-Left/Right Arrow (where VO is the VoiceOver modifier, typically Control-Option) or VO-U; when Quick Nav is enabled, pressing the Up Arrow together with the Left or Right Arrow opens the Quick Nav rotor. The available Rotor options are contextual and depend on the app or web content, and correct behavior in web contexts depends on proper semantic markup. This entry describes assistive-technology behavior and is not legal advice; consult current Apple documentation, as behavior and shortcuts may change across versions.

Why it matters

The VoiceOver Rotor is one of the primary ways blind and low-vision users navigate content efficiently on Apple devices. Rather than moving through a page or app one item at a time, the Rotor lets a user jump directly between headings, links, form controls, and other elements, or quickly reach settings and actions. Because some of these settings and actions are available only through the Rotor, it is not merely a convenience but a core part of how many VoiceOver users interact with content.

For teams building and testing websites and apps, the Rotor is significant because its usefulness depends heavily on the underlying structure of the content. In web contexts, correct behavior depends on proper semantic markup: if headings, links, and form controls are not marked up correctly, the Rotor cannot reliably expose them, and users lose the ability to navigate by those units. This means that supporting the Rotor is closely tied to building content with well-structured, semantically meaningful markup.

Because the Rotor exposes contextual navigation and commands that shift depending on the app or web content, manual testing with VoiceOver and the Rotor is an important complement to automated checking. Automated tools detect only a portion of accessibility issues, and verifying that Rotor navigation works as expected generally requires hands-on testing with the assistive technology itself. This entry describes assistive-technology behavior and is not legal advice.

Who it's relevant to

Blind and low-vision VoiceOver users
The Rotor gives VoiceOver users quick access to a large number of settings and actions and lets them navigate content by chosen units such as headings, links, and form controls. Because some settings and actions are available only through the Rotor, it is an essential part of the day-to-day VoiceOver experience on macOS, iOS, and iPadOS.
Accessibility testers and QA engineers
Testers verifying accessibility on Apple platforms commonly use the Rotor to confirm that content can be navigated by heading, link, form control, and other units. Because Rotor behavior is contextual and depends on the app or web content, hands-on testing with VoiceOver complements automated checks, which detect only a portion of issues.
Web and app developers
In web contexts, correct Rotor behavior depends on proper semantic markup. Developers who structure content with meaningful, correctly marked-up headings, links, and form controls help ensure that VoiceOver users can navigate reliably by those categories through the Rotor.
UX designers and product teams
Designers and product teams benefit from understanding that many VoiceOver users rely on the Rotor to move efficiently through content rather than reading linearly. Designing information architecture and interactive components with clear, navigable structure supports this mode of interaction.

Inside VoiceOver Rotor

Rotor Concept
The VoiceOver Rotor is a navigation control in Apple's VoiceOver screen reader that lets users cycle through categories of on-page or on-screen elements, allowing quicker movement than reading content linearly.
Rotor Categories (Items)
The selectable groupings the Rotor exposes, which commonly include headings, links, form controls, landmarks, tables, and lists on the web, plus configurable options such as text navigation granularity (characters, words, lines) on macOS.
Opening the Rotor on macOS
On macOS, the Rotor is commonly opened using VO-U (Control-Option-U) or by using VO-Command-Left Arrow / VO-Command-Right Arrow to move between Rotor options, where VO represents the VoiceOver modifier keys.
Quick Nav Rotor on macOS
When Quick Nav is enabled on macOS, pressing the Up Arrow and Left Arrow or Up Arrow and Right Arrow keys simultaneously opens the Quick Nav rotor, letting users choose which navigation category is active.
iOS Rotor Gesture
On iOS and iPadOS, the Rotor is typically operated with a two-finger rotating gesture on the touchscreen to select a category, after which flicking up or down moves through items in that category.
Navigating Within a Selected Category
Once a Rotor category is chosen, the user moves to the next or previous element of that type, enabling targeted navigation such as jumping heading-to-heading or link-to-link.

Common questions

Answers to the questions practitioners most commonly ask about VoiceOver Rotor.

Is the VoiceOver Rotor the same feature on iOS and macOS?
No. While both platforms use a feature called the Rotor to navigate by categories such as headings, links, and form controls, the interaction models differ. On iOS and iPadOS, the Rotor is a touch gesture performed by rotating two fingers on the screen, then flicking up or down to move through items of the selected type. On macOS, the Rotor is opened with keyboard commands and is often used with Quick Nav for keyboard-only navigation. Treating them as identical can lead to incorrect guidance, so distinguish the platform when documenting or testing Rotor behavior.
If my content works with the VoiceOver Rotor, does that mean my site is fully accessible or legally compliant?
Not on its own. The Rotor surfaces elements such as headings, landmarks, and links based on the underlying markup, so good Rotor navigation is one useful signal of well-structured content. However, working with the Rotor does not guarantee conformance with WCAG across all success criteria, nor does it guarantee an accessible experience for users of other assistive technologies or a defense against legal claims. Rotor checks should be part of broader manual and assistive technology testing across multiple screen readers. This is general information and not legal advice; consult qualified counsel for compliance questions.
How do I open the Rotor when using VoiceOver on macOS?
On macOS, you can open the VoiceOver Rotor using VO-U (where VO is the VoiceOver modifier, by default Control-Option), or by using VO-Command-Left Arrow and VO-Command-Right Arrow to move between rotor categories. When Quick Nav is enabled, pressing Up Arrow together with Left Arrow or Right Arrow simultaneously opens the Quick Nav rotor. Because default modifier keys and settings can be customized, confirm the active configuration on the specific machine when documenting steps.
How do I move through Rotor categories and items on macOS?
Once the Rotor is open on macOS, you move between categories (such as headings, links, or form controls) using the left and right arrow keys, and you move through the individual items within the selected category using the up and down arrow keys. Behavior can depend on whether Quick Nav is enabled and on the user's VoiceOver settings, so verify the current mode when testing.
Which categories appear in the Rotor, and can I control them?
The categories available in the Rotor generally reflect the structural elements present in the content, such as headings, links, landmarks or regions, tables, and form controls. Because these categories are populated from the underlying markup, using semantic HTML elements and correct roles, names, and states helps ensure that relevant items appear and are labeled meaningfully. Missing or improperly marked-up structure can cause elements to be absent from or mislabeled in the Rotor.
What should I test with the Rotor to catch accessibility issues?
Use the Rotor to verify that headings form a logical, well-ordered hierarchy, that landmarks or regions are present and correctly identified, that links and form controls have clear and distinguishable names, and that these elements can be reached and understood out of visual context. Confirm findings by navigating the content directly as well, since the Rotor reflects the markup rather than validating the full user experience. Combine this with testing on other screen readers and with manual review for a more complete picture.

Common misconceptions

The Rotor is opened on macOS with Control-Option-Left/Right Arrow alone.
On macOS the Rotor is commonly opened with VO-U (Control-Option-U), while VO-Command-Left/Right Arrow is used to move between Rotor options. The plain arrow-key combinations relate to Quick Nav rather than opening the standard Rotor.
Pressing Up Arrow with Left or Right Arrow merely switches the currently selected Rotor option.
On macOS with Quick Nav enabled, pressing Up Arrow together with Left or Right Arrow actually opens the Quick Nav rotor; it does not simply toggle the already-selected option.
The Rotor works identically on macOS and iOS.
The interaction models differ. On iOS the Rotor is driven by a two-finger rotating touchscreen gesture, whereas on macOS it is operated through keyboard commands and, when enabled, Quick Nav key combinations.

Best practices

Use clear, semantic HTML structure such as properly nested headings, landmark regions, and descriptive link text so the Rotor's category-based navigation surfaces meaningful elements.
Test with VoiceOver's Rotor on both macOS and iOS, since the interaction models differ and issues may appear on one platform but not the other.
Verify that headings, links, form controls, and landmarks each appear in their expected Rotor categories, confirming that assistive technology can navigate content as intended.
Document the correct platform commands for teams, noting that macOS commonly uses VO-U to open the Rotor and VO-Command-Left/Right Arrow to move between options, to avoid propagating incorrect shortcuts.
Include manual assistive technology testing with real VoiceOver navigation, since automated checks detect only a portion of accessibility issues and cannot confirm the Rotor experience.
Treat Rotor-based navigation as one part of a broader accessibility evaluation, and consult qualified professionals for conformance and legal questions, as this guidance is not legal advice.