Доступность согласия на cookie: соответствие WCAG 2.2 для баннеров согласия
Баннер cookie, который пользователи клавиатуры не могут закрыть, программы чтения с экрана не могут озвучить, а посетители с дальтонизмом не могут прочитать, — это не просто плохой UX, это провал соответствия по двум фронтам. С момента вступления в силу Европейского акта о доступности в июне 2025 года интерфейсы согласия на коммерческих сайтах, обслуживающих пользователей ЕС, должны соответствовать WCAG 2.1 уровня AA, при этом WCAG 2.2 настоятельно рекомендуется на 2026 год. В сочетании с требованием GDPR о том, что согласие должно быть «свободно данным, конкретным, осознанным и недвусмысленным», недоступные баннеры теперь несут двойную юридическую уязвимость. Это руководство объясняет, как именно выглядит баннер cookie, соответствующий WCAG, в 2026 году.
Почему доступность и согласие теперь пересекаются
GDPR требует, чтобы согласие можно было получить от каждого пользователя, а не только от тех, кто может видеть и нажимать баннер. Европейский совет по защите данных разъяснил, что если субъект данных не может осмысленно взаимодействовать с интерфейсом согласия — из-за инвалидности, которую сайт не учёл, — согласие не получено должным образом. Это значит, что cookie вообще не должны были загружаться.
Со стороны доступности Европейский акт о доступности (EAA), перенесённый в национальное законодательство государств — членов ЕС, делает WCAG 2.1 AA минимумом для частных веб-сайтов и приложений, предлагающих потребительские услуги. Режим штрафов варьируется по странам, но обычно составляет от 50 000 до 500 000 евро за нарушение, плюс приказы об изъятии с рынка при стойком несоответствии.
Основные требования WCAG к баннерам cookie
Управляемость с клавиатуры
Каждый элемент управления баннером — «Принять», «Отклонить», «Управлять настройками», «Закрыть» — должен быть достижим и управляем только с клавиатуры. Пользователи должны иметь возможность переходить между кнопками клавишей Tab в логическом порядке и активировать их клавишами Enter или Space. Фокус должен быть видимым с минимальным контрастом 3:1 относительно фона.
Захват фокуса в модальных баннерах
Если баннер блокирует взаимодействие с остальной частью страницы, фокус клавиатуры должен удерживаться внутри баннера, пока пользователь не сделает выбор. Пользователи не должны иметь возможности перейти клавишей Tab из баннера, чтобы прокрутить нижележащую страницу. Когда фокус был захвачен и баннер закрывается, фокус должен вернуться к элементу, который вызвал баннер, или к разумному значению по умолчанию.
Объявления программ чтения с экрана
Баннер должен объявляться как диалог с доступным именем и ролью. Используйте `role="dialog"` или `role="alertdialog"` с `aria-labelledby`, указывающим на заголовок баннера, и `aria-describedby`, указывающим на пояснительный текст.
Контраст цвета
Основной текст должен соответствовать контрасту 4.5:1 относительно фона; крупный текст (18pt+ или 14pt полужирный) требует 3:1. Текст кнопок, иконки и индикаторы фокуса имеют свои минимумы контраста. Светло-серая кнопка «Отклонить» на белом фоне — частый провал WCAG, который мы видим в аудитах.
Никаких подсказок только цветом
Не полагайтесь только на цвет для различения «Принять» и «Отклонить». Используйте различные подписи, иконки или формы, чтобы пользователи с дальтонизмом могли отличить кнопки.
Тёмные паттерны и доступность
WCAG 2.2 вводит новые критерии, прямо нацеленные на тёмные паттерны — особенно актуальные для согласия:
- 3.3.8 Доступная аутентификация — запрещает когнитивные головоломки как трение согласия.
- 3.3.7 Повторный ввод — пользователи не должны повторно вводить информацию только для отзыва согласия.
- 2.4.11 Фокус не закрыт — сам баннер не должен закрывать индикатор фокуса элементов позади него.
- 2.5.7 Движения перетаскивания — если ваш баннер использует взаимодействие «перетащить, чтобы принять», должна существовать альтернатива с одним указателем.
RTL и интернационализация
Доступность распространяется на языки с письмом справа налево (арабский, иврит, персидский, урду) и на произношение программами чтения с экрана:
- Установите `dir="rtl"` на баннере, когда язык документа RTL, чтобы порядок кнопок и поток фокуса соответствовали направлению чтения.
- Используйте корректные атрибуты `lang` на переведённом тексте баннера, чтобы программы чтения с экрана произносили слова с правильной фонетикой.
- Зеркальте иконографику — шевроны, стрелки и индикаторы прогресса должны переворачиваться для RTL-локалей.
Тестирование вашего баннера на соответствие WCAG
Не полагайтесь на один инструмент. Сочетайте автоматическое сканирование с реальным тестированием на ассистивных технологиях:
- axe DevTools или Lighthouse — улавливают примерно 30–40 % провалов WCAG автоматически.
- NVDA или JAWS на Windows, VoiceOver на Mac/iOS, TalkBack на Android — тестируйте с реальными программами чтения с экрана. Можно ли объявить, навигировать и закрыть баннер, используя только программу чтения с экрана?
- Навигация только с клавиатуры — отключите мышь. Если вы не можете «Принять», «Отклонить» и управлять настройками, не могут и пользователи клавиатуры.
- Симуляция дальтонизма — Chrome DevTools имеет встроенные симуляторы дефицита зрения. Проверьте, различимы ли «Принять» и «Отклонить» при протанопии, дейтеранопии и тританопии.
- Масштабирование до 400 % — WCAG требует, чтобы контент оставался пригодным к использованию при 400 % масштабе без горизонтальной прокрутки. Баннеры с фиксированным положением часто не проходят этот тест.
Распространённые провалы доступности, которые мы видим
- Скрытое «Отклонить» за иконкой шестерёнки — тёмный паттерн плюс провал доступности (нет доступного имени на кнопке-иконке).
- Фокус никогда не достигает баннера — баннеры, которые привлекают визуальное внимание, но пропускаются в порядке Tab.
- Модальный баннер без захвата фокуса — пользователи могут перейти Tab на фоновую страницу, пока баннер заявляет, что блокирует взаимодействие.
- Нет `aria-live` на изменениях настроек — пользователи программ чтения с экрана не слышат подтверждения сохранения их выбора.
- Переведённые баннеры без атрибута `lang` — программы чтения с экрана произносят испанский текст с английской фонетикой.
Как FlexyConsent обеспечивает доступность
FlexyConsent соответствует WCAG 2.2 AA из коробки:
- Все элементы управления управляемы с клавиатуры с видимыми индикаторами фокуса 3:1.
- Корректный `role="dialog"` с `aria-labelledby` и `aria-describedby`.
- Захват фокуса с закрытием по Escape для необязательных баннеров.
- Контраст 4.5:1+ на каждом текстовом элементе, включая «Отклонить».
- Автоматический переворот RTL для арабской, ивритской, персидской и урду локалей.
- Атрибут `lang`, установленный для каждого перевода, для корректного произношения программами чтения с экрана.
- Устойчивый к масштабированию макет, остающийся пригодным к использованию при 400 %.