Оновлено: .

Доступність перевіряють кількома методами: автоматичним аналізом, ручним дослідженням і проходженням завдань людьми. Жоден із них не замінює решту. Одиницею перевірки має бути завершений сценарій, включно з помилками та відновленням.

Спочатку визначте межі перевірки

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

Наш робочий маршрут: знайти послугу → відкрити опис → заповнити заявку → виправити помилку → надіслати → отримати підтвердження. Для магазину додаються кошик, оплата й повернення; для особистого кабінету — вхід і відновлення доступу. Якщо один обов’язковий крок недоступний, попередні успішні кроки не рятують результат.

Знайти, зрозуміти, виконати, виправити, підтвердити. Кожен перехід потрібен для завершення завдання.
П’ять контрольних точок сценарію. Це робоча схема команди, а не шкала оцінювання WCAG.

Автоматизація: швидкий пошук частини дефектів

WAVE допомагає виявляти помилки та перевіряти структуру сторінки, але не є скринридером і не відтворює точно, як кожен скринридер її прочитає. Він підтримує ручне оцінювання. Нуль знайдених помилок не означає повної відповідності.

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

Ручне проходження без миші

  1. Почніть із завантаження сторінки. Перевірте можливість перейти до основного вмісту й логічний порядок фокуса.
  2. Пройдіть завдання клавіатурою. Перевіряйте доступність усіх дій і відсутність випадкових пасток.
  3. Відкрийте й закрийте кожен складний компонент. Стежте, куди перемістився фокус.
  4. Створіть помилку та виправте її. Переконайтеся, що значення не втрачено і є зрозуміле пояснення.
  5. Перевірте підтвердження: користувач має розуміти, чи виконано дію.

Окремо перевірте вказівник. Мінімальна ціль 24 × 24 CSS px у WCAG 2.5.8 AA має винятки, включно з достатніми проміжками між цілями. 44 × 44 — інший, посилений критерій, а не універсальний мінімум AA. Для дотику можна проєктувати більші цілі, не видаючи проєктне рішення за буквальну вимогу.

Перетягування повинно мати альтернативу з одним вказівником без перетягування, якщо не діє виняток. Наприклад, елемент можна перемістити кнопками «Вище» та «Нижче». Одна клавіатурна альтернатива не покриває потреб людини, яка користується вказівником, але не може утримувати й тягнути.

Перевірка сприйняття та налаштувань

Перевірте текст за 200%, перекомпонування за еквівалента ширини 320 CSS px, користувацькі інтервали та примусові кольори. Перегляньте всі теми, а не лише основну. Звертайте увагу на обрізані помилки, зниклі підписи та перекриття закріпленими панелями.

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

Для руху передбачте зменшення необов’язкової анімації з урахуванням prefers-reduced-motion. Окремо перевіряйте вміст з автоматичним рухом, можливість паузи та спалахи: один медіазапит не підтверджує виконання всіх пов’язаних вимог. Прості інструкції, відсутність зайвого тиску часом і збереження введеного після помилки також впливають на можливість завершити завдання.

Скринридер та участь користувачів

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

Запрошуйте людей із різними потребами до перевірки реальних завдань та оплачуйте цю роботу. Не зводьте дослідження до питання «вам подобається сайт?». Дивіться, чи вдається виконати дію, де потрібна допомога й наскільки зрозуміле відновлення після помилки. Учасники не замінюють перевірку критеріїв, а перевірка критеріїв — учасників.

Який вигляд має корисний опис дефекту

Сценарій: надсилання заявки з неправильним email. Середовище: зазначені версії ОС, браузера та скринридера. Кроки: заповнити форму, ввести некоректну адресу, надіслати. Факт: рамка стала червоною, текст причини відсутній. Наслідок: незрозуміло, яке значення і як виправити. Очікування: помилку названо текстом і пов’язано з полем. Повторна перевірка: помилка сприймається, виправлення зберігається, заявка надсилається.

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

Як зробити результат стійким

Додайте вимоги до компонентів у дизайн-систему: ім’я, роль, стани, клавіатура, фокус, помилки, масштабування. Після змін повторюйте зачеплені сценарії. Виправивши спільний компонент, перевіряйте не лише його стенд, а й сторінки, де він використовується.

У підсумковому звіті розділяйте знайдені проблеми, перевірену область, обмеження перевірки та залишкові ризики. Формулювання «у перевіреній вибірці таких-то станів не знайдено таких-то порушень» інформативніше, ніж нічим не обмежене «сайт на 100% доступний».

Щоб включити ці перевірки до розробки з ШІ-помічником, можна встановити скіл Accessible UI із GitHub. У першій статті є інструкція зі встановлення в Codex і Claude Code.

За результатами дослідження ми створили відкриті скіли для Codex і Claude Code, які допомагають аналізувати й покращувати сайти та застосунки. Accessible UI спрямовує агента під час перевірки семантики, керування клавіатурою, фокуса, форм і контрасту; Adaptive Interfaces допомагає адаптувати інтерфейс до розмірів вікна, масштабу тексту, клавіатури та складаних пристроїв. Агент вивчає поточний проєкт, пропонує обґрунтовані покращення та перевіряє погоджені зміни. Скіли не замінюють перевірку з користувачами й допоміжними технологіями.

Джерела та статус стандартів перевірено 5 листопада 2026 року.