Скринридеры: как проверить интерфейс за час с помощью VoiceOver и NVDA

Каждый раз, когда я предлагаю фронтенд-разработчикам поработать со скринридером, в ответ слышу одно из двух: «у меня нет времени разобраться» или «но я и так слышу, как голос читает страницу, что ещё». Оба ответа неверные. Час с VoiceOver или NVDA даёт больше информации о реальной доступности интерфейса, чем все автотесты вместе взятые. Просто никто не показал, как правильно подойти к этому за час, без курса в шесть недель.

Эта статья — про быстрый способ проверить свой интерфейс скринридером. Без амбиций «стать профессиональным тестировщиком a11y», но с полезным результатом: увидишь конкретные места, где интерфейс плохо работает для незрячих пользователей.

Как пользователи реально слушают

Первая ошибка, которую делают разработчики при первом запуске скринридера, — нажимают Tab и ждут, что им зачитают всю страницу. Реальный пользователь так не делает. У скринридера три режима навигации:

1. Tab/Shift+Tab — по интерактивным элементам. Кнопки, ссылки, инпуты, чекбоксы. Не по тексту.
2. Стрелки + модификаторы — построчно по контенту. Заголовки, абзацы, элементы списка.
3. Перепрыгивание по типам — сразу к следующему заголовку (H), к следующему landmark (D в NVDA), к следующей ссылке (K).

Незрячий пользователь чаще использует именно третий способ. Никто не слушает страницу с начала до конца. Открыл — прыгнул на h1, услышал общую тему, прыгнул на main, оттуда по подзаголовкам.

Если твоя страница не проходится по h2/h3 — у тебя нет структуры. Если у тебя нет landmarks — пользователь застрянет в верхушке.

VoiceOver на macOS: запуск за минуту

VoiceOver включён в macOS из коробки. Включить — Cmd+F5. Появится окошко с курсом первого использования; кликни «Узнать больше», если есть пять минут, иначе закрой.

Управление построено на клавише модификаторе VO. По умолчанию это Ctrl+Option. Везде, где я пишу «VO+что-то», читай как Ctrl+Option+что-то.

Самый важный набор:

• VO+→ / VO+← — следующий/предыдущий элемент.
• VO+Cmd+H — следующий заголовок.
• VO+Cmd+L — следующая ссылка.
• VO+U — открыть Rotor (меню навигации). В нём стрелками выбираешь категорию (Headings, Landmarks, Links, Form Controls), и стрелками вниз/вверх прыгаешь по элементам.
• VO+A — прочитать всё с текущего места.
• Ctrl — остановить чтение немедленно.
• Cmd+F5 — выключить VoiceOver.

Один раз пройди по своей странице через Rotor. Это занимает пять минут, но сразу видишь, насколько структурирован контент.

NVDA на Windows: запуск за минуту

NVDA — бесплатный скринридер, скачивается с nvaccess.org. Установка стандартная.

Управление через клавишу-модификатор NVDA. По умолчанию это Insert (на Mac-клавиатуре часто заменяется на CapsLock в настройках при первом запуске).

Минимальный набор:

• ↓ / ↑ — построчно по контенту.
• H — следующий заголовок (Shift+H — предыдущий). Всё остальные одиночные буквы — те же категории.
• K — следующая ссылка.
• D — следующий landmark.
• F — следующее поле формы.
• NVDA+F7 — открыть список элементов на странице (как Rotor в VoiceOver).
• Ctrl — остановить речь.
• NVDA+Q — выйти.

Я обычно держу обе тулзы. У них разные алгоритмы озвучки одних и тех же элементов, и проблемы вылезают разные. Проверять только в одном — половинчато.

Часовая проверка: что именно слушать

За час реалистично пройти три ключевых сценария интерфейса. Я обычно беру: главную страницу, форму регистрации/логина, рабочий экран приложения (дашборд или список).

На каждом сценарии задаю шесть вопросов:

1. Понятно ли назначение страницы за первые пять секунд

Включаешь скринридер, нажимаешь H для перехода на h1. Что слышишь. «Дашборд», «Личный кабинет» — отлично. «Logo», «Untitled», «Главная» (на нелогичной странице) — баг.

2. Можно ли быстро перейти к main контенту

Открываешь Rotor / список элементов, ищешь main landmark. Должен быть один. Прыгаешь на него — фокус и чтение начинаются с основной части страницы.

3. Все ли интерактивные элементы озвучиваются как интерактивные

Tab по странице. Каждый шаг — слышишь роль элемента: «button», «link», «edit». Если слышишь только текст без роли — это div с onClick, чини.

4. Совпадает ли визуальное и аудио описание

На каждой иконочной кнопке слушай, что озвучивается. «Кнопка» без названия — нет лейбла. «Х кнопка» — лейбл прибит к символу. Должно быть «Закрыть кнопка» или «Удалить кнопка».

5. Озвучиваются ли изменения после действия

Заполни форму, нажми «Отправить» с пустым обязательным полем. Скринридер должен сообщить о появлении ошибки. Если ошибка появилась визуально, но скринридер молчит — у тебя нет live-региона или нет связи через aria-describedby от input к тексту ошибки.

6. Понятен ли порядок Tab-навигации

Просто пройдись Tab'ом сверху вниз. Логичен ли порядок? Иногда DOM-порядок не совпадает с визуальным (например, sidebar справа в DOM идёт первым). Если фокус прыгает «как попало» — работа на завтра.

Конкретные проблемы, которые ловишь сразу

За семь лет проверки интерфейсов скринридером я видела одни и те же баги десятки раз. Список того, что обычно вылезает в первый же час:

• Незакрытый модал. Открыли модалку, нажали Tab — фокус ушёл за её пределы, в фон. Признак того, что нет focus trap.
• Озвучка названий файлов. «slash-images-slash-banner-final-final-2-png» — это alt отсутствует, скринридер озвучивает имя файла.
• Двойная озвучка. «Кнопка кнопка сохранить кнопка» — это aria-label="Кнопка сохранить" на <button>. ARIA дублирует роль, которая уже есть.
• Скрытые от глаз, но видимые скринридером. display: none убирает отовсюду, а visibility: hidden — отовсюду тоже. Но opacity: 0 или position: absolute; left: -9999px — скринридер всё ещё читает. На странице с offscreen-меню часто слышишь все его пункты, хотя визуально их нет.
• Заголовки h1 в нескольких экземплярах. Скринридер озвучивает «уровень 1» три раза. Это сбивает.
• Нет связи между error и input. Внизу формы сообщение «Email некорректный», но при фокусе на input ничего не озвучивается. Нужно aria-describedby от input на id текста ошибки.

Что НЕ нужно делать в первый час

Не пытайся работать со скринридером без зрения. Это бесполезно: профессиональный пользователь учится годами, у него вся память про комбинации клавиш и звуковые паттерны. За час ты только себя замучаешь.

Не ставь цель «прослушать всю страницу до конца». Реальный пользователь так не делает. Слушай по структуре: заголовки, landmark'и, по форме — поля и ошибки.

Не делай вывод «всё хорошо», если просто Tab-нул без проблем. Tab — это самое лёгкое. Реальные баги вылезают на динамических обновлениях и сложных виджетах.

Когда подключать профессионалов

Часовая проверка — это уровень 0 для разработчика. Найдёшь 30-50% типовых проблем. Этого достаточно, чтобы не выкатить откровенно сломанный интерфейс. Но дальше идут вещи, которые нужно проверять с реальными пользователями скринридеров: насколько естественно звучат подсказки, не утомляет ли длинная навигация, удобны ли динамические таблицы.

Я работала в продуктовой компании, где раз в квартал мы приглашали тестировщиков с инвалидностью по зрению. За день платного аудита они находили вещи, которых я в жизни бы не нашла. Например, что наш «удобный» drag-and-drop переноса карточек был полностью недоступен — а альтернативного способа мы не предусмотрели.

Если у проекта серьёзный охват — заложи бюджет на такой аудит хотя бы раз в полгода. Если бюджета нет — хоть час со скринридером в неделю силами разработчика. Это всё ещё в десять раз больше, чем у среднего проекта.

Что унести с собой

Скринридер — это не магия и не отдельная профессия. Это обычный инструмент, как Chrome DevTools, который любому фронтенду полезно держать в руках. Час в неделю с VoiceOver или NVDA даёт реальную обратную связь о том, как интерфейс работает для незрячих. Это лучше, чем все автотесты на доступность вместе взятые.

Минимум для старта: VO+U / NVDA+F7 для просмотра структуры, Tab по форме, проверка что у каждой иконочной кнопки есть лейбл, а у каждой ошибки в форме — связь с input. Этих четырёх вещей достаточно, чтобы интерфейс перестал быть «тёмным пятном» для пользователей assistive technology.