Составление 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 становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность 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 — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение 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 или на почту — ответим в течение часа.