Кнопку починили — нашли ещё четыре дефекта: почему доступность нужно проектировать до разработки

На демо всё работало. Имя вводилось, чекбокс отмечался, кнопка «Продолжить» красиво меняла цвет при наведении. Регистрация занимала меньше минуты. Пока человек не убирал руку с мыши.

Клавиша Tab дошла до чекбокса, потом перескочила в футер. Кнопка осталась на экране, но добраться до неё было нельзя. Для команды это выглядело как мелкий баг. Для пользователя регистрация закончилась на втором шаге.

Привет, я Антон Фокин, CEO Qtim. Проблема появляется ещё до разработки: когда в прототипе не задан порядок фокуса, а в ТЗ остаётся только «учесть доступность». Одна пропущенная кнопка заставляет проверить весь маршрут регистрации. Пока готова только одна форма, это можно сделать без срочной встречи перед релизом.

Разработчик вернул кнопке фокус. На следующем экране открылось модальное окно, из которого клавиатурой уже не выйти. Ошибка формы осталась красной рамкой без текста. Скринридер не сообщил, что данные отправлены. У видео не оказалось субтитров.

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

С кнопкой всё довольно конкретно: фокус до неё доходит, скринридер объявляет название и состояние, после нажатия человек понимает, что произошло. До разработчика эти требования доходят последними. Серый текст уже появился в макете. Таймер без паузы закрепили в требованиях. Субтитры вспомнили добавить после монтажа.

WebAIM Million 2025 показывает масштаб: автоматическая проверка нашла вероятные нарушения WCAG на 94,8% из миллиона популярных главных страниц, в среднем 51 ошибку на страницу. Исследование не сообщает, когда появились эти дефекты и на каком этапе их заметили. Эти данные говорят о распространённости проблем: базовые ошибки встречаются даже на самых популярных сайтах.

Фраза выглядит солидно и помещается в одну строку ТЗ. Владелец продукта представляет доступный сервис целиком. Дизайнер думает о контрасте и состояниях компонентов. Разработчик готовит семантику и управление с клавиатуры. Тестировщик включает скринридер и обнаруживает, что список маршрутов никто не согласовал.

WCAG 2.2 на уровне AA даёт команде общий язык. Границы продукта стандарт за неё не выберет.

Представим интернет-магазин. Каталог открывается с клавиатуры, карточка товара читается правильно, фильтры работают. На вводе адреса фокус улетает в начало страницы, а ошибка остаётся красной рамкой. Команда успешно проверила десятки экранов. Покупатель всё равно ушёл без заказа.

На приёмке проходят путь покупки целиком: поиск, корзину, адрес, оплату, подтверждение и возврат после сбоя. Число проверенных экранов само по себе ничего не доказывает.

У него стабильный интернет, правильный пароль и терпение человека, который заранее прочитал сценарий тестирования. Сессия не истекает, текст остаётся в масштабе 100%, форма заполняется с первой попытки. Реальный пользователь этот сценарий, разумеется, не читал.

Связь оборвалась во время оплаты. Ошибка появилась после отправки формы. Урок перенесли. Текст увеличили, и кнопка уехала за край экрана. Человек вернулся после сбоя и не понял, сохранился ли результат.

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

Я считаю требование рабочим, когда команда знает, какой маршрут проверить и в какой момент остановить выпуск. Фраза «работает со скринридером» для этого примерно так же полезна, как «работает на компьютере». Нужны конкретные сочетания: например, NVDA с Chrome на Windows, VoiceOver с Safari на iOS и macOS, TalkBack с Chrome на Android. Набор зависит от аудитории, аналитики и рынка запуска.

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

Рабочее требование для веб-сервиса может выглядеть так:

«Веб-версия продукта соответствует WCAG 2.2 на уровне AA. Требование распространяется на регистрацию, вход, восстановление пароля, поиск, оформление заказа, оплату, подтверждение и обращение в поддержку. Каждый критический маршрут можно завершить с клавиатуры. Сценарии проверяются в согласованной матрице браузеров и вспомогательных технологий. Компоненты и состояния проверяются в дизайн-системе, новые сценарии — в каждом спринте, полный маршрут — перед релизом. Дефекты, блокирующие критический процесс, останавливают выпуск. Результат подтверждают чек-лист, журнал дефектов и повторная проверка».

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

Вернёмся к форме с демо. Теперь Tab снова идёт по шагам регистрации и доходит до кнопки «Продолжить». Скринридер объявляет её название. Ошибка после нажатия объясняет следующий шаг. Цвет помогает, но не остаётся единственным сигналом.

Слово «доступность» само по себе до релиза доживает легко. Пользователю от этого не легче.

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