Доступність сайту у 2026 році: WCAG 2.2, вимоги EAA та практичний чекліст

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

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

Якщо потрібно оцінити не лише accessibility, а весь шлях до заявки чи покупки, почніть з UX-аудиту сайту. У цьому матеріалі зосередимося саме на доступності.

Коротка відповідь

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

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

Що таке WCAG 2.2

WCAG 2.2 є рекомендацією W3C для доступності вебконтенту. Вона побудована на чотирьох принципах:

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

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

Що додала WCAG 2.2

WCAG 2.2 додала дев’ять критеріїв до попередньої версії. Для більшості бізнес-сайтів особливо помітні такі зміни:

• фокус не повинен повністю ховатися за липким хедером, cookie-банером або модальним вікном;
• видимий індикатор фокусу має бути достатньо помітним;
• ціль натискання на рівні AA повинна мати щонайменше 24 на 24 CSS-пікселі або достатній простір навколо;
• функція, доступна перетягуванням, повинна мати альтернативу без drag gesture;
• довідка, контакти й способи підтримки мають з’являтися послідовно;
• система не повинна змушувати повторно вводити вже надані дані без причини;
• автентифікація не повинна залежати лише від когнітивного тесту, який людина мусить розв’язати або запам’ятати.

Ці критерії добре показують напрям розвитку стандарту. Доступність стосується не тільки кольору й alt. Вона охоплює реальну поведінку інтерфейсу.

EAA та сайти бізнесу

European Accessibility Act охоплює визначені товари й послуги в ЄС, серед яких є електронна комерція, банківські послуги, електронні книги, частина транспортних і комунікаційних сервісів. Конкретні обов’язки залежать від країни, моделі роботи, типу послуги та передбачених винятків.

У вересні 2026 року опублікували EN 301 549 v4.1.1 на базі WCAG 2.2. На дату підготовки матеріалу нова версія ще не стала гармонізованим стандартом, офіційно процитованим у Official Journal of the European Union. Для юридичної оцінки потрібно перевіряти чинну національну реалізацію EAA та актуальний гармонізований стандарт.

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

Практичний чекліст доступності

1. Семантична структура

Використовуйте один змістовний H1, послідовні H2 і H3, справжні списки, таблиці лише для табличних даних і коректні landmark-області. Кнопка має бути кнопкою, посилання має вести на іншу адресу.

Не замінюйте семантику набором div з обробником кліку. Екранний читач повинен розуміти роль, назву і стан елемента без візуальних підказок.

2. Клавіатурна навігація

Відкладіть мишу й пройдіть сторінку клавішами Tab, Shift+Tab, Enter, Space та Escape. Фокус має рухатися в логічному порядку. Меню, фільтр, слайдер, модальне вікно, форма й кошик повинні працювати без курсора.

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

3. Видимий фокус

Не вимикайте outline без рівноцінної заміни. Стан фокусу має відрізнятися від hover, бути видимим на світлому й темному фоні та не ховатися під sticky-елементами.

Перевіряйте фокус після відкриття і закриття модального вікна. Він має перейти всередину діалогу, а після закриття повернутися до кнопки, яка його відкрила.

4. Контраст і колір

Для звичайного тексту орієнтуйтеся на контраст 4,5:1, для великого тексту на 3:1. Контролам, межам полів і важливим графічним станам також потрібен достатній контраст.

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

5. Масштабування й reflow

Збільште сторінку до 200%. Текст не повинен обрізатися, кнопки не мають перекривати одна одну, а горизонтальний скрол не повинен з’являтися для звичайного контенту на вузькому екрані.

Не блокуйте масштабування через viewport. Людина сама вирішує, який розмір їй потрібен.

6. Зображення, іконки та відео

Змістовне зображення потребує короткого alt, який передає його функцію в контексті. Декоративному зображенню достатньо порожнього alt. Не повторюйте у підписі й alt однаковий довгий текст.

Відео з мовленням потребує субтитрів. Для важливого візуального змісту підготуйте опис або текстову альтернативу. Не запускайте звук автоматично.

7. Форми й повідомлення про помилки

Кожне поле має видимий label. Placeholder не замінює підпис, бо зникає після введення. Пояснюйте формат до помилки, а не після кількох невдалих спроб.

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

8. Меню, модальні вікна й каруселі

Компонент повинен повідомляти свій стан через aria-expanded, aria-current або іншу доречну семантику. Escape закриває діалог. Фон за модальним вікном не повинен залишатися доступним для фокусу.

Автоматичну карусель потрібно зупинити. Кнопки наступного і попереднього слайда мають зрозумілі назви, а перемикання не повинно красти фокус.

9. Мобільні цілі й жести

Робіть кнопки достатньо великими та залишайте відстань між сусідніми діями. Не вимагайте лише свайпу, перетягування або складного жесту. Додайте звичайні кнопки.

Мобільна клавіатура не повинна закривати активне поле, CTA або повідомлення про помилку.

10. Вхід і підтвердження особи

Дозвольте вставляти пароль і використовувати менеджер паролів. Не блокуйте автозаповнення без реальної потреби. Якщо CAPTCHA створює бар’єр, запропонуйте доступну альтернативу.

Код підтвердження з листа або SMS краще приймати через автозаповнення та вставлення. Не змушуйте людину запам’ятовувати складну послідовність.

11. PDF і завантажувані документи

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

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

12. Швидкість і стабільність

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

Перевірте 12 способів прискорити сайт і запустіть власний домен через інструмент перевірки швидкості. Performance не замінює accessibility, але підтримує її.

Як провести аудит

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

Для кожного сценарію використайте чотири шари:

1. автоматичний сканер для очевидних помилок семантики, контрасту й назв;
2. ручний прохід клавіатурою;
3. перевірка екранним читачем;
4. тест на реальному телефоні зі збільшенням і системними налаштуваннями.

Записуйте проблему у форматі: сторінка, елемент, критерій, кроки відтворення, вплив, скриншот, рекомендація, відповідальний і статус.

Автоматичні інструменти не дають гарантії

Lighthouse, axe, WAVE та інші сканери швидко знаходять відсутні назви, частину проблем контрасту й помилки структури. Вони не визначать, чи зрозумілий текст кнопки, чи логічний порядок фокусу, чи доречний alt і чи реально завершити оплату.

Зелений звіт означає лише відсутність знайдених автоматично помилок. Він не підтверджує повну відповідність WCAG.

Як визначити пріоритет

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

Як закласти доступність у новий сайт

Зафіксуйте вимоги ще до макетів: цільовий рівень WCAG, критичні сценарії, підтримувані технології, правила контрасту, клавіатури, фокусу, форм, документів і приймання.

Структуру такого документа можна взяти з гайда про технічне завдання на розробку сайту. Компоненти перевіряйте в дизайн-системі, а не виправляйте одну кнопку на сорока сторінках.

Для чинного проєкту часто достатньо поетапного редизайну критичних шаблонів. Послуга UI/UX-дизайну BB STUDIO охоплює структуру, адаптивні макети та стани компонентів, а розробка сайтів дозволяє реалізувати ці вимоги в коді.

План на 30 днів

Дні 1-5

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

Дні 6-15

• виправити семантику й назви контролів;
• відновити видимий фокус;
• виправити контраст і стани помилок;
• налаштувати модальні вікна та меню;
• перевірити зміни екранним читачем.

Дні 16-25

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

Дні 26-30

• повторити аудит критичних сценаріїв;
• зафіксувати залишкові проблеми;
• додати accessibility до критеріїв приймання;
• призначити відповідальних за контент і компоненти;
• погодити регулярну перевірку після релізів.

Типові помилки

1. Поставити віджет-оверлей і вважати проблему закритою.
2. Орієнтуватися лише на автоматичний бал.
3. Прибрати стандартний outline без заміни.
4. Використовувати placeholder замість label.
5. Додавати ARIA замість виправлення неправильної HTML-семантики.
6. Перевіряти тільки головну сторінку.
7. Ігнорувати checkout, кабінет і PDF.
8. Вимагати лише drag, swipe або складний жест.
9. Виправляти дрібниці раніше за блокери.
10. Не тестувати повторно після оновлення.

Висновок

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

Почніть із дій, які приносять бізнесу результат: пошуку, заявки, кошика, оплати й входу. Якщо потрібен аудит або план виправлень, напишіть BB STUDIO.