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) та сторонні рішення для специфічних ніш — наприклад, для користувачів китайських смартфонів без сервісів 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%), — додаток потребує доопрацювання доступності.