Screen Reader: What It Is, Types of Screen Readers and How They Work

What is a Screen Reader?

Screen Reader is an assistive technology (AT) that interprets the graphical user interface and presents it in non-visual form: through synthesized speech or a tactile Braille display. Screen readers are the primary means of accessing computers and mobile devices for people with complete or partial vision loss.

The first screen readers appeared in the late 1980s for MS-DOS (e.g., Vocal-Eyes) and later for Windows (JAWS, NVDA). On mobile platforms, screen readers became integrated at the system level: Apple integrated VoiceOver into the iPhone 3GS in 2009, Google integrated TalkBack into Android 1.6 the same year. By 2025, virtually all modern smartphones have a built-in screen reader that requires no additional software installation.

A screen reader does not just read text from the screen — it analyzes the interface hierarchy, determines element types (button, link, heading, input field), their states (enabled/disabled, selected/unselected) and relationships (parent-child, group). This information is conveyed to the user through voice prompts or tactile sensations from a Braille display, which updates cells in real time according to the focus position.

How Does a Screen Reader Work?

A screen reader works closely with the operating system, gaining access to its internal interface representation — the Accessibility Tree. This mechanism is the same on iOS and Android, although the API names differ.

Text-to-Speech (TTS)

The main output channel of a screen reader is a speech synthesizer (Text-To-Speech, TTS). When the accessibility focus lands on an element, the screen reader extracts its text content (or the description provided by the developer) and sends it to the TTS engine. Modern TTS engines, such as Apple Speech Synthesis and Google Text-to-Speech, use neural networks to generate natural speech with correct intonation, pauses, and emphasis depending on punctuation and content type.

The user can adjust speech rate (usually 60–80% of maximum for comfortable perception), pitch, and volume. Some screen readers support multiple voices and switch between them depending on content type — for example, a slower voice for reading text and a faster one for interface navigation. Braille displays connect via Bluetooth and display up to 40–80 characters at a time, updating the line with each focus change.

Focus Management and Navigation

A screen reader uses the concept of Accessibility Focus, which differs from the standard input focus. The user moves the accessibility focus using gestures (touch, swipe), and the screen reader announces the element under focus. Navigation order by default follows the visual order: left to right, top to bottom. The developer can override this order for complex layouts.

The screen reader also supports various navigation modes that the user switches through the rotor (VoiceOver) or menu (TalkBack): by headings, links, characters, words, forms. In headings mode, the screen reader moves only between H1–H6 — this is critical for efficient navigation through long pages and documents. Character mode helps when entering confirmation codes or complex passwords, pronouncing each character individually.

Main Screen Readers for Mobile Platforms

Two screen readers dominate mobile platforms: VoiceOver on iOS and TalkBack on Android. They have different APIs, gestures, and capabilities, but the common principle is reading the Accessibility Tree and gesture control.

VoiceOver (iOS)

VoiceOver is Apple’s screen reader, built into iOS, iPadOS, and macOS. It uses the UIAccessibility API to obtain information about elements and supports the rotor for switching navigation modes. VoiceOver is integrated with iCloud (settings sync across devices), Apple Pay (payment confirmation via Touch ID or Face ID), and Dynamic Text (font adapts to user settings).

VoiceOver gestures differ from TalkBack: it uses two-finger rotation (rotor), triple-tap for Screen Curtain, and two-finger double-tap to cancel an action. VoiceOver supports custom rotors that the developer adds through UIAccessibilityCustomRotor — for example, for quick navigation through app sections, bypassing the standard order.

TalkBack (Android)

TalkBack is Google’s screen reader, part of Android Accessibility Suite. It uses AccessibilityService and AccessibilityNodeInfo to access the interface. TalkBack supports a global menu via L-shaped swipe, custom actions for elements, and LiveRegion for dynamic updates. Starting with Android 14, TalkBack gained one-handed gesture support and improved Google Assistant integration.

TalkBack has a more flexible gesture system than VoiceOver: the user can assign virtually any gesture to any action. TalkBack also supports on-screen Braille input (BrailleBack) — the user enters text using Braille characters directly on the touchscreen in a special 3×2 layout per finger, which significantly speeds up text entry compared to the on-screen keyboard.

Besides VoiceOver and TalkBack, there are less common mobile screen readers: Select to Speak (Android, speaks selected area), Samsung Voice Assistant (replaces TalkBack on Samsung devices with One UI), and third-party solutions for specific niches — for example, for users of Chinese smartphones without Google services.

How Screen Reader Interacts with an App

A screen reader does not have direct access to the app’s UI components. Instead, it works through a layer — the operating system’s accessibility API. The operating system builds an Accessibility Tree that the screen reader traverses and analyzes.

Accessibility Tree on iOS and Android

On iOS, the Accessibility Tree is built from UIAccessibilityElement objects corresponding to each View on the screen. Each element contains a label (main text), traits (element type: button, heading, link), hint (tooltip), value (current value for sliders and indicators), and frame (touch area). The system automatically creates elements for standard UI components, but the developer can add and customize them.

On Android, the Accessibility Tree is built from AccessibilityNodeInfo objects. Each node contains: text (text or contentDescription), className (element type), contentDescription (description), stateDescription (state), isEnabled, isChecked, isClickable and other flags. Android also supports AccessibilityAction — a list of actions the screen reader can perform on behalf of the user: click, long press, scroll, set focus, set text.

Accessibility Events

When a change occurs in the interface (a new element appears, text changes, an element becomes visible or invisible), the operating system sends an AccessibilityEvent. The screen reader subscribes to these events and reacts to them: for example, when a dialog appears, the screen reader automatically moves focus to its title and announces the content.

// Listening to accessibility events on Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

On iOS, similar events are handled through UIAccessibility.Notification: layoutChanged (layout changed), screenChanged (completely new screen), announcement (custom announcement), pageScrolled (page scroll). The developer sends these events via UIAccessibility.post so that the screen reader correctly responds to changes. For example, when opening a modal window, you need to send screenChanged with the new title — otherwise VoiceOver stays on the previous element under the window.

Developing Apps for Screen Readers

Creating an accessible app is not about adding contentDescription to every element — it is about designing the user experience for non-visual interaction. The basic rules are the same for both platforms, although implementation varies.

Basic Accessibility Rules

All interactive elements must have meaningful descriptions: a “Submit” button should be described as “Submit message”, not just “Button”. Decorative elements (separators, background images, non-functional icons) should be hidden from the screen reader. Navigation order should follow the logical flow of the screen, not the visual layout. Text contrast should be at least 4.5:1 for body text and 3:1 for large text (WCAG AA).

// iOS: proper configuration for a complex element
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Sound volume"
customControl.accessibilityValue = "75 percent"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Increases or decreases volume"

// Update when value changes
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) percent"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

On iOS, the isAccessibilityElement flag enables VoiceOver support for custom elements. The traits combination (.adjustable + .button) tells VoiceOver that the element can be adjusted by swiping up/down and activated by double-tap. After changing the value, a layoutChanged notification must be sent — otherwise VoiceOver continues to announce the old value.

Platform-Specific Recommendations

For iOS: use accessibilityElements to override the reading order, accessibilityCustomActions for additional actions in the context menu, and shouldGroupAccessibilityChildren to group elements into logical groups. For SwiftUI, use the .accessibilityLabel(), .accessibilityAddTraits(), and .accessibilityRespondsToUserInteraction() modifiers. Avoid setting isAccessibilityElement = false on containers that contain interactive children — this will hide them from VoiceOver.

For Android: use accessibilityTraversalBefore and accessibilityTraversalAfter for navigation order, AccessibilityDelegate for custom elements, and LiveRegion (polite/assertive) for dynamic updates. In Compose, use the .semantics {} modifier with contentDescription, stateDescription, and customActions. Avoid setting focusable = true on non-interactive elements — this creates false focus points for TalkBack and confuses the user.

Testing Tools

Testing with a screen reader must be done on a physical device. An emulator/simulator provides a basic understanding, but gestures and response speed differ. Use Accessibility Inspector (Xcode) for iOS and Accessibility Scanner (Android) for automatic problem detection.

Key testing scenarios: registration (filling a form, validation, submission), search and catalog navigation, checkout, password recovery. Each scenario must be completable without visual control — only through screen reader voice prompts. If a screen reader user cannot complete a scenario in the same time as a regular user (±50%), the app requires accessibility improvements.