Перейти к содержимому
Pandus
ru Сменить язык
Меню

Как проверить сайт на соответствие WCAG: пошагово

Обновлено 14 октября 2026 г. · 7 мин чтения

Проверить сайт на WCAG — значит сверить его с критериями успеха Web Content Accessibility Guidelines, обычно на уровне AA. Ни один инструмент не делает этого целиком. Надёжная проверка сочетает автоматический тест с ручным тестированием: человек работает с клавиатурой, масштабом браузера и экранным диктором. Ниже — порядок, который мы советуем магазинам, сервисам и веб-студиям: он находит больше всего проблем с наименьшими усилиями.

Это общая информация, а не юридическая консультация. Наши собственные проверки — автоматическая проверка, а не полный аудит.

Шаг 0: выберите, что проверять (выборка)

Проверять каждую страницу приходится редко. Методология W3C Website Accessibility Conformance Evaluation Methodology (WCAG-EM) описывает пять шагов: определить охват, изучить сайт, выбрать репрезентативную выборку, оценить её и описать результаты. Выборка сочетает структурированную выборку с несколькими случайно выбранными страницами.

Для интернет-магазина структурированная выборка обычно включает:

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

Запишите версию и уровень WCAG (например, WCAG 2.2 AA), браузеры и ассистивные технологии, которыми вы пользуетесь, и дату. Это понадобится для заявления о доступности.

Шаг 1: автоматический тест

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

Сначала исправьте автоматические находки. Обычно это проблемы шаблона: одно исправление в теме убирает одну и ту же ошибку на сотнях страниц. Затем переходите к ручным шагам: исследования по-разному оценивают, какую долю проблем находит автоматика, но сходятся в том, что не все.

Шаг 2: проверка с клавиатуры

Уберите мышь и пользуйтесь только клавиатурой:

Клавиша Что должно происходить
Tab / Shift+Tab Переход к следующей или предыдущей ссылке, кнопке или полю
Enter Переход по ссылке, нажатие кнопки, отправка формы
Пробел Нажатие кнопки, отметка флажка
Стрелки Перемещение внутри меню, групп переключателей, ползунков и вкладок
Esc Закрытие диалога, меню или всплывающего окна

Проверьте, что:

  1. Всё работает с клавиатуры — меню, фильтры, параметры товара, добавление в корзину, оформление заказа, cookie-баннер (2.1.1).
  2. Фокус нигде не застревает — во всплывающем окне, чат-виджете или встроенном плеере (2.1.2).
  3. Фокус всегда виден (2.4.7) и не скрыт за липкими шапками или баннерами (2.4.11).
  4. Порядок логичен и совпадает с визуальным (2.4.3).
  5. Ссылка «перейти к содержимому» или ориентиры позволяют пропустить меню (2.4.1).
  6. Диалоги при открытии переносят фокус внутрь, а при закрытии возвращают его обратно.

Шаг 3: масштаб, перекомпоновка и интервалы в тексте

  1. Увеличьте браузер до 200 %: текст не обрезается, ничего не наезжает, всё по-прежнему работает (1.4.4).
  2. Увеличьте до 400 % или сузьте окно до 320 CSS-пикселей: текст переносится, горизонтальная прокрутка для чтения не нужна (1.4.10).
  3. Примените увеличенные интервалы в тексте: ничего не обрезается (1.4.12).
  4. Поверните телефон: страница работает и в портретной, и в альбомной ориентации.

Подробнее о размерах — в статье размер шрифта по WCAG.

Шаг 4: проверка экранным диктором

Экранный диктор показывает, понятна ли страница без зрения. Используйте хотя бы одно настольное и одно мобильное сочетание:

  • NVDA (бесплатный, Windows) с Firefox или Chrome;
  • VoiceOver (встроен в macOS и iOS) с Safari;
  • TalkBack (встроен в Android) с Chrome.

Прислушайтесь:

  • есть ли осмысленный заголовок страницы и структура заголовков, по которой можно перемещаться (1.3.1);
  • говорят ли описания изображений о главном (1.1.1);
  • говорят ли кнопки и ссылки, что они делают, — «Добавить в корзину», а не «Кнопка» (4.1.2);
  • объявляются ли сообщения о состоянии, например «Добавлено в корзину» или «3 результата», без переноса фокуса;
  • читаются ли подписи полей, обязательные поля и ошибки вместе с полем.

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

Шаг 5: формы и оформление заказа

Пройдите каждую форму и намеренно ошибитесь:

  • у каждого поля есть видимая подпись, а не только плейсхолдер;
  • ошибки описаны текстом рядом с полем, с подсказкой, как их исправить (3.3.1);
  • уже введённые данные не запрашиваются повторно (3.3.7);
  • вход допускает менеджеры паролей и вставку, а у головоломок есть альтернатива (3.3.8);
  • атрибуты autocomplete для имени, e-mail, адреса и телефона заданы;
  • ограничения по времени можно продлить, а заказ можно проверить перед отправкой.

Шаг 6: медиа, цвет и движение

  • У видео есть субтитры (1.2.2); у контента только со звуком есть расшифровка.
  • Ничто не воспроизводит звук автоматически дольше трёх секунд без возможности остановить.
  • Карусели и анимации можно поставить на паузу.
  • Цвет — не единственный сигнал для ошибок, наличия товара или ссылок в тексте.
  • Текст и элементы управления достаточно контрастны; спорные случаи проверьте проверкой контраста.

Шаг 7: запишите и проверьте снова

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

Когда заказывать аудит доступности

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

Частые вопросы

Что такое тестирование WCAG?

Проверка сайта по критериям успеха Web Content Accessibility Guidelines. Она сочетает автоматические тесты, которые быстро находят проблемы в коде, с ручными проверками, которые человек проводит с клавиатурой, масштабом и экранным диктором.

Можно ли полностью автоматизировать проверку WCAG?

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

Как проверить доступность с клавиатуры?

Уберите мышь. Перемещайтесь клавишами Tab и Shift+Tab, открывайте ссылки клавишей Enter, нажимайте кнопки клавишей Enter или пробелом, в меню используйте стрелки, а диалоги закрывайте клавишей Esc. Фокус должен быть всегда виден, идти в логичном порядке и нигде не застревать.

С каким экранным диктором проверять?

NVDA с Firefox или Chrome в Windows, VoiceOver с Safari в macOS и iOS и TalkBack с Chrome в Android. Проверка одним настольным и одним мобильным диктором находит большинство проблем.

Сколько страниц нужно проверить?

Репрезентативную выборку, как описывает методология W3C WCAG-EM: главную страницу, по одной странице каждого шаблона, все шаги ключевых процессов, например оформления заказа и входа, и несколько случайных страниц.

Когда нужен профессиональный аудит доступности?

Когда вам нужно заявление о соответствии, перед публичным запуском или тендером, после жалобы или претензии или когда собственные проверки оставляют открытые вопросы. Аудит охватывает все критерии вручную, автоматическая проверка — нет.

Источники