Zum Hauptinhalt springen
Förderungen bis zu $15.000/Jahr für Medien
InclusiveWeb
Leitfäden

Screen Reader Testing Guide: NVDA, JAWS, and VoiceOver

How to test your site with a screen reader: installing NVDA, key commands, 10 checkpoints, common issues. Step-by-step guide for devs and QA.

A

Andrii Vdovyn

12 Min. Lesezeit

Чому треба тестувати скрін-рідером

Автоматизовані сканери (Lighthouse, axe) знаходять близько 30% реальних проблем доступності. Решту — 70% — можуть виявити лише два методи: ручний прохід клавіатурою і тестування скрін-рідером. Без screen reader-тесту ви ніколи не дізнаєтесь, що ваша «доступна» форма насправді озвучується як беззмістовний потік символів.

Які скрін-рідери існують

За даними WebAIM Screen Reader User Survey 2024, реальний розподіл серед користувачів:

Скрін-рідерПлатформаЧастка користувачівВартість
NVDAWindows65%Безкоштовно
JAWSWindows60%~$1000/рік
VoiceOver (macOS)macOS10%Вбудовано
VoiceOver (iOS)iPhone, iPad71% мобільнихВбудовано
TalkBackAndroid29% мобільнихВбудовано

Сума більше 100% — багато користувачів використовують кілька скрін-рідерів. Для розробників на Windows мінімум — це NVDA. Для тестування iOS/Android — VoiceOver та TalkBack.

Як встановити NVDA за 5 хвилин

  1. 1Завантажте інсталятор з nvaccess.org/download — близько 50 МБ.
  2. 2Запустіть інсталятор. Через 1–2 хвилини NVDA доступний у Start menu або через Ctrl+Alt+N.
  3. 3У налаштуваннях оберіть голос (Microsoft або Espeak), швидкість, мову. Для тестування українських сайтів — Microsoft українські голоси.
  4. 4Зменшіть гучність системи — голос за замовчуванням дуже швидкий і голосний. Адаптуйтесь поступово.

Базові команди NVDA

«NVDA-клавіша» за замовчуванням — Insert або CapsLock (вмикається в налаштуваннях).

  • Insert + ↓ — читати все від поточної позиції
  • Ctrl — зупинити озвучку
  • H — перейти до наступного заголовка (1–6 для конкретного рівня)
  • K — перейти до наступного посилання, B — до кнопки, F — до поля форми
  • D — наступний landmark (header, nav, main, footer)
  • Insert + F7 — список усіх посилань, заголовків і landmarks на сторінці
  • Tab — фокус на наступному інтерактивному елементі (стандартна навігація)

10 чекпоінтів тестування сторінки

  1. 1Title сторінки — натисніть Insert+T. Чи зрозуміло про що сторінка?
  2. 2Skip-link — перший Tab має пропонувати «Перейти до основного контенту». Працює?
  3. 3Структура заголовків — натисніть Insert+F7 → Headings. Чи є H1? Чи рівні йдуть послідовно (1→2→3, без стрибків)?
  4. 4Landmarks D має знайти header, navigation, main, footer. Якщо немає — ваш HTML без семантичних тегів.
  5. 5Зображення — пройдіться G (graphic). NVDA повинен прочитати alt-текст. «Image без опису» = провал.
  6. 6Посилання — список через Insert+F7 → Links. Чи є «детальніше», «тут», «читати»? Це провал WCAG 2.4.4.
  7. 7Форми — натисніть F і пройдіть всі поля. Кожне має озвучуватись зі своїм label. «Edit» без опису = провал.
  8. 8Кнопки B має знайти всі кнопки. Якщо <div onClick> замість <button> — їх не буде у списку.
  9. 9Динаміка — натисніть кнопку «Відправити» з помилкою. Чи озвучилась помилка? Якщо ні — потрібен role="alert" або aria-live.
  10. 10Модальні вікна — після відкриття focus має перейти у модалку, Esc закриває, Tab не виходить за межі. Класична пастка accessibility.

VoiceOver на macOS і iOS

macOS: увімкнути через Cmd+F5. «VO-клавіша» — це Control+Option. Основні команди: VO+A (читати все), VO+→ (наступний елемент), VO+U (Web Rotor — швидкий доступ до заголовків/посилань/форм).

iOS: Settings → Accessibility → VoiceOver. Жести: один тап (озвучити елемент), подвійний тап (активувати), свайп вправо (наступний елемент), три пальці свайп вгору/вниз (прокрутка). Для тестування mobile-сайтів незамінний.

Поширені проблеми, які знаходять скрін-рідери

  • «Click here», «детальніше» — у списку посилань через Insert+F7 одне «детальніше» нічого не означає поза контекстом
  • SVG-іконки без aria-label — кнопка з іконкою-серцем озвучується як «button» без слова «улюблене»
  • Toast-нотифікації без aria-live — «Замовлення оформлено» з'являється на 3 секунди і зникає без звуку
  • Карусель без управління — слайди змінюються автоматично, скрін-рідер постійно перечитує контент і користувач не встигає сприйняти
  • Custom dropdowns на div — без role="combobox" та aria-expanded, скрін-рідер не розуміє що це
  • Hidden link у меню — display:none ховає для всіх, visibility:hidden ховає для скрін-рідера, але CSS clip або abs+overflow:hidden залишає для assistive tech

Часті питання

Який скрін-рідер обрати для тестування?

Для desktop — NVDA: безкоштовний, найбільш популярний серед користувачів, працює у Firefox і Chrome. Якщо ваша аудиторія — корпоративний сектор США, додатково тестуйте у JAWS (там специфічна підтримка таблиць і форм). Для mobile — VoiceOver на iOS обов'язково, бо це 71% мобільних користувачів з порушеннями зору.

Чи можна автоматизувати скрін-рідер тестування у CI?

Частково. Тулзи на кшталт @guidepup/guidepup керують реальним VoiceOver через AppleScript і дозволяють писати скрипти. Але повноцінне розуміння UX — це досі ручна робота. Реальний підхід: автомат-перевірки (axe-core у Playwright) + квартальні ручні аудити з реальним скрін-рідером.

Скільки часу займає прохід однієї сторінки?

Швидкий smoke-test (10 чекпоінтів) — 5–10 хвилин для статичної сторінки, до 20 хвилин для складної (форми, динаміка, модалки). Повний детальний аудит з документацією — від 30 до 60 хвилин на сторінку. Тому критично спершу пройти автоматичним сканером, потім фокусуватись на проблемних шаблонах.

Чи варто залучати незрячих тестувальників?

Так, але це окремий процес. Усереднена практика: внутрішня команда (devs/QA) проходить базовий smoke-test з NVDA, що знаходить ~70% проблем. Раз на 6–12 місяців замовляйте аудит у користувачів зі справжніми порушеннями — вони знаходять unique edge-cases і дають feedback про UX, який не знайде нічий чек-лист.

Vom Lesen zum Handeln

InclusiveWeb scannt Ihre Website und behebt Barrierefreiheitsfehler in 3 Minuten. 7 Tage kostenlos, ohne Kreditkarte.

Screen Reader Testing Guide: NVDA, JAWS, and VoiceOver | InclusiveWeb