Вебдоступність сайту: юридичні ризики та відповідальність бізнесу

Ще кілька років тому доступність сайту сприймалася як питання доброї волі компанії. Тепер це нормативна вимога: у ЄС вона вже застосовується до комерційних сервісів, в Україні – формалізується на рівні законодавства. Для бізнесу це означає, що недоступний інтерфейс перестає бути суто UX-проблемою і перетворюється на джерело юридичних, ринкових та репутаційних ризиків. Давайте розберемо, які вимоги діють уже сьогодні, для яких компаній вони обов'язкові, як розподіляється відповідальність усередині команди і що саме перевіряють під час аудиту.

Вебдоступність як вимога до сучасного бізнес-сайту

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

Найкритичніше доступність вебсайтів впливає на такі групи користувачів:

• незрячі люди та люди з порушеннями зору, які працюють через screen reader або значне збільшення картинки на дисплеї;

• люди зі слабким зором і порушеннями кольоросприйняття – для них важлива контрастність тексту та елементів керування;

• люди з порушеннями слуху, яким потрібні субтитри й транскрипції для відеоконтенту;

• люди з моторними порушеннями, які не використовують мишу і потребують навігації з клавіатури та достатнього розміру цілей натискання;

• користувачі з когнітивними особливостями та дислексією – для них важливі проста мова, передбачувана навігація й зрозумілі повідомлення про помилки;

• люди літнього віку, у яких одночасно може погіршуватись зір, слух і точність рухів.

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

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

Що обмежує доступність веб-сайту? Типові бар'єри залежать від типу ресурсу. На корпоративних ресурсах це меню, що розкривається лише на hover, каруселі з автопрокруткою, скановані PDF замість тексту, форми без програмно пов'язаних підписів. У сервісах та особистих кабінетах –  це модальні вікна без керування фокусом, таблиці без семантичної розмітки, помилки, позначені лише кольором, короткі таймаути сесії. В інтернет-магазинах критичними стають фільтри каталогу, кастомні селекти розміру й кольору, ускладнені кроки оформлення замовлення, CAPTCHA та сторонні чат-віджети: саме тут недоступність напряму блокує купівлю.

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

Які закони та стандарти регулюють вебдоступність

Вимоги в Україні та роль ДСТУ EN 301 549:2022

Базовий національний документ для України — ДСТУ EN 301 549:2022 «Інформаційні технології. Вимоги щодо доступності продуктів та послуг ІКТ», ухвалений наказом Національного центру стандартизації № 68 від 5 травня 2022 року. Цей наказ ідентичний європейському стандарту EN 301 549 V3.2.1 (2021-03), тому фактично переносить в українське правове поле європейські технічні вимоги. Для вебконтенту стандарт спирається на WCAG 2.1 рівнів A та AA, але охоплює значно ширше поле: програмне забезпечення, електронні документи, апаратні термінали, послуги підтримки.

Постановою Кабінету Міністрів № 757 від 21 липня 2023 року дотримання цього стандарту стало обов'язковим для органів виконавчої влади під час створення й модернізації їхніх вебсайтів та інформаційно-комунікаційних систем. Передбачені й винятки – наприклад, для аудіо- та відеозаписів, опублікованих до набрання чинності постановою, та для прямих трансляцій, крім оповіщення про загрозу життю. Рамковим документом залишається Національна стратегія створення безбар'єрного простору до 2030 року, затверджена указом Президента у 2021 році.

Тут важливо розрізняти два європейські інструменти, які часто плутають. Директива (ЄС) 2016/2102 стосується вебсайтів і застосунків державного сектору – саме її логіка вже відображена в українських вимогах до органів влади. European Accessibility Act, натомість, вперше поширює обов'язки на приватний сектор. Українські норми поки що рухаються за першою моделлю, тоді як бізнесу, що працює з ЄС, доводиться орієнтуватися на другу.

Для приватного бізнесу універсальної прямої норми в Україні станом на зараз немає, але напрям руху зафіксований. У листопаді 2025 року уряд схвалив і подав до Верховної Ради законопроєкт № 14278 «Про цифрову доступність в Україні», згодом було зареєстровано й альтернативний проєкт. Обидва передбачають поширення вимог не лише на державні органи, а й на приватний сектор у ключових сферах: банки, транспорт, інтернет-магазини, медицина, освіта, зв'язок. Малий бізнес планують вивести з-під основних обов'язків, а власників сервісів – зобов'язати публічно звітувати про рівень доступності, з державним моніторингом виконання. Закон на момент підготовки матеріалу ще не ухвалили, проте компаніям, які зараз планують редизайн, дешевше одразу закласти в продукт вимоги вебдоступності, ніж переробляти інтерфейс після набуття чинності новими нормами. 

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

WCAG 2.2: рівні A, AA та AAA

Web Content Accessibility Guidelines (WCAG) – це вимоги вебдоступності, розроблені W3C – провідною глобальною організацією зі стандартизації Інтернету. WCAG 2.2 отримала статус рекомендації 5 жовтня 2023 року (з редакційним оновленням у грудні 2024-го). Рівень A – базовий мінімум, без якого частина користувачів фізично не може працювати з сайтом. Рівень AA – практичний орієнтир, на який спираються регулятори та закупівельні процедури. Рівень AAA не розрахований на повне застосування до всього ресурсу й використовується вибірково.

Саме тому в комерційних проєктах цільовим значенням майже завжди обирають WCAG 2.2 AA. Рівень A залишає надто багато реальних бар'єрів, зокрема в частині контрасту й повідомлень про помилки, а орієнтація на AAA робить вимоги нездійсненними для типового каталогу з тисячами товарів і зовнішніми інтеграціями. AA – це той рівень, який одночасно закриває основні судові та регуляторні ризики й залишається керованим у типовій комерційній розробці.

Для бізнесу важливо, що WCAG 2.2 додала критерії, які прямо стосуються бізнес-інтерфейсів: мінімальний розмір цілі натискання, альтернатива для drag-and-drop, доступна автентифікація без обов'язкового відтворення капчі чи паролю з пам'яті, відсутність повторного введення тих самих даних у межах процесу, послідовне розміщення блоків допомоги та видимість елемента у фокусі.

European Accessibility Act та ринок ЄС

European Accessibility Act – Директива ЄС 2019/882 – була ухвалена у 2019 році, транспонована державами-членами до 28 червня 2022 року і застосовується до економічних операторів з 28 червня 2025 року. Її сфера дії охоплює e-Commerce, споживчі банківські послуги, електронні комунікації, елементи пасажирських перевезень, електронні книги, аудіовізуальні медіасервіси, а також продукти: банкомати, платіжні й самообслуговні термінали, ридери тощо.

Технічною базою відповідності виступає європейський стандарт EN 301 549: у чинній редакції V3.2.1 він містить WCAG 2.1 AA, але у підготовці вже перебуває нова версія, орієнтована на WCAG 2.2. Відтак сьогодні цільове проєктування ресурсу під WCAG 2.2 AA — це не перестраховка, а розумний крок з прицілом під майбутні оновлення.

Для українських компаній ключовий фактор — не місце реєстрації, а факт надання послуг споживачам у ЄС. Якщо український інтернет-магазин, SaaS-сервіс чи маркетплейс приймає замовлення від європейських покупців, вимоги EAA 2025 стосуються його так чи інакше. 

Директива EAA передбачає перехідні режими: договори про надання послуг, укладені до 28 червня 2025 року, можуть виконуватися без змін не довше ніж до 28 червня 2027 року, а для терміналів самообслуговування діють значно більш м’які строки.

Для яких компаній вебдоступність може бути юридично обов'язковою

• Інтернет-магазини, ритейл та онлайн-продажі. Доступність e-Commerce – один з наріжних кейсів EAA. Під вимоги потрапляє весь шлях покупця: пошук, каталог, картка товару, кошик, оформлення, оплата, статус замовлення й повернення.

• Банки, фінансові сервіси та електронні платежі. Крім вебсайту й застосунку, оцінюється доступність автентифікації, підписання документів, платіжних форм і клієнтської підтримки.

• Телекомунікаційні компанії та цифрові послуги. Тут додаються вимоги до екстреного зв'язку, тарифної інформації та самообслуговування в особистому кабінеті.

• Транспортні, туристичні та інші клієнтські онлайн-сервіси. Бронювання, купівля квитків, реєстрація, електронні талони й повідомлення про зміни в рейсі.

• Медичні, освітні та дотичні до держави сервіси. В українських законопроєктах ці сфери визначені чітко: онлайн-запис до лікаря, електронні кабінети пацієнта, навчальні платформи тощо.

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

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

Винятки існують, але вони вужчі, ніж здається. Від вимог до сервісу звільнені мікропідприємства – компанії з менш ніж 10 працівниками та річним оборотом або балансом до 2 млн євро; при цьому мікропідприємство, яке виробляє чи розповсюджує охоплені регуляцією продукти, обов'язків не втрачає. Другий механізм – принцип непропорційного навантаження: бізнес може обґрунтувати, що виконання окремої вимоги створює надмірний тягар, але це потребує задокументованої оцінки, повідомлення наглядового органу й періодичного перегляду. Це процедура, а не безстрокове звільнення, і саме тут компанії найчастіше залишаються без доказів своєї позиції.

Хто відповідає за доступність на вебсайті?

Питання «яка людина відповідає за доступність на вебсайті?» на практиці має незручну відповідь: одну відповідальну особу тут виділити неможливо, а спроба призначити нею одного лише розробника гарантовано провалюється. Frontend-інженер не може виправити недостатню контрастність, затверджену в макеті, а дизайнер не відповідає за alt-текст, який контент-менеджер додасть через два місяці після релізу.

На практиці працює лише багатогранна модель контролю вимог, що має укорінитись в бізнес-культурі. Свою роль відіграють усі сторони:  

• Власник бізнесу та керівництво. Топ-менеджмент ухвалює accessibility policy, виділяє бюджет на аудит вебдоступності та ремедіацію, визначає цільовий рівень відповідності. Юридична відповідальність бізнесу за недоступний сервіс залишається на компанії, а не на підрядникові.

• UX/UI-дизайнер. Контраст, стани фокусу, розміри інтерактивних елементів, логіка порядку читання, текстові підписи замість самих лише іконок, доступні патерни для складних компонентів — усе це зона відповідальності фахівця з UX/UI.

• Frontend-розробник. Він відповідає за семантичний HTML, коректну структуру заголовків, керування фокусом у модальних вікнах, підтримку масштабування й клавіатури та коректні ARIA-атрибути. 

• QA-фахівець. На нього покладаються тест-кейси з accessibility testing у регресії: прохід сценаріїв лише з клавіатурою, перевірка зі скринрідером, контроль повідомлень про помилки у формах тощо.

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

• Accessibility Lead або accessibility coordinator. Окрема роль виправдана, коли продукт дуже масштабний, релізи частіші за щомісячні, є кілька команд або жорсткий регуляторний тиск. Профільний менеджер з вебдоступності інспектує єдині критерії на всіх рівнях, веде реєстр порушень і готує accessibility statement.

Щоб це не залишилося декларацією, відповідальність фіксують у процесах: вимоги доступності вносять до definition of done, до чеклиста code review, до критеріїв приймання макетів і до інструкції для редакторів контенту. Без цього accessibility compliance тримається на конкретних сумлінних людях і зникає, якщо вони йдуть з проєкту. 

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

Брак вебдоступності на сайті: юридичні ризики для бізнесу

Юридичні проблеми сайту рідко починаються одразу з суду. Типова послідовність інша: скарга користувача, публічний розголос, звернення до регулятора, і лише потім – судовий або адміністративний трек. Бізнес, що нехтує вимогами вебдоступності, ризикує зіткнутися з цілим спектром наслідків:

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

• Перевірки, приписи та санкції. У юрисдикціях, де діють вимоги, наглядові органи можуть вимагати план виправлень у стислі строки. Ремедіація «під тиском» майже завжди дорожча за планову.

• Судові суперечки та витрати на захист. Навіть виграна справа означає витрати на юристів, технічну експертизу й підготовку доказів того, що компанія системно працювала над доступністю.

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

• Ризики для тендерів і корпоративних закупівель. У публічних закупівлях відповідність WCAG або EN 301 549 може бути кваліфікаційною умовою: невідповідність просто знімає пропозицію з розгляду.

• Удар по репутації й втрата клієнтів. Недоступний checkout – це не абстрактна проблема, а незавершені замовлення й негативні відгуки, які довго живуть у пошуку.

Ще один ризик, який недооцінюють, – накопичений технічний борг. Якщо доступність не була закладена в дизайн-систему, виправлення після претензії доводиться робити швидко й точково, у режимі патчів. Такі патчі рідко узгоджені між собою, ускладнюють подальшу підтримку і майже гарантовано повертають частину порушень уже за кілька релізів.

Що перевіряють під час аудиту вебдоступності сайту

Accessibility audit – це не просто огляд чи тестування сайту, а структурована перевірка усіх ключових сценаріїв. Перед його початком фіксують scope: перелік шаблонів сторінок, користувацькі шляхи, версії браузерів і допоміжних технологій, цільовий стандарт. Без цього результати неможливо ані порівняти в часі, ані використати як доказ перед регуляторними органами. Практичний обсяг перевірки такий:

• Навігація з клавіатури. Чи можна пройти весь шлях – від меню до підтвердження замовлення – без мишки, чи видимий фокус, чи не «провалюється» він у приховані елементи, чи працює вихід із модальних вікон.

• Контрастність. Текст, кнопки, поля введення, стани помилки, елементи на зображеннях і градієнтах, а також неактивні, але значущі елементи.

• Alt-тексти та зображення. Змістовні описи для інформативної графіки, порожній alt для декоративної, текстові альтернативи для таблиць та схем.

• Структура й семантика. Один H1, послідовна ієрархія заголовків, семантичний HTML для списків, таблиць і landmark-регіонів, ARIA-атрибути без конфлікту з нативною семантикою.

• Доступні вебформи. Програмно пов'язані підписи, зрозумілі повідомлення про помилки з передаванням у assistive technologies, підказки щодо формату, збереження введених даних і доступна автентифікація.

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

• Сумісність зі скринрідерами. Перевірка щонайменше в двох комбінаціях, наприклад NVDA з Firefox та VoiceOver із Safari: результати можуть помітно різнятись.

• Відео й аудіо. Субтитри, транскрипції, керування плеєром із клавіатури, відсутність автозапуску звуку.

• Мобільна версія. Робота з увімкненими системними допоміжними технологіями, підтримка орієнтації екрана, розмір цілей натискання, коректне масштабування без горизонтального скролу.

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

Окремо перевіряють сторонні інтеграції: віджети чатів, платіжні iframe, банери згоди на cookie. Формально це чужий код, але для користувача й для регулятора це частина сервісу сайту.

WCAG 2.2 AA як орієнтир для зменшення accessibility-ризиків

Стандарти WCAG базуються на чотирьох принципах: 

• Perceivable – контент можна сприйняти будь-яким доступним каналом; 

• Operable – інтерфейсом можна керувати різними способами введення; 

• Understandable – поведінка системи передбачувана, а помилки зрозумілі; 

• Robust – розмітка коректно інтерпретується браузерами й допоміжними технологіями.

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

Автоматизованої перевірки недостатньо. Валідатори добре ловлять формальні дефекти — брак alt, низький контраст, порушення порядку заголовків, — але не оцінюють, чи має alt-текст сенс, чи логічний порядок фокуса, чи зрозуміле повідомлення про помилку, чи можна завершити оформлення замовлення скринрідером. Тому робоча схема перевірки на WCAG складається з трьох шарів: автоматизоване сканування в CI, ручний аудит критичних сценаріїв і тестування з реальними assistive technologies. Оптимальний підхід до аудиту — коли ручну частину виконує людина, яка щодня працює зі скринрідером або хоча б регулярно проходить сценарії лише клавіатурою: інакше перевірка зводиться до формального проходження чеклиста без розуміння реального користувацького досвіду.

Завершальний крок – accessibility statement на сайті. Варто вказати цільовий стандарт і рівень (наприклад, WCAG 2.2 AA), дату останньої оцінки, відомі обмеження та строки їх усунення, канал зворотного зв'язку для повідомлень про бар'єри. Публічна заява сама по собі не робить сайт доступним, але демонструє системну роботу — і саме вона стає першим документом, який затребують після скарги.

Як бізнесу організувати відповідність вимогам вебдоступності

Крок 1. Визначити нормативні вимоги. Зафіксуйте країни продажів, галузь, тип послуг і цільовий стандарт. Для бізнесу, орієнтованого на ЄС, це EN 301 549 та WCAG 2.2 AA як робочий рівень.

Крок 2. Провести accessibility-аудит сайту. Починати варто не з усього одразу, а з  критичних шляхів користувача: головна, каталог, картка товару, checkout, авторизація, форми контакту, особистий кабінет.

Крок 3. Пріоритезувати порушення. Спочатку слід виправити блокери, які унеможливлюють завершення сценарію, потім суттєві бар'єри, і лише далі – косметичні дефекти.

Крок 4. Внести вимоги до дизайн-системи. Доступні компоненти в UI-kit дають кумулятивний ефект: одне виправлення поширюється на всі сторінки, де використано компонент.

Крок 5. Перевірити контент і зовнішні модули. PDF-файли, презентації, відео, віджети, платіжні форми. Тут накопичується найбільше «нового боргу» після релізу.

Крок 6. Запровадити регулярний accessibility testing. Автоперевірки в pipeline, accessibility-регресія перед релізом, ручний прохід ключових сценаріїв після великих змін.

Крок 7. Призначити відповідальну особу й взятися за документування. Важливо вести реєстр порушень зі статусами, звіти аудитів, дати перевірок, оновлений accessibility statement. Документація — це і робочий інструмент, і доказова база у комунікації з регуляторами. 

Цей план навмисно поетапний. Спроба привести весь великий сайт до повної відповідності одним спринтом зазвичай закінчується або зривом строків, або формальним «закриттям» пунктів без реального ефекту. Значно результативніше зафіксувати цільовий рівень, закрити блокери на критичних сценаріях, а решту рухати уперед планово, разом із продуктовим беклогом.

Вебдоступність під час розробки та редизайну: як уникнути дорогих виправлень

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

Що варто закласти:

• Технічне завдання. Пряме зазначення цільового стандарту та рівня доступності, вимог до клавіатурної навігації, контрасту, форм, повідомлень про помилки, мультимедіа тощо.

• Дизайн. Токени контрасту й видимого фокуса в дизайн-системі, доступні патерни для модальних вікон, табів, аккордеонів, кастомних селектів і датапікерів.

• Розробка. Пріоритет нативних елементів над кастомними, лінтери доступності в IDE та CI, ARIA лише як доповнення до семантики.

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

• Контроль після релізу. Інструкція для редакторів та контент-менеджерів, обов'язковий alt при завантаженні зображень у CMS, повторна перевірка після оновлення функціоналу та підключення нових інтеграцій.

Редизайн – найдешевша точка входу в accessibility compliance, бо компоненти й контент однаково переробляються. Якщо ж проєкт уже в активній розробці, мінімальний крок – додати доступність до критеріїв приймання нових компонентів, аби не нарощувати технічний борг. 

FAQ