Доступность сайтов в 2026: European Accessibility Act, WCAG 2.2 и практический чек-лист для WordPress и Битрикс

Сценарий, с которого всё началось

Недавно мне позвонил клиент — владелец интернет-магазина с оборотом, который торгует по всей Европе. Голос слегка панический: «Евгений, нам пришло письмо от партнёра из Германии. Они говорят, что с 2025 года у них действует закон про доступность, и если наш сайт не пройдёт требования, они просто перестанут с нами работать». Клиент никогда не слышал про WCAG, а про European Accessibility Act — тем более.

Я открыл его сайт, пробежался клавишей Tab. Фокус был невидим уже на третьем элементе. Кнопки без подписей, контраст серого на сером, формы без <label>, слайдер, который невозможно остановить. Классика — и одновременно приговор, если вы продаёте в Европу.

В этой статье разберу, что реально требует закон, что нового в WCAG 2.2 и, главное, — практический чек-лист, который я использую на проектах на WordPress и Битрикс. Без воды и без страшилок «доступность — это сложно».

European Accessibility Act: почему «когда-нибудь потом» закончилось

European Accessibility Act (EAA) — это директива ЕС, которая устанавливает единые требования к доступности товаров и услуг. Ключевой факт, который до сих пор упускает половина владельцев бизнеса: требования уже вступили в силу 28 июня 2025 года, а в 2026-м пошло реальное правоприменение. То есть это не «нужно подготовиться к 2027», это «уже действует».

Кого это касается? Если коротко — любого бизнеса, который продаёт товары или услуги потребителям в ЕС, независимо от того, где зарегистрирована компания. В списке прямо упомянуты:

интернет-магазины и электронная коммерция;
банковские и финансовые сервисы;
транспорт, билеты, бронирование;
медиа и стриминговые сервисы (электронные книги, аудиовизуальный контент);
телеком-услуги.

Важный нюанс: EAA не вводит собственный «стандарт доступности». Он отсылает к гармонизированному стандарту EN 301 549, который, в свою очередь, опирается на WCAG 2.1 уровня AA. На практике это значит: чтобы закрыть требования закона, нужно привести сайт к WCAG 2.1 AA. А раз вы всё равно это делаете, разумнее целиться сразу в WCAG 2.2 AA — он актуальнее и покрывает больше кейсов.

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

WCAG 2.2: что нового и что реально ловят в аудитах

WCAG 2.2 не отменяет 2.1, а добавляет девять новых критериев. Из них шесть — уровня AA, то есть обязательных для соответствия. Разберу их по-человечески, потому что формулировки в оригинале сухие.

2.4.11 — Фокус не перекрыт (Focus Not Obscured, AA)

Элемент, на котором сейчас фокус, не должен быть спрятан за липкой шапкой, всплывающим баннером или cookie-плашкой. Классический провал: пользователь табает по странице, а активный элемент уезжает под фиксированный хедер. Решение — проверять scroll-padding-top и не давать оверлеям перекрывать контент.

2.5.7 — Действия перетаскиванием (Dragging Movements, AA)

Если на сайте есть drag-and-drop (сортировка корзины, перетаскивание в конструкторе), у пользователя должна быть альтернатива без перетаскивания — кнопки, стрелки, обычный клик. Человек с тремором или тем, кто работает с клавиатуры, физически не может «перетащить» элемент.

2.5.8 — Минимальный размер цели (Target Size, AA)

Интерактивные элементы — кнопки, ссылки, иконки — должны иметь целевую область минимум 24×24 CSS-пикселя. Есть исключения для inline-ссылок в тексте и случаев, когда рядом есть эквивалент достаточного размера. На практике это правило ломают чаще всего: крошечные иконки соцсетей, «крестики» закрытия, стрелочки слайдеров.

3.2.6 — Постоянная помощь (Consistent Help, AA)

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

3.3.7 — Без повторного ввода (Redundant Entry, AA)

Информация, которую пользователь уже ввёл в рамках процесса, не должна запрашиваться повторно в том же процессе. Классика: ввели адрес на этапе оформления, а на этапе оплаты просят тот же адрес ещё раз. Либо дайте автозаполнение, либо не дублируйте.

3.3.8 — Доступная аутентификация (Accessible Authentication, AA)

Вход на сайт не должен требовать решения головоломок или запоминания сложных комбинаций. Если есть капча — нужна альтернатива (например, аудио или кнопка «я не робот» вместо ввода текста с картинки). Когнитивные тесты вроде «введите 3-й символ пароля» — под запретом.

Остальные три критерия — уровня AAA (2.4.12, 2.4.13, 3.3.9), то есть опциональные. Для соответствия AA они не нужны, но знать про них полезно: они задают направление, куда развивается доступность.

Практический чек-лист: 10 пунктов, которые закрывают 80% проблем

За годы аудитов я вывел список из десяти вещей, которые ловятся в 80% проектов. Если закрыть их — сайт уже проходит значительную часть WCAG 2.2 AA. Идите по порядку.

Видимый фокус везде. Откройте сайт и пройдите Tab’ом по всем элементам. Фокус должен быть виден на каждом шаге и не перекрыт. Если где-то исчезает — это блокер №1.
Контраст текста 4.5:1 (для крупного текста — 3:1). Серый текст на белом — самый частый провал. Проверяйте не только основной текст, но и плейсхолдеры, подписи, вторичный текст.
Alt-текст у информативных изображений и пустой alt="" у декоративных. Картинка-ссылка должна описывать, куда ведёт, а не «что нарисовано».
Подписи у полей форм. Каждое поле — с <label> или aria-label. Плейсхолдер — не замена подписи: он исчезает при вводе.
Понятные ошибки. Ошибка валидации должна быть видна, связана с конкретным полем и объяснять, что исправить. «Произошла ошибка» — не объяснение.
Логичная структура заголовков. Один <h1> на страницу, дальше по иерархии без пропусков. Скринридеры навигацию строят именно по заголовкам.
Размер целей 24×24. Кнопки, иконки, кликабельные элементы — не меньше 24px. Крошечные «крестики» увеличивайте или расширяйте кликабельную зону.
Не только цвет. Ошибки, статусы и ссылки не должны отличаться только цветом. Добавляйте иконки, подчёркивание, текст.
Уважение к motion. Поддержка prefers-reduced-motion для анимаций и слайдеров. Автопроигрывающиеся карусели — с кнопкой паузы.
Skip-link и landmarks. Ссылка «перейти к контенту» в начале и семантические ориентиры (<nav>, <main>, <footer>).

Вот минимальный CSS-кусок, который закрывает сразу три пункта — видимый фокус, контраст и уважение к анимации:

/* Видимый фокус, который не перекрывается */
:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 2px;
}

/* Не даём липкой шапке перекрывать элемент при переходе */
html {
    scroll-padding-top: 90px;
}

/* Уважение к prefers-reduced-motion */
@media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        transition-duration: 0.01ms !important;
        scroll-behavior: auto !important;
    }
}

/* Минимальная целевая область для мелких иконок */
.icon-button {
    min-width: 24px;
    min-height: 24px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

А это — правильная разметка поля формы с подписью и читаемой ошибкой:

<div class="form-field">
    <label for="phone">Телефон</label>
    <input
        type="tel"
        id="phone"
        name="phone"
        aria-describedby="phone-hint phone-error"
    />
    <p id="phone-hint" class="hint">Укажите номер в международном формате</p>
    <p id="phone-error" class="error" role="alert" hidden>
        Номер должен содержать не меньше 10 цифр
    </p>
</div>

Обратите внимание на aria-describedby: скринридер прочитает подсказку и ошибку в связке с полем, а role="alert" сообщит об ошибке сразу, как только она появится. Это и есть та «мелочь», которая отличает прошедший аудит сайт от проваленного.

Чек-лист доступности: контраст, клавиатурная навигация, alt-тексты и формы

Доступность в WordPress: не только плагины

WordPress давно позиционирует себя как доступная платформа, и ядро действительно неплохо: административная панель проходит значительную часть требований, а тема Twenty Twenty-Four из коробки достаточно чистая. Но проблемы начинаются там, где подключаются кастомные темы и куча плагинов.

Что я проверяю на каждом WordPress-проекте:

Тема. Прежде чем покупать «красивую» тему с Themeforest, проверьте её на доступность. Тема без accessibility-ready тега — почти гарантия проблем с фокусом и клавиатурой. Лучше брать тему, которая прошла ревью в официальном каталоге.
Формы. Contact Form 7, WPForms, Gravity Forms — все умеют делать доступные формы, но не «из коробки». Подписи, обязательные поля с текстовым обозначением (не только звёздочкой), понятные ошибки — это настраивается руками.
Слайдеры и попапы. Большинство плагинов-слайдеров проваливают 2.5.7 и работу с клавиатуры. Если слайдер не критичен — замените на статичную сетку. Если критичен — берите плагин с ARIA-поддержкой и проверяйте фокус.
alt-тексты. WordPress просит их при загрузке медиа, но никто не заполняет. Заведите привычку: информативные картинки — с описанием, декоративные — с пустым alt.

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

<?php
// Добавляем skip-link для тем, где его нет
add_action('wp_body_open', function () {
    echo '<a class="skip-link screen-reader-text" href="#main">' .
         'Перейти к содержимому</a>';
});

// Гарантируем роль main для основного контента
add_filter('the_content', function ($content) {
    return '<main id="main">' . $content . '</main>';
});

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

Доступность в Битрикс: свои грабли

С Битриксом (и 1С-Битрикс, и Битрикс24) ситуация сложнее. Исторически платформа меньше внимания уделяла a11y, и «коробочные» шаблоны часто проваливают даже базовые проверки. Но это не приговор — просто работы больше.

На что обращать внимание:

Композитный сайт и готовые шаблоны. Шаблоны из маркетплейса — самое слабое звено. Проверяйте их так же строго, как сторонние WordPress-темы, и закладывайте время на доработку разметки.
Формы обратной связи. Компоненты форм в Битрикс генерируют разметку, которую почти всегда нужно допиливать: подписи, aria-*, сообщения об ошибках.
Таблицы и каталоги. Если у клиента каталог товаров или прайс-таблицы — проверяйте семантику <table> (заголовки <th>, scope) и сортировку с клавиатуры.
Личный кабинет. Если есть ЛК на Битрикс24 или 1С-Битрикс — это отдельный пласт: аутентификация (3.3.8), повторный ввод данных (3.3.7), навигация по заказам.

Главный принцип тот же: доступность не «прикручивается» сверху, а вносится в шаблон компонента. Когда дорабатываете компонент каталога или форму — сразу добавляйте семантику и ARIA, а не откладывайте «на потом». Потом переделывать дороже.

Как проверить сайт самому: инструменты

Вот мой стандартный набор, от быстрого к глубокому:

Lighthouse (в Chrome DevTools) — даёт общий балл доступности и список конкретных проблем. Хорош для старта, но не заменяет ручную проверку.
axe DevTools — расширение для браузера, точнее Lighthouse и показывает элементы, которые нарушают конкретные критерии WCAG.
WAVE — визуализирует структуру, alt-тексты, контраст прямо на странице.
Ручной тест клавиатурой — Tab по всей странице, проверка фокуса, работы меню и попапов без мыши. Автоматика этого не увидит.
Скринридер — NVDA (Windows) или VoiceOver (macOS). Пройдите ключевой сценарий: найдите товар, заполните форму, оформите заказ. Это самая показательная проверка.
Проверка контраста — любым онлайн-чекером или в DevTools.

Правило, которое я повторяю клиентам: автоматические инструменты находят 30–40% проблем. Остальное — только руками и скринридером. Нельзя «прогнать сайт через плагин» и считать, что он доступен.

Что чаще всего проваливают: моя статистика по аудитам

Если посмотреть на проекты, которые я аудировал за последний год, картина стабильная. Вот топ-5 провалов:

Невидимый или отсутствующий фокус — почти в каждом втором проекте. Часто разработчики вообще убирают outline «для красоты», не добавляя альтернативу.
Контраст ниже 4.5:1 — особенно вторичный текст, подписи, футеры.
Формы без подписей и понятных ошибок — ломают и доступность, и конверсию. Что характерно, это совпадает с ошибками из моей прошлой статьи про формы.
Крошечные кликабельные элементы — иконки, пагинация, слайдеры.
Слайдеры и попапы без управления с клавиатуры — пользователь открывает попап и не может из него выйти.

Показательный момент: почти все эти проблемы — не «сложная доступность», а базовый уровень качества интерфейса. Когда я показываю клиенту, что его слайдер нельзя остановить с клавиатуры, а кнопка «купить» меньше 24 пикселей, — вопрос «зачем нам это» обычно снимается сам собой.

Что в итоге

Доступность в 2026 году перестала быть нишевой темой для госсектора. European Accessibility Act сделал её условием работы с европейским рынком, а WCAG 2.2 дал конкретные, измеримые критерии. Для разработчика это не «ещё один пункт в ТЗ», а стандарт качества, который совпадает с хорошим UX: видимый фокус, нормальный контраст, крупные кнопки и понятные формы нужны всем пользователям, а не только людям с ограничениями.

Начните с чек-листа из десяти пунктов выше, прогоните сайт через axe и пройдите ключевой сценарий с клавиатуры. Этого достаточно, чтобы закрыть большую часть требований WCAG 2.2 AA — и спать спокойно, когда клиент из ЕС спросит про EAA.

А вы уже приводили сайты к WCAG 2.2? Какие критерии оказались самыми неожиданными на практике? Делитесь в комментариях — соберу народный топ граблей для следующего разбора.