Працює
Академія
Практика

Внутрішній a11y-аудит командою розробки: 7 кроків

Як провести внутрішню перевірку доступності до зовнішнього аудиту — 7 кроків: scope, axe DevTools, клавіатура, скрін-рідер, контраст, план.

· 3 хв читання

Як провести внутрішній a11y-аудит до розробників: 7-крокова інструкція

Зовнішній accessibility-аудит коштує від €1 500 до €5 000 для типового сайту. Перед тим, як замовляти його, варто провести внутрішню перевірку силами власної команди розробки. Це закриває 60–70% проблем, які зовнішній аудитор все одно знайде, і дає вам реальну картину обсягу робіт.

Чому внутрішній аудит

Тренування команди — головна цінність. Розробники, які раз пройшли свій код через axe, NVDA, тест клавіатурою, починають писати a11y-чистий код «на льоту». Це інвестиція в довгострокову якість продукту, а не одноразова витрата.

Що знадобиться

  • Будь-який сучасний браузер (Chrome, Edge, Firefox)
  • Розширення axe DevTools (безкоштовно)
  • Розширення WAVE (безкоштовно)
  • Скрін-рідер: NVDA (Windows) або VoiceOver (Mac)
  • 1 виділений день для невеликого сайту (5–10 ключових сторінок)

Крок 1 · Визначте scope

Не намагайтеся перевірити весь сайт одразу. Виберіть 5–10 критичних сторінок з найбільшим трафіком або найвищою цінністю для користувача. Типово це: головна, каталог, карточка товару/послуги, кошик, форма реєстрації, контакти.

Крок 2 · Автоматичний прохід

Запустіть axe DevTools на кожній обраній сторінці. Результат — список конкретних порушень з severity (critical, serious, moderate, minor). Експортуйте у CSV або скриншоти. Це база.

Очікуйте: автомат знаходить 30–40% реальних проблем. Решта потребує ручної перевірки. Не заспокоюйте себе «зеленим» axe-репортом.

Крок 3 · Перевірка клавіатурою

Закрийте мишку. Натисніть Tab і пройдіть кожну сторінку від початку до кінця:

  • Чи всі інтерактивні елементи отримують focus?
  • Чи видно, де зараз focus (focus-ring)?
  • Чи порядок focus логічний (співпадає з візуальним)?
  • Чи можете ви активувати кожну кнопку через Enter/Space?
  • Чи модалі мають focus-trap (focus не «втікає» назад на сторінку)?
  • Чи Escape закриває модаль?

Виявлені проблеми додайте до списку.

Крок 4 · Перевірка скрін-рідером

Увімкніть NVDA + Firefox (найкраща комбінація для тестування). Пройдіть ті самі 5–10 сторінок через:

  • Заголовки (H)
  • Landmark-блоки (D)
  • Посилання (K)
  • Форми (F)

Якщо щось озвучується як «button», «link» без додаткового пояснення — це баг. Якщо форми не зв'язані з лейблами — баг. Якщо зображення мають порожній або криптичний alt — баг.

Крок 5 · Контраст і zoom

  • Перевірте контраст основного тексту через WebAIM Contrast Checker (вимога WCAG: ≥ 4.5:1)
  • Зробіть Ctrl+Plus на сторінці до 200% масштабу. Чи не з'явився горизонтальний скрол? Чи весь контент видно?
  • Перевірте сторінку у режимі Windows High Contrast (для Windows-користувачів)

Крок 6 · Класифікуйте знайдене

Зведіть весь список (axe + клавіатура + скрін-рідер + контраст) у таблицю з колонками:

  • Сторінка
  • Опис
  • Severity (Critical / Serious / Moderate / Minor)
  • WCAG-критерій
  • Estimated effort (S/M/L)

Прибудьте ригорозними з severity — критичне завдає реального шкоди користувачу.

Крок 7 · Зробіть план виправлень

Розділіть на 3 sprint:

  1. Sprint 1 (тиждень): усі Critical порушення
  2. Sprint 2 (2 тижні): усі Serious + найпоширеніші Moderate
  3. Sprint 3 (1 тиждень): залишок Moderate + Minor

Після цього — повторіть аудит. Зазвичай після 1 sprint Lighthouse Accessibility-score зростає на 15–25 пунктів.

Коли все ж замовляти зовнішнього аудитора

Внутрішній аудит закриває технічну частину. Зовнішній потрібен коли:

  • Сайт орієнтований на регульовану галузь (банкінг, держсектор, e-commerce у ЄС)
  • Потрібен публічний Accessibility Statement з підписом професіонала
  • Виникає юридичне питання (позов, скарга)
  • Внутрішня команда не має досвіду — щоб не пропустити критичне

Що далі

Чи була ця стаття корисною?