Составление отчёта о соответствии WCAG для сайта

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Составление отчёта о соответствии WCAG для сайта
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1368
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1255
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    963
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1199
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    942
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    956

Разработка отчёта о соответствии WCAG

Законодательные требования к доступности сайтов ужесточаются. Без официального отчёта о соответствии WCAG вы не сможете участвовать в госзакупках, получить ESG-сертификацию или избежать исков от пользователей с ограниченными возможностями. Типичный сценарий: компания тратит миллионы на разработку, но из-за отсутствия alt-текстов или контраста 2.7:1 теряет тендер. При этом многие разработчики уверены, что достаточно автоматической проверки, но Axe-core находит лишь треть критических нарушений. Наши инженеры с 10-летним опытом аудита доступности подготовят документ, который примут любые проверяющие органы, за 5–8 рабочих дней. Всё — под ключ, от тестирования до финального отчёта с планом исправлений.

Почему аудит WCAG обязателен для госзакупок?

В Европе, США и Австралии отсутствие доступности карается штрафами до 10% годового оборота. Несвоевременный аудит может обернуться затратами, в десятки раз превышающими стоимость самого отчёта. Отчёт WCAG — доказательство выполнения обязанностей. Кроме того, многие коммерческие заказчики требуют сертификат доступности как условие тендера.

Какие проблемы решает аудит доступности

  • Юридические риски. Штрафы и судебные иски — реальность. Аудит снижает их вероятность.
  • N+1 ошибок в разметке: изображения без alt, неправильная иерархия заголовков, отсутствие меток форм. Axe-core находит такие ошибки, но не все. Сравнение: автоматика покрывает 30–40% критериев, ручное тестирование — ещё 60%.
  • Проблемы с контролем: контраст текста 2.7:1 вместо минимальных 4.5:1, модальные окна без захвата фокуса, отсутствие live-regions для динамического контента.

Мы не просто фиксируем нарушения — мы предлагаем конкретные исправления с указанием файлов и сроков.

Как ручная проверка дополняет автоматику?

Автоматические инструменты обнаруживают лишь треть критических нарушений — ручная проверка в 2 раза эффективнее при выявлении серьёзных ошибок, таких как клавиатурные ловушки. Наш чеклист включает клавиатурную навигацию (Tab, фокус, модальные окна), работу с экранными читалками (NVDA, VoiceOver) и проверку контраста/масштабирования.

Как мы проводим аудит

Стек: Axe-core 4.x через Playwright, ручное тестирование с NVDA (Firefox), VoiceOver (Safari), клавиатурная навигация.

// scripts/wcag-report-generator.js
const AxeBuilder = require('@axe-core/playwright').default;
const { chromium } = require('@playwright/test');
const fs = require('fs');

const PAGES = [
  { url: 'https://example.com',          name: 'Главная страница' },
  { url: 'https://example.com/catalog',  name: 'Каталог' },
  { url: 'https://example.com/login',    name: 'Вход в систему' },
  { url: 'https://example.com/checkout', name: 'Оформление заказа' },
];

// Маппинг axe rule ID → WCAG критерии
const RULE_TO_WCAG = {
  'color-contrast':   '1.4.3 (Level AA)',
  'image-alt':        '1.1.1 (Level A)',
  'label':            '1.3.1, 4.1.2 (Level A)',
  'button-name':      '4.1.2 (Level A)',
  'link-name':        '2.4.4 (Level A)',
  'heading-order':    '1.3.1 (Level A)',
  'duplicate-id':     '4.1.1 (Level A)',
  'html-has-lang':    '3.1.1 (Level A)',
  'keyboard':         '2.1.1 (Level A)',
  'focus-visible':    '2.4.7 (Level AA)',
};

async function generateReport() {
  const browser = await chromium.launch();
  const allViolations = [];
  const pageSummaries = [];

  for (const pageConfig of PAGES) {
    const page = await browser.newPage();
    await page.goto(pageConfig.url, { waitUntil: 'networkidle' });

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();

    const violations = results.violations.map(v => ({
      rule:       v.id,
      wcag:       RULE_TO_WCAG[v.id] || 'See axe docs',
      impact:     v.impact,
      count:      v.nodes.length,
      description: v.description,
      help_url:   v.helpUrl,
      elements:   v.nodes.slice(0, 3).map(n => n.target[0]),
    }));

    pageSummaries.push({
      name:        pageConfig.name,
      url:         pageConfig.url,
      total:       violations.length,
      critical:    violations.filter(v => v.impact === 'critical').length,
      serious:     violations.filter(v => v.impact === 'serious').length,
      violations,
    });

    allViolations.push(...violations);
    await page.close();
  }

  await browser.close();

  const report = {
    generated_at: new Date().toISOString(),
    standard:     'WCAG 2.1 Level AA',
    tool:         'axe-core 4.x via Playwright',
    pages_tested: PAGES.length,
    total_violations: allViolations.length,
    by_impact: {
      critical: allViolations.filter(v => v.impact === 'critical').length,
      serious:  allViolations.filter(v => v.impact === 'serious').length,
      moderate: allViolations.filter(v => v.impact === 'moderate').length,
      minor:    allViolations.filter(v => v.impact === 'minor').length,
    },
    pages: pageSummaries,
  };

  fs.writeFileSync('wcag-report.json', JSON.stringify(report, null, 2));
  console.log('Отчёт сохранён: wcag-report.json');
  return report;
}

generateReport();

Скрипт автоматически прогоняет указанные страницы через Axe-core, маппит правила на критерии WCAG и формирует JSON-отчёт. Затем вручную проверяем то, что автомат не может: клавиатурные ловушки, порядок фокуса, работу скринридеров.

Что входит в отчёт

Раздел Описание
Методология Используемые инструменты, версии, критерии проверки
Принципы POUR Сводка по восприимчивости, управляемости, понятности, надёжности
Детальные результаты Постраничный перечень нарушений с правилом, Impact, количеством элементов
План устранения Приоритет, сроки, ответственные, конкретные исправления
Рекомендации Лучшие практики для поддержания доступности
Резюме для руководства Количественные показатели по критичности и соответствию стандарту

Ручное тестирование: чеклист

Автоматика покрывает ~40% критериев. Оставшиеся проверяются вручную:

  • Клавиатурная навигация: все интерактивные элементы достижимы через Tab, порядок фокуса логичен, модальные окна перехватывают фокус, Escape закрывает.
  • Экранные читалки: NVDA + Firefox (формы, таблицы, модальные окна), VoiceOver + Safari (мобильные жесты), live regions для динамики.
  • Контраст и масштаб: текст проходит 4.5:1 при обычном и 3:1 при крупном, zoom 400% без скролла, режим высокого контраста Windows.

Пример типичных нарушений:

Критерий WCAG Проблема Решение
1.1.1 (A) Изображения без alt Добавить alt="" для декоративных, осмысленный — для информационных
1.4.3 (AA) Контраст 2.7:1 Изменить цвет на #6b7280 (4.6:1)
2.1.1 (A) Клавиатурная ловушка Добавить обработчики focus и blur

Процесс работы

  1. Аналитика: изучаем структуру сайта, определяем набор страниц для аудита.
  2. Автоматическое тестирование: прогоняем Axe-core на всех выбранных URL, получаем JSON-лог.
  3. Ручная проверка: клавиатура, экранные читалки, контраст — фиксируем неочевидные нарушения.
  4. Составление отчёта: формируем документ с таблицами, диаграммами, планом исправлений.
  5. Финальная вычистка и передача: проверяем корректность критериев, отправляем PDF и Excel.

Сроки и стоимость

Сроки: от 5 до 8 рабочих дней в зависимости от размера сайта (до 10 страниц — 5 дней, свыше — до 8). Стоимость рассчитывается индивидуально после технического анализа. Получите консультацию и коммерческое предложение в течение дня.

Почему выбирают нас?

  • Опыт сертифицированных аудиторов — 10+ лет, 50+ выполненных проектов.
  • Гарантируем признание отчёта госорганами и аудиторами.
  • Включаем план исправлений с приоритетами — вы сразу знаете, что делать.

Закажите аудит доступности сегодня — получите детальный отчёт с планом исправлений за 5–8 рабочих дней.

Доступность сайтов: 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.

Пример реализации кастомного комбобокса с ARIA
<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 вступила в силу с новыми критериями:

Критерий Уровень Суть
2.5.7 Dragging Movements AA Все drag-операции должны иметь клавиатурную альтернативу
2.5.8 Target Size AA Минимальный размер интерактивного элемента 24×24 px
3.2.6 Consistent Help A Расположение контакта/чата должно быть одинаковым на всех страницах
3.3.7 Redundant Entry A Не заставлять вводить одну информацию дважды в одной сессии

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Уровень Минимальный контраст текста Контраст крупного текста
AA 4.5:1 3:1
AAA 7:1 4.5:1

Аудит и устранение нарушений

Автоматические инструменты находят около 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 на момент сдачи

Сроки

Этап Длительность
Аудит сайта (до 50 страниц) 3–7 дней
Устранение нарушений A/AA на существующем проекте 3–8 недель
Разработка нового проекта с соблюдением WCAG 2.2 AA от 6 недель

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

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

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

Уровни веб-доступности a11y по стандарту WCAG 2.2: A, AA, AAA — уровни веб-доступности a11y по версии 2.2.

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