Як читати WCAG 2.2 для власного сайту, виправити типові проблеми, провести 30-хвилинну самостійну перевірку й зрозуміти взаємозв’язок доступності та зручності.
Поширені запитання
Що означає відповідність сайту WCAG?
Сайт відповідає критеріям успішності Настанов із доступності вебконтенту на обраному рівні, зазвичай рівні AA стандарту WCAG 2.1 чи 2.2. Рівень AA включає всі критерії рівнів A та AA. Більшість законів і політик закупівель, які посилаються на WCAG, вимагають рівня AA.
Як застосувати настанови WCAG до свого сайту?
Почніть із короткого довідника W3C «Як відповідати WCAG», залиште критерії рівнів A й AA, а для кожного прочитайте сторінку «Розуміння», що пояснює мету простою мовою. Перевіряйте основні шаблони (головну, сторінку контенту, форму й оформлення покупки), а не кожну сторінку окремо.
Чи може накладка або плагін доступності забезпечити відповідність сайту?
Ні. Жоден інструмент самостійно не зробить сайт відповідним вимогам. Накладки з панеллю інструментів не виправляють базовий код і, за повідомленнями користувачів із інвалідністю та фахівців, часто заважають. Виправляйте безпосередньо HTML, контраст, підписи й підтримку клавіатури.
Чим відрізняється зручність від доступності?
Доступність означає, що люди з інвалідністю можуть сприймати, розуміти, переглядати сайт і взаємодіяти з ним. Зручність — що сайт простий і ефективний для всіх. Ці поняття тісно пов’язані: зрозумілі підписи, контраст і передбачувана навігація допомагають кожному.
Чи знаходять автоматичні перевірки всі проблеми доступності?
Ні. Інструменти на кшталт WAVE, axe й Lighthouse виявляють відсутність альтернативного тексту, слабкий контраст і підписи, але деякі критерії — наприклад, чи змістовний альтернативний текст і чи логічний порядок фокуса — має перевірити людина.
Сайт, що відповідає WCAG, дотримується Настанов із доступності вебконтенту на обраному рівні. Для майже кожного бізнесу це означає WCAG 2.2, рівень AA. На практиці більшість сайтів має однакові проблеми: низький контраст кольорів, відсутні альтернативні описи зображень, підписи полів форми, порожні посилання й кнопки, а також елементи, недоступні з клавіатури. Виправте їх, перевірте клавіатурою й програмою зчитування з екрана — і охопите чимало реальних перешкод для користувачів.
Цей посібник пояснює, як читати WCAG, не загубившись у стандарті, які виправлення найважливіші та як провести самостійну 30-хвилинну перевірку.
Структура WCAG
WCAG публікує W3C. Стандарт має кілька рівнів:
Чотири принципи, відомі як POUR: контент має бути сприйнятним (Perceivable), функціональним (Operable), зрозумілим (Understandable) і надійним (Robust).
Настанови для кожного принципу, наприклад «Текстові альтернативи» чи «Доступність з клавіатури».
Критерії успішності кожної настанови — перевірювані правила з номером (наприклад, 1.4.3 «Контраст») і рівнем A, AA чи AAA.
Рівень A — мінімальний. Рівень AA зазвичай вимагають закони й політики закупівель. Рівень AAA суворіший і зазвичай не потрібен для всього сайту.
У жовтні 2023 року WCAG 2.2 отримав статус рекомендації W3C. Додано критерії мінімального розміру цілей натискання, видимості фокуса й доступної автентифікації; критерій 4.1.1 «Розбір» вилучено як застарілий.
Як застосувати WCAG до власного сайту
Стандарт написано як технічну специфікацію — бо це вона і є. Скористайтеся таким практичним порядком:
Для кожного критерію прочитайте пов’язану сторінку «Розуміння». Вона простою мовою пояснює призначення та містить приклади відповідності й порушень.
Замість кожної сторінки перевірте шаблони: головну, звичайну сторінку, допис блогу, форму й сторінку товару чи оформлення покупки. Виправлення шаблону вплине на всі сторінки на його основі.
Записуйте проблему разом із номером критерію, сторінкою та способом виправлення.
Виправлення, що усувають більшість поширених проблем
1. Контраст кольорів (1.4.3 і 1.4.11)
Звичайний текст: щонайменше 4.5:1 відносно тла.
Великий текст (приблизно 24 px звичайного накреслення або від 18.66 px жирного): щонайменше 3:1.
Елементи інтерфейсу й змістовна графіка (рамки кнопок, контури полів, інформаційні піктограми): щонайменше 3:1.
Типові проблеми — світло-сірий текст підказок і білий текст на блідих кольорах бренду. Перевірте їх засобом WebAIM Contrast Checker чи інструментами розробника браузера.
2. Текстові альтернативи зображень (1.1.1)
Для змістовних зображень додайте опис важливої інформації: alt="Технік замінює фільтр печі".
Декоративним зображенням задайте порожній alt: alt="", щоб програма зчитування пропустила їх.
Текст на зображенні (фото листівки чи меню у JPG) має дублюватися звичайним текстом.
Для зображень-посилань, наприклад логотипа, що веде на головну, зазначте ціль: alt="Головна Acme Plumbing".
3. Підписи й помилки у формах (1.3.1, 3.3.1, 3.3.2)
До кожного поля потрібен видимий <label>, прив’язаний до поля. Текст-підказка всередині поля не є підписом: він зникає після введення.
Повідомлення має пояснювати, що не так і як виправити («Введіть телефон із кодом міста») — текстом, а не лише червоною рамкою.
Позначайте обов’язкові поля текстом або доступним для зчитування сигналом, не лише кольором.
4. Керування клавіатурою (2.1.1, 2.4.3, 2.4.7)
Усі посилання, кнопки, меню й поля мають працювати клавішами Tab, Shift+Tab, Enter і Space.
Порядок фокуса має відповідати візуальному порядку.
Показуйте видимий індикатор фокуса. Видалення обведення браузера через outline: none без заміни — поширена помилка.
Випадаючі меню й модальні вікна мають відкриватися, працювати й закриватися з клавіатури; модальне вікно має утримувати фокус усередині, доки його не закриють.
5. Іменовані посилання й кнопки (2.4.4, 4.1.2)
Кнопкам лише з піктограмами (меню-гамбургер, пошук, соціальні мережі) потрібне доступне ім’я: видимий текст, aria-label чи прихований текст.
Не заповнюйте сторінку посиланнями «Натисніть тут» і «Докладніше». Назвіть ціль у тексті посилання або задайте кожному унікальне доступне ім’я.
6. Структура й заголовки (1.3.1, 2.4.6)
На кожній сторінці має бути один <h1> із її назвою.
Дотримуйтеся логічного порядку заголовків (h2 для розділів, h3 для підрозділів), а не обирайте їх за розміром шрифту.
Використовуйте справжні списки, таблиці із заголовковими клітинками й орієнтири (<header>, <nav>, <main>, <footer>).
Задайте мову сторінки: <html lang="en">.
7. Нові критерії WCAG 2.2, які варто знати
2.5.8 Розмір цілі (мінімальний), AA: цілі натискання мають бути щонайменше 24 × 24 CSS-пікселі або мати достатній відступ від менших.
2.4.11 Фокус не перекрито (мінімальний), AA: закріплені заголовки, банери cookies й чат-віджети не мають повністю закривати елемент у фокусі.
3.3.8 Доступна автентифікація (мінімальна), AA: не вимагайте розв’язувати головоломки чи запам’ятовувати дані для входу без альтернативи; підтримуйте менеджери паролів і вставлення.
3.3.7 Повторне введення даних, A: не змушуйте вводити знову інформацію, яку людина вже надала в тому самому процесі.
8. Медіа й анімація
Для відео потрібні субтитри (1.2.2); до записаного відео потрібен аудіоопис або текстова альтернатива важливої візуальної інформації.
Автоматичний рух тривалістю понад п’ять секунд має мати можливість призупинення (2.2.2).
Дотримуйтеся параметра prefers-reduced-motion для великих анімацій.
Самостійна 30-хвилинна перевірка
Автоматичні інструменти виявляють лише частину проблем. Додайте таку перевірку для кожного важливого шаблону.
Хвилини 0–5: автоматичне сканування. Запустіть розширення WAVE чи axe DevTools або перевірку доступності в Lighthouse. Виправте очевидні помилки: відсутній alt, підписи та контраст.
Хвилини 5–15: лише клавіатура. Відкладіть мишу. Перейдіть Tab-ом від початку сторінки.
Чи завжди видно, де перебуває фокус?
Чи можна відкрити й закрити меню, заповнити й надіслати кожне поле?
Чи працює посилання «Перейти до вмісту»?
Чи не зникає фокус за закріпленим заголовком або банером?
Хвилини 15–25: програма зчитування з екрана. Скористайтеся VoiceOver (вбудована в macOS та iOS) або NVDA (безплатна для Windows).
Прослухайте список заголовків. Чи описує він сторінку?
Перейдіть до зображень і кнопок. Чи зрозумілий їхній зміст без контексту?
Заповніть форму. Чи оголошується підпис кожного поля? Чи зачитуються помилки?
Хвилини 25–30: збільшення й перебудова. Збільште браузер до 200%, а потім до 400%. За 400% контент має переходити в одну колонку без горизонтального прокручування (1.4.10 «Перебудова»), і нічого не має обрізатися.
Спільне між зручністю й доступністю
Ті, хто шукає «зручність і доступність сайтів», правильно поєднують ці поняття. Майже кожне виправлення доступності також покращує зручність:
Виправлення доступності
Кому ще допомагає
Високий контраст
Кожному, хто користується телефоном на сонці
Видимі підписи
Тим, хто поспіхом заповнює форму
Субтитри
Людям, які дивляться без звуку
Керування клавіатурою
Досвідченим користувачам і тим, у кого зламався тачпад
Більші області натискання
Усім на мобільних пристроях
Чіткі повідомлення про помилки
Усім, хто припускається описки
Накладки, заяви й законодавство
Накладки: віджети з обіцянкою відповідності «одним рядком» не змінюють базовий код. Виправляйте сам сайт.
Заява про доступність: опублікуйте коротку сторінку з цільовим стандартом, відомими проблемами й контактами для допомоги чи альтернативних форматів.
Правові вимоги: вони різняться залежно від країни. Європейський акт про доступність із червня 2025 року застосовується до багатьох продуктів і послуг у ЄС; у США до сайтів часто застосовують ADA; для державного сектору діють окремі правила. Для своєї ситуації зверніться по юридичну консультацію.
Контрольний список
[ ] Контраст: текст 4.5:1, великий текст і компоненти інтерфейсу 3:1
[ ] Альтернативний текст для змістовних зображень; порожній alt для декоративних
[ ] Видимий прив’язаний підпис кожного поля
[ ] Увесь сайт працює клавіатурою, фокус видимий
[ ] Кнопки-піктограми мають доступні назви
[ ] Логічні заголовки й орієнтири, задана мова сторінки
[ ] Цілі натискання щонайменше 24 × 24 CSS-пікселі
[ ] Для відео є субтитри, для руху — кнопка призупинення
[ ] Перебудова сторінки за збільшення до 400%
[ ] Опублікована заява про доступність
Доступність також допомагає пошуковому просуванню: заголовки, альтернативний текст і зрозумілі посилання є основами внутрішнього SEO. Докладніше — у контрольному списку внутрішнього SEO.
We.Inc створює сайти як стандартний код HTML, CSS і React, який можна редагувати: виправте підписи, альтернативний текст і контраст самі або попросіть про це в чаті. Усе опубліковане однаково перевіряйте вручну за списком вище.