Що нового у WCAG 2.2? Дев’ять нових критеріїв простими словами

Людина, яка користується клавіатурою, проходить клавішею Tab вашим оформленням замовлення. Фокус потрапляє на кнопку «Оплатити», але згори її закриває закріплений банер про cookie, і людина не бачить, де вона. За WCAG 2.1 така сторінка могла пройти перевірку. За WCAG 2.2 — ні.

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

Що таке WCAG 2.2?

WCAG 2.2 — чинна версія Настанов з доступності вебконтенту (Web Content Accessibility Guidelines), стандарту W3C, на який посилається більшість законів і договорів про доступність. Вона отримала статус рекомендації W3C 5 жовтня 2023 року (відкриється в новій вкладці), була оновлена 12 грудня 2024 року (відкриється в новій вкладці), а в жовтні 2025 року її затвердили як ISO/IEC 40500:2025 (відкриється в новій вкладці).

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

Що змінилося порівняно з WCAG 2.1?

WCAG 2.2 додає дев’ять критеріїв успішності й вилучає один. Шість нових належать до рівня A або AA, тож входять до звичної цілі AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 і 3.3.8. Решта три — рівня AAA. Вилучено критерій 4.1.1 «Синтаксичний аналіз» (Parsing), який W3C тепер називає застарілим.

Критерій 4.1.1 «Синтаксичний аналіз» перевіряв помилки розмітки, наприклад повторювані ID. У FAQ щодо WCAG 2 (відкриється в новій вкладці) пояснено, що тепер такі проблеми підпадають під інші критерії, як-от 4.1.2 «Ім’я, роль, значення». Є нюанс: якщо договір досі вимагає WCAG 2.0 чи 2.1, вам, можливо, «доведеться й далі перевіряти критерій 4.1.1 і звітувати щодо нього».

«Фокус не приховано» і «Вигляд фокуса»: чи бачать користувачі клавіатури, де вони?

Ці критерії стежать, щоб елемент із фокусом клавіатури залишався видимим. На рівні AA (2.4.11) посилання чи кнопка у фокусі не має повністю ховатися за контентом, який додали ви: закріпленою шапкою, банером про cookie чи значком чату. На рівні AAA ніщо не має перекривати жодної її частини (2.4.12), а контур фокуса має бути великим і помітно контрастним (2.4.13).

• Кому допомагає: зрячим людям, які користуються клавіатурою замість миші, часто через порушення моторики. Якщо фокуса не видно, їм доводиться вгадувати.
• Швидка перевірка: відкрийте довгу сторінку так, щоб було видно банер про cookie, закріплену шапку та віджет чату, і кілька разів натисніть Tab. Якщо фокус повністю зникає за якимсь елементом, це порушення 2.4.11.
• Звичайне виправлення: додайте CSS-властивість scroll-padding, що дорівнює висоті закріпленої шапки чи футера, щоб браузер прокручував елементи у фокусі так, аби вони не опинялися під ними. W3C називає це достатньою технікою (відкриється в новій вкладці). Банер також проходить перевірку, якщо він модальний і його треба спершу закрити.

«Вигляд фокуса» (2.4.13) вимагає індикатора, не меншого за контур завтовшки 2 CSS-пікселі навколо компонента, зі зміною контрасту щонайменше 3:1 між станами з фокусом і без нього. Це рівень AAA, але суцільний контур у 2 пікселі яскравого кольору зазвичай його забезпечує. Як виміряти 3:1, пояснює наш посібник із колірного контрасту.

«Перетягування» й «Розмір області натискання»: чи можна користуватися сайтом без точного наведення?

Ці два критерії рівня AA допомагають людям, яким важко точно керувати вказівником. 2.5.7 вимагає, щоб усе, що робиться перетягуванням, працювало й із поодинокими клацаннями чи дотиками. 2.5.8 вимагає, щоб області натискання мали щонайменше 24 на 24 CSS-пікселі або були розташовані так, щоб коло діаметром 24 пікселі з центром на кожній із них не торкалося сусідньої.

2.5.7 Перетягування

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

Швидка перевірка: виконайте кожну дію з перетягуванням лише клацаннями чи дотиками. Звичайне виправлення: дозвольте клацати будь-де на шкалі повзунка, додайте поруч поля «від» і «до» або кнопки «Вище» й «Нижче» в списки, які можна сортувати. Самої підтримки клавіатури замало: у пояснювальному документі (відкриється в новій вкладці) W3C сказано, що клавіатурна альтернатива «не означає автоматичного виконання цього критерію успішності».

2.5.8 Розмір області натискання (мінімум)

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

• Винятки: посилання всередині речення, елементи, для яких деінде на сторінці є рівнозначний елемент керування потрібного розміру, елементи керування, розмір яких задає браузер і які ви не перестилізовували, а також випадки, коли певний розмір принципово важливий або вимагається законом.
• Швидка перевірка: на телефоні спробуйте натиснути кожен маленький значок і кнопку; щоб виміряти елемент, відкрийте його в інструментах розробника браузера.
• Звичайне виправлення: додайте внутрішні відступи (padding). Область натискання збільшиться, навіть якщо значок виглядає так само. І вважайте 24 пікселі нижньою межею: давніший критерій рівня AAA 2.5.5 вимагає 44 на 44.

«Послідовна допомога» й «Повторне введення»: чи не змушуєте ви людей шукати й повторюватися?

Обидва критерії — рівня A. 3.2.6 «Послідовна допомога» вимагає: якщо довідка — контакти, чат чи посилання на FAQ — є на кількох сторінках, вона щоразу має стояти в тому самому порядку відносно решти сторінки. 3.3.7 «Повторне введення» вимагає, щоб людям не доводилося знову вводити дані, які вони вже вказали в межах того самого процесу.

«Послідовна допомога» зовсім не зобов’язує вас пропонувати допомогу. Вона лише каже: якщо на сторінках товарів телефон указано в шапці, він не має переїжджати у футер на етапі оформлення замовлення, де він потрібен найбільше. Найбільше це допомагає людям із порушеннями пам’яті чи уваги. Зазвичай проблему розв’язує спільний шаблон, а не розміщення довідки на кожній сторінці окремо.

«Повторне введення» стосується багатокрокових форм. Форма бронювання, яка питає e-mail на першому кроці й ще раз на третьому, не проходить перевірку; те саме з оформленням замовлення, де доводиться знову вводити ідентичну адресу для рахунку. Заповнюйте поле автоматично або давайте вибрати раніше введене, наприклад прапорцем «Адреса для рахунку збігається з адресою доставки». Винятки: повторне введення принципово необхідне, потрібне для безпеки або попередні дані вже не чинні.

«Доступна автентифікація»: чи можна увійти без перевірки пам’яті?

Критерій успішності 3.3.8 (рівень AA) вимагає, щоб жоден крок входу не спирався на тест когнітивних функцій — запам’ятати пароль, ввести спотворені символи чи розв’язати головоломку, — якщо ви не пропонуєте альтернативи або допомоги. На практиці: дозвольте менеджерам паролів заповнювати поля, дозвольте вставлення й запропонуйте спосіб, що не залежить від пам’яті.

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

• Альтернативний спосіб без когнітивного тесту, наприклад ключ доступу (passkey) або посилання електронною поштою.
• Механізм допомоги, наприклад підтримку менеджерів паролів або копіювання й вставлення, щоб одноразовий код не доводилося передруковувати.
• Розпізнавання об’єктів, наприклад «виберіть зображення з велосипедом».
• Особистий контент, наприклад вибір зображення, яке ви самі завантажили.

Версія рівня AAA, 3.3.9, прибирає два останні варіанти, тож CAPTCHA з картинками може пройти на рівні AA, але не на AAA. Типові порушення: поля пароля, що блокують вставлення чи менеджери паролів, поля одноразового коду, які ламаються під час вставлення, і текстова CAPTCHA без альтернативи. Найбільше виграють люди з дислексією чи порушеннями пам’яті, але проблему впізнає кожен, кому хоч раз не вдалося увійти наприкінці довгого дня.

Чи обов’язковий WCAG 2.2 за законом?

Залежить від того, де ви і хто ви. Закони рідко прямо називають версію WCAG, і чимало досі посилаються на WCAG 2.1 AA. Оскільки WCAG 2.2 зворотно сумісний, відповідність 2.2 AA означає й відповідність 2.1 AA, за винятком вилученого 4.1.1. Ціль 2.2 покриває обидві версії. Якщо версію зазначено в договорі, дотримуйтеся договору.

• Європейський Союз: за Європейським актом про доступність відповідність презюмується, якщо ви виконуєте гармонізований стандарт EN 301 549. За даними AccessibleEU (відкриється в новій вкладці), версія 4.1.1, опублікована у вересні 2026 року, переходить на WCAG 2.2, але ще не є юридичним орієнтиром; доки посилання на неї не з’явиться в Офіційному віснику ЄС, діє v3.2.1 (на основі WCAG 2.1 AA). На кого поширюється акт, розповідає наш розбір Європейського акта про доступність.
• Велика Британія: згідно з настановами уряду (відкриється в новій вкладці), сайти й застосунки публічного сектору мають відповідати WCAG 2.2 AA. Ці настанови стосуються державних органів, а не приватного бізнесу.
• США: правило Міністерства юстиції для органів влади штатів і місцевого самоврядування спирається на WCAG 2.1 AA, а строки його виконання у квітні 2026 року перенесли (відкриється в новій вкладці) на 26 квітня 2027 та 26 квітня 2028 року. Щодо приватного бізнесу, роз’яснення міністерства 2022 року (відкриється в новій вкладці) кажуть, що ADA поширюється на їхні сайти, але не встановлюють конкретного технічного стандарту.

А як щодо WCAG 3?

WCAG 3 — чернетка, тож відповідати їй поки що неможливо. W3C опублікував оновлені чернетки у вересні 2026 року й повідомляє, що завершеним стандартом WCAG 3 стане, як очікується, лише «за кілька років». WCAG 2 не оголосять застарілим ще кілька років після цього, тож орієнтуватися зараз треба на 2.2.

Як перевірити нові критерії за 15 хвилин?

Більшість порушень шести критеріїв рівнів A і AA можна знайти приблизно за 15 хвилин із клавіатурою, телефоном і вашою власною сторінкою входу. Це не замінить повного аудиту чи тестування за участю людей з інвалідністю, але підкаже, з чого почати, і дасть розробникові конкретний перелік завдань.

1. Пройдіть клавішею Tab головною сторінкою, сторінкою товару й оформленням замовлення, коли всі банери відкриті. Фокус завжди видно? (2.4.11)
2. Виконайте кожну дію з повзунком чи перетягуванням лише клацаннями або дотиками. (2.5.7)
3. На телефоні спробуйте натиснути кожну кнопку закриття, номер сторінки й маленький значок. (2.5.8)
4. Порівняйте, де розташовані довідка й контакти на сторінках трьох типів. (3.2.6)
5. Пройдіть купівлю чи бронювання й позначте кожне запитання, на яке відповідаєте двічі. (3.3.7)
6. Увійдіть за допомогою менеджера паролів, потім вставте пароль і одноразовий код. Чи має кожна CAPTCHA альтернативу? (3.3.8)

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

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