Коли мова заходить про цифрову доступність, більшість команд роблять ставку на одне — WCAG 2.1. Перевірили контраст, додали alt-тексти, налаштували фокус і можна зітхнути з полегшенням. Здається, все за правилами.
Але нещодавно у гру вступив новий гравець — Європейський Акт про Доступність (EAA). І раптом виявляється, що ваша система доступності — це як дверний прохід без пандуса.
Сьогодні я проллю трохи цифрового чаю на тему оптимізації продуктів у світлі нових законодавчих вимог.
Давайте одразу домовимось: Цей матеріал не для всіх. Але якщо ви, як і я, розумієте, що сьогодні це може здаватися неактуальним, а завтра саме ці знання зроблять вас конкурентоспроможним, тоді цей текст для вас.
WCAG — це основа. Але не страховка
Почнемо з хороших новин: WCAG потрібен. Це авторитетний і важливий стандарт. Він вчить нас, як створювати інтерфейси, дружні до людей з порушеннями зору, слуху або моторики.
Більше того, WCAG часто допомагає ухвалювати дизайнерські рішення. Тож я не сприймаю його як обмеження. Навпаки, це додатковий вектор, що допомагає приймати обґрунтовані дизайнерські рішення.
А тепер погані новини: одного лише WCAG недостатньо, особливо якщо ви працюєте в Європі, або обслуговуєте європейських користувачів. З 28 червня 2025 року Європейський Акт про Доступність (EAA) набув чинності в повному обсязі. Якщо ви думали, що WCAG охоплює все, час переглянути цю стратегію.
Де закінчується WCAG і починається EAA
WCAG — це гайдлайн. Він каже: “Зроби так, щоб кнопку можна було натиснути з клавіатури” або “Додай опис до зображення”.
Це про інтерфейс.
EAA — це закон. Його мета — забезпечити рівний доступ до товарів і послуг для всіх громадян, включно з людьми з інвалідністю.
І він не запитує "Чи читається цей екран скрінрідером?".
Він запитує:
Чи може користувач пройти весь шлях? Від вибору товару до повернення грошей? Без бар’єрів? Без допомоги іншої людини? На будь-якому пристрої? З будь-якою допоміжною технологією?
Ключові особливості EAA
1. Це закон, а не рекомендація
На відміну від WCAG (який є гайдлайном), EAA має юридичну силу. Недотримання може призвести до скарг, судових позовів і штрафів.
2. Застосовується до всього життєвого циклу продукту
Від маркетингу та покупки до підтримки, повернення та розірвання договору. Це не лише вебсайт, а ще й email, мобільні застосунки, термінали самообслуговування, документація, служба підтримки тощо.
3. Охоплює конкретні категорії товарів і послуг, зокрема:
- Вебсайти та мобільні застосунки
- Електронні книги
- Онлайн-магазини та маркетплейси
- Банківські інтерфейси
- Квиткові автомати, POS-термінали, банкомати
- Електронні комунікаційні послуги
- Операційні системи
4. Спирається на конкретні технічні стандарти
EN 301 549 — технічні вимоги (включає WCAG, але значно ширше)
EN 17161 — як керувати доступністю в межах організації (процеси, ролі, навчання, відповідальність)
5. Обов’язковий для всіх компаній, що працюють у ЄС
Навіть якщо ваша компанія зареєстрована поза межами ЄС, але ви пропонуєте товари чи послуги в Європі — ви зобов’язані дотримуватись EAA.
Так, справді можна успішно пройти аудит WCAG і… отримати штраф.
Якщо ваша команда використовує автоматизовані тестери, фіксує кілька помилок контрасту і вішає бейджик “WCAG compliant” — це ще не означає, що ви в безпеці з юридичної точки зору.
Бо EAA дивиться ширше:
- Що відбувається після покупки?
- Чи можна скасувати замовлення без візуального інтерфейсу?
- Чи читається ваша email-розсилка скрінрідером?
- Наскільки адаптований ваш застосунок до Android accessibility tools?
- Якщо я клієнт і хочу поставити питання — чи є доступний канал зв’язку, окрім дзвінка?
Це не “опції”. Це обов’язкові вимоги.
Приклад з життя
Уявіть, що ваш продукт — це банк. Сайт відповідає WCAG, і мобільний застосунок бездоганно доступний.
Але клієнт з інвалідністю намагається:
- Скасувати підписку → і не може
- Подзвонити в підтримку → а там лише голосове меню
- Отримати повернення коштів → а форма повернення в PDF, яку не можна заповнити без миші
- Формально ви відповідаєте WCAG, але ви все одно порушуєте EAA.
Що ж робити?
Якщо у вас вже є налаштовані процеси відповідності GDPR чи кібербезпеки — структура вам буде знайома.
Що варто зробити:
- Вивчити EN 301 549 — технічні вимоги, що значно ширші за WCAG
- Прийняти EN 17161 — як внутрішній стандарт керування доступністю
- Вибудувати процеси: ролі, відповідальні, документація, аудит
- Інтегрувати перевірки доступності у розробку
- Подумати про GDPR-підхід: з бордами, політиками, інструкціями
- Залучити службу підтримки, маркетинг, контент і юристів
- Навчити команду
- Документувати: що зроблено, що в роботі, де вузькі місця
Раз на квартал “ручний аудит” — уже не працює.
Наостанок
Підсумуємо: WCAG — це перевірка якості інтерфейсу. EAA — це перевірка зрілості вашої організації в цілому.
Якщо ви створюєте цифрові продукти для європейського ринку, доступність більше не можна сприймати як “додаток до UI”.
Це корпоративне зобов’язання. І якщо ви це ігноруєте, вам швидко нагадають. Через суд.
І повертаючись до початку: Уміння впроваджувати і WCAG, і EAA — це не обмеження. Це ще один ваш скіл. І саме він робить вас сильнішим і більш затребуваним.
Добра 🦫
Топ коментарі (0)