Складання VPAT для сайту: шаблон звіту доступності

Складання VPAT — шаблону звіту про доступність

При участі в тендерах для урядових установ США або комерційних закупівлях великих корпорацій без документа VPAT (Voluntary Product Accessibility Template) заявка автоматично відхиляється. Підготовка цього звіту вручну займає тижні та вимагає глибокого розуміння стандартів WCAG та Section 508. Ми складаємо VPAT під ключ: проводимо аудит доступності, документуємо кожен критерій та готуємо фінальний звіт, придатний для замовників. В результаті ви отримуєте документ, який не тільки відкриває доступ до держконтрактів, але й підвищує довіру користувачів з обмеженими можливостями.

Версії VPAT

Шаблони VPAT доступні на сайті IT Industry Council (itic.org). Вибір версії визначає вимоги до аудиту.

Чому VPAT обов'язковий для держзакупівель?

Державні контракти в США та Європі вимагають підтвердження доступності. Відсутність VPAT веде до відхилення заявки або штрафів до 10% бюджету. Компанії, які ігнорують це, втрачають доступ до мільйонних контрактів. Наш досвід показує: навіть часткова відповідність WCAG 2.1 рівня AA суттєво збільшує шанси на перемогу. Економія часу та бюджету за рахунок автоматизації чернетки — до 40%.

Які ризики відсутності VPAT?

Окрім штрафів до 10% бюджету, відсутність VPAT блокує участь у закупівлях таких гігантів, як державні IT-системи США (GSA) та європейські держструктури. Репутаційні ризики: користувачі з інвалідністю можуть подати скаргу на недоступність сайту, що загрожує судовими позовами. У деяких юрисдикціях відсутність звіту прирівнюється до порушення закону про інвалідність (наприклад, ADA в США).

Структура VPAT

VPAT складається з таблиць по кожному розділу WCAG. Для кожного критерію вказується рівень підтримки:

Що включає аудит доступності?

Аудит — основа VPAT. Ми проводимо систематичне ручне тестування з екранними читалками (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari) та автоматизованими інструментами (axe-core, WAVE). Перевіряються всі WCAG Success Criteria рівня A та AA: клавіатурне керування, контраст, семантика, анімації, альтернативний текст, ARIA-атрибути. Особлива увага — критичним помилкам: відсутність фокусу, пастки клавіатури, нечитабельні контрасти.

Процес підготовки VPAT

Крок 1: Аудит продукту

Проводиться систематичне ручне тестування з екранними читалками (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari) та автоматизованими інструментами (axe-core, WAVE). Тестуємо всі розділи: клавіатурне керування, контраст, семантику, анімації.

Крок 2: Заповнення критеріїв

Для кожного WCAG Success Criterion (всього 78 для рівня AA в 2.1):

1.1.1 Non-text Content (Level A)
  Criteria: Supports
  Remarks: All images have appropriate alt text. Decorative images
           use empty alt="" attribute. Complex charts include
           long description via aria-describedby.

Крок 3: Документування обмежень

1.4.3 Contrast (Minimum) (Level AA)
  Criteria: Partially Supports
  Remarks: Most text meets 4.5:1 contrast ratio requirement.
           Exception: placeholder text in form fields uses #9ca3af
           on white background (2.7:1 ratio). Fix planned in upcoming release.
           Workaround: Users can use browser high contrast mode.

Як прискорити складання VPAT за допомогою автоматизації?

Автоматичне заповнення VPAT у 2-3 рази швидше за ручне, але точність вимагає ручної верифікації. Використовуйте скрипт для генерації чернетки:

// scripts/generate-vpat-draft.js
// На основі звіту axe-core створюємо чернетку VPAT

const WCAG_CRITERIA = require('./wcag-criteria.json');  // Список всіх критеріїв

async function generateVpatDraft(axeReport) {
  const violations = new Set(axeReport.violations.map(v => v.tags).flat()
    .filter(t => t.startsWith('wcag')));

  const draft = WCAG_CRITERIA.map(criterion => ({
    id:       criterion.id,
    title:    criterion.title,
    level:    criterion.level,
    support:  violations.has(criterion.wcag_tag) ? 'Partially Supports' : 'Supports',
    remarks:  violations.has(criterion.wcag_tag)
      ? `Automated testing found issues: ${axeReport.violations.filter(v => v.tags.includes(criterion.wcag_tag)).map(v => v.description).join('; ')}`
      : 'No issues detected in automated testing. Manual verification recommended.',
  }));

  // Генеруємо Markdown
  return draft.map(c =>
    `### ${c.id} ${c.title} (Level ${c.level})\n\n**${c.support}**\n\n${c.remarks}\n`
  ).join('\n');
}

Чернетка вимагає обов'язкової ручної перевірки — автоматика покриває близько 40% критеріїв. Решта 60% — нюанси клавіатури, фокус-стилі, prefers-reduced-motion.

Що зазвичай перевіряється вручну

• Робота з клавіатурою (Tab/Shift+Tab/Enter/Space/Escape/стрілки)
• Сумісність з NVDA, JAWS, VoiceOver
• Zoom 200% та 400% без втрати функціональності
• Режим високого контрасту Windows
• Анімації при prefers-reduced-motion
• Сесійні таймаути та попередження

Що входить в роботу

• Повний аудит доступності зі звітом по кожному критерію
• Заповнення VPAT 2.4 (потрібна версія)
• Документування знайдених обмежень та рекомендації з виправлення
• Фінальний звіт для надання замовнику
• Навчання команди щодо підтримки VPAT в актуальному стані

Гарантуємо конфіденційність даних. Всі сертифіковані спеціалісти мають досвід роботи з WCAG 2.1/2.2.

Терміни

Аудит, заповнення VPAT 2.4 та його рев'ю займають від 5 до 10 робочих днів залежно від складності продукту. Для термінових проєктів можлива прискорена підготовка.

Замовте аудит доступності — і ми підготуємо VPAT за 5–10 днів. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту.

Доступність сайтів: WCAG, скрінридери, клавіатурна навігація

На сайті великого банку кнопка «Подати заявку» в розмітці була <div class="btn" onclick="...">. Скрінридер NVDA її не анонсував, Tab пропускав, Enter не спрацьовував. Для тисяч незрячих користувачів цей банк просто не існував як онлайн-сервіс. Ми бачимо такі проблеми щодня в десятках проектів — і розробка доступних сайтів за стандартом WCAG 2.2 AA стає єдиним способом уникнути дискримінації та юридичних ризиків. Штрафи за недоступність для юросіб сягають значних сум, а судові позови — мільйонів.

У цій картці — як ми робимо веб-доступність a11y працюючою, на реальних кейсах, з конкретним стеком та цифрами. Без загальних фраз.

Чому семантична розмітка — основа веб-доступності a11y?

Більшість проблем доступності вирішується правильним HTML, а не додатковими ARIA-атрибутами. <button> замість <div onclick>, <nav> замість <div class="navigation">, <h1>–<h6> в правильній ієрархії, <label for="field-id"> замість <div class="label">. Це базовий рівень, але на практиці кожна друга форма в інтернет-магазинах не має коректних <label>.

ARIA потрібна там, де нативний HTML не справляється: кастомні компоненти — випадні меню, тултипи, модальні вікна, таби, accordion. І ось тут починається складність.

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

• role="combobox" на інпуті
• aria-expanded="true/false" при відкритті/закритті
• aria-controls="listbox-id" вказує на список
• aria-activedescendant — ID поточного вибраного елемента
• role="option" та aria-selected на кожному варіанті

Це не теорія, це те, що тестується скрінридером. NVDA + Chrome або VoiceOver + Safari — обов'язкова частина QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Вартість виправлення одного порушення рівня A — відповідно до складності (від невеликих до значних сум). Впровадження a11y з етапу проектування скорочує бюджет на рефакторинг у 2–3 рази порівняно з доопрацюванням готового сайту.

Як правильно побудувати клавіатурну навігацію?

Tab-порядок має збігатися з візуальним порядком елементів. Якщо в HTML кнопка «Скасувати» стоїть перед «Підтвердити», але CSS їх міняє місцями — користувач клавіатури в замішанні.

Focus trap в модальних вікнах. Коли модалка відкривається, Tab має циклітися тільки всередині неї. При закритті — повернення фокусу на елемент, який відкрив модалку. Без цього користувач після закриття опиняється на початку сторінки.

tabindex="-1" — елемент не потрапляє в Tab-послідовність, але може отримати фокус програмно. Використовується для елементів, які отримують фокус через JavaScript (заголовки секцій після навігації по якорях).

tabindex="1" і вище — майже завжди помилка. Явний порядок ламає природний і створює непередбачувану поведінку. Керуйте порядком через DOM, не через tabindex.

Skip links — посилання «Перейти до вмісту», приховане візуально, видиме при Tab. Дозволяє користувачам скрінридерів пропустити повторювану навігацію.

Колір та контраст: вимоги та часті порушення

WCAG 2.2 AA вимагає контраст 4.5:1 для звичайного тексту, 3:1 для великого (18px+ або 14px+ bold). AAA вимагає 7:1 та 4.5:1.

Найчастіші порушення: сірий placeholder в інпутах (#999 на білому = 2.9:1), світло-сірий secondary текст, білий текст на пастельному фоні.

Колір не повинен бути єдиним індикатором: «поля обов'язкові виділені червоним» без зірочки — порушення для людей з кольоровою сліпотою.

Інструменти перевірки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core інтегрується в Playwright-тести: автоматична перевірка на 80+ правил при кожному деплої. Ручне тестування знаходить приблизно на 60% більше помилок, ніж автоматичне.

Медіаконтент та динаміка: що важливо?

Зображення без alt — частий базовий провал. alt має бути смисловим: не alt="image_123.jpg", а опис вмісту, релевантний контексту. Декоративні зображення — alt="" (порожній, не відсутній атрибут).

Відео повинно мати субтитри. YouTube автосубтитри — не стандарт, вони помиляються. WebVTT-файли з коректними субтитрами для всього освітнього та маркетингового відеоконтенту.

Анімації — проблема для користувачів з вестибулярними розладами. @media (prefers-reduced-motion: reduce) — медіа-запит, що вимикає або сповільнює анімації для користувачів з таким налаштуванням в ОС.

Що змінилося в WCAG 2.2?

Версія 2.2 набрала чинності з новими критеріями:

Ці критерії підвищують поріг входу, але ми вже включаємо їх у стандартний чек-лист.

Аудит та усунення порушень

Автоматичні інструменти знаходять близько 30–40% порушень. Решта — тільки ручне тестування. Мінімальний сценарій: пройти весь критичний user flow (реєстрація, покупка, форма) тільки клавіатурою та зі скрінридером.

Процес роботи

1. Автоматичний аудит — axe-core, Lighthouse, WAVE — видача 80+ правил.
2. Ручне тестування — NVDA, VoiceOver, клавіатура — 2–3 дні на типовий сайт.
3. Пріоритизація порушень — P1 (блокує використання), P2 (створює складності), P3 (покращення).
4. Виправлення — ітераціями, вбудовуємо перевірки в CI через Playwright + axe.
5. Повторний аудит — закриття всіх P1/P2 перед релізом.
6. Документація та передача — звіт з результатами, рекомендації по підтримці, навчання команди.

Результати та обсяг робіт

• Повний звіт по аудиту з пріоритизацією порушень (PDF/HTML)
• Виправлений код: семантична розмітка, ARIA, клавіатурна навігація
• Інтеграція axe-core в CI/CD для регресійного контролю
• Навчання розробників замовника по роботі з a11y (2-годинна сесія)
• Доступ до репозиторію з прикладами коректних компонентів
• Гарантія відповідності WCAG 2.2 AA на момент здачі

Терміни

Бюджет розраховується індивідуально після аудиту. Зв'яжіться з нами — оцінимо ваш проект за 1 день. Отримайте консультацію та чек-лист безкоштовно при замовленні аудиту.

Досвід та гарантії

Ми займаємося веб-доступністю a11y понад 8 років. Реалізували понад 50 проектів для банків, рітейлу та держсектора. Сертифіковані спеціалісти (IAAP CPACC, WAS). Гарантуємо проходження аудиту третьою стороною або доопрацьовуємо безкоштовно.

Стандарт WCAG 2.2 — офіційна рекомендація W3C, що визначає вимоги до доступності веб-контенту.

Wikipedia: Web Content Accessibility Guidelines Wikipedia: ARIA

— рівні веб-доступності a11y за версією 2.2.

Замовте аудит зараз — отримайте чек-лист та попередню оцінку безкоштовно. Пишіть в Telegram або на пошту — відповімо протягом години.