Сделали по WCAG, но всё ещё нарушаете закон? Добро пожаловать в мир EAA
Когда речь заходит о цифровой доступности, большинство команд делают ставку на одно: WCAG 2.1. Проверили цвета, добавили alt-теги, проставили фокус и выдохнули. Вроде всё по правилам. Но с недавнего времени в игру вступает Европейский Акт о Доступности (EAA). И внезапно оказывается, что ваша система доступности как дверной проём без пандуса. Сегодня пролью цифровой чай на вопрос оптимизации продуктов с точки зрения последних нововведений уже на уровне законодательства.
Предлагаю сразу договориться. Это материал не для всех. Но если вы, как и я понимаете, что сегодня для вашего продукта это не актуально, а завтра обладая этим навыком вы будете конкурентоспособны на рынке. Этот материал для вас.
WCAG — это база. Но не страховка.
Начнём с хорошей новости: WCAG нужен. Да, это важный и уважаемый стандарт. Он учит нас, как делать интерфейсы дружелюбными к людям с ограничениями по зрению, слуху и моторике. и даже больше скажу. Он помогает зачастую принимать решения о реализации того или иного варианта дизайна. Т.е. я бы не воспринимал его, как ограничитель. Скорее как дополнительный вектор который помогает принимать обоснованные решения в дизайне.
Но вот плохая новость: одних WCAG недостаточно, если вы работаете в Европе или просто на европейскую аудиторию.
С 28 июня 2025 года начал полноценно действовать Европейский Акт о Доступности (EAA). И если вы думали, что WCAG покрывает всё, то пришло время пересмотреть ваши планы.
Где заканчивается WCAG и начинается EAA?
WCAG — это гайдлайн. Он говорит: “Сделай так, чтобы кнопку можно было нажать с клавиатуры” или “Поставь текст к изображению”. Это про интерфейс.
EAA — это Европейский Акт о Доступности, принятый ЕС с целью обеспечить равный доступ к товарам и услугам для всех граждан, включая людей с инвалидностью. Он уже вступил в силу с 28 июня 2025 года и обязателен для компаний, работающих в странах ЕС. EAA — это закон, который обязывает бизнес делать свои цифровые и физические продукты доступными.
По сути, он спрашивает:
“А клиент смог пройти весь путь? От выбора товара до возврата денег? Без барьеров? Без помощи другого человека? На любом устройстве? С любой технологией поддержки?”
Ключевые особенности EAA:
1. Это закон, а не рекомендация
- В отличие от WCAG (гайдлайны), EAA имеет юридическую силу.
- Несоблюдение может привести к жалобам, судебным искам и штрафам.
2. Применяется ко всему жизненному циклу продукта
- От маркетинга и покупки, до поддержки, возвратов и расторжения договора.
- Не только веб-сайт, но и email, приложение, терминалы, документация, поддержка и т. д.
3. Охватывает конкретные категории товаров и услуг
Например:
- Веб-сайты и мобильные приложения
- Электронные книги
- Онлайн-магазины и платформы
- Банковские интерфейсы
- Билетные автоматы, POS-терминалы, банкоматы
- Электронные службы связи
- Операционные системы
4. Ссылается на технические стандарты
- EN 301 549 — технические требования (включают WCAG, но шире)
- EN 17161 — требования к управлению доступностью в организации (процессы, роли, обучение, контроль)
5. Обязателен для компаний, работающих в ЕС
- Даже если ваша компания зарегистрирована за пределами ЕС, но вы предлагаете услуги или товары в ЕС — вы обязаны соблюдать EAA.
Можно пройти аудит по WCAG и… получить штраф
Именно так. Если ваша команда использует автоматические тестеры, ловит пару недочётов по цветам и вешает на сайт бейджик “мы compliant” — это не гарантирует, что вы законно чисты по EAA.
Потому что EAA смотрит шире:
- Что происходит после покупки?
- А можно ли отменить заказ без визуального интерфейса?
- А что с email-рассылкой, её можно прочитать скринридером?
- А если у вас мобильное приложение, насколько оно адаптировано под Android accessibility tools?
- А если я клиент и хочу задать вопрос: “есть ли доступный канал связи, кроме звонка?”
И выходит так, что это не “опции”. Это обязательные требования.
Давайте приведу пример, для наглядности:
Представьте, что ваш продукт — это банк. Сайт полностью по WCAG, и приложение идеально адаптировано.
Но клиент с инвалидностью пытается:
- отменить подписку → и не может,
- хочет дозвониться → а у вас только голосовой автоответчик,
- получить возврат → а форма возврата в PDF и её нельзя заполнить без мыши.
По итогу, вы формально соответствуете WCAG, но всё ещё нарушаете EAA.
Хорошо. А что делать?
Если у вас уже налажены процессы по безопасности и приватности (например, GDPR), то путь вам знаком. Тут тоже нужно:
Изучить EN 301 549 — технические требования, которые шире WCAG.
Принять EN 17161 — как корпоративный стандарт управления доступностью.
Выстроить процессы: роли, ответственные, документация, аудит.
- Встроить проверку доступности в процесс разработки. Подумать, как вы внедряли GDPR с бордами, формами, инструкциями. Здесь будет примерно то же самое.
- Вовлекать поддержку, маркетинг, контент и даже юридический отдел.
- Подумать об обучении команды.
- Документировать: что сделано, что в работе, где узкие места.
Просто делать “ручной аудит раз в квартал” больше не работает.
Как итог
Ну по сути, держим в голове и понимании, что WCAG — это проверка качества интерфейса, а EAA — это проверка зрелости всей вашей организации в целом.
И если вы строите цифровой продукт на европейском рынке, пора воспринимать доступность не как “добавку в UI”, а как полноценную корпоративную обязанность. Иначе вам быстро напомнят через суд.
Ну и то с чего начали. Понимание и умение внедрять то и другое — это не ограничитель, а еще один ваш скил, который делает вас сильнее и востребованее.
Добра 🦫