Доступність сайту: що виправляти першим і чому віджет цього не вирішить

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

КОРОТКО

Що виправляти першим

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

Причину такого порядку видно в одному дослідженні. WebAIM просканував головні сторінки мільйона найвідвідуваніших сайтів: автоматично виявлювані порушення WCAG знайшлися на 95,9% з них, у середньому 56,1 помилки на сторінку, а шість типів помилок дали 96% усього знайденого. Це низький контраст, відсутній альтернативний текст і підписи до полів, порожні посилання й кнопки, а також не вказана мова сторінки (WebAIM, дані лютого 2026 року). Більшість таких помилок живе у спільних шаблонах і стилях, тому одна правка прибирає ту саму помилку з тисяч сторінок.

У статті Скільки тестування потрібно сайту або застосунку перед запуском? доступності присвячено один розділ у межах плану запуску. Тут розібрано саму роботу, для власників, CTO і розробників, яким вони її передадуть. Це технічний огляд, а не юридична консультація: із претензією чи питанням за договором звертайтеся до юриста на вашому ринку.

Сканер підкаже, звідки почати, але ніколи не скаже, що ви закінчили.

ЗАКОН

Що вимагають в Україні, ЄС і США

Україна сьогодні. Постанова Кабінету Міністрів № 757 від 21 липня 2023 року зобов'язує міністерства, інші центральні органи виконавчої влади, підприємства у сфері їхнього управління й обласні адміністрації дотримуватися стандарту ДСТУ EN 301 549:2022 на своїх сайтах і в системах. Для органів місцевого самоврядування вона має рекомендаційний характер. Приватний бізнес у її тексті не згадано.

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

Продажі в ЄС. Європейський акт про доступність поширюється на послуги електронної торгівлі для споживачів, надані після 28 червня 2025 року. Виняток є для мікропідприємств у сфері послуг: менше 10 осіб і не більше 2 млн євро обороту чи балансу. Суди вже застосовують ці правила. 4 червня 2026 року суд у Кані ухвалив тимчасове рішення проти Carrefour: власного аудиту з результатом 71,21% відповідності не вистачило, а сайт, як зазначив суд, не може бути доступним лише частково. Серед бар'єрів він назвав альтернативний текст, контраст, погано підписані посилання, несумісність із допоміжними технологіями і неправильну семантику HTML. На виправлення дано шість місяців, далі штраф 500 євро на день (Taylor Wessing, червень 2026 року).

Продажі в США. Розділ III закону ADA забороняє дискримінацію з боку бізнесів, відкритих для публіки. Міністерство юстиції зазначає, що запропоноване онлайн теж має бути доступним, і називає бар'єри: поганий контраст, зображення без тексту, поля без підписів, навігація лише мишею (ADA.gov, березень 2022 року). Юристи Seyfarth Shaw нарахували 3 117 позовів про доступність сайтів у федеральних судах за 2025 рік, на 27% більше, ніж роком раніше, причому справи в судах штатів сюди не входять. UsableNet, постачальник таких послуг, рахує федеральні суди й суди штатів разом і прогнозує близько 6 176 позовів за 2026 рік, 79% з них проти електронної торгівлі (UsableNet, липень 2026 року). У нашій роботі робоча мірка лишається одна: WCAG 2.2 рівня AA, чинна рекомендація W3C від 12 грудня 2024 року.

ПОРЯДОК

У якому порядку ми виправляємо

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

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

Решта чекає, якщо не лежить на грошовому шляху. Для записаного відео потрібні субтитри (1.2.2, рівень A): якщо відео і є вашим способом продавати, підніміть це вище. Текст має працювати за збільшення до 200% (1.4.4, рівень AA). Важкій анімації потрібен перемикач: наш власний 3D-екран, про який розповідає стаття 3D на живому сайті: наш експеримент із three.js і що побачив Google, замінюється легкою версією, якщо відвідувач просить зменшити рух.

НЕДОРОГІ ПРАВКИ

Мова, назви, контраст, текст зображень

Мова. Один атрибут в елементі html повідомляє допоміжним технологіям, яким голосом читати. На багатомовному сайті кожна версія має свій атрибут, а спільний шаблон з одним зашитим значенням псує всі інші версії. Українська версія має вказувати код uk, а не ua (стандарт ISO 639), навіть якщо в адресі стоїть /ua/. Детальніше про такі сайти у статті Дизайн багатомовного сайту: що змінюється, крім перекладу.

Назви. Іконка кошика чи стрілка слайдера часто взагалі без тексту, і читалка вимовляє «кнопка» або зачитує адресу файлу. Вирішує прихований текст або aria-label. Заодно використовуйте справжні елементи HTML: справжня кнопка отримує роботу з клавіатури від браузера, ролі ARIA її не додають, а посібник W3C починається з попередження, що поганий ARIA гірший за його відсутність. WebAIM знайшов 59,1 помилки на сторінках з ARIA і 42 на сторінках без нього, хоча такі сторінки ще й складніші, тож цей розрив не доводить провини ARIA.

Контраст. Звичайному тексту потрібно щонайменше 4,5:1 до фону, великому 3:1, кнопкам, межам полів і значущим іконкам теж 3:1 (1.4.3 і 1.4.11). Світло-сірий для дрібного шрифту зазвичай заданий однією змінною, яка стоїть у сотнях місць. Фірмовий колір, що не проходить на білому, можна залишити акцентом, а для тексту взяти темніший відтінок. Це змінює зовнішній вигляд, тому рішення за дизайнером. Контраст люди відчувають, навіть не називаючи його, про що ми писали у статті Дизайн, який не відчуваєш: чому найкращий дизайн зникає.

Текст зображень. Опишіть, яку роботу зображення виконує на цій сторінці. На картці товару напишіть те, що потрібно покупцеві («чорна шкіряна сумка, вигляд спереду»), у кейсі те, що зображення доводить. Суто декоративним зображенням ставте порожній alt, щоб їх пропускали. Зробіть поле обов'язковим в адмінці для кожної мови, інакше помилка повернеться з наступним завантаженням.

Один колірний токен може закрити сотні помилок контрасту відразу.

ФОРМИ І КЛАВІАТУРА

Форми, клавіатура, фокус і вхід

Підписи й помилки. Кожному полю потрібен видимий підпис, пов'язаний із ним у коді. Посібник W3C із форм прямо каже, що плейсхолдер його не замінює, і екранні читалки не вважають його підписом. Помилку треба назвати текстом (3.3.1, рівень A), а не лише червоною рамкою, і підказати рішення, якщо воно відоме (3.3.3, рівень AA): «Введіть дату у форматі 31.12.2026», а не «Неправильне введення». Поля з особистими даними мають повідомляти своє призначення (1.3.5, рівень AA), щоб браузер міг їх заповнити, а це допомагає кожному покупцеві з телефона.

Клавіатура. Усе, що можна зробити мишею, має працювати з клавіатури, і фокус не має застрягати (2.1.1 і 2.1.2, рівень A). Тут потрібні справжні години фронтенду, бо збої сидять у власних компонентах: меню, що відкривається лише за наведення, фільтр з елементів div, вибір розміру, календар, висувний кошик. В опитуванні користувачів екранних читалок WebAIM меню, вкладки й діалоги, які поводяться неочікувано, посіли друге місце серед проблем (1 539 відповідей, грудень 2023 і січень 2024 року). Для спливних вікон шаблон діалогу W3C вміщується в одне завдання: під час відкриття фокус переходить усередину, Tab лишається всередині, Escape закриває вікно, фокус повертається на елемент, який його відкрив. За цими чотирма рядками перевірте банери cookie, вікна підписки й чати.

Фокус і розміри. Фокус має бути видимим (2.4.7, рівень AA). Звичайна причина збою в одному рядку скидання стилів, outline: none, замість якого нічого не поставили; стиль :focus-visible у вашому фірмовому кольорі вирішує завдання і нічого не змінює для тих, хто працює мишею. У WCAG 2.2 додалася вимога, щоб ваш власний контент не закривав елемент у фокусі повністю (2.4.11, рівень AA), і W3C називає типовими винуватцями закріплені шапки й банери cookie; більшу частину вирішує CSS scroll-padding. Цілі для натискання мають бути щонайменше 24 на 24 CSS-пікселі або мати достатньо місця навколо (2.5.8, рівень AA). Зазвичай страждають кнопки закриття, пагінація й перемикачі мови, а відступи виправляють це, не змінюючи дизайну.

Вхід. Критерій доступної автентифікації (3.3.8, рівень AA) означає: жодних перевірок пам'яті й головоломок без альтернативи. Пояснення W3C цілком практичне: заборона вставлення в поле пароля чи блокування менеджера паролів порушують критерій, а посилання на пошту входить до переліку способів його виконати. CAPTCHA в тому самому опитуванні WebAIM стала найбільшою проблемою із помітним відривом. Дані, уже зазначені в цьому самому процесі, не мають вводитися знову (3.3.7, рівень A), що до того ж просто гарний дизайн оформлення замовлення.

СКАНЕРИ

Що сканер знаходить і що пропускає

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

Британська Government Digital Service у 2017 році зробила сторінку зі 143 бар'єрами й перевірила її десятьма інструментами. Усі десять разом пропустили 29%, а найкращий із них знайшов 41%. Deque, яка робить axe і продає такі інструменти, розібрала майже 300 000 проблем із власних аудитів і повідомляє, що правила axe-core знайшли 57,38% з них, причому автоматичні знахідки дали лише 16 із 50 критеріїв рівня AA у WCAG 2.1. Правильне і те, і те: кілька частих видів помилок повторюються тисячі разів, тому сканер ловить більшу частину обсягу й малу частину видів. З Lighthouse та сама історія. Його оцінка доступності складається як зважене середнє перевірок «пройшов чи ні», а ручні перевірки до неї не входять (Chrome for Developers, листопад 2026 року), тож 100 балів означають лише одне: автоматичні правила нічого не знайшли.

Сканер усе одно потрібен. Запускайте axe або Lighthouse у збірці як сигналізацію, щоб реліз із новими помилками зупинявся до виходу, поруч із ручними перевірками в плані QA і тестування.

ОВЕРЛЕЇ

Чому віджет-оверлей не вирішує завдання

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

У квітні 2025 року Федеральна торгова комісія США затвердила остаточне рішення, за яким accessiBe має сплатити 1 млн доларів. Компанія заявляла, що її плагін accessWidget може зробити будь-який сайт відповідним до WCAG, а в скарзі ці заяви названо неправдивими, оманливими або необґрунтованими. Рішення забороняє такі заяви без доказів. Читати його треба точно: йдеться про рекламу однієї компанії, віджетів воно не забороняє і правового становища сайту з віджетом не визначає.

Головна проблема в самому механізмі: скрипт працює поверх сторінки, а ваші шаблони лишаються такими самими. Overlay Fact Sheet, який підписали фахівці з доступності, зокрема автори специфікацій WCAG, ARIA і HTML, пояснює чому: відповідність означає виконання всіх вимог стандарту, оверлеї не можуть виправити все і не торкаються PDF, canvas, SVG і медіафайлів. Там само наведено опитування практиків WebAIM, де 72% респондентів з інвалідністю оцінили такі інструменти як зовсім або не дуже ефективні.

Захистом від позовів він теж не слугує. UsableNet, яка сама продає послуги з доступності, повідомляє, що приблизно у 20% компаній, які отримали позов у 2026 році, стояв віджет або оверлей (липень 2026 року), а суд у справі Carrefour оцінював сайт за кожним критерієм окремо. Ці гроші краще витратити на спільні шаблони, де вони прибирають помилки назовсім.

Віджет змінює сторінку після завантаження. Шаблон лишається зламаним.

20 ХВИЛИН

Тест на 20 хвилин для керівника

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

1. Від 0 до 7 хвилини: лише клавіатура. Відкладіть мишу й працюйте клавішами Tab, Shift+Tab, Enter, пробіл, стрілки та Escape. Чи завжди видно, де ви перебуваєте? Чи вдається відкрити меню й вибрати фільтр? Чи випускає вас спливне вікно?
2. Від 7 до 9 хвилини: збільшення. Поставте у браузері 200%. Чи не обрізається текст, чи можна дістатися до кнопки?
3. Від 9 до 16 хвилини: екранна читалка. На Mac натисніть Command-F5 для VoiceOver, потім VO-U для ротора зі списками заголовків і посилань. У Windows натисніть Ctrl + Windows + Enter для Екранного диктора, потім двічі клавішу диктора + S, щоб побачити заголовки, посилання й орієнтири. На iPhone відкрийте Параметри, Доступність, VoiceOver. Чи читаються заголовки як план? Чи кажуть посилання, куди ведуть? Чи повідомляє форма, що це за поле і що пішло не так?
4. Від 16 до 18 хвилини: сканер. Запустіть Lighthouse із Chrome DevTools на сторінці з формою й запишіть, що не пройшло.
5. Від 18 до 20 хвилини: дерево. У DevTools відкрийте Elements, потім Accessibility, потім Show accessibility tree. Відкрийте своє спливне вікно. Чи на місці ціна й головна кнопка?

Не пропускайте телефон: 91,3% опитаних користувачів екранних читалок працюють із ними і на мобільному пристрої (WebAIM, грудень 2023 і січень 2024 року; опитування неконтрольоване, тож це орієнтир).

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

ТЕ САМЕ ДЕРЕВО

Те саме дерево читають ШІ-агенти

Браузер будує з кожної сторінки дерево доступності, підмножину DOM із тим, що важливо для допоміжних технологій, і екранні читалки спираються саме на нього (Chrome for Developers, листопад 2026 року). Тепер його читають і програми: сервер Playwright MCP від Microsoft, через який ШІ-моделі керують браузером, прямо зазначає, що працює з деревом доступності, а не з пікселями.

Результат ми бачили самі. Про це стаття Ми відправили ШІ-агента по покупки в 15 американських інтернет-магазинів. Ось де він здався: у жовтні 2026 року у двох магазинах вікно підписки залишало в дереві доступності лише iframe, і агент, що читає сторінку через це дерево, не бачив ціни, розмірів і кнопки, доки вікно не закриється.

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

ЦІНА І ПІДТРИМКА

Скільки це коштує і як утримати результат

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

Цю роботу в нас можна замовити трьома способами, усі ціни опубліковано:

• Дізнатися, де ви перебуваєте: Юзабіліті аудит, від $1 500, триває від одного до двох тижнів і перевіряє основи WCAG 2.2 на шляхах, які приносять гроші, разом із даними про поведінку та швидкістю. Це огляд основ, а не аудит відповідності й не юридична консультація, а виправлення оцінюються окремо, коли стануть відомі.
• Перевіряти кожен реліз: QA і тестування, від $30 на годину, із цими перевірками в тест-плані. Платні інструменти оплачуються окремо, а виправлення знайденого це робота розробників.
• Утримувати результат: Підтримка та обслуговування сайтів, від $1 000 на місяць, де невеликі правки входять у години тарифу.

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

FAQ

Джерела

• Кабінет Міністрів України: постанова № 757 від 21 липня 2023 року
• Кабінет Міністрів України, Мінцифри: законопроєкт про цифрову доступність
• WebAIM: The WebAIM Million 2026
• W3C: WCAG 2.2
• FTC: Final order against accessiBe