Screen Reader: что это, типы экранных дикторов и принцип работы

Что такое Screen Reader?

Screen Reader (экранный диктор) — это вспомогательная технология (Assistive Technology, AT), которая интерпретирует графический интерфейс пользователя и представляет его в невизуальной форме: через синтезированную речь или тактильный брайлевский дисплей. Screen reader'ы являются основным средством доступа к компьютерам и мобильным устройствам для людей с полной или частичной потерей зрения.

Первые screen reader'ы появились в конце 1980-х годов для MS-DOS (например, Vocal-Eyes) и позднее для Windows (JAWS, NVDA). На мобильных платформах screen reader'ы стали встраиваться на системном уровне: Apple интегрировала VoiceOver в iPhone 3GS в 2009 году, Google — TalkBack в Android 1.6 в том же году. К 2025 году практически все современные смартфоны имеют встроенный screen reader, не требующий установки дополнительного ПО.

Screen reader не просто читает текст с экрана — он анализирует иерархию интерфейса, определяет типы элементов (кнопка, ссылка, заголовок, поле ввода), их состояние (включено/отключено, выбрано/не выбрано) и взаимосвязи (родитель-ребёнок, группа). Эта информация передаётся пользователю через голосовые подсказки или тактильные ощущения брайлевского дисплея, который обновляет ячейки в реальном времени в соответствии с положением фокуса.

Как работает Screen Reader?

Screen reader работает в тесной связке с операционной системой, получая доступ к её внутреннему представлению интерфейса — дереву доступности (Accessibility Tree). Этот механизм одинаков на iOS и Android, хотя названия API различаются.

Преобразование текста в речь (TTS)

Основной канал вывода screen reader'а — синтезатор речи (Text-To-Speech, TTS). Когда фокус доступности попадает на элемент, screen reader извлекает его текстовое содержимое (или описание, заданное разработчиком) и отправляет в TTS-движок. Современные TTS-движки, такие как Apple Speech Synthesis и Google Text-to-Speech, используют нейронные сети для генерации естественной речи с правильной интонацией, паузами и акцентами в зависимости от пунктуации и типа контента.

Пользователь может настроить скорость речи (обычно 60–80% от максимальной для комфортного восприятия), высоту тона и громкость. Некоторые screen reader'ы поддерживают несколько голосов и переключение между ними в зависимости от типа контента — например, более медленный голос для чтения текста и быстрый для навигации по интерфейсу. Брайлевские дисплеи подключаются через Bluetooth и отображают до 40–80 символов одновременно, обновляя строку при каждом изменении фокуса.

Управление фокусом и навигация

Screen reader использует концепцию фокуса доступности (Accessibility Focus), который отличается от стандартного фокуса ввода. Пользователь перемещает фокус доступности с помощью жестов (касание, свайп), и screen reader озвучивает элемент под фокусом. Порядок навигации по умолчанию следует визуальному порядку: слева направо, сверху вниз. Разработчик может переопределить этот порядок для сложных макетов.

Screen reader также поддерживает различные режимы навигации, которые пользователь переключает через ротор (VoiceOver) или меню (TalkBack): по заголовкам, ссылкам, символам, словам, формам. В режиме заголовков screen reader перемещается только между H1-H6 — это критически важно для эффективной навигации по длинным страницам и документам. Режим символов помогает при вводе кодов подтверждения или сложных паролей, произнося каждый символ отдельно.

Основные Screen Reader'ы для мобильных платформ

На мобильных платформах доминируют два screen reader'а: VoiceOver на iOS и TalkBack на Android. Они имеют разные API, жесты и возможности, но общий принцип работы — чтение дерева доступности и управление жестами.

VoiceOver (iOS)

VoiceOver — screen reader от Apple, встроенный в iOS, iPadOS и macOS. Он использует API UIAccessibility для получения информации об элементах и поддерживает ротор для переключения режимов навигации. VoiceOver интегрирован с iCloud (настройки синхронизируются между устройствами), Apple Pay (подтверждение платежа через Touch ID или Face ID) и динамическим текстом (шрифт подстраивается под пользовательские настройки).

Жесты VoiceOver отличаются от TalkBack: используется вращение двумя пальцами (ротор), тройное касание для Screen Curtain и двойное касание двумя пальцами для отмены действия. VoiceOver поддерживает кастомные роторы, которые разработчик добавляет через UIAccessibilityCustomRotor — например, для быстрой навигации по разделам приложения в обход стандартного порядка.

TalkBack (Android)

TalkBack — screen reader от Google, входящий в Android Accessibility Suite. Он использует AccessibilityService и AccessibilityNodeInfo для доступа к интерфейсу. TalkBack поддерживает глобальное меню через L-образный свайп, кастомные действия для элементов и LiveRegion для динамических обновлений. Начиная с Android 14, TalkBack получил поддержку жестов одной рукой и улучшенную интеграцию с Google Assistant.

TalkBack имеет более гибкую систему жестов, чем VoiceOver: пользователь может настроить практически любой жест на любое действие. Также TalkBack поддерживает брайлевский ввод на экране (BrailleBack) — пользователь вводит текст символами брайля прямо на сенсорном экране в специальной раскладке 3×2 для каждого пальца, что значительно ускоряет набор текста по сравнению с экранной клавиатурой.

Помимо VoiceOver и TalkBack, существуют менее распространённые мобильные screen reader'ы: Select to Speak (Android, озвучивание выделенной области), Samsung Voice Assistant (замена TalkBack на устройствах Samsung с One UI) и third-party решения для специфических ниш — например, для пользователей китайских смартфонов без сервисов Google.

Как Screen Reader взаимодействует с приложением

Screen reader не имеет прямого доступа к UI-компонентам приложения. Вместо этого он работает через прослойку — API доступности операционной системы. Операционная система строит дерево доступности (Accessibility Tree), которое screen reader обходит и анализирует.

Accessibility Tree на iOS и Android

На iOS дерево доступности строится из объектов UIAccessibilityElement, соответствующих каждому View на экране. Каждый элемент содержит label (основной текст), traits (тип элемента: кнопка, заголовок, ссылка), hint (подсказка), value (текущее значение для ползунков и индикаторов) и frame (область касания). Система автоматически создаёт элементы для стандартных UI-компонентов, но разработчик может добавлять и настраивать их.

На Android дерево доступности строится из объектов AccessibilityNodeInfo. Каждый узел содержит: text (текст или contentDescription), className (тип элемента), contentDescription (описание), stateDescription (состояние), isEnabled, isChecked, isClickable и другие флаги. Android также поддерживает AccessibilityAction — список действий, которые screen reader может выполнить от имени пользователя: клик, долгое нажатие, прокрутка, установка фокуса, установка текста.

События доступности (Accessibility Events)

Когда в интерфейсе происходит изменение (появился новый элемент, изменился текст, элемент стал видимым или невидимым), операционная система отправляет AccessibilityEvent. Screen reader подписан на эти события и реагирует на них: например, при появлении диалогового окна screen reader автоматически перемещает фокус на его заголовок и озвучивает содержимое.

// Прослушивание событий доступности на 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)
        }
    }
}

На iOS аналогичные события обрабатываются через UIAccessibility.Notification: layoutChanged (изменился макет), screenChanged (полностью новый экран), announcement (произвольное объявление), pageScrolled (прокрутка страницы). Разработчик отправляет эти события через UIAccessibility.post, чтобы screen reader корректно реагировал на изменения. Например, при открытии модального окна нужно отправить screenChanged с указанием нового заголовка — иначе VoiceOver останется на предыдущем элементе под окном.

Разработка приложений с учётом Screen Reader

Создание доступного приложения — это не добавление contentDescription к каждому элементу, а продумывание пользовательского опыта для невизуального взаимодействия. Базовые правила едины для обеих платформ, хотя реализация различается.

Базовые правила доступности

Все интерактивные элементы должны иметь осмысленное описание: кнопка «Отправить» должна быть описана как «Отправить сообщение», а не «Кнопка». Декоративные элементы (разделители, фоновые изображения, иконки без функциональности) должны быть скрыты от screen reader'а. Порядок навигации должен соответствовать логическому потоку экрана, а не визуальному расположению. Контрастность текста должна быть не ниже 4.5:1 для основного текста и 3:1 для крупного (WCAG AA).

// iOS: правильная настройка для сложного элемента
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Громкость звука"
customControl.accessibilityValue = "75 процентов"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Увеличивает или уменьшает громкость"

// Обновление при изменении значения
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) процентов"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

На iOS флаг isAccessibilityElement включает поддержку VoiceOver для кастомных элементов. Комбинация traits (.adjustable + .button) сообщает VoiceOver, что элемент можно регулировать свайпом вверх/вниз и активировать двойным касанием. После изменения значения обязательно отправляется уведомление layoutChanged — иначе VoiceOver продолжит озвучивать старое значение.

Специфичные рекомендации для обеих платформ

Для iOS: используйте accessibilityElements для переопределения порядка чтения, accessibilityCustomActions для дополнительных действий в контекстном меню и shouldGroupAccessibilityChildren для объединения элементов в логические группы. Для SwiftUI применяйте модификаторы .accessibilityLabel(), .accessibilityAddTraits() и .accessibilityRespondsToUserInteraction(). Избегайте использования isAccessibilityElement = false на контейнерах, содержащих интерактивные дочерние элементы — это скроет их от VoiceOver.

Для Android: используйте accessibilityTraversalBefore и accessibilityTraversalAfter для порядка навигации, AccessibilityDelegate для кастомных элементов и LiveRegion (polite/assertive) для динамических обновлений. В Compose применяйте модификатор .semantics {} с contentDescription, stateDescription и customActions. Избегайте использования focusable = true на неинтерактивных элементах — это создаст ложные фокусные точки для TalkBack и запутает пользователя.

Инструменты тестирования

Тестирование с screen reader'ом обязательно на физическом устройстве. Эмулятор/симулятор даёт базовое представление, но жесты и скорость отклика различаются. Используйте Accessibility Inspector (Xcode) для iOS и Accessibility Scanner (Android) для автоматического поиска проблем.

Основные сценарии тестирования: регистрация (заполнение формы, валидация, отправка), поиск и навигация по каталогу, оформление заказа, восстановление пароля. Каждый сценарий должен быть выполнимым без визуального контроля — только через голосовые подсказки screen reader'а. Если пользователь screen reader'а не может завершить сценарий за то же время, что и обычный пользователь (±50%), — приложение требует доработки доступности.