Аудит доступности сайта: порядок проверки и приоритет нарушений

Прямой ответ

Аудит доступности выполняется по набору типовых страниц и сочетает автоматическую и ручную проверку, поэтому результат охватывает критерии, не определяемые инструментом.

1. Типовые страницы → 2. Уровень AA → 3. Инструмент
4. Клавиатура → 5. Читалка → 6. Отчёт с приоритетом

Этапы выполняются последовательно, поэтому нарушение фиксируется с указанием страницы, критерия и приоритета устранения. О требованиях — в статье про WCAG для разработчика.

Выбор страниц и область аудита

Область аудита определяется набором типовых страниц, поэтому проверка единственной страницы не охватывает типы содержимого сайта.

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

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

Страницы с формами и таблицами. Отдельные типы содержимого проверяются явно, поэтому критерии для форм не пропускаются.

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

Отдельный аспект — состояние элементов. Состояния при наведении, фокусе и после действия проверяются отдельно, поэтому нарушение в состоянии обнаруживается только при проверке состояния.

Автоматическая и ручная проверка

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

Автоматическая проверка. Инструмент находит нарушения по разметке, поэтому часть критериев проверяется быстро по всем страницам.

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

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

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

Приоритет нарушений и план устранения

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

Блокирующее нарушение. Действие не выполняется, поэтому нарушение устраняется в первую очередь.

Затрудняющее нарушение. Действие выполняется с трудом, поэтому нарушение устраняется после блокирующих.

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

Практическое следствие: устранение нарушений без приоритета оставляет блокирующие нарушения на поздний срок, поэтому часть действий остаётся недоступной.

Об основах — в статье про доступность веб-интерфейсов; о проверке читалкой — в статье про экранные читалки.

Регулярность аудита и повторная проверка

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

Периодичность проверки. Аудит выполняется по расписанию, поэтому нарушение обнаруживается до накопления на всех страницах.

Проверка после изменений. Новая страница либо компонент проверяется до выпуска, поэтому нарушение не попадает в выпуск.

Повторная проверка устранённого. Устранённое нарушение проверяется повторно, поэтому устранение подтверждается фактом.

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

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

Практика: проведение аудита доступности

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

2. Выбирайте набор типовых страниц. Каждый тип содержимого проверяется явно, поэтому охват соответствует сайту.

3. Проверяйте повторяющиеся области отдельно. Нарушение в шапке либо навигации затрагивает все страницы.

4. Выполняйте автоматическую проверку по всем страницам. Нарушения по разметке находятся быстро и по всему объёму.

5. Проверяйте навигацию с клавиатуры. Достижимость элементов и порядок фокуса подтверждаются переходом.

6. Проверяйте объявления читалкой. Название и состояние элемента подтверждаются слушанием.

7. Ранжируйте нарушения по влиянию и фиксируйте план устранения. Блокирующие нарушения устраняются в первую очередь.

Рекомендации:

1. Не ограничивайтесь автоматическим анализом. Критерии по объявлению и смыслу подтверждаются только ручной проверкой.
2. Учитывайте состояния элементов при проверке. Нарушение в состоянии при фокусе не обнаруживается при проверке основного состояния.
3. Сопоставляйте охват аудита с разнообразием страниц. Проверка единственной страницы не отражает состояние сайта.
4. Фиксируйте нарушение с указанием страницы и критерия. Устранение выполняется по конкретному требованию.
5. Пересматриваем аудит при добавлении нового типа страницы. Новый тип требует включения в набор проверяемых страниц.

Практический сценарий: аудит показал отсутствие нарушений, но действие было недоступно

Контекст: автоматический анализ по всем страницам не показал замечаний, при этом пользователь не мог завершить оформление заказа.

1. Диагностика. Проверка с клавиатуры показала, что часть элементов формы не достигалась клавишей перехода, а объявление ошибки отсутствовало. Автоматический анализ не проверял достижимость элементов и объявление состояния.
2. Причина. Аудит ограничивался автоматическим анализом, поэтому критерии, требующие ручной проверки, не оценивались.
3. Действия. (а) Добавили в аудит проверку навигации с клавиатуры по всем интерактивным элементам типовых страниц; (б) добавили проверку объявлений читалкой для полей форм и сообщений об ошибках; (в) включили в область аудита состояния элементов при фокусе и после действия; (г) ранжировали найденные нарушения по влиянию на выполнение действия и составили план устранения; (д) зафиксировали целевой уровень и список применимых критериев, чтобы результат аудита был сопоставим.
4. Результат. Аудит выявляет блокирующие нарушения, поэтому оформление заказа выполняется без указателя.

Вывод: автоматический анализ не проверяет достижимость элементов и объявление состояния, поэтому результат без замечаний не подтверждает доступность действия. Ручная проверка с клавиатуры и читалкой в составе аудита обнаруживает нарушения, блокирующие выполнение действия.

FAQ

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

Почему автоматического анализа недостаточно? Инструмент находит нарушения по разметке, но не проверяет достижимость элементов и объявление состояния.

Как определить приоритет нарушения? По влиянию на выполнение действия. Блокирующие нарушения устраняются в первую очередь, повторяющиеся дают широкий эффект.

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

Источники: W3C WAI Evaluation, WCAG 2.2 Quick Reference, W3C WAI Conformance — ссылки в шапке.