VoiceOver: What It Is, Gesture Controls and Features on iOS

What is VoiceOver?

VoiceOver is a screen reader built into Apple operating systems. It is designed for blind and visually impaired users and provides full interaction with the device without visual contact. VoiceOver vocalizes all interface elements: buttons, links, text, images, notifications and system elements.

The technology was first introduced in 2005 for macOS, and appeared on iOS with the iPhone 3GS in 2009. Since then, VoiceOver has become an integral part of the Apple ecosystem and one of the main arguments in favor of the platform's accessibility. VoiceOver is built in at the system level — meaning it works in any application without additional integration from the developer, although the quality of vocalization directly depends on how well the application uses iOS Accessibility API.

VoiceOver supports over 40 languages with natural speech synthesis and adapts to regional voice settings. On iOS, VoiceOver uses Siri voice engines for Russian and a number of other languages, ensuring the most natural sound and correct intonation depending on punctuation and context.

How Does VoiceOver Work?

VoiceOver intercepts touch events and interprets them differently than standard iOS input. When a user touches the screen, VoiceOver does not activate the element under the finger, but first vocalizes it. Only after a double-tap does the element activate. This key difference allows blind users to explore the interface without the risk of accidental clicks.

Reading Order and Navigation

VoiceOver reads interface elements in logical order: left to right, top to bottom. The reading order is inherited from the iOS view hierarchy, but the developer can change it through the accessibilityElements property for complex layouts. The user can move between elements by swiping right (next) and left (previous), as well as touching a specific element to have it vocalized.

With each movement, VoiceOver speaks the element type (button, link, heading), its name (accessibilityLabel), state (selected, disabled) and hint (accessibilityHint). If the element contains a value — for example, a volume slider — VoiceOver vocalizes that too. Accessibility Traits (UIAccessibilityTraits) additionally inform the user about the element's behavior: whether it is a button, switch, search field, or keyboard key.

VoiceOver Rotor

The Rotor is a virtual adjustment dial that switches the VoiceOver navigation mode. The user rotates the rotor with two fingers (like a volume knob) and selects a mode: words, characters, headings, links, entry points, table rows and others. Headings mode allows quick switching between H1-H6 on web pages and in applications, while characters mode speaks text letter by letter, useful when filling out forms or entering verification codes.

The developer can add custom modes to the rotor via the UIAccessibilityCustomRotor API. For example, in a notes application, you can add a "Favorite Notes" or "Recent Changes" rotor. Custom rotors significantly speed up navigation in specific applications and are considered best practice for iOS accessibility.

VoiceOver Gesture Controls

VoiceOver uses its own set of gestures that do not match standard iOS gestures. Most gestures are performed with three fingers instead of one — this prevents conflicts with normal operation and allows VoiceOver to work simultaneously with standard input.

The double-tap gesture is the primary way to activate elements in VoiceOver. If an element requires a special action (for example, dragging), VoiceOver uses the sequence "tap — double-tap and hold" to enter move mode. This allows performing complex gestures such as drag-and-drop without seeing the screen. VoiceOver also supports the "two-finger double-tap" gesture for canceling an action and "triple-tap" for turning the Screen Curtain on/off.

VoiceOver in Mobile Development

An iOS application developer can significantly improve VoiceOver interaction through the UIAccessibility API. Basic accessibility settings are added in Interface Builder (Identity Inspector → Accessibility), but complex interfaces require programmatic configuration in code.

Accessibility Label and Traits

The accessibilityLabel property sets the text that VoiceOver speaks for the element. If no label is set, VoiceOver uses the button text or text field placeholder. For elements without text (icons, custom views), a label is mandatory. The accessibilityTraits property defines the element type: button, heading, switch, search field, keyboard key, value changes, link and others.

let profileButton = UIButton(type: .custom)
profileButton.setImage(UIImage(named: "avatar"), for: .normal)
profileButton.isAccessibilityElement = true
profileButton.accessibilityLabel = "User Profile"
profileButton.accessibilityTraits = .button
profileButton.accessibilityHint = "Opens the profile settings screen"

The isAccessibilityElement flag enables VoiceOver support for custom views — by default it is true only for standard elements (UIButton, UILabel, UITextField). The accessibilityHint parameter adds a hint: VoiceOver speaks it after a pause if the user lingers on an element. The hint should describe the result of the action, not the instruction: "Opens the settings screen" instead of "Press to open".

Grouping and Element Order

For complex screens where the logical group of elements does not match the visual order, accessibilityElements is used — an array that sets the reading order. For example, a product card contains an image, name, price and an "Add to Cart" button. If these elements are arranged chaotically in the view hierarchy, accessibilityElements establishes the correct order for VoiceOver.

let productCard = UIView()
let productImage = UIImageView()
let productName = UILabel()
let productPrice = UILabel()
let addToCartButton = UIButton()

productCard.accessibilityElements = [
    productImage, productName, productPrice, addToCartButton
]

To combine multiple elements into one accessible element, UIAccessibilityContainer or accessibilityFrame is used to override the touch area. This is useful when a table cell contains several UI components but logically represents one element — VoiceOver should vocalize the entire cell as a whole, not iterate through its contents individually.

Configuring Accessibility for VoiceOver

Correct accessibility configuration for VoiceOver requires attention to several aspects: semantic markup, dynamic updates, custom element handling and testing with a real screen reader.

Semantic Markup in SwiftUI

In SwiftUI, accessibility is configured through the .accessibilityLabel(), .accessibilityValue(), .accessibilityHint() and .accessibilityAddTraits() modifiers. SwiftUI automatically inherits accessibility from standard elements, but custom components require explicit configuration. For example, a custom slider must report its value and change format to VoiceOver.

Slider(value: $volume, in: 0...100)
    .accessibilityLabel("Volume")
    .accessibilityValue(
        Text("\(Int(volume)) percent")
    )
    .accessibilityAddTraits(.adjustsAudioForAccessibility)
    .accessibilityAdjustableAction { direction in
        switch direction {
        case .increment: volume = min(volume + 5, 100)
        case .decrement: volume = max(volume - 5, 0)
        }
    }

The accessibilityAdjustableAction modifier adds the ability to change values with VoiceOver gestures: swipe up to increase, swipe down to decrease. Without this modifier, the slider will remain inaccessible for screen reader control. Similar configuration is required for custom steppers, pickers and other elements that change their value.

Dynamic Updates and Notifications

When content on the screen changes dynamically (a notification appears, a loading status updates, a price changes), VoiceOver must receive a notification through UIAccessibility.post. Without this call, the screen reader will not know about changes and the user will miss important information. For SwiftUI, the .accessibilityAnnouncement() modifier is used.

UIAccessibility.post(
    notification: .announcement,
    argument: "Price reduced by 20 percent"
)

// SwiftUI
Text("Price updated")
    .accessibilityAnnouncement(Text("20% discount"))

VoiceOver notifications should be used thoughtfully: excessive announcements annoy the user, while their absence makes the application inaccessible. The optimal strategy is to announce only those changes that affect the user's current workflow: cart updates, loading status, form validation error, chat notification. Background changes (time on the panel, currency rates) do not require announcement — the user will check them when needed.

VoiceOver testing is performed using a physical device with the screen reader enabled or an iOS simulator with the Accessibility Inspector option. It is important to test full usage scenarios: complete registration, place an order, find a product by search without visual control. If the flow is navigable without visual feedback — VoiceOver is configured correctly.