# Екранний читач

## Що це таке

Екранний читач — це програма, яка подає все, що є на комп'ютері чи телефоні, від тексту документа до
кнопок навколо нього й стану кожної з них, синтезованим мовленням або рядком на брайлівському
дисплеї та дає змогу керувати цим інтерфейсом із клавіатури чи жестами. Екранні читачі — це ціла
родина програм, а не один продукт: NVDA, безплатний і з відкритим кодом, та JAWS у Windows;
VoiceOver, вбудований у macOS і мобільні системи Apple; TalkBack в Android. Користуються ними
здебільшого незрячі люди й люди з порушеннями зору, а дехто, хто добре бачить екран, усе одно вмикає
екранний читач, бо слухати легше, ніж читати.

Найчастіше розробники не помічають одного: звідки беруться слова. Екранний читач не дивиться на
пікселі. Браузер перетворює HTML на другу структуру, дерево доступності, де кожен елемент зведено до
ролі (кнопка, посилання, заголовок, список), імені (слів, що його називають) і стану (позначено,
розгорнуто, вимкнено). Інтерфейс доступності операційної системи передає це дерево екранному
читачеві, а той його озвучує. Кнопка, видимий вміст якої — малюнок паперового літачка, а в коді
немає тексту, у цьому дереві є кнопкою без імені, і саме це людина й почує.

Сторінку також не слухають згори донизу. Зі стандартними клавішами NVDA в режимі огляду окремі
літери стають клавішами навігації: `H` переходить до наступного заголовка, `D` — до наступного
орієнтира, `K` — до наступного посилання, `F` — до наступного поля форми, а цифри від 1 до 9 — до
заголовка відповідного рівня. `NVDA+F7` відкриває список усіх посилань, заголовків або орієнтирів на
сторінці. У VoiceOver є ротор, який відкривають через `VO-U` і який пропонує ті самі списки. Зряча
людина переглядає текст, зачіпаючись поглядом за жирне виділення й відступи; той, хто працює з
екранним читачем, переглядає його, перестрибуючи між структурними елементами, і на сторінці без
такої структури стрибати просто нікуди.

## Чому це важливо

Справжнє рішення, яке стоїть перед командою, звучить так: чи працює випущений інтерфейс для людини,
що отримує його лише в тому вигляді, в якому його описує розмітка. Екранний читач — найбуквальніший
споживач, який є у сторінки. Макет, колір, розташування, піктограма, яку всі впізнають, поле, що
стає червоним: кожен сигнал, який живе лише у візуальному дизайні, губиться, і до слухача доходить
тільки те, що каже код.

Тому це та перевірка розмітки, яку не замінить скільки завгодно уважне розглядання сторінки. Огляд
дизайну, порівняння знімків екрана й ретельне проклацування відбуваються у візуальному каналі, а
саме там дефекти, які виявляє екранний читач, за визначенням невидимі. Автоматичні рушії правил
допомагають і ловлять справжні проблеми гуртом: зображення без альтернативного тексту, поле форми
без мітки, атрибут із неможливим значенням. Перевіряють вони те, що ім'я існує, а не те, що воно
правильне. Щоб почути, як кнопку оплати оголошують просто «кнопка», а меню — «гамбургер», потрібні
людина й кілька хвилин.

Ця людина й ці хвилини коштують менше, ніж думає більшість команд. NVDA встановлюється безплатно, а
VoiceOver уже є на кожному Mac та iPhone в офісі, тож перша перевірка не потребує ні покупки, ні
фахівця. Потрібно, щоб хтось заплющив очі або вимкнув екран і спробував виконати головне завдання
сторінки клавіатурою та на слух. Виправлення знайденого найдешевше, коли його роблять рано:
справжній елемент `button` чи `a` приносить свою роль і поведінку з клавіатурою із собою, а
клікабельний `div` потребує, щоб усе це збудували й підтримували вручну.

Компроміс у тому, що екранні читачі різні. Кожен тлумачить дерево доступності по-своєму, кожен
браузер будує це дерево по-своєму, і сторінка, перевірена в одній парі, в іншій може звучати інакше.
Дві поширені комбінації покривають більше, ніж одна, перевірена до дрібниць.

## Як це виглядає на практиці

В одному застосунку дефект було чути одразу. Інтерфейс малював свої елементи керування системними
символами, а символ без мітки доступності озвучується власним внутрішнім іменем, тож кнопка
надсилання називала себе «стрілка вгору коло, кнопка».
[Сімнадцять елементів керування лише з піктограмою отримали імена за тим, що вони роблять](/uk/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/):
кожна мітка називає дію, а не форму, і йде за станом елемента там, де разом зі станом змінюється
його значення. Тепер лінтер вимагає мітки доступності в межах восьми рядків від будь-якого елемента
лише з піктограмою; ця відстань навмисно груба й обрана вимірюванням, тож вісімнадцятий без мітки
вже не додати. Сторінка прямо називає межу: правило доводить, що мітка є поруч, а чи вона правильна,
досі має почути людина.

Документи ставлять те саме питання в іншому форматі. PDF, що має правильний вигляд на екрані, сам по
собі не показує, чи прочитає його екранний читач, тому дев'ять згенерованих документів, CV у
варіантах, аркуш рекомендацій, портфоліо й супровідний лист різними мовами,
[прогнали через незалежний валідатор для профілю доступності PDF/UA](/uk/portfolio/established-pdf-ua-1-conformance-across-nine-documents-146/),
і вони проходять 106 зі 106 правил. Для цього знадобилися тегована структура, оголошена мова
документа, альтернативний текст на кожній графіці, яка не є оздобою, справжній заголовок у метаданих
і явний порядок читання замість того, що випадково дає розкладка. Обидва числа походять від одного
валідатора, і сторінка про це каже.

Цей сайт ставиться до власних автоматичних перевірок так само. [Сторінка подяк](/uk/credits/)
називає їх мінімальним рівнем, а не доказом, і просить кожного, хто користується тут екранним
читачем і чує, що щось читається неправильно, написати про це, бо це той єдиний звіт, якого
перевірки самі не створять.

## Де виникають проблеми

Більшість вад, які чує екранний читач, на екрані не видно, і тому вони переживають рев'ю. Зазвичай
вони мають одну з кількох форм.

**Елемент керування оголошує свій малюнок.** Кнопка-піктограма без тексту отримує ім'я з того, що
дає код: назву файлу, назву символу або нічого, і тоді лишається голе «кнопка». Дайте кожному
елементу лише з піктограмою ім'я, що описує дію, а сам малюнок сховайте з дерева:

```html
<button type="button" aria-label="Надіслати повідомлення">
    <svg aria-hidden="true" focusable="false"><!-- піктограма --></svg>
</button>
```

**Сторінка звучить як один довгий потік.** Заголовки, які насправді є стилізованими елементами
`div`, і макет без орієнтирів виглядають нормально, але клавішам `H` і `D` нема на що стрибати, тож
слухачеві доводиться йти стрілками через кожен рядок, щоб знайти потрібне. Використовуйте справжні
`h1`–`h6` по порядку, а ділянки сторінки розміщуйте в `header`, `nav`, `main` і `footer`.

**Щось змінюється, а слухач чує тишу.** Під полем з'являється повідомлення про помилку, лічильник у
кошику зростає, коротке сповіщення виринає й зникає. Зрячі користувачі це бачать; екранний читач
мовчить, бо його фокус деінде. Перенесіть фокус на повідомлення або розмістіть динамічні оновлення в
ділянці з `aria-live`, щоб екранний читач їх оголосив.

**Приховане читається, а видиме мовчить.** Текст, відсунутий за межі екрана засобами CSS, лишається
в дереві доступності й читається вголос; `aria-hidden="true"` на видимому елементі прибирає його для
слухача, хоча всі інші й далі його бачать. І те, і те корисне навмисно й заплутує випадково, тож
перевіряйте, що містить дерево, а не лише що показує екран.

**Усі перевірки проходять, а сторінка й далі звучить погано.** Мітка може існувати й бути хибною,
альтернативний текст може описувати файл замість суті, а порядок читання може бути коректним і
безглуздим. Додайте короткий прохід на слух до контрольного списку випуску для кожної сторінки,
структура якої змінилася.

## Що почитати далі

- [Tools and Techniques](https://www.w3.org/WAI/people-use-web/tools-techniques/) — огляд W3C про
  те, як люди з інвалідністю користуються вебом, і про екранні читачі серед інших допоміжних
  засобів.
- [NVDA User Guide](https://download.nvaccess.org/documentation/userGuide.html) — режим огляду,
  навігація однією літерою та список елементів від розробників безплатного екранного читача.
- [Use the VoiceOver rotor on Mac](https://support.apple.com/guide/voiceover/use-the-voiceover-rotor-mchlp2719/mac)
  — посібник Apple про переходи за заголовками, посиланнями й орієнтирами.
- [Core Accessibility API Mappings 1.2](https://www.w3.org/TR/core-aam-1.2/) — як ролі, імена та
  стани переходять від браузера до інтерфейсу платформи, який читає екранний читач.

<https://engineer.company/uk/glossary/screen-reader/>