Доступный сайт: план внедрения без формальной галочки

Что означает доступность для работающего сайта

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

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

С чего начать, если сайт уже работает

Выберите ограниченный, но законченный пользовательский путь. Так команда увидит пользу и поймёт трудоёмкость до масштабирования.

• Составьте перечень ключевых задач: найти услугу, сравнить варианты, оставить заявку, получить ответ. Для интернет-магазина добавьте поиск товара, корзину и оплату. Зафиксируйте устройство, браузер и технологию помощи, с которыми будете проверять путь.
• Соберите типовые шаблоны: главная, каталог, карточка, статья, форма, меню, модальное окно. Ошибка в общей кнопке или поле повторяется на десятках URL; исправление компонента эффективнее точечных правок.
• Проверьте семантику HTML, порядок заголовков, подписанные поля, видимый фокус, контраст, альтернативы значимых изображений и сообщения об ошибках. Автоматический инструмент используйте как один из входов, а не как итоговый вердикт.
• Назначьте владельцев: дизайнер отвечает за состояния и макеты, редактор — за ясность и альтернативный текст, разработчик — за поведение и семантику, тестировщик — за воспроизводимую проверку, владелец продукта — за приоритет.
• Зафиксируйте исходное состояние в виде конкретных препятствий: например, меню не открывается с клавиатуры или ошибку формы нельзя услышать скринридером. Каждой проблеме привяжите сценарий и критерий успешного исправления.

План внедрения по шагам

Порядок выбирают по влиянию на задачу и повторяемости компонента, а не по удобству закрытия замечания.

• Сначала устраните блокирующие препятствия на критическом пути. Если без мыши нельзя открыть меню или отправить форму, косметическая доработка второстепенной страницы не компенсирует проблему.
• Исправьте базовые компоненты дизайн-системы: кнопки, ссылки, поля, подсказки, диалоги и уведомления. Запишите состояния наведения, фокуса, ошибки и успешного завершения, чтобы одна и та же логика сохранялась во всех шаблонах.
• Уберите управление, завязанное только на цвет, жест или таймер. Смысловое состояние должно быть понятно по тексту или доступной подписи. Проверьте, что при увеличении масштаба контент не исчезает и не требует двухмерной прокрутки без необходимости.
• Проверьте путь клавиатурой без мыши: последовательность фокуса, возможность открыть и закрыть диалог, возврат фокуса, отсутствие ловушек. Затем пройдите тот же путь с распространённым скринридером и документируйте обнаруженные расхождения.
• Проведите редакторскую проверку: понятные названия ссылок, инструкции до поля, ошибки с объяснением способа исправления, субтитры для значимого видео и альтернативные описания там, где изображение несёт смысл.
• После исправлений выполните регрессию на разных размерах экрана и в основных браузерах. Результат фиксируйте по сценариям, а не только числом закрытых задач; оставшиеся исключения опишите открыто.
• Включите доступность в определение готовности нового интерфейса: дизайн-ревью, проверка компонентов, ручная приёмка критического пути и контроль после публикации. Иначе следующий релиз вернёт те же ошибки.

Артефакты, которые не дадут работе рассыпаться

Короткий реестр препятствий и проверяемые сценарии лучше неопределённого задания «сделать по WCAG».

• Для каждого замечания храните URL или компонент, шаг воспроизведения, ожидаемое поведение, фактическое поведение, затронутую задачу и ответственного. Приложите критерий WCAG, если он применим; не подменяйте описание проблемы номером критерия.
• В дизайн-системе заведите примеры корректных состояний поля, ошибки, сообщения об успехе и диалога. Разработчик получает не только картинку, но и порядок фокуса, подписи и поведение при ошибке.
• Разделите исправления на блокирующие сценарий, серьёзно затрудняющие и локальные. Приоритет обсуждайте с владельцем продукта и людьми, использующими вспомогательные технологии, а не только с командой интерфейса.
• Планируйте повторную проверку после изменений CMS, темы, библиотеки компонентов, формы заявки и платежного пути. Доступность — свойство работающего процесса выпуска, а не разовый сертификат.

Типичные ошибки при внедрении

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

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

Как оценивать результат

Считайте не только найденные ошибки, но и завершённые сценарии с понятным контекстом проверки.

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

Рабочий результат первого цикла

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

Если команда не может показать воспроизводимый сценарий приёмки, формулировка «сайт доступен» пока преждевременна. Начните с наблюдаемого пользовательского результата и стройте выпуск вокруг него.

Пример приёмки формы заявки

Откройте страницу услуги без мыши и пройдите от заголовка до подтверждения отправки. Фокус должен быть видимым и идти в логичном порядке. У каждого поля есть подпись; если обязательное поле пусто, сообщение объясняет ошибку и доступно скринридеру. После исправления данные не пропадают. Затем повторите путь на мобильном масштабе и с другим устройством ввода. Это один проверяемый сценарий, а не утверждение о полной доступности сайта.