Аудит доступности WordPress нужен, когда сайт должен оставаться понятным и управляемым не только мышью, но и клавиатурой, экранным диктором, увеличением интерфейса и другими вспомогательными технологиями. Проверка по WCAG 2.2 помогает разложить эту задачу на конкретные технические критерии: структура страницы, контраст, фокус, формы, подписи, альтернативный текст и поведение интерактивных элементов.
При этом WCAG-аудит нельзя свести к одному автоматическому сканеру. W3C прямо рассматривает критерии как тестируемые требования, а документация WordPress отдельно указывает, что автоматические инструменты должны дополняться ручной проверкой и usability testing.
Что такое WCAG 2.2
WCAG 2.2 — рекомендация W3C для доступности веб-контента. Требования организованы вокруг четырёх принципов: контент должен быть воспринимаемым, управляемым, понятным и устойчивым к разным пользовательским агентам и вспомогательным технологиям.
У критериев есть уровни A, AA и AAA. В стандартах разработки WordPress для нового и обновляемого кода ориентиром является WCAG 2.2 уровня AA. Это полезная техническая точка отсчёта и для коммерческого WordPress-сайта, хотя формальные требования конкретной организации зависят от её юрисдикции и отрасли.
Что проверяется на WordPress-сайте
- логичная структура заголовков и landmarks;
- управление меню, формами, модальными окнами и кнопками с клавиатуры;
- видимый и предсказуемый focus state;
- достаточный цветовой контраст текста и элементов управления;
- корректные label, инструкции и сообщения об ошибках в формах;
- alt-тексты для содержательных изображений и пустой alt для декоративных;
- семантика кнопок, ссылок, списков, таблиц и полей;
- увеличение текста и адаптивность без потери содержимого;
- поведение всплывающих окон, слайдеров и динамических блоков;
- использование ARIA только там, где нативного HTML недостаточно.
Почему плагин не делает сайт доступным автоматически
Плагин может добавить отдельные вспомогательные функции, но он не способен исправить семантику всей темы, неправильный порядок DOM, непонятные подписи полей или JS-компонент, который вообще не принимает клавиатурный фокус.
Проблема часто находится в нескольких слоях одновременно: шаблон темы, Elementor-виджет, сторонняя форма, кастомный JavaScript, WooCommerce-компонент и контент редактора. Поэтому надёжнее сначала провести аудит, определить источник каждого барьера и только затем менять код.
Автоматическая и ручная проверка — зачем нужны обе
Автоматические инструменты хорошо находят формальные ошибки: отсутствующие alt, некоторые проблемы контраста, дублирующиеся ID, часть ошибок ARIA и структуры. Это быстрый первый слой проверки.
Но сканер не может полностью оценить, удобно ли пройти меню клавиатурой, логичен ли порядок фокуса, понятно ли сообщение об ошибке формы и возвращается ли фокус в нужное место после закрытия modal. Такие сценарии нужно проходить вручную.
Клавиатурная навигация
Один из простых, но показательных тестов — пройти ключевую страницу клавишами Tab, Shift+Tab, Enter, Space и Escape без мыши. Пользователь должен видеть текущий фокус и понимать, какой элемент будет активирован.
Частые проблемы WordPress-проектов — выпадающее меню открывается только hover-событием, кастомная кнопка сделана через div, popup блокирует Tab внутри себя неправильно или после закрытия переносит фокус в начало документа.
Фокус и новые критерии WCAG 2.2
WCAG 2.2 добавила, среди прочего, критерии, связанные с тем, чтобы фокус не был скрыт другими элементами, минимальным размером цели и доступностью аутентификации. Для сайтов с фиксированными шапками, sticky-панелями и popup-интерфейсами это особенно важно.
Например, клавиатурный фокус может технически существовать, но оказаться полностью закрытым sticky header. Для пользователя результат тот же — текущий элемент невозможно увидеть.
Контраст и визуальные состояния
Недостаточный контраст встречается не только в обычном тексте. Нужно проверять placeholder, подписи, вторичные кнопки, границы полей, focus state, сообщения об ошибках и текст поверх изображений.
Важно также не передавать смысл только цветом. Если ошибка поля обозначена исключительно красной рамкой без текста или иконки с понятной подписью, часть пользователей может не понять, что произошло.
Формы WordPress и лидогенерация
Для коммерческого сайта формы — одна из самых важных зон аудита. Contact Form 7, Elementor Forms, Gravity Forms и кастомные формы могут выглядеть нормально визуально, но оставаться неудобными для screen reader или клавиатуры.
- Каждому полю нужна понятная программная подпись.
- Обязательность поля не должна передаваться только цветом.
- Ошибка должна быть связана с конкретным полем.
- После отправки пользователь должен получить понятный результат.
- Captcha и антиспам не должны делать форму непроходимой без альтернативного сценария.
Изображения и alt-тексты
Не каждому изображению нужен описательный alt. Если картинка несёт смысл — альтернативный текст должен передавать этот смысл. Если элемент чисто декоративный, лучше использовать пустой alt="", чтобы экранный диктор не зачитывал бессмысленное имя файла.
Для интернет-магазина особенно важно различать продуктовые фотографии, декоративные баннеры и изображения, которые одновременно являются ссылками.
Семантика HTML важнее лишнего ARIA
ARIA полезна для сложных компонентов, но не должна заменять нормальный HTML. Настоящая кнопка <button> уже имеет ожидаемую клавиатурную семантику. Если сделать кликабельный div и затем вручную имитировать кнопку через role и события, появляется больше мест для ошибки.
На практике часть accessibility-багов устраняется не добавлением атрибутов, а упрощением разметки.
Elementor и кастомные виджеты
Elementor ускоряет сборку интерфейса, но итоговая доступность зависит от конкретных виджетов и настроек. Стоит проверять порядок заголовков, карусели, tabs, accordions, popup, mobile menu и кастомный CSS, который может убрать outline.
Если проблема находится в собственном Elementor-виджете или shortcode, её лучше исправлять в исходном компоненте, а не добавлять JS-патч на каждой странице.
WooCommerce: что проверить отдельно
В магазине путь пользователя длиннее обычной формы: каталог, фильтры, карточка, выбор вариации, корзина, checkout и сообщения об ошибках. Поэтому accessibility-аудит WooCommerce должен проходить полный сценарий покупки.
Особое внимание нужно уделить обновлениям корзины через AJAX, выбору способов доставки и оплаты, focus после ошибок checkout и понятным названиям кнопок.
Как проходит технический аудит
- Определяются ключевые шаблоны и пользовательские сценарии.
- Запускается автоматическая проверка для быстрого поиска типовых нарушений.
- Проводится ручной keyboard-only проход.
- Проверяются семантика HTML и дерево доступности проблемных компонентов.
- Отдельно тестируются формы, меню, popup и динамические блоки.
- Ошибки группируются по компонентам и приоритету, чтобы не править один и тот же дефект на десятках страниц.
- После исправлений выполняется повторная проверка критичных сценариев.
Что можно исправить без полного редизайна
Многие accessibility-проблемы не требуют менять визуальную концепцию сайта. Часто достаточно поправить HTML, состояния фокуса, подписи, контраст отдельных элементов, порядок заголовков и JavaScript-логику.
Полный редизайн нужен только тогда, когда сама структура интерфейса создаёт системные барьеры. Поэтому аудит полезно проводить до принятия решения о дорогой переработке.
Что входит в работу A.S Groups
Для существующего WordPress-сайта можно заказать технический аудит ключевых страниц и компонентов, получить список проблем и затем исправлять их по приоритету. Работа может включать тему, Elementor, формы, кастомные виджеты, WooCommerce и JavaScript.
Это сочетается с услугой доработки WordPress. Если сайт ещё проектируется, доступность лучше учитывать сразу в разработке WordPress, чтобы не переделывать базовые компоненты после запуска.
Для оценки можно прислать URL, перечислить ключевые страницы и указать, какие сценарии важнее всего. Связаться можно через контакты A.S Groups.
Что аудит не обещает
Техническая проверка не должна продаваться как магическая «сертификация одной кнопкой». Автоматический отчёт сам по себе не доказывает полное соответствие WCAG, а юридические требования зависят от страны, отрасли и конкретной организации.
Корректная цель работы — найти воспроизводимые барьеры, исправить их в коде и повторно проверить пользовательские сценарии.
Частые вопросы
Можно ли проверить WCAG только Lighthouse?
Нет. Автоматический тест полезен, но он покрывает только часть критериев. Клавиатурные сценарии, логика фокуса и понятность взаимодействия требуют ручной проверки.
Нужно ли менять тему WordPress?
Не всегда. Если проблемы локализованы в шаблонах или компонентах, их часто можно исправить без полной смены темы.
Можно ли сделать доступнее Elementor-сайт?
Да. Нужно проверить конкретные виджеты, структуру заголовков, меню, popup, формы и пользовательские стили. Часть ошибок исправляется настройками, часть — кодом.
Что важнее проверить сначала?
Для бизнес-сайта — основную навигацию, формы заявки и ключевые CTA; для WooCommerce — полный путь от каталога до checkout.
Гарантирует ли аудит юридическое соответствие?
Нет. Технический аудит оценивает сайт относительно выбранных критериев доступности. Юридическую применимость требований нужно рассматривать отдельно для конкретной юрисдикции.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.