Європейський акт про доступність: що перевірити в цифровому продукті після 28 червня 2025 року

Європейський акт про доступність діє в ЄС із 28 червня 2025 року. Він не перетворює кожен сайт на однаковий набір екранів, але вимагає, щоб охопленими законом продуктами й послугами могли користуватися люди з різними порушеннями зору, слуху, моторики та сприйняття. Для продуктової команди це означає системну роботу з інтерфейсом, інформацією, підтримкою і внутрішніми процесами, а не встановлення «віджета доступності» перед перевіркою.

Закон охоплює визначені продукти та послуги

Директива (ЄС) 2019/882, відома як European Accessibility Act, поширюється не на будь-який цифровий продукт без винятку. До переліку входять, зокрема, комп’ютери та операційні системи, смартфони, електронні книги, платіжні й окремі термінали самообслуговування. Серед послуг названі електронна комерція, споживчі банківські послуги, електронні комунікації, доступ до аудіовізуальних медіасервісів та певні цифрові елементи пасажирського транспорту.

Тому перший крок — не механічний аудит головної сторінки, а визначення сфери застосування. Команда має описати, який саме продукт або сервіс вона пропонує в ЄС, хто є економічним оператором і які національні правила реалізують директиву в потрібній державі. Для юридичного висновку цього матеріалу недостатньо: остаточну оцінку потрібно звіряти з текстом закону та національним законодавством.

Доступність є властивістю повного сценарію

Людина може без проблем прочитати каталог, але не завершити покупку через невидиму для скринрідера помилку у формі. Інша користувачка здатна обрати товар із клавіатури, однак втратить контекст, коли фокус після відкриття діалогу опиниться за його межами. Формальна наявність альтернативного тексту також мало допомагає, якщо він повторює ім’я файлу або не передає функцію зображення.

Перевіряти варто наскрізні завдання: пошук і вибір товару, реєстрацію, вхід, оплату, підтвердження, повернення, завантаження документа та звернення до підтримки. Кожен сценарій проходять без миші, зі скринрідером, зі збільшенням, за високого контрасту та на вузькому екрані. Автоматичний сканер знаходить частину порушень, але не визначає, чи зрозуміла назва кнопки, чи логічний порядок читання і чи можна виправити помилку без сторонньої допомоги.

Стандарт допомагає, але не замінює тестування

У європейській практиці технічні вимоги до цифрової доступності пов’язують із гармонізованим стандартом EN 301 549, який містить критерії для вебсайтів, застосунків, документів та інформаційно-комунікаційних технологій. Багато вебкритеріїв спираються на WCAG. Проте відповідність контрольному списку не гарантує, що реальна людина успішно виконає завдання: критерій може бути реалізований формально, а повідомлення або послідовність кроків усе одно залишаться незрозумілими.

Продуктовій команді корисно вести матрицю: вимога, охоплений компонент, спосіб перевірки, результат, відповідальна особа й дата повторного тесту. Так доступність стає частиною звичайного контролю якості. Додавання нового платіжного провайдера, редактора, відеоплеєра чи механізму входу має запускати повторну перевірку відповідного сценарію.

Інтерфейс має працювати без припущень про користувача

Клавіатурний фокус повинен бути видимим, порядок переходу — відповідати змісту, а всі дії — мати зрозумілі назви. Колір не може бути єдиним способом повідомити про помилку або статус. Текст і важливі елементи мають зберігати читабельність після збільшення. Відео потребує субтитрів там, де звук передає зміст, а аудіоопис або текстова альтернатива потрібні, коли суттєва інформація міститься лише в зображенні.

Особливу увагу варто приділити автентифікації, таймерам і захисту від ботів. Завдання не повинно вимагати лише точного жесту, розпізнавання дрібного об’єкта або запам’ятовування складної послідовності без доступної альтернативи. Якщо сесія завершується, користувача потрібно попередити й дати можливість продовжити роботу, коли це не суперечить вимогам безпеки.

Документи, листи та підтримка є частиною послуги

Доступний інтерфейс не компенсує рахунок у PDF без структури, лист із важливою інформацією у вигляді картинки або чат підтримки, який неможливо відкрити з клавіатури. Інструкції, договори, повідомлення про помилки, підтвердження операції та канали допомоги потрібно включити до того самого аудиту. Інформація про доступність послуги має бути реально корисною: пояснювати підтримувані можливості, відомі обмеження й спосіб повідомити про проблему.

Зворотний зв’язок слід перетворити на керований процес. Звернення отримує відповідального, строк відповіді та зв’язок із системою дефектів. Людині не варто доводити технічну причину порушення: достатньо описати дію, очікуваний результат, використаний пристрій або допоміжну технологію.

Оверлей не виправляє архітектуру продукту

Європейська комісія прямо застерігає, що інструменти-оверлеї не є належним рішенням, якщо сам сайт не відповідає детальним критеріям. Панель зі зміною шрифту чи контрасту не додасть семантичних підписів до полів, не виправить порядок фокусу й не зробить недоступний сторонній платіжний модуль керованим із клавіатури.

Ефективні зміни починаються на рівні дизайн-системи: контрастні токени, стани фокусу, доступні компоненти форм, коректні діалоги, шаблони повідомлень і правила для редакційного вмісту. У спорідненому матеріалі TechPulse пояснює, як зменшити шум сповіщень без втрати важливого, а стаття про експорт даних показує, чому доступність потрібно враховувати і в рідше використовуваних сценаріях.

Виняток потрібно обґрунтувати, а не припустити

Директива містить винятки й перехідні правила. Наприклад, мікропідприємства, які надають послуги, виключені зі сфери окремих вимог; передбачені положення про фундаментальну зміну продукту та непропорційний тягар. Проте розмір компанії, характер послуги й застосовність винятку потрібно перевіряти за конкретними нормами. Загальне твердження «ми малий бізнес» не є редакційно або юридично достатнім доказом.

Навіть коли певна вимога формально не застосовується, доступний продукт залишається практично корисним: ним легше користуватися на мобільному пристрої, у яскравому світлі, з тимчасовою травмою або повільним з’єднанням. Це не скасовує витрат, але допомагає пріоритезувати базові рішення ще до дорогого перепроєктування.

Закупівлі та сторонні компоненти потребують окремого контролю

Частина критичного шляху часто належить не команді продукту. Платіжний віджет, система автентифікації, чат, карта, відеоплеєр або платформа електронного підпису можуть мати власні бар’єри. Контракт із постачальником має містити вимоги до доступності, спосіб підтвердження, повідомлення про зміни та строк виправлення дефектів. Загального запевнення на сторінці продажу недостатньо: потрібні результати перевірки для версії, яку фактично інтегрує продукт.

Перед закупівлею корисно попросити звіт про відповідність, відомі обмеження й демонстрацію ключового сценарію з клавіатурою та скринрідером. Якщо компонент не можна виправити самостійно, команда повинна мати доступну альтернативу або план заміни. Відповідальність перед користувачем не зникає через те, що недоступний екран завантажив сторонній постачальник.

Доступність потрібно вимірювати після релізу

Одна успішна перевірка не захищає від регресії. Новий банер, змінена форма або оновлена бібліотека можуть порушити порядок фокусу чи назви елементів. До автоматичних тестів варто додати перевірки семантики, контрасту та керування клавіатурою, а перед великим релізом повторювати ручні сценарії. Команда також відстежує кількість звернень, час до першої відповіді, строк виправлення й повторні проблеми в тому самому компоненті.

Метрика не повинна заохочувати приховувати складні дефекти. Відсоток пройдених автоматичних правил мало говорить про можливість завершити оплату. Корисніше поєднати технічні результати з успішністю наскрізних завдань і зворотним зв’язком людей, які користуються допоміжними технологіями. Так доступність переходить із разового юридичного проєкту в постійну властивість якості.

Тестування з людьми виявляє проблеми, яких немає у звіті

Учасників потрібно залучати не як фінальне підтвердження готового рішення, а під час дослідження, прототипування й перевірки релізу. Невелика різноманітна група може показати, що формально правильна назва елемента незрозуміла, звичний порядок кроків порушений або допоміжна технологія повідомляє забагато другорядної інформації. Один учасник не представляє всіх людей із таким самим діагнозом, тому результат доповнює, а не замінює технічну перевірку.

Дослідження має бути доступним саме по собі: запрошення, форма згоди, платформа дзвінка, матеріали й винагорода не повинні створювати нових бар’єрів. Модератор не підказує потрібний шлях, а фіксує мету, перешкоду та наслідок. Після виправлення сценарій повторюють, щоб переконатися, що зміна не перенесла проблему на іншу групу користувачів.

Практичний план перевірки

1. Визначте, чи входять продукт і послуга до сфери EAA у кожній країні роботи.
2. Складіть перелік критичних користувацьких сценаріїв і сторонніх компонентів.
3. Перевірте їх автоматичними інструментами, клавіатурою та допоміжними технологіями.
4. Додайте ручне тестування людьми з інвалідністю або компетентними фахівцями.
5. Зафіксуйте відомі обмеження, відповідальних і строки усунення.
6. Включіть доступність до критеріїв приймання, закупівель і регресійних тестів.

Першоджерела: текст Директиви (ЄС) 2019/882, офіційний огляд EUR-Lex і повідомлення Європейської комісії про початок застосування EAA.