Редакция Romanov Lab · Обновлено
Первую проверку доступности можно начать без сложной лаборатории: пройти важный сценарий с клавиатуры, внимательно проверить форму и измерить контраст. Это помогает найти заметные барьеры до запуска или редизайна. Однако короткий чек-лист не подтверждает соответствие всего сайта WCAG: полноценная оценка охватывает больше требований, страниц, состояний и способов взаимодействия.
Выберите несколько разных шаблонов: главную, страницу услуги, статью, форму обращения и результат отправки. Проверяйте также всплывающее окно, мобильное меню и сообщение об ошибке. Если готовится дизайн или редизайн сайта, такие состояния стоит включать в макеты сразу, а не добавлять после вёрстки.
Пройдите путь посетителя без мыши
Откройте страницу заново и используйте Tab для перехода вперёд, Shift+Tab для возврата, Enter и пробел для предусмотренных элементом действий. В некоторых браузерах сначала нужно проверить настройку клавиатурной навигации. Цель теста: выбрать услугу, открыть форму, заполнить её и получить результат, не прибегая к указателю.
W3C описывает требование доступности функциональности с клавиатуры и отдельно видимый фокус. На практике проверяйте три вопроса: где сейчас находится пользователь, логично ли следующее перемещение и можно ли завершить начатое действие. Видимая рамка полезна лишь тогда, когда её не скрывает соседний блок.
- Ссылки и кнопки получают различимый фокус, включая элементы в шапке и подвале.
- Порядок перемещения соответствует смыслу страницы и не скачет между несвязанными областями.
- Меню можно открыть, пройти и закрыть без мыши.
- После закрытия диалога фокус возвращается в понятное место, обычно к открывшему его элементу.
- Фокус не застревает в компоненте; у модального окна есть доступный способ закрытия.
- Важная информация, показанная при наведении, доступна и другим способом взаимодействия.
Зафиксируйте конкретные шаги, если проблема воспроизводится. Формулировка «клавиатура работает плохо» мало помогает разработчику. Полезнее: «после открытия меню третий Tab переводит фокус под затемнённую подложку, пункт “Услуги” недоступен». Приложите адрес, браузер и состояние интерфейса.
Проверьте подписи и смысл полей
У каждого поля должна быть понятная подпись, программно связанная с элементом. В типовом HTML для этого используют label и соответствующий идентификатор поля. Placeholder исчезает при вводе и не заменяет постоянную видимую подпись. Инструкции о формате полезно разместить рядом до начала заполнения.
Проверьте поле с пустым значением, введённым текстом, автоматическим заполнением и ошибкой. Для группы переключателей должно быть понятно, на какой общий вопрос отвечает выбор. Для кнопки с одной иконкой нужно доступное название. Техническое имя вроде «icon-right» не объясняет пользователю назначение действия.
Полезный ручной тест: попросите человека назвать, что нужно ввести в каждое поле, не объясняя форму голосом. Если приходится подсказывать «сюда рабочий телефон, а это необязательный комментарий», уточните текст интерфейса. Дополнительные вопросы о составе и поведении формы разобраны в материале о форме заявки.
Сделайте ошибки исправимыми
Отправьте незаполненную форму и проверьте реакцию. Человек должен понять, какие данные требуют внимания и что необходимо изменить. Одна красная рамка оставляет смысл ошибки неясным. Сообщение «неверный формат» тоже стоит уточнить, если допустимый формат нельзя восстановить из подписи.
После ошибки сохраните уже корректно заполненные значения. Объясните отдельно ошибку поля и технический сбой отправки: во втором случае человек не должен бесконечно менять правильный телефон. Для динамически появляющихся сообщений проверьте, доступны ли они экранному диктору. Эту часть лучше выполнять с человеком, знакомым с соответствующим инструментом, чтобы не принять непривычное управление за дефект сайта.
Измерьте контраст вместо оценки на глаз
Для обычного текста WCAG 2.2 уровня AA задаёт минимальное соотношение контраста 4,5:1, для крупного текста по определению стандарта действует порог 3:1. Не считайте любой заголовок крупным только из-за его роли. Размер, начертание и исключения нужно сверять с критерием W3C.
Измеряйте реальные цвета текста и фона инструментом проверки контраста. Включите подписи, подсказки, ссылки, текст на кнопках, сообщения ошибок и все состояния взаимодействия. Для текста поверх фотографии проверьте разные участки изображения и варианты кадрирования. Полупрозрачный слой может менять итоговый фон.
Не пытайтесь решать проблему только увеличением насыщенности. Важна разница яркости. Ссылку внутри абзаца полезно отличать не одним цветом, а также подчёркиванием или другим устойчивым признаком. Сохраните исправленные сочетания в общих стилях, иначе новые блоки снова принесут прежний дефект.
Подготовьте выборку, а не случайный обход страниц
Если на сайте сотни материалов, начинать с просмотра каждого адреса не обязательно. Сначала составьте карту шаблонов и общих компонентов. В выборку включите обычную и длинную статью, страницу с таблицей, форму, поиск без результатов, меню и диалог. Добавьте хотя бы один материал, созданный редактором после запуска: в нём могут появиться другие заголовки, ссылки и изображения. Такая выборка помогает найти системные проблемы, но её границы нужно честно указать в отчёте.
Для каждого сценария запишите начальное состояние. «Проверена форма» может означать пустую форму, уже заполненную форму или ошибку сервера — это разные проверки. Укажите браузер, операционную систему, используемые вспомогательные средства и дату. Если специалист проверяет экранным диктором, результат относится к конкретной комбинации инструментов; один успешный проход не доказывает одинаковое поведение во всех сочетаниях.
Разберите барьер на примере заявки
Учебная ситуация: возле поля телефона нет постоянной подписи, а после отправки появляется только красная рамка. Зрячий пользователь может догадаться о проблеме, пока помнит исчезнувший placeholder. Человек, который слушает страницу, может услышать лишь неопределённое «поле редактирования». Исправление состоит из нескольких связанных частей, а не добавления одного атрибута.
- Разместить видимую подпись «Телефон для связи» и программно связать её с полем.
- До ввода объяснить ограничения, если они действительно нужны. Не требовать декоративного формата, который можно обработать автоматически.
- При ошибке показать конкретное сообщение, например «Укажите телефон, чтобы мы могли связаться с вами».
- Связать сообщение с полем средствами разметки и обозначить ошибочное состояние.
- Проверить, что пользователь узнаёт о результате отправки и может перейти к исправлению.
- Повторить тест с корректным значением и убедиться, что устаревшее сообщение исчезло.
Рекомендации W3C по формам связывают подписи, инструкции и уведомления в единый процесс. В проекте полезно зафиксировать не только «добавлен label», но и проверяемый результат: назначение поля понятно до ввода и после него, ошибка названа, способ исправления доступен. При этом автоматический тест связи идентификаторов дополняет ручной сценарий, а не заменяет его.
Проверьте структуру страницы на слух и без оформления
Откройте список заголовков средствами экранного диктора или инструментами инспекции. По нему должно быть понятно, какие разделы есть на странице. Заголовок используют для структуры, а не только ради крупного шрифта. Карточка «Подробнее» может выглядеть очевидно рядом с названием услуги, но вне визуального контекста несколько одинаковых ссылок становятся неразличимыми. Проверьте, объясняет ли доступное название каждой ссылки её назначение.
Для изображений задайте простой вопрос: что потеряет человек, если не увидит картинку? Для фотографии конкретного изделия может понадобиться описание значимой детали. Для декоративного разделителя отдельное озвучивание лишь мешает. Если диаграмма содержит выводы, одного текста «график» недостаточно: рядом нужен смысловой эквивалент или данные. Не переносите длинную статью в альтернативное описание; предоставьте информацию в подходящем формате.
Проверьте также порядок содержимого при переходе к узкой версии. Визуально карточки могут переставиться, а последовательность чтения остаться прежней. Проблема возникает, если объяснение оказывается после действия, к которому относится, или кнопка теряет связь со своей карточкой. Здесь полезно совместить аудит с проверкой адаптивности.
Различайте три вида результата автоматической проверки
- Подтверждённая техническая ошибка: инструмент обнаружил конкретный дефект, который можно воспроизвести и исправить.
- Требуется ручная оценка: разметка формально допустима, но смысл подписи, порядок чтения или поведение нужно проверить человеку.
- Проверка ничего не нашла: это результат в пределах возможностей инструмента и текущего состояния страницы, а не сертификат доступности.
Например, сканер может увидеть альтернативный текст изображения, но не установить, объясняет ли он нужную пользователю информацию. Он также может не попасть в закрытое меню или состояние после ошибки отправки. Поэтому важные состояния открывают явно и проверяют отдельно. Если отчёт содержит сотни повторов одного дефекта кнопки, заведите общую задачу на компонент и перечислите затронутые сценарии.
Оформите исправление так, чтобы его можно было принять
Карточка замечания должна содержать адрес, шаги, фактический барьер, ожидаемое поведение, доказательство и границы проверки. Пример: «В диалоге заявки после открытия фокус остаётся на странице под ним. Пользователь с клавиатурой не достигает полей в ожидаемом порядке. Проверить вход в диалог, заполнение, закрытие и возврат к кнопке открытия». Номер критерия WCAG полезен, если связь установлена; случайно выбранный номер не делает замечание точнее.
Приоритет определяйте по последствиям и распространённости. Невозможность отправить запрос требует внимания раньше неидеального текста редкой подписи. После исправления общего компонента повторите проверки в нескольких местах: изменение фокуса в меню может затронуть и диалог, если они используют общий механизм. В отчёте разделите исправленное, непроверенное и отложенное с объяснением причин.
Закрепите результат в правилах команды: дизайнер показывает фокус и ошибки, разработчик проверяет клавиатуру, редактор задаёт осмысленные заголовки и описания изображений. Это превращает аудит в поддерживаемый процесс, не создавая необоснованного обещания полного соответствия стандарту.
Составьте очередь исправлений
- Вначале устраните барьеры, из-за которых нельзя завершить основную задачу.
- Затем исправьте повторяющиеся компоненты: меню, поля, кнопки, уведомления.
- Проверьте уникальные блоки, иллюстрации и документы.
- Повторите исходные сценарии после изменения и сохраните результат проверки.
- Добавьте доступность в требования к новым макетам и публикациям.
Автоматический сканер полезен как дополнительный источник замечаний, но не заменяет прохождение сценария человеком. Итог первого аудита: список воспроизводимых барьеров с приоритетами, ответственными и критерием устранения. В рамках поддержки сайта этот список становится повторяемой проверкой после изменений общих компонентов.
Источники
W3C: управление с клавиатуры; W3C: видимый фокус; W3C: подписи полей; W3C: контраст текста.
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
