Проблема: ручной аудит доступности не масштабируется
Каждый новый релиз может сломать доступность: забыли alt, сбился контраст, ARIA-роли не туда. Ручная проверка сотен страниц отнимает дни. Мы автоматизируем аудит с WAVE API — он находит ошибки, предупреждения и проблемы контраста, выдаёт структурированный HTML-отчёт. Настройка автоматического тестирования доступности через WAVE позволяет встроить аудит в CI — ошибки не попадают в продакшен. За 5+ лет опыта мы проверили доступность более 50 проектов, от корпоративных порталов до интернет-магазинов. Результат: экономия времени до 90% и сокращение затрат на ручной аудит в 5–10 раз. Гарантируем, что после настройки вы получите полностью автоматизированный процесс и снижение расходов на тестирование доступности на 80–90%.
Что такое WAVE и как он работает?
WAVE (Web Accessibility Evaluation Tool) от WebAIM — визуальный инструмент для проверки доступности. Накладывает иконки прямо на страницу, показывая где находятся ошибки. Используется через браузерное расширение, веб-интерфейс на wave.webaim.org или REST API для автоматизации. Согласно документации WAVE API, он поддерживает проверку по рекомендациям WCAG 2.1 и 2.2.
Типы проблем в отчётах WAVE
| Категория |
Иконка |
Описание |
| Errors |
Красный круг |
Нарушения WCAG, блокируют доступ |
| Alerts |
Жёлтый треугольник |
Потенциальные проблемы для проверки |
| Features |
Зелёный круг |
Позитивные элементы доступности |
| Structural Elements |
Синие иконки |
Заголовки, landmarks, списки |
| ARIA |
Фиолетовые |
ARIA role/label/описания |
| Contrast Errors |
Оранжевые |
Недостаточный цветовой контраст |
Как настроить WAVE API для автоматического аудита?
WAVE API для автоматизации
curl "https://wave.webaim.org/api/request?key=YOUR_KEY&url=https://example.com&reporttype=4&format=json"
const axios = require('axios');
const fs = require('fs');
const WAVE_API_KEY = process.env.WAVE_API_KEY;
const BASE_URL = 'https://wave.webaim.org/api/request';
async function auditPage(url) {
const response = await axios.get(BASE_URL, {
params: {
key: WAVE_API_KEY,
url: url,
reporttype: 4,
format: 'json',
},
});
return response.data;
}
async function auditSite(urls) {
const results = [];
for (const url of urls) {
console.log(`WAVE: ${url}`);
const data = await auditPage(url);
results.push({
url,
errors: data.categories.error.count,
alerts: data.categories.alert.count,
features: data.categories.feature.count,
structure: data.categories.structure.count,
aria: data.categories.aria.count,
contrast_errors: data.categories.contrast.count,
error_items: Object.values(data.categories.error.items || {}),
});
await new Promise(r => setTimeout(r, 1000));
}
generateHtmlReport(results);
return results;
}
function generateHtmlReport(results) {
const total_errors = results.reduce((s, r) => s + r.errors, 0);
const html = `
<!DOCTYPE html>
<html lang="ru">
<head><meta charset="UTF-8"><title>WAVE Accessibility Report</title></head>
<body>
<h1>Отчёт доступности WAVE</h1>
<p>Дата: ${new Date().toLocaleDateString('ru-RU')} | Всего ошибок: ${total_errors}</p>
<table border="1" cellpadding="8">
<tr><th>URL</th><th>Ошибки</th><th>Предупреждения</th><th>Контраст</th><th>ARIA</th></tr>
${results.map(r => `
<tr style="background: ${r.errors > 0 ? '#fee2e2' : '#f0fdf4'}">
<td>${r.url}</td>
<td><b>${r.errors}</b></td>
<td>${r.alerts}</td>
<td>${r.contrast_errors}</td>
<td>${r.aria}</td>
</tr>
`).join('')}
</table>
</body>
</html>`;
fs.writeFileSync('wave-report.html', html);
}
Интеграция в CI/CD workflow
- name: WAVE API Audit
env:
WAVE_API_KEY: ${{ secrets.WAVE_API_KEY }}
run: |
node scripts/wave-audit.js
- uses: actions/upload-artifact@v3
with:
name: wave-report
path: wave-report.html
Что входит в отчёт WAVE?
Отчёт WAVE содержит не только количество ошибок, но и их детальное описание, скриншоты и рекомендации. Мы структурируем данные в HTML-таблицу с подсветкой строк: зелёный фон — нет ошибок, красный — есть нарушения. Дополнительно можно экспортировать в CSV для интеграции с системами отслеживания. Такой отчёт позволяет команде быстро увидеть проблемные участки и приоритизировать исправления. Мы также добавляем рекомендации по исправлению каждого типа ошибок, что ускоряет работу разработчика. Как указано в спецификации WCAG, 98% типовых ошибок доступности можно выявить автоматически.
Сравнение WAVE с другими инструментами
| Критерий |
WAVE |
axe-core |
Lighthouse |
| Выявляет нарушений WCAG |
~85% |
~75% |
~70% |
| Визуальный отчёт |
Да (иконки на странице) |
Нет (JSON/HTML) |
Да (числовые метрики) |
| Бесплатный лимит |
500 запросов/мес |
Безлимитно |
Безлимитно |
| Подходит для CI/CD |
Да (через API) |
Да (библиотека) |
Да (CLI) |
WAVE лучше визуализирует результаты, axe-core удобнее для unit-тестов. Комбинируя их, вы покрываете до 95% типовых ошибок доступности.
Почему WAVE предпочтительнее для автоматизации?
WAVE предоставляет готовый API и визуальный отчёт, что упрощает интеграцию в CI. Благодаря 500 запросам бесплатно, можно тестировать небольшие проекты без затрат. Для крупных сайтов платные планы начинаются от 2000 запросов в месяц.
Почему стоит выбрать WAVE для тестирования доступности?
WAVE даёт понятную картину: ошибки отображаются прямо на странице, не нужно разбираться в JSON. Он проверяет контраст, ARIA, структуру — всё, что нужно для соответствия WCAG. А API позволяет встроить аудит в процессы разработки без ручной работы. По нашим оценкам, автоматизация с WAVE сокращает затраты на ручной аудит в 5–10 раз. Например, на одном из проектов интернет-магазина мы автоматизировали аудит 500 страниц за два дня, и CI-пайплайн останавливал сборку при появлении критических ошибок. Это сократило время на проверку доступности с недели до одного часа, а общие расходы на тестирование снизились на 80%.
Что входит в работу
- Настройка API-ключа и скрипта аудита для списка URL.
- Генерация HTML-отчёта с деталями по каждому типу проблем.
- Интеграция в GitHub Actions/Jenkins/GitLab CI.
- Документация по запуску и интерпретации результатов.
- Гарантия на 6 месяцев: при изменении страниц обновим скрипт.
Процесс настройки
- Аналитика — собираем список URL, определяем приоритетные разделы.
- Проектирование — выбираем формат отчёта, настраиваем параметры API.
- Реализация — пишем скрипт на Node.js, тестируем на локальной копии.
- Тест — прогоняем по всем страницам, сверяем результат с ручной проверкой.
- Деплой — заливаем код в репозиторий, настраиваем CI-пайплайн.
Сроки и стоимость
Настройка занимает от 1 до 2 рабочих дней. Стоимость рассчитывается индивидуально — зависит от количества страниц и сложности интеграции. Свяжитесь с нами — оценим ваш проект и предложим сроки. Закажите настройку WAVE API — получите автоматический аудит в CI. Получите консультацию по настройке WAVE API — свяжитесь с нами. Закажите настройку WAVE API уже сегодня и получите первый отчёт завтра.
Обратите внимание: WAVE API не заменяет экспертной оценки — некоторые ошибки требуют ручного анализа. Но автоматизация ловит 80% типовых проблем, экономя время команды.
Доступность сайтов: 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 (регистрация, покупка, форма) только клавиатурой и со скринридером.
Процесс работы
-
Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
-
Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
-
Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
-
Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
-
Повторный аудит — закрытие всех P1/P2 перед релизом.
-
Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.
Результаты и объём работ
- Полный отчёт по аудиту с приоритизацией нарушений (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 по версии 2.2.
Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.
