WCAG 2.2: New Criteria and How to Prepare

У жовтні 2023 року W3C опублікував WCAG 2.2 — нову версію стандарту веб-доступності. Вона містить 9 нових критеріїв успіху, видаляє один застарілий критерій (4.1.1 Parsing) і залишає без змін усі попередні критерії WCAG 2.1. Розуміння нових вимог критично важливе для бізнесу, адже більшість нових законів прямо посилаються на WCAG 2.2.

Що змінилося з WCAG 2.1 до WCAG 2.2

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

Нові критерії рівня A

Рівень A — мінімальні вимоги. Два нових критерії рівня A у WCAG 2.2 стосуються послідовності інтерфейсу та зменшення когнітивного навантаження на користувачів.

3.2.6 Consistent Help — послідовне розташування допомоги

Якщо ваш сайт містить механізми допомоги — чат-підтримку, телефонний номер, форму зворотного зв'язку, сторінку FAQ або розділ «Допомога» в навігації — вони мають розташовуватися в одному й тому самому місці на кожній сторінці, де присутні.

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

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

<!-- ПРАВИЛЬНО: підтримка завжди у шапці (header) на всіх сторінках -->
<header>
  <nav>
    <a href="/help">Допомога</a>
    <a href="tel:+380800000000">0800 000 000</a>
  </nav>
</header>

<!-- НЕПРАВИЛЬНО: підтримка в шапці на одних сторінках,
     але у футері на сторінці оформлення замовлення -->
<footer>
  <a href="/support">Служба підтримки</a>
</footer>

3.3.7 Redundant Entry — не вимагай повторного вводу

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

Найпоширеніший кейс — процес оформлення замовлення: якщо користувач уже вказав адресу доставки, поле «адреса виставлення рахунку» має містити чекбокс «Така ж, як адреса доставки» або автоматично заповнюватися. Інший приклад — реєстрація в кілька кроків: email, введений на першому кроці, не потрібно вводити знову.

Нові критерії рівня AA: найважливіші для бізнесу

Рівень AA — це стандарт, якого вимагають більшість законів. П'ять нових критеріїв рівня AA у WCAG 2.2 потребують особливої уваги при аудиті та розробці.

2.4.11 Focus Not Obscured (Minimum) — фокус не може бути повністю прихованим

Коли користувач переміщує фокус за допомогою клавіші Tab, сфокусований компонент не повинен бути повністю прихований іншими елементами — sticky заголовками, фіксованими панелями навігації, чат-віджетами або cookie-банерами. Частково прихований елемент допустимий за рівня AA (для повного відображення існує рівень AAA — критерій 2.4.12).

Типова проблема: sticky навігаційна панель висотою 60px перекриває кнопку «Купити» при Tab-навігації. Виправлення: додайте scroll-margin-top до інтерактивних елементів або використовуйте JavaScript для прокрутки сторінки при отриманні фокусу.

/* Виправлення прихованого фокусу за sticky header */
/* Якщо header висотою 64px */

:target {
  scroll-margin-top: 80px;
}

/* Або для всіх інтерактивних елементів */
a:focus,
button:focus,
input:focus,
select:focus,
textarea:focus {
  scroll-margin-top: 80px;
}

2.4.13 Focus Appearance — видимий та достатній індикатор фокусу

WCAG 2.1 вимагав лише «видимого» фокусу (критерій 2.4.7) без конкретних числових вимог. WCAG 2.2 додає критерій 2.4.13 із чіткими специфікаціями: focus-індикатор повинен відповідати обом умовам одночасно:

• Площа охоплення: периметр focus-індикатора має оточувати компонент або мати ≥ периметр кола діаметром 4 CSS пікселів.
• Контрастність зміни: зміна між станами із фокусом і без має контраст ≥ 3:1 як відносно кольору елемента, так і відносно сусідніх кольорів.

Практично це означає: рамки товщиною 2–3 CSS пікселі з кольором, що контрастує з фоном. Найпоширеніша помилка — використання тонкого 1px outline або outline того ж кольору, що й фон сторінки.

/* НЕПРАВИЛЬНО — видаляє focus */
button:focus {
  outline: none;
}

/* НЕПРАВИЛЬНО — занадто тонкий, малоконтрастний */
button:focus {
  outline: 1px solid #ccc;
}

/* ПРАВИЛЬНО — WCAG 2.2 Focus Appearance (2.4.13) */
button:focus-visible {
  outline: 3px solid #1E3A8A;
  outline-offset: 2px;
  border-radius: 4px;
}

/* Альтернатива: box-shadow для rounded кнопок */
button:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px #ffffff, 0 0 0 5px #1E3A8A;
}

2.5.7 Dragging Movements — альтернатива для перетягування

Функціональність, що вимагає перетягування (drag-and-drop), має альтернативний спосіб виконання за допомогою одного вказівника (click або tap) — без необхідності утримувати кнопку натиснутою і переміщувати об'єкт. Це особливо важливо для людей із тремором рук, порушеннями моторики або тих, хто використовує тачскрін.

Приклади виправлення: drag-and-drop список із пріоритетами повинен мати кнопки «Вгору» / «Вниз» або можливість вибрати позицію через dropdown. Слайдер діапазону повинен допускати введення числового значення в текстове поле. Kanban-дошка повинна дозволяти переміщення карток через меню або контекстне меню.

2.5.8 Target Size (Minimum) — мінімальний розмір цілі 24×24 пікселів

Розмір клікабельної або торканої області кожного елемента інтерфейсу має бути щонайменше 24×24 CSS пікселів. Якщо сам елемент менший — навколо нього повинна бути достатня відступна зона (spacing), щоб сумарна площа взаємодії досягала мінімуму.

Виняток: якщо між елементом і будь-якою сусідньою ціллю є простір щонайменше 24 CSS пікселів у найвужчому місці — вимога вважається виконаною навіть якщо сам елемент менший за 24px. Також виняток стосується вбудленого тексту (inline links), нативних елементів браузера та незамінних функціональних подань.

/* Іконка 16px: додаємо padding для мінімальної цілі 24px */
.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  /* Мінімум 24x24 CSS пікселів */
  min-width: 24px;
  min-height: 24px;
  padding: 4px; /* 16px іконка + 4px з кожного боку = 24px */
}

/* Або через min-size з CSS */
.icon-button {
  width: max(24px, 1.5rem);
  height: max(24px, 1.5rem);
}

3.3.8 Accessible Authentication (Minimum) — доступна автентифікація

Процес логіну не повинен вимагати від користувача виконання когнітивного тесту, якщо немає доступної альтернативи. Когнітивний тест у контексті цього критерію — це завдання на запам'ятовування (введення пароля від руки, без менеджера паролів), розпізнавання об'єктів (класичний text-based captcha) або будь-яке завдання, що навантажує оперативну пам'ять.

Критерій не забороняє паролі — він вимагає, щоб поле пароля підтримувало функції автозаповнення браузера та менеджерів паролів (тобто мало атрибут autocomplete="current-password"). Також допускаються: magic links, одноразові коди (OTP), passkeys, OAuth.

Щодо captcha: image-based captcha з альтернативою (аудіо-captcha або email-підтвердження) допустима за рівня AA. Рівень AAA (критерій 3.3.9) забороняє когнітивні тести взагалі, навіть із альтернативами.

<!-- ПРАВИЛЬНО: autocomplete дозволяє менеджерам паролів -->
<form method="post" action="/login">
  <label for="email">Email</label>
  <input
    id="email"
    type="email"
    name="email"
    autocomplete="username"
  />

  <label for="password">Пароль</label>
  <input
    id="password"
    type="password"
    name="password"
    autocomplete="current-password"
  />

  <button type="submit">Увійти</button>
</form>

<!-- НЕПРАВИЛЬНО: autocomplete="off" блокує менеджери паролів -->
<input type="password" autocomplete="off" />

Видалений критерій 4.1.1 Parsing: чому його прибрали

Критерій 4.1.1 Parsing вимагав, щоб HTML-розмітка була синтаксично коректною: без дублікатів атрибутів, із правильно закритими тегами, без дублікатів id. Причина видалення — сучасні браузери та асистивні технології навчилися коректно обробляти навіть помилкову розмітку. Валідатори HTML тепер самі виправляють більшість синтаксичних помилок до того, як сторінка відображається.

Важливо: видалення 4.1.1 Parsing не означає, що якість розмітки втратила значення. Семантично коректний HTML залишається фундаментом доступності — він просто тепер оцінюється в контексті інших критеріїв, насамперед 4.1.2 Name, Role, Value. Дублікати id все ще можуть ламати ARIA-посилання та порушувати критерій 4.1.2.

Що вже відповідає WCAG 2.1 і залишається в силі

WCAG 2.2 є повністю зворотньо сумісним із WCAG 2.1. Усі 78 критеріїв WCAG 2.1 залишаються чинними у WCAG 2.2 (за винятком видаленого 4.1.1). Це означає:

• Сайт, сертифікований на відповідність WCAG 2.1 AA, вже задовольняє 78 із 87 критеріїв WCAG 2.2 AA.
• Для повної відповідності WCAG 2.2 AA потрібно виконати лише 5 нових критеріїв AA: 2.4.11, 2.4.13, 2.5.7, 2.5.8, 3.3.8, та 2 нових критерії A: 3.2.6, 3.3.7.
• Всі раніше виконані покращення — alt-тексти, контраст, keyboard navigation, ARIA, субтитри — продовжують зараховуватися.
• W3C рекомендує організаціям, що вже посилаються на WCAG 2.1, оновити посилання на WCAG 2.2 — стандарт є покращеним продовженням, а не заміною.

Чекліст оновлення з WCAG 2.1 до WCAG 2.2: 10 кроків

Якщо ваш сайт вже відповідав WCAG 2.1 AA, ось покроковий план переходу на WCAG 2.2.

1. 1Проведіть автоматичний аудит інструментом axe або InclusiveWeb Scanner з профілем WCAG 2.2 AA — це дасть базовий звіт про нові порушення.
2. 2Перевірте всі sticky і fixed елементи (header, footer, chat widget, cookie banner): чи перекривають вони інтерактивні елементи при Tab-навігації? (критерій 2.4.11)
3. 3Перегляньте всі CSS-стилі focus-індикаторів: перевірте товщину рамки (≥ 3px або 2px з offset) і контрастність зміни стану (≥ 3:1). (критерій 2.4.13)
4. 4Знайдіть всі drag-and-drop функції: сортовані списки, слайдери, канбан-дошки. Додайте клавіатурну або click-альтернативу для кожної. (критерій 2.5.7)
5. 5Перевірте розмір всіх іконок, кнопок і посилань: чи є мінімальна зона взаємодії 24×24 CSS px? Додайте padding або min-width/height де потрібно. (критерій 2.5.8)
6. 6Проаналізуйте розташування елементів допомоги (чат, контакти, FAQ): чи однаково вони розміщені на всіх сторінках, де присутні? (критерій 3.2.6)
7. 7Перегляньте багатокрокові форми і процеси оформлення: де можна автозаповнити або надати вибір раніше введених даних? (критерій 3.3.7)
8. 8Перевірте форму логіну: чи підтримують поля пароля autocomplete="current-password"? Чи є альтернатива captcha? (критерій 3.3.8)
9. 9Оновіть заяву про доступність (Accessibility Statement): змініть посилання з «відповідає WCAG 2.1» на «відповідає WCAG 2.2» після завершення всіх виправлень.
10. 10Проведіть фінальне ручне тестування з клавіатури і скрінрідером, щоб перевірити, що виправлення не порушили існуючу функціональність.

Як перевірити відповідність WCAG 2.2

Перевірка відповідності WCAG 2.2 поєднує автоматичні інструменти та ручний аналіз. Автоматичні інструменти виявляють типові помилки розмітки, контрасту та структури — але нові критерії WCAG 2.2 здебільшого вимагають ручної перевірки:

• Прихований фокус (2.4.11) вимагає ручної Tab-навігації по всіх сторінках.
• Focus Appearance (2.4.13) потребує перевірки кожного інтерактивного елемента і виміру контрасту focus-рамки.
• Redundant Entry (3.3.7) потребує ручного проходження всіх форм і флоу оформлення замовлення.
• Consistent Help (3.2.6) вимагає порівняння розташування елементів допомоги на різних сторінках.

InclusiveWeb пропонує повний аудит на відповідність WCAG 2.2 AA з детальним звітом, пріоритизованим переліком порушень і рекомендаціями щодо виправлення. Безкоштовний аудит 5 сторінок доступний одразу після реєстрації.