Роками вебдоступність вважали чимось бажаним, але необов'язковим. З 28 червня 2025 року вона стала юридичною вимогою для широкого кола цифрових продуктів і послуг, що продаються споживачам у ЄС, — відповідно до European Accessibility Act. Водночас стан вебу поганий: у 2026 році автоматичні тести знайшли порушення доступності на 95,9% головних сторінок із мільйона найпопулярніших сайтів. У гайді пояснюємо, кого стосується EAA, що змінилося у WCAG 2.2, які проблеми трапляються найчастіше і як зробити наявний продукт на React чи Next.js доступним без переписування.

European Accessibility Act коротко

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

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

Ключові моменти для IT-компаній:

  • Мікропідприємства, що надають послуги, звільнені — компанії з менш ніж 10 працівниками і річним оборотом чи балансом не більше €2 млн.
  • Йдеться про B2C. Суто внутрішні інструменти та B2B-системи загалом поза EAA, хоча для сайтів публічного сектору діють окремі правила Директиви про вебдоступність.
  • Компанії поза ЄС теж підпадають, якщо продають споживачам у ЄС.
  • Технічний орієнтир — гармонізований стандарт EN 301 549, що включає критерії успіху WCAG рівня AA. Практична ціль — WCAG 2.2 AA.

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

WCAG 2.2: що нового

WCAG 2.2 став рекомендацією W3C 5 жовтня 2023 року і додав дев'ять критеріїв успіху; застарілий критерій 4.1.1 Parsing вилучено (W3C: What's new in WCAG 2.2; WCAG 2.2). Критерії рівнів A і AA, яким має відповідати більшість продуктів:

Критерій Рівень Що вимагає
2.4.11 Focus Not Obscured (Minimum) AA Елемент у фокусі не повністю закритий липкими шапками, банерами cookies чи чат-віджетами
2.5.7 Dragging Movements AA Усе, що робиться перетягуванням, працює й одним кліком чи дотиком
2.5.8 Target Size (Minimum) AA Інтерактивні цілі щонайменше 24×24 CSS-пікселі або мають достатні відступи
3.2.6 Consistent Help A Посилання на допомогу чи контакти розташовані в тому самому місці на різних сторінках
3.3.7 Redundant Entry A Користувачу не доводиться повторно вводити вже надану в тому ж процесі інформацію
3.3.8 Accessible Authentication (Minimum) AA Вхід не вимагає когнітивного тесту (запам'ятати, переписати) без альтернативи; дозвольте менеджери паролів і вставлення

Найпоширеніші помилки

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

  1. Низький контраст тексту — 83,9% сторінок
  2. Відсутній альтернативний текст зображень — 53,1%
  3. Поля форм без підписів — 51%
  4. Порожні посилання — 46,3%
  5. Порожні кнопки — 30,6%
  6. Не вказана мова документа — 13,5%

Хороша новина: їх дешево виправити і легко тестувати автоматично.

Як виправити доступність у React і Next.js

Спершу семантика

Використовуйте нативні елементи: <button> для дій, <a href> для навігації, <label> для полів, заголовки по порядку. <div onClick> невидимий для користувачів клавіатури й скрінрідерів, якщо ви не відтворите все, що кнопка вже вміє.

// Погано: кнопка-іконка без доступного імені, недоступна з клавіатури
<div className="icon" onClick={openCart}><CartIcon /></div>

// Добре: нативна кнопка з доступним іменем
<button type="button" onClick={openCart} aria-label="Відкрити кошик, 3 товари">
  <CartIcon aria-hidden="true" />
</button>

Форми

Кожне поле потребує видимого підпису, пов'язаного через htmlFor, помилок, описаних текстом і озвучених, та позначених обов'язкових полів. Не використовуйте placeholder замість підпису. Підтримуйте атрибути autocomplete, щоб браузери й менеджери паролів могли заповнювати поля, — це також допомагає з 3.3.7 і 3.3.8.

Клавіатура і фокус

  • Кожен інтерактивний елемент має бути доступний і керований з клавіатури в логічному порядку.
  • Ніколи не прибирайте рамки фокусу без видимої заміни.
  • Діалоги утримують фокус, поки відкриті, і повертають його після закриття; бібліотеки на кшталт Radix UI роблять це коректно з коробки.
  • Враховуйте липкі шапки й банери, щоб елементи у фокусі не перекривалися (2.4.11), наприклад через scroll-padding-top.

Зображення, колір і анімація

  • Змістовні зображення отримують описовий alt, декоративні — alt="".
  • Контраст тексту щонайменше 4,5:1, для великого тексту 3:1. Перевірте токени дизайн-системи один раз, а не кожну сторінку.
  • Враховуйте prefers-reduced-motion для анімацій.

Мова і структура

Встановлюйте lang на елементі <html> і на фрагментах іншою мовою. На багатомовних сайтах кожна локалізована сторінка має оголошувати власну мову — це допомагає і скрінрідерам, і пошуковим системам, як ми писали у статті Технічне SEO для Next.js.

Тестування: автоматичне плюс ручне

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

  • Автоматично: axe-core в unit- чи E2E-тестах, аудити доступності Lighthouse у CI, лінтинг eslint-plugin-jsx-a11y.
  • Вручну: проходження ключових сценаріїв лише з клавіатурою (пошук, сторінка товару, кошик, оформлення, вхід), перевірка скрінрідерами NVDA чи VoiceOver, масштабування до 200% і 400%.
  • З користувачами: залучайте людей з інвалідністю до юзабіліті-тестування критичних сценаріїв.
// Playwright + axe: білд падає на серйозних порушеннях у checkout
import AxeBuilder from "@axe-core/playwright"

test("checkout has no serious a11y violations", async ({ page }) => {
  await page.goto("/checkout")
  const results = await new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa", "wcag22aa"]).analyze()
  expect(results.violations.filter((v) => ["serious", "critical"].includes(v.impact!))).toEqual([])
})

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

  1. Обсяг: перелічіть споживчі сценарії, що підпадають під EAA, і країни, які ви обслуговуєте.
  2. Аудит: автоматичне сканування всіх шаблонів плюс ручне тестування п'яти головних шляхів користувача.
  3. Спершу виправте дизайн-систему: кольорові токени, стилі фокусу, компоненти кнопок і форм. Одне виправлення поширюється всюди.
  4. Виправте шаблони й сценарії в порядку трафіку і виручки.
  5. Опублікуйте заяву про доступність з описом відповідності, відомими обмеженнями і контактом для зворотного зв'язку.
  6. Запобігайте регресіям: автоматичні перевірки в CI і доступність у definition of done.

Робота з доступністю часто покращує продуктивність і конверсію: легша семантична розмітка допомагає Core Web Vitals, див. Core Web Vitals у 2026 році. Якщо ваш продукт має AI-функції для користувачів у ЄС, AI Act додає власні обов'язки прозорості — про це у статті EU AI Act для IT-компаній.

Що написати в заяві про доступність

Заява про доступність очікується відповідно до EAA і підвищує довіру користувачів. Пишіть коротко й чесно:

  • Сфера дії: які сайти й застосунки вона охоплює.
  • Стандарт і статус: наприклад, «частково відповідає WCAG 2.2 рівня AA».
  • Відомі обмеження: що поки недоступне, чому і коли плануєте виправити.
  • Альтернативи: як користувач може отримати ту саму послугу іншим способом, наприклад телефоном чи email.
  • Контакт для зворотного зв'язку: email чи форма з очікуваним часом відповіді.
  • Дата останнього перегляду.

FAQ

Чи стосується EAA нашого B2B SaaS? Загалом ні, якщо він продається лише бізнесу. Споживчі частини, як-от checkout, яким користуються споживачі, можуть підпадати під дію акта. Уточнюйте з юристом.

Достатньо WCAG 2.1 чи потрібен 2.2? EN 301 549 наразі посилається на WCAG 2.1 AA, але WCAG 2.2 зворотно сумісний і є чинним стандартом W3C. Ціль 2.2 AA робить роботу стійкою до майбутніх змін.

Чи може віджет-«оверлей» доступності забезпечити відповідність? Ні. Оверлеї не виправляють проблем у коді й часто заважають допоміжним технологіям.

Скільки часу займають виправлення? Для типового магазину виправлення дизайн-системи та основних сценаріїв займає чотири-вісім тижнів; постійне тестування підтримує відповідність.

Хто на практиці контролює виконання EAA? Національні органи ринкового нагляду в кожній державі-члені. Багато з них також приймають скарги від користувачів і споживчих організацій, тож недоступний checkout може стати приводом для перевірки.

Чи стосується це PDF і документів? Так, документи, що є частиною послуги, — рахунки, договори, підтвердження бронювань — теж мають бути доступними.

Джерела

  1. Європейський Союз. Директива (ЄС) 2019/882 — European Accessibility Act.
  2. Європейська комісія. European Accessibility Act.
  3. W3C. Web Content Accessibility Guidelines (WCAG) 2.2 і What's new in WCAG 2.2.
  4. WebAIM (2026). The WebAIM Million.