Доступность сайта по WCAG 2.2: что проверить за 15 минут

Ошибки доступности остаются массовыми даже в 2026 году

В исследовании WebAIM Million за 2026 год автоматически проверили один миллион главных страниц популярных сайтов. Ошибки, с высокой вероятностью нарушающие требования WCAG уровней A и AA, обнаружили на 95,9% страниц. Всего система выявила более 56 миллионов ошибок – в среднем 56,1 на страницу.

Это не означает, что 95,9% сайтов полностью «не соответствуют WCAG». Автоматическая проверка видит только часть проблем и не заменяет ручное тестирование. Но масштаб хорошо показывает, насколько тема далека от теории.

Что показала выборка сайтов .ua

Отдельно в исследование попали 5316 главных страниц в доменной зоне .ua. На них автоматическая проверка обнаружила в среднем 103,1 ошибки на страницу при среднем значении всей миллионной выборки 56,1.

Разница – 83,7%. Но трактовать её как «украинские сайты почти вдвое хуже остальных» было бы неправильно: сравнивались только попавшие в исследование главные страницы, а автоматический анализ фиксирует лишь часть проблем доступности.

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

Доступность и юзабилити – не одно и то же

Граница между ними действительно тонкая. Если покупателю неудобно искать товар из-за запутанного каталога – это прежде всего вопрос юзабилити. Если кнопка слишком далеко от описания товара и её плохо замечают – тоже.

Но если до этой кнопки вообще нельзя добраться с клавиатуры, её назначение не определяет программа экранного доступа или состояние кнопки обозначается только цветом – это уже проблема доступности.

Один интерфейс – разные результаты

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

Можно ли управлять сайтом без мыши

Откройте главную страницу и больше не трогайте мышь. Используйте Tab для перехода вперёд, Shift + Tab – назад, Enter и Space – для действий, Esc – для закрытия меню и диалоговых окон.

Попробуйте пройти обычный путь клиента: меню → услуга или товар → форма → кнопка → отправка. Если в какой-то момент дальнейшее действие возможно только мышью, вы уже нашли серьёзный барьер.

Всегда ли видно, где находится фокус

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

В WCAG 2.2 есть ещё один важный нюанс: элемент с фокусом не должен полностью исчезать за закреплённой шапкой, сообщением о файлах cookie, плавающим блоком или другим перекрывающим интерфейсом.

Можно ли открыть и закрыть всплывающее окно

Проверьте, попадает ли фокус внутрь окна после открытия, можно ли пройти все элементы клавишей Tab, не уходит ли фокус под окно, работает ли Shift + Tab и можно ли закрыть окно клавишей Escape. После закрытия пользователь должен понимать, куда вернулся.

Есть ли действия, которые требуют только перетаскивания

Слайдер цены, загрузка файла, сортировка карточек, конструктор или изменение порядка элементов могут стать барьером, если единственный способ выполнить действие – захватить объект указателем и перетащить его.

Если перетаскивание не является сутью функции, полезно дать альтернативу. Например, диапазон цены может иметь не только ползунок, но и обычные поля «от» и «до».

Не слишком ли малы области нажатия

Крестик закрытия окна, стрелка карусели, значок поиска, удаление товара из корзины, небольшой переключатель – всё это требует точности. WCAG 2.2 для уровня AA предусматривает минимальную область нажатия 24×24 CSS-пикселя либо достаточное расстояние между меньшими целями, с предусмотренными стандартом исключениями.

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

Можно ли понять форму и результат действия

Форма может быть визуально очевидной и одновременно непонятной для программы экранного доступа. Текст внутри поля не всегда заменяет полноценную подпись. Корректно связанный с полем элемент label помогает определить назначение поля программно и делает интерфейс понятнее.

Одна и та же форма может быть двумя разными интерфейсами

Если назначение полей существует только визуально, часть смысла интерфейса теряется.

Специально заполните форму неправильно

Оставьте обязательное поле пустым, введите буквы вместо телефона или неправильный адрес электронной почты. Плохой вариант – поле просто становится красным. Цвет не должен быть единственным способом передачи важной информации.

Человеку нужно понять, где именно возникла ошибка и как её исправить. Для обязательных полей и ошибок важна не только визуальная индикация, но и программно определяемое состояние.

Проверьте успешную отправку

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

Если задача касается уже не доступности, а текста, расположения и логики самого призыва к действию, это отдельный вопрос – как оформить CTA-кнопку и следующий шаг пользователя.

Можно ли воспринять содержимое страницы

Не передаётся ли смысл только цветом

Представьте, что красный и зелёный выглядят одинаково. Останется ли интерфейс понятным? Типичные проблемы – ошибка только красной рамкой, статус наличия только цветом, выбранный тариф отличается лишь оттенком, а линии графика невозможно различить без цвета.

Цвет полезен, но важный смысл не должен зависеть только от способности пользователя различать его.

Достаточен ли контраст

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

Что происходит с изображениями без зрения

Совет «добавьте alt ко всем изображениям» слишком примитивен. У изображений разные функции. Фотография товара передаёт информацию – ей нужен осмысленный текстовый эквивалент. Иконка внутри кнопки выполняет функцию – пользователь должен понимать назначение кнопки. Декоративная волна на фоне ничего не сообщает – заставлять программу экранного доступа проговаривать её нет смысла.

Плохой alt вроде image123.webp или «картинка» формально существует, но практически ничего не объясняет.

Увеличьте страницу до 400%

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

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

Структура заголовков – это ещё и навигация

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

Поэтому H1–H3 – не только поисковая разметка и визуальная структура текста. Для части посетителей заголовки фактически становятся способом перемещения по документу.

Быстрая проверка доступности сайта

Если времени мало, пройдите хотя бы основной сценарий. Это не полноценный аудит WCAG, но такой проход способен обнаружить барьеры, которые месяцами остаются незаметными владельцу сайта.

Что проверять и исправлять в первую очередь

Если сайт большой, бессмысленно начинать с последовательного просмотра тысяч URL. Сначала проверьте основные пользовательские сценарии.

Для интернет-магазина маршрут можно расширить: каталог → фильтр → карточка → выбор варианта → корзина → оформление → оплата. Для сайта услуг: главная → услуга → кнопка действия → форма → ошибка → успешная отправка.

Если ключевой сценарий нельзя пройти клавиатурой или часть его непонятна программе экранного доступа, проблема важнее декоративного недочёта на малопосещаемой странице.

«Сайт работает» – слишком слабый критерий

Обычная техническая проверка отвечает на вопрос «сломано или работает». Проверка доступности задаёт второй вопрос: для кого именно это работает?

Автоматическая проверка – только начало

Можно запустить WAVE, Lighthouse, axe или другой инструмент и получить список замечаний. Это полезно, но автоматическая проверка не способна подтвердить полное соответствие WCAG или реальную доступность пользовательского сценария.

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

Если нужен более широкий контроль сайта перед публикацией или после изменений, используйте также общий чек-лист проверки сайта.

Доступность – это не отдельная версия сайта

Веб-доступность начинается не с специальной кнопки и не с отчёта автоматической проверки. Она начинается с устройства самого интерфейса.

В опросе пользователей программ экранного доступа WebAIM 2026 большинство участников считали, что больший эффект даст повышение доступности самих сайтов, а не только развитие вспомогательных технологий.

Хорошая первая проверка проста: сможет ли другой человек получить ту же информацию и выполнить то же действие, если он взаимодействует с сайтом не так, как вы?

Если проблема касается общего удобства, а не именно доступности, продолжите с материалом как самостоятельно проверить юзабилити сайта. Для интернет-магазинов причины незавершённой покупки отдельно разобраны в статье почему покупатели бросают корзину.

Частые вопросы о доступности сайта