Требования к доступности цифрового продукта до начала разработки
На демо кнопка «Продолжить» видна. Клавиша Tab до неё не доходит. Мышью форма проходится за минуту, а с клавиатуры регистрация заканчивается на втором шаге.
Команда может исправить кнопку перед релизом. Следом обнаружатся модальное окно без фокуса, ошибка формы, которую не замечает скринридер, и видео без субтитров. Такой ремонт не заканчивается, потому что доступность не была частью исходных требований.
Ниже мы собрали каркас требований для владельца продукта, аналитика и подрядчика. Он помогает договориться о результате до дизайна и первой строки кода.
94,8% страниц ошибаются там, где требования молчат
В исследовании WebAIM Million 2025 автоматическая проверка нашла вероятные нарушения WCAG на 94,8% миллиона популярных главных страниц. Средний результат: 51 обнаруживаемая ошибка на страницу. Чаще всего встречались низкий контраст, пропущенные альтернативные описания изображений, поля без подписей, пустые ссылки и кнопки.
У цифры есть важное ограничение. WebAIM проверял только главные страницы и только те проблемы, которые умеет уверенно находить автоматический инструмент. Отсутствие ошибок в отчёте сканера ещё не доказывает, что продукт доступен. Масштаб исследования показывает другое: базовые дефекты годами повторяются в самых разных интерфейсах.
Обычно они рождаются раньше HTML. Серый текст на светлом фоне появляется в макете. Кнопка без ясного названия появляется в прототипе. Таймер без паузы закрепляется в бизнес-правиле. Разработчик получает уже принятое решение и может лишь аккуратно реализовать заложенный барьер.
Доступность до первой строки кода начинается с проверяемого требования. В нём указаны стандарт, охват, пользовательские сценарии, тестовые среды, ответственность и доказательства приёмки.
Фразе «сделать по WCAG» не хватает четырёх решений
Для веб-продукта рабочей базой часто становится стандарт WCAG 2.2 и уровень AA. Этого всё равно мало для постановки задачи. Нужно назвать версию стандарта, платформы, часть продукта в охвате и способ проверки.
WCAG рассматривает полную страницу и полный процесс. У интернет-магазина нельзя признать доступным каталог, когда оформление заказа разваливается на вводе адреса или оплате. В требованиях фиксируют маршрут целиком: регистрация, вход, поиск, корзина, оплата, подтверждение, возврат и обращение в поддержку.
Для нативных приложений границы нужно описать отдельно. Проект руководства WCAG2Mobile переносит критерии уровня A и AA на нативные, веб- и гибридные приложения, но прямо называет документ ненормативным и недостаточным сам по себе. Значит, ТЗ должно назвать iOS, Android, версии ОС, системные средства доступности и комбинации для тестирования.
Рынок запуска тоже влияет на требования. Европейский акт о доступности применяется с июня 2025 года к отдельным категориям продуктов и услуг, среди них электронная коммерция, банковские и платёжные сервисы, электронные коммуникации. Точный охват зависит от продукта и страны, поэтому юридическую проверку нельзя заменять ссылкой на WCAG.
Семь пунктов, которые стоит записать до дизайна
1. Цель и уровень соответствия
Запишите конкретную цель: например, веб-версия соответствует WCAG 2.2 на уровне AA. Рядом укажите применимые законы, корпоративные политики и исключения, подтверждённые юристами. Формулировка «учесть доступность» не задаёт результата и не помогает принять работу.
2. Охват продукта и критические маршруты
Перечислите платформы, роли и процессы, которые входят в проверку. Для магазина это путь от поиска товара до подтверждения оплаты. Сценарий LMS включает вход, выбор курса, запуск урока, выполнение задания и просмотр результата. Сценарий кабинета сотрудника включает авторизацию, заявку, согласование, статус и получение документа.
Важно зафиксировать состояния внутри маршрута: пустые данные, ошибка сети, неверный ввод, истёкшая сессия, загрузка, отмена и успешное завершение. Доступный счастливый путь не компенсирует тупик после ошибки.
3. Пользователи и способы взаимодействия
Требования должны учитывать людей, которые пользуются клавиатурой без мыши, скринридером, увеличением, голосовым управлением, субтитрами или изменёнными настройками цвета и шрифта. Это перечень способов взаимодействия, которые продукт обязан поддержать.
W3C рекомендует подключать людей с инвалидностью на протяжении разработки и одновременно проверять соответствие стандарту. Опыт одного участника нельзя переносить на всех, поэтому исследование с пользователями дополняет экспертную проверку.
4. Поведение интерфейса
Для компонентов нужны критерии, которые можно воспроизвести. Все действия доступны с клавиатуры; порядок фокуса следует логике экрана; фокус заметен и не перекрыт; у элемента есть понятное имя, роль и состояние; ошибки и изменения статуса передаются вспомогательным технологиям; инструкция не опирается только на цвет, форму или положение; перетаскивание, жест и таймер имеют доступную альтернативу.
Эти правила влияют на дизайн-систему. Один доступный компонент кнопки, поля, вкладки или модального окна затем работает в десятках экранов. Одна неверная основа так же уверенно размножает дефект.
5. Контент и медиа
Заранее распределите ответственность за заголовки, названия ссылок, альтернативные описания, субтитры, расшифровки, сообщения об ошибках и язык страницы. Смысл изображения задаёт автор. Подпись к ошибке должна прямо помогать человеку исправить платёжные данные.
У контента должен быть владелец и срок подготовки. Иначе доступность видео или сложной инфографики всплывёт после монтажа, когда переделка уже требует отдельного бюджета.
6. Матрица совместимости
Назовите реальные сочетания устройств, браузеров и вспомогательных технологий. Для веб-сервиса это могут быть клавиатура без мыши, NVDA с Chrome на Windows, VoiceOver с Safari на iOS и macOS, TalkBack с Chrome на Android. Состав матрицы выбирают по аудитории, аналитике продукта и рынку запуска.
Фраза «работает со скринридером» слишком широка. Приёмке нужны версии платформ, критические маршруты и ожидаемый результат. Матрицу пересматривают вместе с поддерживаемыми браузерами и устройствами.
7. Проверка, ответственность и доказательства
W3C советует заранее документировать цель, охват и ответственных, а также планировать ресурсы на обучение, аудит и тестирование с пользователями. В проекте это превращается в распределённую ответственность. Аналитик описывает сценарии, дизайнер готовит состояния и контраст, автор отвечает за контент, разработчик сохраняет семантику и управление, QA проверяет маршруты, владелец продукта принимает остаточный риск.
Автоматические проверки запускаются на компонентах и в сборке. Специалист проходит сценарии клавиатурой и со вспомогательными технологиями. Пользовательское исследование показывает барьеры, которые формальная проверка могла не объяснить. W3C отдельно подчёркивает: один инструмент не определяет соответствие стандарту, для этого нужна компетентная оценка.
В требованиях также фиксируют доказательства приёмки: чек-лист по критическим маршрутам, отчёт аудита, список дефектов с приоритетами и результаты повторной проверки. Барьер, который не даёт завершить основной процесс, становится блокером релиза.
Готовая формулировка для требований
Для веб-сервиса запись может выглядеть так:
«Веб-версия продукта соответствует WCAG 2.2 на уровне AA. Требование распространяется на регистрацию, вход, восстановление пароля, поиск, оформление заказа, оплату, получение подтверждения и обращение в поддержку. Каждый маршрут можно завершить только с клавиатурой. Критические сценарии проверяются в NVDA с Chrome на Windows, VoiceOver с Safari на iOS и TalkBack с Chrome на Android. На этапе дизайн-системы проверяются компоненты и состояния, в каждом спринте проверяются новые сценарии, перед релизом проходит проверку полный маршрут. Дефекты, блокирующие критический процесс, останавливают выпуск. Результат подтверждают чек-лист, журнал дефектов и повторная проверка».
Это пример требуемой детализации. Юридический охват проверяют отдельно. У требования есть объект, среда, момент проверки, критерий результата и ответственный за решение.
Приёмка охватывает маршрут целиком
Поздний аудит всё ещё полезен: он находит реальные барьеры и даёт план исправлений. Его цена растёт вместе с количеством уже принятых решений. Замена цвета в одном токене дизайн-системы проста. Перестройка навигации, форм, видеоплеера и купленной библиотеки компонентов затрагивает дизайн, код, контент, QA и сроки релиза.
Поэтому доступность живёт в тех же артефактах, что безопасность и производительность: в пользовательских историях, макетах, библиотеке компонентов, критериях приёмки, тест-плане и Definition of Done. Отдельный аудит остаётся контрольной точкой и дополняет проверки на каждом этапе.
Вернёмся к кнопке «Продолжить». До неё должен доходить фокус, её название должен объявлять скринридер, состояние должно быть понятно без цвета, а ошибка после нажатия должна объяснять следующий шаг. Всё это можно решить до разработки. Для этого достаточно записать поведение раньше пикселей и кода.
Правило короткое: хорошее требование заканчивается проверяемым результатом. Когда в документе есть только слово «доступность», команда получит разное понимание и общий дедлайн.
Если вы собираете новый цифровой продукт или пересматриваете требования к существующему, можно обсудить требования и контур разработки с нами. На старте определим критические маршруты, платформы, критерии приёмки и места, где доступность влияет на архитектуру и дизайн-систему.
