Кнопка «Отправить» в форме обратной связи работает мышью, но до неё нельзя добраться клавишей Tab. Для части посетителей это значит, что задать вопрос не получится, хотя на вид форма исправна. Аудит доступности помогает находить такие препятствия: проверять, можно ли воспринимать содержимое сайта, перемещаться по нему и выполнять действия разными способами. В отчёте важно указать, где возникла проблема, кому она мешает и как проверить исправление.
Сначала — границы проверки и основные задачи
Проверить вручную каждую страницу обычно невозможно. Для начала составляют выборку разных типов страниц: главная, каталог, карточка товара, статья, поиск, форма обратной связи, оформление заказа — если оно есть. В семейном блоге о детских самокатах стоит отдельно посмотреть статью с таблицей размеров, страницу с фотографиями моделей и форму вопроса редакции. Ошибка в общем меню затронет весь сайт, а ошибка в таблице может встретиться только в одном материале.
Списка адресов мало: нужны задачи, которые посетитель решает на сайте. Например, найти информацию о тормозе, сравнить характеристики двух самокатов, отправить вопрос или вернуться к предыдущему разделу. Раскрывающиеся меню, вкладки, фильтры и всплывающие окна проверяют в разных состояниях: до открытия, после него и при ошибке. В отчёте записывают дату аудита, проверенные страницы, устройства, браузеры, вспомогательные технологии и ограничения выборки. Тогда будет ясно, где проблема подтверждена, а до каких участков проверка ещё не дошла.
Критерии и сочетание методов
Для системной проверки обычно выбирают применимую редакцию WCAG — международных рекомендаций по доступности веб-контента — и согласованный уровень соответствия, часто AA. Перед началом стоит уточнить требования для конкретной организации и региона. Сослаться на стандарт недостаточно: каждое замечание нужно связать с определённым критерием и тем, как интерфейс ведёт себя на деле.
Автоматические инструменты находят часть технических ошибок — например, поле без доступного имени или изображение без текстового описания. Но сканер не скажет, помогает ли описание понять снимок, ясна ли инструкция и удаётся ли завершить действие без мыши. Поэтому аудит сочетает:
- автоматическое сканирование выбранных страниц и состояний интерфейса;
- ручную проверку с клавиатуры;
- проверку доступных имён, ролей и состояний элементов с помощью вспомогательных технологий;
- оценку текста, структуры и визуального представления;
- повторное тестирование после исправлений.
Результат сканера — повод проверить замечание, а не готовый вердикт. Некоторые предупреждения оказываются неприменимыми. И наоборот: если сканер ничего не нашёл, это ещё не значит, что страницей удобно пользоваться.
Что проверять на каждой странице
Структура и ориентиры
Заголовки помогают находить разделы, поэтому их выстраивают в логичном порядке, а не используют лишь для увеличения шрифта. При проверке смотрят, есть ли основной заголовок страницы, можно ли быстро перейти к нужной теме по подзаголовкам, отделены ли навигация и основное содержимое. Назначение ссылки должно быть понятно и вне соседнего абзаца: «характеристики трёхколёсной модели» говорит больше, чем «узнать больше».
Списки и таблицы оформляют по смыслу, а не пробелами и декоративными символами. В таблице сравнения колёс заголовки строк и столбцов должны быть связаны с данными: при чтении отдельной ячейки человек должен понимать, о какой модели и характеристике идёт речь. Если таблица слишком сложная, возможно, её стоит разделить на несколько простых.
Клавиатура и видимый фокус
Любое действие с интерактивным элементом должно выполняться без мыши: открытие меню, выбор фильтра, переключение слайдов, отправка формы, закрытие диалога. Проверяющий последовательно нажимает Tab и Shift+Tab, а также клавиши, предусмотренные для конкретного элемента. Переходы должны идти в понятном порядке, соответствующем содержимому страницы. Нужен и заметный индикатор фокуса: закреплённое меню или всплывающая панель не должны его перекрывать.
Отдельно ищут «ловушки» клавиатуры. Бывает, человек открывает окно, а перейти к кнопке закрытия или обратно на страницу уже не может. После закрытия окна фокус обычно возвращают к элементу, которым его открыли. По скриншоту такое поведение не оценить — окно нужно проверить в работе.
Текст, цвет и масштаб
Проверяют контраст текста и элементов управления на фоне, включая состояния ошибки, наведения и фокуса. Цвет не должен оставаться единственным сигналом: если поле с ошибкой обведено красным, рядом нужна понятная текстовая подсказка. При увеличении текста и масштаба страницы содержимое не должно исчезать или накладываться друг на друга. Там, где можно обойтись без прокрутки сразу в двух направлениях, её тоже не должно быть.
Инструкции имеют значение не меньше оформления. Фраза «нажмите зелёную кнопку справа» бесполезна, если на узком экране кнопка окажется в другом месте или человек не различает цвет. «Нажмите „Отправить вопрос“» отсылает к надписи и назначению кнопки.
Изображения и другие материалы
Описание информативного изображения должно передавать то, ради чего его разместили. Если фотография помогает сравнить высоту рулей, подписи «два самоката» мало: нужно назвать различие. Декоративную картинку, которая ничего не добавляет к содержанию, не стоит включать в чтение вспомогательными технологиями. А кнопке из одного значка требуется доступное имя: иконка лупы должна восприниматься как поиск, а не как безымянная кнопка.
Для видео проверяют субтитры, передающие речь и значимые звуки. Если важные сведения содержатся только в изображении, понадобится текстовый эквивалент или другое доступное пояснение. Для аудио нужна текстовая версия. Файлы тоже проверяют отдельно: доступная HTML-страница не делает автоматически доступной PDF-инструкцию по сборке самоката, которую с неё скачивают.
Формы и сообщения об ошибках
Форму проверяют как задачу целиком, а не только как набор полей. У каждого поля нужна понятная видимая или программно связанная метка. Подсказку о формате данных размещают так, чтобы её можно было прочитать до отправки. Если обязательное поле осталось пустым, сообщение должно объяснять, что исправить, и быть связано с этим полем. Изменить цвет рамки недостаточно.
Не менее важен результат отправки. Появилось ли сообщение об успехе? Узнает ли о нём человек, использующий программу чтения с экрана? Сохранятся ли введённые данные при ошибке? Если страница обновляется, человек не должен заново искать форму и повторять всю работу. В заказе или записи, где вводят важные сведения, отдельно проверяют, можно ли просмотреть и исправить их до окончательного подтверждения.
Проверка со вспомогательными технологиями
С программой чтения с экрана проходят конкретные задачи, а не просто слушают страницу от начала до конца. Удаётся ли перейти по заголовкам к разделу о защитной экипировке? Понятны ли названия ссылок, если вывести их отдельным списком? Сообщает ли фильтр, открыт он или закрыт? Озвучивается ли ошибка после отправки формы? При обычном просмотре эти проблемы легко пропустить. Для материалов о детских самокатах раздел о защитной экипировке особенно важен: кататься нужно в защите и под присмотром взрослых.
Сочетания браузера и вспомогательной технологии подбирают для выбранной платформы и записывают в отчёте. Одна программа чтения с экрана не отражает опыт всех посетителей. По возможности к проверке привлекают людей с инвалидностью и предлагают им реальные задачи. Их наблюдения дополняют технический аудит, но не заменяют его.
Каким должен быть итоговый отчёт
По хорошему отчёту редактор или разработчик сможет воспроизвести каждую проблему. Запись «сайт недоступен с клавиатуры» не поможет понять, что именно сломано. В замечании указывают страницу и элемент, шаги воспроизведения, фактический и ожидаемый результат, затронутый критерий, влияние на пользователя и рекомендацию по исправлению. Скриншот или короткая запись экрана пригодятся, но текстовое описание всё равно нужно.
Приоритет замечаний определяют по последствиям и охвату. Форма, которую нельзя отправить с клавиатуры, блокирует задачу; малозаметный фокус в общем меню затрагивает множество страниц. При этом остальные находки не исчезают из отчёта: сохраняют полный список и план исправлений. Если причина в компоненте, который используется повсюду, её можно описать один раз и перечислить места, где она проявляется.
После исправлений повторно проходят затронутые сценарии, а не только запускают сканер. Если меняли кнопку раскрытия меню, проверяют её доступное имя, управление с клавиатуры, сообщение об открытом состоянии и возврат фокуса. Затем в карточке замечания записывают результат и дату повторной проверки: так будет видно, что исправление подтвердили на практике.
