Доступность сайта по WCAG: практический план для команды

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

Доступность — не отдельная версия интерфейса, а качество основных пользовательских сценариев.

Используйте логичную структуру заголовков, подписи полей и настоящие кнопки для действий.

Интерактивный элемент должен иметь доступное имя и предсказуемое поведение.

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

В модальных окнах корректно переводите фокус и возвращайте его после закрытия.

Оцените контраст текста, масштабирование, размер целей на сенсорном экране и поведение при увеличенном шрифте.

Не передавайте важный смысл только цветом или анимацией.

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

Документируйте найденные проблемы с приоритетами и повторно проверяйте исправленные сценарии.

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

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

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

Проверяйте страницу без CSS: остаются ли порядок текста, навигация и смысл блоков логичными? Затем откройте её с клавиатуры и проходите Tab, Shift+Tab, Enter и Escape. Если порядок фокуса перескакивает между не связанными секциями, верстка может быть визуально красивой, но реальный сценарий пользоваться ей трудно.

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

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

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

Изображения несут разную функцию. Декоративному фону часто нужен пустой альтернативный текст, а содержательной иллюстрации — короткое объяснение. Подпись не должна повторять весь абзац рядом. Если график передаёт важные данные, предложите текстовый эквивалент или таблицу, чтобы смысл не терялся без изображения.

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

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

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

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

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

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

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

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