Доступність сайту (a11y) і WCAG 2.2: як перетворити це на конкурентну перевагу

Запити про доступність сайтів і WCAG зростають щороку. Причини три: юридичні вимоги (European Accessibility Act набирає чинності у червні 2025), ширша аудиторія (15–20 % людей мають ту чи іншу форму інвалідності) і банальна зручність — доступний сайт зручніший для всіх. У цій статті розбираємо, що таке a11y без маркетингового шуму: мінімальний стандарт, компоненти, які ламаються найчастіше, European Accessibility Act, тестування, Definition of Done і повний чекліст перед релізом.

01 Коротко: що важливо знати

• a11y (accessibility) — це не «окремий проєкт». Це частина якості, як безпека чи швидкість. Її вбудовують у процес, а не «прикручують перед релізом».
• WCAG 2.2 рівня AA — мінімальний стандарт, на який орієнтуються закони ЄС, Великобританії, США, Канади й Австралії.
• Що ламається найчастіше: кастомні селекти, модалки без focus trap, слайдери без aria, іконки-кнопки без aria-label, форми без підписів, анімації без prefers-reduced-motion.
• European Accessibility Act (EAA) з червня 2025 поширюється на e-commerce, банкінг, транспорт і телеком у всьому ЄС. Штрафи залежать від країни, але репутаційний ризик однаковий.
• Бізнес-ефект реальний: краще SEO через семантику, менше відмов у формах, ширша аудиторія, сильніший бренд відповідальності.
• Включіть a11y у Definition of Done (DoD) перед кожним релізом — інакше «поправимо потім» перетворюється на технічний борг, який не поправляють ніколи.

Зміст

02 Що таке a11y і навіщо це бізнесу

a11y — скорочення від «accessibility» (a, 11 літер, y). Це практика проєктування й розробки сайтів так, щоб ними могли користуватися люди з різними можливостями: незрячі та слабозорі, глухі, люди з моторними порушеннями, когнітивними відмінностями, тимчасовими травмами (зламана рука, яскраве сонце на екрані).

Чому це стосується бізнесу:

• 15–20 % населення мають ту чи іншу форму інвалідності (дані ВООЗ). Це не «маленька ніша» — це кожен п'ятий потенційний клієнт.
• Ситуативні обмеження є у всіх: одна рука зайнята пакетом, шумне кафе без навушників, розбитий екран із зоною, що не реагує на тап.
• Юридичні вимоги: European Accessibility Act, ADA (США), EN 301 549 (ЄС), AODA (Канада). Ігнорування ризикує позовами, штрафами й репутаційними збитками.
• SEO-бонус: семантична розмітка, правильні заголовки, alt-тексти, текстові альтернативи — усе це покращує індексацію й ранжування.
• Конверсія: зрозумілі форми, чіткі CTA, логічна навігація — це не «для інвалідів», це зручніший сайт для всіх.

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

03 WCAG 2.2: структура і рівні

WCAG (Web Content Accessibility Guidelines) — стандарт W3C, який описує, яким має бути доступний вебконтент. Версія 2.2 опублікована у жовтні 2023, і саме на неї посилаються сучасні закони.

Чотири принципи (POUR):

Три рівні відповідності:

Що нового у WCAG 2.2 порівняно з 2.1:

• 2.4.11 Focus Not Obscured (Minimum) — фокус не має бути повністю прихований під sticky-хедером чи модалкою.
• 2.4.12 Focus Not Obscured (Enhanced) — фокус повністю видимий (AAA).
• 2.4.13 Focus Appearance — мінімальний розмір і контраст індикатора фокусу (AAA).
• 2.5.7 Dragging Movements — дія drag має мати альтернативу (кнопку, тап) (AA).
• 2.5.8 Target Size (Minimum) — мінімальний розмір тапу 24×24 px (AA).
• 3.2.6 Consistent Help — допомога (чат, FAQ, телефон) на кожній сторінці в одному місці (A).
• 3.3.7 Redundant Entry — не просити повторно ту саму інформацію (A).
• 3.3.8 Accessible Authentication (Minimum) — автентифікація без когнітивних тестів (AA).
• 3.3.9 Accessible Authentication (Enhanced) — жодних паззлів, розпізнавання об'єктів (AAA).

Практична порада: орієнтуйтесь на WCAG 2.2 AA як базу. Окремі AAA-критерії (фокус, автентифікація) варто впроваджувати одразу — вони значно покращують UX.

04 Мінімальний стандарт: що має бути завжди

Нижче — абсолютний мінімум, без якого сайт не може вважатися доступним. Це не «бажано», а «обов'язково».

Контраст тексту:

• Звичайний текст: коефіцієнт контрасту ≥ 4.5:1.
• Великий текст (18 px bold або 24 px regular): ≥ 3:1.
• UI-елементи й графіка: ≥ 3:1.

Видимий фокус:

• Кожен інтерактивний елемент має видимий outline при навігації клавіатурою.
• Не ховайте фокус через outline: none без заміни. Якщо дефолтний outline «некрасивий» — стилізуйте його, але не прибирайте.

:focus-visible {
  outline: 2px solid var(--accent);
  outline-offset: 2px;
}

Логічний порядок табуляції:

• Tab рухається зверху вниз, зліва направо, в тому порядку, в якому контент розташований візуально.
• Не використовуйте tabindex > 0. Використовуйте tabindex="0" для кастомних елементів і tabindex="-1" для програмного фокусу.

Підписи полів:

• Кожне поле форми має видимий <label>, пов'язаний через for/id.
• Placeholder — не заміна label. Він зникає при введенні й має недостатній контраст.

<div class="form-group">
  <label for="email">Електронна пошта</label>
  <input type="email" id="email" name="email"
         autocomplete="email"
         aria-describedby="email-hint">
  <span id="email-hint" class="form-hint">
    Використовуємо лише для відповіді на заявку
  </span>
</div>

alt для змістовних зображень:

• Якщо зображення несе сенс — alt описує, що на ньому.
• Декоративне зображення — alt="" (порожній, не відсутній).
• Іконка без тексту — aria-label на кнопці.

Коректні заголовки H1–H6:

• Одна H1 на сторінку.
• Заголовки йдуть послідовно: H1 → H2 → H3, не перескакуючи.
• Заголовок описує зміст секції, а не «красиве слово».

Не лише колір для стану:

• Помилка у формі — не тільки червоний border, але й текстове повідомлення.
• Обов'язкове поле — не тільки зірочка, але й aria-required="true" та текстове пояснення.
• Посилання в тексті — не лише колір, а й підкреслення або інший візуальний маркер.

Мова документа:

<html lang="uk">

Скрінрідер читає сторінку з правильною вимовою, тільки якщо знає мову. Якщо частина контенту іншою мовою — <span lang="en">Definition of Done</span>.

Skip-посилання:

<a href="#main-content" class="skip-link">
  Перейти до основного вмісту
</a>

Перший елемент у DOM, видимий при фокусі. Дозволяє клавіатурному користувачеві пропустити навігацію.

05 Компоненти, які ламаються найчастіше

80 % проблем доступності сконцентровані в кількох типах компонентів. Якщо ви виправите лише їх — сайт стане значно доступнішим.

Кастомні селекти

Нативний <select> доступний з коробки. Як тільки ви замінюєте його на <div> з випадаючим списком — ви берете на себе всю роботу зі скрінрідером, клавіатурою та фокусом.

Мінімум для кастомного селекта:

• role="combobox" на тригері.
• aria-expanded="true|false".
• aria-activedescendant для поточного вибору.
• Стрілки ↑/↓ для навігації, Enter для вибору, Escape для закриття.
• aria-selected="true" на обраному елементі.

Порада: якщо кастомний селект потрібен лише для стилізації — використовуйте нативний <select> зі стилями. Сучасні CSS-техніки дозволяють стилізувати його достатньо.

Модалки без focus trap

Модальне вікно, яке не ловить фокус — це пастка для клавіатурного користувача. Tab «проходить крізь» модалку і потрапляє на елементи під оверлеєм.

Правила модалки:

• При відкритті фокус переходить на перший інтерактивний елемент або заголовок модалки.
• Tab/Shift+Tab циклічно ходить всередині модалки.
• Escape закриває модалку.
• При закритті фокус повертається на елемент, який її відкрив.
• role="dialog", aria-modal="true", aria-labelledby для заголовка.
• Фон під оверлеєм: aria-hidden="true" на #app або inert на решті контенту.

<div role="dialog"
     aria-modal="true"
     aria-labelledby="modal-title">
  <h2 id="modal-title">Залишити заявку</h2>
  <form>
    <!-- поля -->
    <button type="submit">Надіслати</button>
    <button type="button" aria-label="Закрити">✕</button>
  </form>
</div>

Слайдери / каруселі

Слайдер без aria — чорна діра для скрінрідера. Він не знає, скільки слайдів, який зараз активний і як переключити.

Мінімум:

• role="group" або role="region" на контейнері з aria-label="Каруселька відгуків".
• aria-roledescription="slide" на кожному слайді.
• aria-label="Слайд 2 з 5" або aria-current="true".
• Кнопки «Попередній» / «Наступний» з текстовими підписами.
• Якщо автопрогортання — кнопка «Пауза», і автопрогортання зупиняється при фокусі чи наведенні.
• prefers-reduced-motion: reduce — вимкнути автопрогортання.

Іконки-кнопки без тексту

Кнопка з іконкою без підпису — для скрінрідера це «кнопка». Без контексту.

<!-- ✗ Погано -->
<button><i class="icon-cart"></i></button>

<!-- ✓ Добре -->
<button aria-label="Відкрити кошик">
  <i class="icon-cart" aria-hidden="true"></i>
</button>

Правило: якщо на кнопці або посиланні немає видимого тексту — додайте aria-label. Якщо є видимий текст — aria-label не потрібен.

Гамбургер-меню

• Кнопка має aria-expanded="false" (закрито) / "true" (відкрито).
• aria-controls="nav-menu" вказує на блок, який розкривається.
• aria-label="Відкрити меню" або видимий текст «Меню».
• При відкритті на мобільному — focus trap, як у модалці.
• Escape — закриває.

Таби (вкладки)

• role="tablist" на контейнері.
• role="tab" на кожній вкладці.
• role="tabpanel" на кожній панелі.
• aria-selected="true" на активній вкладці.
• Стрілки ← / → переключають вкладки.
• Tab переносить фокус у панель.
• aria-labelledby зв'язує панель із вкладкою.

Акордеон / FAQ

• Кнопка (не div!) як тригер.
• aria-expanded="true|false".
• aria-controls на пов'язану панель.
• Enter / Space — розкривають / згортають.
• Контент панелі не ховається через display: none або hidden, поки панель згорнута — саме так, ховається тоді, коли згорнута.

06 Клавіатурна навігація: як перевірити за 5 хвилин

Відкрийте сайт і відкладіть мишу. Це найшвидший тест доступності.

Що перевірити:

1. Tab — чи можна дістатися до кожного інтерактивного елемента?
2. Shift+Tab — чи можна повернутися назад?
3. Enter — чи активуються посилання та кнопки?
4. Space — чи перемикаються чекбокси та радіокнопки?
5. Escape — чи закриваються модалки, дропдауни, тултіпи?
6. Стрілки — чи працюють у селектах, табах, меню?
7. Фокус — чи видно, де зараз фокус?
8. Порядок — чи логічний порядок переходу?

Типові проблеми:

• Фокус «застряє» — не можна вийти з елемента.
• Фокус «зникає» — переходить на невидимий елемент (наприклад, приховане мобільне меню).
• Фокус «перескакує» — нелогічний порядок через tabindex > 0 або position: absolute.
• Інтерактивний елемент недоступний — div замість button, клік лише через onClick без onKeyDown.

Головне правило:

Якщо це можна натиснути — це <button> або <a>.
Не <div>, не <span>, не <li>.

07 Контраст і типографіка

Контраст — найчастіша проблема, яку знаходять автоматичні інструменти. І найлегша у виправленні.

Вимоги WCAG 2.2 AA:

Що забувають:

• Placeholder у полях — зазвичай надто блідий.
• Disabled-стан кнопок — контраст не потрібен за WCAG, але практика показує, що занадто блідий disabled заважає.
• Текст на зображеннях — контраст залежить від конкретної частини фото під текстом. Рішення: напівпрозорий overlay або текстова тінь.
• Кольори посилань — мають контраст ≥ 3:1 з навколишнім текстом (якщо відрізняються лише кольором).

Розмір тексту:

• Мінімум основного тексту: 16 px. Менший — складно читати на мобільному.
• Висота рядка (line-height): ≥ 1.5 для основного тексту.
• Відстань між абзацами: ≥ 2× розмір шрифту.
• Відстань між літерами (letter-spacing): не стискайте. Мінімум 0.12 em можна задати через налаштування.

Перевірити контраст:

• WebAIM Contrast Checker
• DevTools → Rendering → Emulate vision deficiencies
• axe DevTools — показує всі порушення контрасту

08 Форми: підписи, помилки, автозаповнення

Форми — головне місце конверсії на сайті. І головне місце, де доступність ламається.

Label:

• Кожне поле — видимий <label>.
• for = id поля. Без цього скрінрідер не зв'яже підпис з полем.
• Плейсхолдер — підказка, не підпис. Він зникає при введенні.

Помилки:

• Повідомлення про помилку — текстове, не лише червоний border.
• aria-invalid="true" на полі з помилкою.
• aria-describedby зв'язує поле з текстом помилки.
• Після відправки з помилками — фокус переходить на перше поле з помилкою або на блок загального повідомлення.

<div class="form-group">
  <label for="phone">Телефон</label>
  <input type="tel" id="phone" name="phone"
         autocomplete="tel"
         aria-invalid="true"
         aria-describedby="phone-error">
  <span id="phone-error" class="form-error" role="alert">
    Вкажіть телефон у форматі +380XXXXXXXXX
  </span>
</div>

Автозаповнення:

WCAG 2.2 вимагає autocomplete для полів з особистими даними. Це допомагає людям із когнітивними порушеннями та просто економить час.

Групи полів:

<fieldset>
  <legend>Контактна інформація</legend>
  <!-- поля -->
</fieldset>

<fieldset> + <legend> — семантичне групування, яке скрінрідер озвучує при вході в групу.

09 Зображення та медіа

Зображення:

• Інформативне зображення — alt описує, що на ньому і навіщо.
• Декоративне зображення — alt="" (порожній). Скрінрідер пропускає його.
• Зображення-посилання — alt описує, куди веде посилання.
• Складна графіка (діаграма, інфографіка) — alt із коротким описом + розгорнутий текстовий опис поблизу.

<!-- Інформативне -->
<img src="team.jpg"
     alt="Команда CROPE на зустрічі з клієнтом у київському офісі">

<!-- Декоративне -->
<img src="pattern.svg" alt="" aria-hidden="true">

<!-- Діаграма -->
<figure>
  <img src="chart.png"
       alt="Графік росту конверсії: +40% після впровадження a11y">
  <figcaption>
    Конверсія зросла з 2.1% до 2.9% за 3 місяці після
    виправлення основних проблем доступності форм.
  </figcaption>
</figure>

Відео:

• Субтитри для відео з мовленням.
• Аудіоопис для відео, де важлива візуальна інформація.
• Якщо відео автоматично стартує — кнопка паузи.
• prefers-reduced-motion — не запускати автоматично.

SVG-іконки:

<!-- Декоративна (поруч є текст) -->
<svg aria-hidden="true" focusable="false">
  <use href="#icon-phone"></use>
</svg>
<span>+380 44 123 4567</span>

<!-- Змістовна (без тексту) -->
<svg role="img" aria-label="Телефон">
  <use href="#icon-phone"></use>
</svg>

10 Анімації та motion

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

prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

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

Що саме потрібно:

• Каруселі з автопрогортанням — пауза при prefers-reduced-motion: reduce, при фокусі й при наведенні.
• Parallax — вимикається повністю або замінюється на статичне зображення.
• Блимаючий контент — заборонений (WCAG 2.3.1). Нічого не має блимати частіше 3 разів на секунду.
• Великі fade/slide-анімації (AOS, GSAP) — скорочуються або вимикаються.
• Відео-фони — prefers-reduced-motion → показати статичний кадр.

Вестибулярні розлади:

Близько 35 % людей старше 40 років мають вестибулярні порушення. Parallax-ефекти, великі zoom-переходи, скрол-зв'язаний рух можуть викликати запаморочення й нудоту.

11 European Accessibility Act і юридичні ризики

European Accessibility Act (EAA) — Директива (ЄС) 2019/882, яка набула чинності 28 червня 2025. Вона зобов'язує бізнеси в ЄС робити свої цифрові продукти доступними.

На кого поширюється:

• E-commerce: інтернет-магазини.
• Банки й фінансові послуги.
• Транспортні сервіси (авіа, залізниця, міський).
• Телекомунікації.
• E-books і е-рідери.
• Операційні системи та апаратне забезпечення.

Стандарт відповідності: EN 301 549, який посилається на WCAG 2.1 AA (практично — WCAG 2.2 AA рекомендований).

Що це означає для українських компаній:

• Якщо ви продаєте послуги або товари клієнтам у ЄС — ваш сайт має відповідати.
• Якщо ви розробляєте сайти для клієнтів із ЄС — ви несете відповідальність як виконавець.
• «Ми не в ЄС» не звільняє, якщо бізнес клієнта працює на ринку ЄС.

Інші юрисдикції:

Штрафи й позови:

• У США кількість позовів за ADA щодо вебдоступності перевищує 4 000 на рік.
• В ЄС штрафи визначаються кожною країною-членом окремо.
• Реальний ризик — не стільки штраф, скільки публічний скандал і втрата клієнтів.

12 a11y і SEO: де вони перетинаються

Доступність і SEO мають спільну основу — семантику. Те, що робить сайт зрозумілим для скрінрідера, робить його зрозумілим і для пошукового бота.

Перетин:

Що НЕ перетинається:

• aria-* атрибути — пошуковий бот їх ігнорує.
• Focus management — не впливає на SEO.
• Color contrast — бот не «бачить» кольори.

Але все, що допомагає скрінрідеру зрозуміти контент, зазвичай допомагає й пошуковому боту.

13 Інструменти тестування

Автоматичні інструменти знаходять 30–50 % проблем доступності. Решту — лише ручне тестування та реальні користувачі.

Автоматичні:

Ручні:

• Клавіатурна навігація — Tab, Shift+Tab, Enter, Escape. 5 хвилин, знаходить критичні проблеми.
• Скрінрідер — NVDA (Windows, безкоштовно), VoiceOver (macOS/iOS, вбудований), TalkBack (Android). Спробуйте пройти user flow.
• Zoom 200–400 % — чи не ламається розмітка при збільшенні?
• DevTools: Emulate vision deficiencies — протанопія, дейтеранопія, ахроматопсія.
• Вимкнення CSS — чи зрозумілий контент без стилів?

Інтеграція в CI/CD:

// Playwright + axe-core
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

test('homepage a11y', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Запускайте a11y-тести в CI так само, як запускаєте unit-тести. Порушення — це баг, а не «побажання».

14 a11y у Definition of Done

Definition of Done (DoD) — набір критеріїв, без яких задача не вважається завершеною. Якщо a11y немає в DoD — його ніхто не робить.

Мінімальний a11y-блок у DoD:

• Клавіатурна навігація працює для нового функціоналу.
• Усі інтерактивні елементи мають accessible name (видимий текст або aria-label).
• Контраст тексту відповідає AA (≥ 4.5:1).
• Нові зображення мають alt (або alt="" для декоративних).
• Нові форми: label зв'язаний з полем, помилки текстові, autocomplete є.
• axe DevTools показує 0 нових порушень.
• Перевірено зі скрінрідером (хоча б VoiceOver / NVDA для основного user flow).

Як це працює на практиці:

1. Дизайнер перевіряє контраст у Figma (плагін Contrast).
2. Фронтенд-розробник використовує семантичний HTML і перевіряє Tab-навігацію.
3. Тестувальник прогоняє axe та проходить основний flow зі скрінрідером.
4. CI/CD-тести (Pa11y, axe-core) блокують merge при порушеннях.
5. QA підписує DoD.

Якщо a11y перевіряється лише перед релізом — вона не перевіряється ніколи.

15 Чекліст доступності перед релізом

• Мова документа: <html lang="uk"> (або відповідна).
• Заголовки: один H1, ієрархія H1→H2→H3, без пропусків.
• Skip-посилання: «Перейти до основного вмісту» першим у DOM.
• Фокус: видимий :focus-visible на всіх інтерактивних елементах.
• Контраст: ≥ 4.5:1 для тексту, ≥ 3:1 для UI.
• Зображення: alt на всіх <img>, порожній alt на декоративних.
• Форми: label + for/id, aria-invalid, aria-describedby для помилок, autocomplete.
• Кнопки: <button> або <a>, не <div>. Іконки — aria-label.
• Модалки: focus trap, Escape закриває, фокус повертається.
• Відео: субтитри, кнопка паузи.
• Анімації: prefers-reduced-motion: reduce відключає автопрогортання й parallax.
• Target size: інтерактивні елементи ≥ 24×24 px (WCAG 2.2).
• Автентифікація: без CAPTCHA-паззлів або з альтернативою (WCAG 2.2).
• axe/Lighthouse: 0 порушень рівня A і AA.
• Клавіатурний прохід: увесь основний user flow доступний з клавіатури.
• Скрінрідер: основний flow перевірений у NVDA або VoiceOver.

16 Типові помилки й антипатерни

«Ми додамо aria і все буде доступно»

ARIA — це доповнення до семантичного HTML, а не заміна. Правило W3C: «Якщо можна використати нативний HTML-елемент — використовуйте його, а не ARIA.»

<!-- ✗ Погано — ARIA замість семантики -->
<div role="button" tabindex="0"

<!-- ✓ Добре — нативна кнопка -->
<button type="submit">Надіслати</button>

«У нас є accessibility overlay»

Overlay-віджети (accessiBe, UserWay, EqualWeb) обіцяють «автоматичну доступність одним рядком коду». На практиці:

• Вони не можуть виправити семантику HTML.
• Часто ламають існуючу доступність.
• Національна федерація сліпих (NFB) та інші організації виступають проти них.
• Overlay не захищає від юридичних позовів — суди це підтвердили.
• Вони додають зайвий JS і сповільнюють сайт.

Рішення: не overlay, а інженерний підхід — семантичний HTML, правильні ARIA, тестування.

«Доступність — це для сліпих»

Доступність — для всіх людей із різними здібностями:

• Моторні порушення: клавіатурна навігація, великі target-зони.
• Когнітивні відмінності: прості тексти, передбачуваний інтерфейс, анімації без руху.
• Слабкий зір: контраст, масштабування, не лише колір для стану.
• Глухота: субтитри, текстові альтернативи аудіо.
• Тимчасові обмеження: зламана рука, шумне середовище, яскраве сонце.
• Вікові зміни: зір, слух, моторика змінюються з віком.

«outline: none» на всьому

/* ✗ Антипатерн — прибирає фокус для ВСІХ */
*:focus { outline: none; }

/* ✓ Правильно — прибирає для миші, залишає для клавіатури */
:focus:not(:focus-visible) { outline: none; }
:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }

Табличний layout без семантики

<!-- ✗ Таблиця для layout -->
<table>
  <tr><td>Лого</td><td>Навігація</td></tr>
  <tr><td colspan="2">Контент</td></tr>
</table>

<!-- ✓ Семантичний layout -->
<header>Лого + Навігація</header>
<main>Контент</main>

«aria-label на всьому»

Надлишок aria-label заважає, а не допомагає. Правила:

• Є видимий текст → aria-label не потрібен.
• Немає видимого тексту (іконка) → aria-label потрібен.
• aria-label переважає видимий текст для скрінрідера. Якщо вони не збігаються — користувач голосового керування не зможе активувати елемент.

17 Як впровадити a11y в існуючий проєкт

Якщо сайт уже в продакшені й будувався без урахування доступності — не панікуйте. Поетапний план:

Фаза 1: Аудит (1–2 тижні)

1. Запустіть axe DevTools або Lighthouse на ключових сторінках.
2. Перевірте клавіатурну навігацію на основних user flows.
3. Пройдіть головний flow зі скрінрідером.
4. Зафіксуйте список проблем, пріоритезуйте.

Фаза 2: Критичні виправлення (2–4 тижні)

1. lang на <html>.
2. Skip-посилання.
3. alt на зображеннях.
4. Labels на формах.
5. Контраст тексту.
6. Видимий :focus-visible.
7. <button> замість кліклабельних <div>.

Фаза 3: Компоненти (4–8 тижнів)

1. Focus trap у модалках.
2. Aria-атрибути на кастомних селектах, табах, акордеонах.
3. Клавіатурна навігація в слайдерах.
4. prefers-reduced-motion для анімацій.

Фаза 4: Процес (постійно)

1. a11y у DoD для нових задач.
2. axe-core в CI/CD.
3. Регулярні ручні перевірки зі скрінрідером.
4. Навчання команди.

Порада: не намагайтесь виправити все одразу. Фокусуйтесь на user flows, які генерують конверсію: головна → послуга/товар → форма заявки/кошик → дякуємо.

18 Часті запитання

Скільки коштує впровадження a11y?

Якщо закласти доступність з початку проєкту — додаткова вартість мінімальна (5–15 % від розробки). Якщо виправляти постфактум — значно більше, бо потрібен аудит, рефакторинг і повторне тестування.

Чи потрібен аудит від сертифікованого спеціаліста?

Для юридичного захисту в ЄС або США — бажано. Для початку — достатньо внутрішнього аудиту з axe + ручним тестуванням + скрінрідером.

Чи може AI-генерований контент бути доступним?

Так, якщо генерація включає семантичний HTML, alt-тексти й правильну структуру. Ні, якщо AI генерує тільки «красивий» div-суп.

Чи знижує a11y швидкість сайту?

Ні, навпаки. Семантичний HTML менший за ARIA-обвіску на div'ах. Видалення зайвого JS (overlay-віджетів) пришвидшує завантаження.

Як переконати клієнта інвестувати в доступність?

Три аргументи: юридичний ризик (EAA, ADA), розширення аудиторії (+15–20 %), SEO-бонус через семантику. Покажіть конкретний аудит із кількістю помилок.

Чи обов'язкова доступність для українських сайтів?

Прямого закону немає. Але: державні сайти підпадають під ратифіковану Конвенцію ООН; сайти, що працюють на ринку ЄС, підпадають під EAA; доступність стає де-факто стандартом у тендерах.

Що робити з legacy-контентом (старі PDF, зображення без alt)?

Пріоритезувати: ключові сторінки → конверсійні flow → решта. Для PDF — генерувати доступні HTML-альтернативи.

Доступність — це не окремий проєкт і не чекбокс у брифі. Це частина інженерної якості продукту. Вбудуйте a11y в процес, перевіряйте в CI, включіть у DoD — і сайт стане зручнішим для всіх, а не тільки для «людей із інвалідністю».

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

Замовити аудит на crope.pro