Оценка доступности

Когда использовать

Проверять доступность (по-английски accessibility evaluation или accessibility testing) нужно на всём пути, а не один раз перед релизом. Контраст и размеры можно оценить на макетах, порядок фокуса и подписи полей — на прототипе, всё остальное — на рабочей сборке. Чем раньше найден барьер, тем дешевле исправление. В готовом продукте проверку повторяют при каждой новой крупной функции.

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

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

Что нужно для старта

• Версия продукта, которую можно открыть. Макет для проверки контраста, кликабельный прототип или рабочая сборка
• Уровень, с которым сравниваете. Для большинства продуктов это WCAG 2.2 уровня AA, для сайтов органов власти — ещё и постановление правительства
• Расширение для проверки страниц (axe DevTools, WAVE или Lighthouse) и хотя бы один скринридер
• Список главных сценариев, которые пользователь должен пройти без барьеров
• Для сессий с людьми. Время на поиск участников, их устройства и запас времени на настройку

Как провести

1. Границы проверки

   Решите, что именно проверяете, для чего и на каком уровне WCAG. Пройдите по продукту и выпишите ключевые экраны, повторяющиеся элементы и сценарии. Если страниц много, выберите образец, в который попадают все типы страниц и все ключевые функции.

2. Быстрый осмотр

   Начните с набора простых проверок. Есть ли у каждой страницы своё название. Есть ли альтернативный текст у значимых картинок. Не пропущены ли уровни заголовков. Достаточен ли контраст, обычному тексту нужно не меньше 4,5 к 1. Увеличивается ли текст до 200 % без обрезания. Виден ли фокус при переходе клавишей Tab, есть ли у полей подписи, есть ли субтитры и расшифровка у видео. Этот осмотр под силу человеку без глубокой подготовки, но он не показывает всего.

3. Автоматические проверки

   Прогоните страницы через axe, WAVE или Lighthouse. Они быстро находят отсутствующие подписи, слабый контраст и ошибки в разметке. Относитесь к результату как к первому списку, а не как к итогу.

4. Ручная проверка

   Пройдите сценарий только с клавиатуры. Порядок фокуса должен совпадать с порядком на экране, каждый элемент должен быть достижим и виден в фокусе, из окон нужно уметь выйти. Затем прочитайте страницу скринридером. У картинок должен быть смысловой текст, у полей и кнопок названия, у собственных компонентов роль и состояние, а порядок чтения должен быть логичным. Проверьте и увеличение примерно до четырёх раз, а также режим высокой контрастности.

5. Вспомогательные технологии

   Решите, на чём проверять. Обязательный минимум из британского руководства для госсервисов такой. На компьютере JAWS и NVDA, на телефоне VoiceOver на iOS и TalkBack на Android, лупа Windows или Apple Zoom и программа голосового управления Dragon. Если на всё времени нет, возьмите то, что доступно, но оставьте хотя бы один компьютерный скринридер, один мобильный, лупу и голосовое управление.

6. Сессии с участниками

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

7. Отчёт и повторная проверка

   Для каждого барьера укажите экран, критерий WCAG, способ обнаружения и как его воспроизвести. После исправления проверьте то же место ещё раз. Для итогового заключения о соответствии используйте пять шагов методики WCAG-EM. Определите область, изучите продукт, выберите образец страниц, оцените его и составьте отчёт.

Результат

Перечень барьеров с привязкой к критериям WCAG. У каждого указаны экран, критерий и его уровень, способ, которым нашли, и что исправить. К перечню прикладывают список проверенных пар «технология и браузер» и, если были сессии, заметки участников.

Типичные ошибки

• Только автоматические проверки

  Инструменты находят часть барьеров, остальные видны только руками и на сессиях. Автоматика не оценивает, осмысленно ли подписано изображение.

• Проверка только в конце

  Неформальные проверки на протяжении проекта дают больше, чем одна итоговая сессия. Барьеры в макете исправляют быстрее, чем в готовом коде.

• Один участник вместо группы

  Опыт одного человека с ограничением не переносится на всех. Результаты маленького исследования нельзя обобщать на всю аудиторию.

• Мало времени на подготовку сессии

  Скринридер, запись и устройства участника требуют настройки. На удалённой сессии звук скринридера бывает плохо слышен, а само ПО для связи может оказаться недоступным.

• Только самые активные участники

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

Российская специфика

С 1 марта 2026 года для официальных сайтов органов власти и подведомственных организаций действует постановление правительства № 102. В нём требования для людей с нарушениями зрения. Работа с клавиатуры и вспомогательными технологиями, увеличение текста не менее чем на 200 % без горизонтальной прокрутки, контраст 4,5 к 1 (для крупного текста 3 к 1), подписи у полей и доступные сообщения об ошибках, возможность остановить движущийся контент. Для остальных продуктов этот список можно брать как готовый чек-лист.

ГОСТ Р 52872-2019 основан на WCAG и описывает требования доступности для людей с ограничениями жизнедеятельности. По общему правилу национальный стандарт применяют добровольно. Яндекс и команда сайтов Югры привлекали незрячих специалистов.

Кто использует

Яндекс проводит аудит своих сервисов с участием незрячего тестировщика. Команда по инклюзии составляет список сервисов и сценариев, исследователь вместе с незрячим экспертом проходит их скринридером и пишет отчёт, затем на открытой сессии незрячий пользователь выполняет главные действия при команде сервиса, после исправлений тестировщик проверяет их снова. По итогам сервисы получают место в одной из четырёх лиг. В 2022 году проверили 21 сервис, в первую лигу, где работают основные сценарии, вошли 10. Подробности — в рассказе тестировщика на Хабре.

Югорский НИИ информационных технологий привёл в порядок единый сайт органов власти ХМАО и 36 ведомственных сайтов. Команда проверяла страницы клавиатурой и NVDA, прогоняла их через Lighthouse, axe DevTools и Colour Contrast Analyser. Позже незрячие специалисты нашли то, что команда пропустила. Исправили таблицы, которые давали горизонтальную прокрутку, потерянный фокус и кнопки-иконки без названия. Автопереключающийся слайдер убрали совсем. Разбор — в статье команды.