Обновление WCAG 2.2: что нового для разработчиков и владельцев сайтов?

Обновление WCAG 2.2: что нового для разработчиков и владельцев сайтов?

В конце 2023 года консорциум W3C опубликовал финальную версию стандарта WCAG 2.2. Новый релиз принёс девять дополнительных критериев успеха, которые направлены на улучшение пользовательского опыта для людей с когнитивными и моторными нарушениями. В 2024 году стандарт был переиздан с редакционными обновлениями.

Важно: WCAG 2.2 в настоящее время является актуальной рекомендацией W3C, на которую ссылаются современные законы о доступности в США и Европе. Это версия, которая наконец серьёзно учитывает когнитивные нарушения, сенсорный ввод и видимость фокуса.

Что изменилось в WCAG 2.2?

WCAG 2.2 — это эволюционное обновление, а не революционное. Все требования WCAG 2.1 остаются в силе. Новые критерии добавляются как дополнения к существующим уровням соответствия (A, AA, AAA).

Ключевые изменения можно разделить на три группы:

  • Когнитивная доступность — помощь пользователям с нарушениями памяти и внимания (4 новых критерия).
  • Вводимые данные и моторика — упрощение заполнения форм и взаимодействия с интерфейсом (2 критерия).
  • Навигация и фокус — улучшение управления с клавиатуры и видимости фокуса (3 критерия).

Всего в WCAG 2.2 насчитывается 86 критериев успеха, сгруппированных по четырём принципам: Воспринимаемость, Управляемость, Понятность и Надёжность.

Новые критерии успеха уровня А

3.2.6 — Consistent Help (Последовательная помощь)

Требование: Если на странице есть механизм помощи (например, ссылка на контакты, чат-поддержка), он должен появляться в одном и том же месте на всех страницах сайта.

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

<footer>
  <nav aria-label="Помощь">
    <a href="/contact">Контакты</a>
    <a href="/faq">Частые вопросы</a>
    <button id="chat-toggle" type="button">Чат поддержки</button>
  </nav>
</footer>

3.3.7 — Redundant Entry (Избыточный ввод данных)

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

Для разработчиков: Это особенно важно для многошаговых форм (оформление заказа, регистрация). Если пользователь ввёл адрес доставки на первом шаге, на втором шаге (для платёжного адреса) данные должны быть предзаполнены или доступны для выбора. Браузерное автозаполнение не считается достаточным механизмом — ответственность лежит на самом сайте.

<fieldset>
  <legend>Платёжный адрес</legend>
  <label>
    <input type="checkbox" id="same-as-shipping" checked>
    Совпадает с адресом доставки
  </label>
</fieldset>

Новые критерии успеха уровня AA

2.4.11 — Focus Not Obscured (Минимальный) — Фокус не перекрывается

Требование: Когда элемент получает фокус с клавиатуры, он не должен быть полностью скрыт другими элементами интерфейса (фиксированными хедерами, баннерами, виджетами чата).

Для разработчиков: Наиболее частая проблема — фиксированные хедеры, которые перекрывают элемент при прокрутке. Простое решение — использовать scroll-margin. Частичное перекрытие допускается на уровне AA. Более строгое требование (без перекрытия вообще) — на уровне AAA (2.4.12).

/* Учитываем высоту фиксированного хедера при прокрутке к элементу */
:focus {
  scroll-margin-top: 5rem;
  scroll-margin-bottom: 5rem;
}

html {
  scroll-padding-top: 5rem;
}

2.5.7 — Dragging Movements (Перетаскивание)

Требование: Любая функциональность, использующая перетаскивание (drag-and-drop), должна иметь альтернативу с использованием одного указателя (клик, тап, кнопки). Исключение: если перетаскивание является essential (необходимым для передачи информации).

Для разработчиков: Это касается не только классических drag-and-drop списков, но и слайдеров, панелей карт, элементов для подписи — если у них нет кнопочных или числовых альтернатив.

<li draggable="true">
  <span>Элемент 1</span>
  <button type="button" aria-label="Переместить вверх">↑</button>
  <button type="button" aria-label="Переместить вниз">↓</button>
</li>

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

Требование: Интерактивные элементы (кнопки, ссылки, поля ввода) должны иметь размер не менее 24×24 CSS пикселя.

Исключения:

  • Spacing: Элемент может быть меньше 24px, если расстояние между соседними целями составляет не менее 24px (измеряется от края до края). Например, две кнопки размером 16×16 с промежутком в 8px проходят проверку (16 + 8 = 24).
  • Inline: Ссылки внутри текста (в предложении).
  • Essential: Если размер критичен для передачи информации (например, интерактивная карта).
  • User Agent: Элементы, размер которых определяется браузером и не изменён автором (например, выпадающие списки <select>).
  • Equivalent: Другой элемент на странице выполняет ту же функцию и имеет размер не менее 24px.

Для разработчиков: Наиболее частый сценарий нарушения — строка иконок размером 16×16 без достаточных отступов. Решение — увеличить область клика без изменения визуального размера (через padding) или объединить их в меню.

button, a, input[type="checkbox"], input[type="radio"] {
  min-width: 24px;
  min-height: 24px;
}

/* Для маленьких иконок увеличиваем область клика */
.icon-button {
  padding: 8px; /* 16px иконка + 8px padding = 32px область клика */
}

3.3.8 — Accessible Authentication (Минимальная) — Доступная аутентификация

Требование: Ни один шаг в процессе аутентификации не должен требовать когнитивного теста (запоминание пароля, расшифровка кода, решение головоломки), если только не существует альтернативного метода, не требующего такого теста.

Для разработчиков: W3C прямо называет два допустимых механизма: автозаполнение через менеджер паролей и поддержка копирования/вставки. Страница не должна блокировать вставку в поля пароля (JavaScript-обработчики типа onpaste="return false" — прямое нарушение).

CAPTCHA: Тесты на распознавание объектов (например, «Выберите все изображения с автобусами») проходят на уровне AA, но не проходят на уровне AAA. Текстовые и аудио CAPTCHA без альтернатив — нарушение на уровне AA.

<form>
  <label for="email">Email</label>
  <input type="email" id="email" autocomplete="username">

  <label for="password">Пароль</label>
  <!-- autocomplete="current-password" для менеджеров паролей -->
  <input type="password" id="password" autocomplete="current-password">

  <!-- Альтернативный метод — вход по ссылке -->
  <button type="button" data-action="magic-link">Отправить ссылку для входа</button>
</form>

Новые критерии успеха уровня AAA

2.4.12 — Focus Not Obscured (Расширенный)

Требование: Строгая версия 2.4.11. Когда элемент получает фокус, он не должен быть перекрыт вообще (ни один пиксель не должен быть скрыт).

2.4.13 — Focus Appearance (Внешний вид фокуса)

Требование: Индикатор фокуса должен соответствовать двум условиям:

  1. Размер: Площадь индикатора должна быть не меньше площади 2-пиксельной обводки вокруг элемента в неактивном состоянии.
  2. Контраст: Контраст между индикатором в состоянии фокуса и тем же пикселем в неактивном состоянии должен быть не менее 3:1.

Исключения: Если индикатор определяется браузером и не может быть изменён автором.

Для разработчиков: Стандартный outline браузера часто не соответствует этим требованиям. Необходимо создавать кастомный индикатор.

/* Кастомный индикатор фокуса */
*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

3.3.9 — Accessible Authentication (Расширенный)

Требование: Убирает исключения для распознавания объектов и личного контента, которые были допустимы на уровне AA (3.3.8). На уровне AAA аутентификация не должна требовать когнитивных тестов любого типа.

Что удалено из WCAG 2.2

4.1.1 — Parsing (Разбор)

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

Важно: Не удаляйте тесты на дублирующиеся ID, неверные ARIA-ссылки и неправильную вложенность. Эти ошибки всё ещё являются нарушениями — просто через другие критерии: через 4.1.2 (Name, Role, Value) и 1.3.1 (Info and Relationships).

Что делать командам разработки и продукта

Практические шаги:

  1. Аудит фиксированных элементов: Проверьте все sticky-хедеры, футеры и виджеты. Убедитесь, что они не перекрывают элементы в фокусе.
  2. Проверьте размеры кликабельных элементов: Пройдитесь по интерфейсу и найдите элементы меньше 24px.
  3. Протестируйте формы: Убедитесь, что данные подтягиваются между шагами, а пароль можно вставить.
  4. Обновите дизайн-систему: Добавьте стили для кастомного индикатора фокуса.
  5. Проверьте чат и виджеты помощи: Закрепите их положение на всех страницах.

Заключение

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

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

Доступный сайт — это сайт, который работает для всех.

— Алексей Любимов

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