Посібники

Ручний аудит доступності: процес і результат

Як проходить ручний аудит за шість етапів, що входить у звіт, навіщо потрібен ACR за шаблоном VPAT і чому офіційного сертифіката WCAG не існує.

Андрій Вдовин

19 вересня 2026 р.

12 хв читання

Коротко

Ручний аудит — це не «ще одне сканування», а шість етапів і набір документів на виході.
Головний артефакт для бізнесу — не список багів, а ACR: звіт про відповідність за шаблоном VPAT.
Офіційного сертифіката WCAG не існує — W3C нікого не акредитує на його видачу.
Замовляти варто на стабільному релізі: на прототипі половина знахідок застаріє раніше, ніж ви їх прочитаєте.

Що саме купують, коли купують аудит

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

Це важливо визнати відверто, бо від цього залежить, який результат вам потрібен. У більшості випадків потрібні два різні документи водночас: технічний список проблем для розробників і формальний звіт про відповідність для тих, хто спитав. Це різні жанри, і плутанина між ними — найчастіша причина розчарування в аудиті.

Ще одна річ, яку варто прийняти заздалегідь: аудит не робить сайт доступним. Він показує стан і дає план. Робота починається після звіту, і саме на ній зазвичай закінчується запал.

Як влаштований процес

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

День 1

Автоматична база й перелік шаблонів

Сканування всіх сторінок кількома незалежними інструментами — щоб не витрачати дорогий ручний час на те, що знаходить машина. На виході — початковий список порушень і перелік унікальних шаблонів, які далі проходяться руками.

Дні 2–3

Скрінрідери й клавіатура

Кожен ключовий сценарій проходиться з NVDA у Firefox, JAWS в Edge, VoiceOver у Safari на macOS та iOS, TalkBack у Chrome на Android. Це найдовша частина: саме тут знаходяться пастки фокуса, невидимі для ока стани й віджети, які озвучуються як набір незрозумілих кнопок.

День 4

Візуальна й колірна перевірка

Контраст за WCAG, симуляція типів колірної сліпоти, режим примусових кольорів, перевірка на різних ширинах вікна, оцінка спалахів. Тут же — збільшення тексту до 200% і перевірка, чи не з’являється горизонтальна прокрутка.

День 5

Когнітивна доступність

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

Дні 6–8

Сесії з реальними користувачами

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

Дні 9–10

Звіт і план дій

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

Як читати звіт, у якому 150 знахідок

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

Тому читати звіт варто не підряд, а зрізами. Робочих зрізи три.

Зріз	Питання, на яке він відповідає	Кому потрібен
За критичністю	Що взагалі блокує сценарій — форма, яку неможливо надіслати, модальне вікно без виходу, оплата, недоступна з клавіатури.	Продукту: що правити цього тижня.
За спільним компонентом	Скільки знахідок насправді є однією помилкою в шапці, картці товару чи полі форми, повтореною на всіх сторінках.	Розробці: тут ховається основна економія годин.
За критерієм	Які пункти стандарту лишаються закритими не повністю — саме в цьому розрізі заповнюється звіт про відповідність.	Юристам і продажам: із цього збирається ACR.

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

VPAT і ACR: документ, який просять під час продажу

VPAT — Voluntary Product Accessibility Template, шаблон, який веде Information Technology Industry Council. Заповнений шаблон називається ACR, Accessibility Conformance Report. Саме його мають на увазі, коли в листі з’являється фраза «надішліть, будь ласка, ваш VPAT».

Шаблон існує в чотирьох редакціях — під WCAG, під Revised Section 508 для США, під EN 301 549 для Європи та об’єднану міжнародну. Редакцію обирають за ринком, на який ви продаєте. Кожному критерію в таблиці присвоюється один із висновків:

Supports — критерій виконується без відомих винятків.
Partially Supports — виконується, але є місця, де ні; вони описуються тут же.
Does Not Support — не виконується.
Not Applicable — критерій не стосується цього продукту.

Ключове, чого зазвичай не пояснюють: ACR — це заява постачальника про власний продукт. Його цінність не в самому факті існування, а в тому, наскільки чесно заповнені графи й наскільки докладно описана методика тестування. Документ, у якому всі рядки — Supports, викликає у досвідченого закупівельника більше підозр, ніж документ із двома десятками Partially Supports і планом виправлень.

«Сертифікат WCAG» не існує як документ

W3C не акредитує жодну організацію на видачу сертифікатів відповідності й прямо про це пише. Тому будь-який «сертифікат доступності» — це висновок конкретної компанії, а не ліцензія. Легітимні форми фіксації результату інші: заява про відповідність за моделлю W3C, окремо описана заява про часткову відповідність, і ACR за шаблоном VPAT. Якщо підрядник пропонує «сертифікувати сайт за WCAG», варто уточнити, що саме він видасть і хто це визнає.

Що має бути в пакеті, крім списку багів

Список проблем — найдешевша частина роботи. Значення має те, що дозволяє цей список виконати.

Звіт із категоризацією

Кожна знахідка з критичністю, критерієм, місцем у коді та оцінкою складності виправлення. Без оцінки складності пріоритезувати неможливо.

Чернетка ACR

Заповнена таблиця за обраною редакцією VPAT — те, що реально просять у закупівлях і enterprise-продажу.

Записи сесій

Відео з озвученням скрінрідера, де чути й видно момент, коли людина зупиняється. Сильніше за будь-який абзац у звіті.

План із пріоритетами

Швидкі перемоги на перші два тижні, середній пріоритет на квартал, архітектурні зміни окремо — з оцінкою годин розробника.

Повторна перевірка

Через місяць після ваших виправлень: без неї невідомо, чи закриті критичні пункти насправді.

Розбір із командою

Година-дві з розробниками. Пояснити системні патерни дешевше один раз голосом, ніж описувати їх у сотні тікетів.

Що спитати в підрядника до оплати

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

1За яким переліком ви тестуєте? Має прозвучати конкретна версія й рівень — WCAG 2.2 AA, EN 301 549 — і згадка про те, які критерії перевіряються вручну. Відповідь «за всіма стандартами» означає, що переліку немає.
2Які скрінрідери й на яких зв’язках? NVDA з Firefox, JAWS з Edge, VoiceOver із Safari — це різні поєднання з різною поведінкою. Один скрінрідер у списку означає одну третину покриття.
3Чи буде чернетка ACR і в якій редакції? Якщо документ потрібен для продажу, редакція шаблона має збігатися з ринком: Section 508 для США, EN 301 549 для ЄС.
4Що входить у повторну перевірку? І чи входить узагалі. Аудит без ретесту лишає вас без відповіді на єдине питання, яке справді цікавить керівництво: ми це виправили чи ні.

Коли аудит передчасний

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

Якщо ви поки що на ранній стадії, розумніший порядок такий: безкоштовні автоматичні інструменти, самостійна перевірка клавіатурою й базове знайомство зі скрінрідером. Про перше й друге ми вже писали окремо — покроковий гайд із тестування і гайд із NVDA, JAWS і VoiceOver. Ручний аудит доречний тоді, коли його результат має шанс дожити до впровадження.

Якщо потрібен зовнішній аудит

Ми проводимо ручне тестування за описаним вище процесом: 5–10 робочих днів, 50 доларів за сторінку, мінімальне замовлення — 10 сторінок. «Сторінка» — це унікальний шаблон або сценарій, а не URL, тож перед розрахунком ми складаємо перелік шаблонів. У пакет входять звіт із категоризацією, чернетка ACR, план дій і повторна перевірка через місяць.

Ручне тестування Автоматичний аудит

Часті запитання

Чи існує офіційний сертифікат відповідності WCAG?

Ні. W3C не акредитує жодну організацію на видачу сертифікатів WCAG і прямо про це пише. Усе, що продається під назвою «сертифікат доступності», — це документ конкретної компанії про те, що вона перевірила сайт і дійшла певного висновку. Легітимні форми фіксації результату інші: заява про відповідність за моделлю W3C і звіт ACR, заповнений за шаблоном VPAT. Обидва документи — це декларація, підкріплена методикою тестування, а не ліцензія.

Що таке VPAT і ACR?

VPAT — Voluntary Product Accessibility Template, шаблон від Information Technology Industry Council. Заповнений шаблон називається ACR, Accessibility Conformance Report. Шаблон має чотири редакції: під WCAG, під Revised Section 508 у США, під EN 301 549 у ЄС і об’єднану міжнародну. Кожен критерій отримує один із висновків: підтримується, підтримується частково, не підтримується, не застосовується. Саме цей документ найчастіше просять під час enterprise-продажу й державних закупівель.

Скільки триває ручний аудит і скільки коштує?

У нас це 5–10 робочих днів залежно від обсягу, і ставка 50 доларів за сторінку з мінімальним замовленням у 10 сторінок. Під «сторінкою» мається на увазі не URL, а унікальний шаблон або сценарій: картка товару перевіряється один раз, а не тисячу. Тому перед розрахунком складається перелік шаблонів, а не вивантаження sitemap.

Коли замовляти аудит не варто?

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

Чи потрібен ручний аудит, якщо автоматичний сканер показує нуль помилок?

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

Джерела та посилання

Останнє оновлення: 19.09.2026