Ваш сайт получает 100/100 в аудите axe-core. И тем не менее после последнего обновления CSS контраст ваших кнопок упал ниже законодательного порога, а индикатор фокуса исчез — невидимый для анализатора кода, но вполне реальный и для пользователя, и для регулятора. Это слепое пятно классических инструментов доступности: они читают код, а не отрендеренную страницу.
И речь не только об эстетике. Обязательства по веб-доступности различаются в зависимости от юрисдикции: Европейский союз требует уровень AA через European Accessibility Act, США требуют соответствия Section 508 в рамках ADA, Канада ориентирует ACA на WCAG 2.1 AA, а Великобритания применяет собственные правила через Equality Act. Это руководство сравнивает требования по регионам, подробно описывает этапы полного теста WCAG и объясняет, как автоматизированное визуальное тестирование дополняет аудит доступности и инструменты статического анализа для покрытия всех критериев.
Ваш аудит кода говорит «соответствует», но экран рассказывает другое? Delta-QA выявляет отклонения контраста, фокуса и вёрстки, которые не видят статические анализаторы, локально и без регистрации. Попробовать Delta-QA бесплатно →
Содержание
- Что WCAG требует визуально
- Требования к тестированию WCAG по регионам
- Как провести полный тест WCAG: этапы
- Почему классические инструменты доступности недостаточны
- Визуальное тестирование как страховочная сеть для доступности
- Критерии WCAG, которые визуальное тестирование выявляет нативно
- Как организовать визуальный мониторинг доступности
- FAQ
Что WCAG требует визуально
WCAG (Web Content Accessibility Guidelines) версии 2.2 содержат 86 критериев успеха, распределённых по трём уровням соответствия: A, AA и AAA. Среди этих критериев значительная доля непосредственно касается визуального оформления интерфейсов.
Рассмотрим наиболее важные.
Контраст цветов (критерий 1.4.3 для уровня AA, 1.4.6 для AAA) устанавливает минимальный коэффициент контрастности 4.5:1 для обычного текста и 3:1 для крупного текста. Этот критерий чисто визуальный: он проверяется путём сравнения цветов текста и его фона.
Размер текста (критерий 1.4.4) требует, чтобы контент мог быть увеличен до 200% без потери информации или функциональности. Это означает, что при 200% масштабе текст не должен выходить за пределы контейнеров, элементы не должны перекрываться, а информация должна оставаться читаемой. Всё это поддаётся визуальной проверке.
Индикатор фокуса (критерий 2.4.7 для AA, усиленный критериями 2.4.11 и 2.4.12 в WCAG 2.2) требует, чтобы каждый интерактивный элемент отображал видимый индикатор при получении фокуса клавиатуры. Этот индикатор должен иметь достаточный контраст и минимальную площадь. Снова — визуальный критерий.
Интервалы в тексте (критерий 1.4.12) требуют, чтобы контент оставался функциональным при изменении пользователем межстрочного интервала до 1,5 от размера шрифта, интервала между абзацами — до 2 раз, интервала между буквами — до 0,12, а между словами — до 0,16. Если эти настройки ломают вёрстку — это нарушение доступности, обнаруживаемое визуально.
Перетекание контента (критерий 1.4.10, также называемый «reflow») требует, чтобы контент отображался без горизонтальной прокрутки при ширине 320 CSS-пикселей. Это именно то, что проверяет адаптивное тестирование.
Вывод очевиден: значительная часть соответствия WCAG основана на визуально измеримых свойствах.
Требования к тестированию WCAG по регионам
Законодательные обязательства в области цифровой доступности различаются в зависимости от юрисдикции. В приведённой ниже таблице сравниваются требования четырёх основных регионов.
| Регион | Требуемый стандарт | Обязательный уровень WCAG | Дедлайн / Год | Законодательный акт | Рекомендуемый инструмент(ы) |
|---|---|---|---|---|---|
| ЕС / EAA | EN 301 549 (на основе WCAG 2.1) | AA | Июнь 2025 (вступление в силу) | European Accessibility Act (EAA) — Директива 2019/882 | axe-core, WAVE, Lighthouse |
| США / ADA + Section 508 | Section 508 (на основе WCAG 2.0) | AA | Section 508: январь 2018 (обновление); ADA: развивающаяся судебная практика | ADA.gov — Section 508 (29 U.S.C. § 794d) | axe-core, ANDI, WAVE |
| Канада / ACA | ACA (на основе WCAG 2.1) | AA | Июнь 2024 (фаза 1); июнь 2025 (фаза 2) | Закон Канады о доступности (ACA) | axe-core, Accessibility Insights |
| Великобритания / EQS | Public Sector Bodies Accessibility Regulations 2018 | AA | Сентябрь 2020 (государственный сектор) | Equality Act 2010 — Accessibility Regulations | axe-core, WAVE, Pa11y |
Ключевые выводы из таблицы:
- Все четыре юрисдикции требуют как минимум уровень WCAG AA. Ни одна не предписывает AAA, но достижение этого уровня снижает юридические риски.
- Европейский союз имеет наиболее свежий и строгий дедлайн с EAA, который охватывает также частный сектор.
- США остаются на WCAG 2.0 через Section 508, однако суды всё чаще применяют WCAG 2.1 AA как ориентир в рамках ADA.
- Канада и Великобритания ориентированы на WCAG 2.1 AA с поэтапными календарями применения.
- axe-core, разработанный Deque Systems, является наиболее цитируемым инструментом во всех юрисдикциях — он интегрируется в тестовые фреймворки и CI/CD.
Как провести полный тест WCAG: этапы
Полный тест WCAG сочетает автоматизированный анализ, визуальную проверку и ручной аудит. Вот этапы, которые следует выполнить, по порядку.
- Определить область тестирования. Определите страницы и компоненты для тестирования, применимую юрисдикцию или юрисдикции (см. таблицу выше) и целевой уровень соответствия (AA в подавляющем большинстве случаев).
- Запустить автоматизированный анализ с axe-core. Выполните axe-core на каждой странице из области тестирования. Этот инструмент обнаруживает примерно 30–50% нарушений WCAG — те, которые можно выявить анализом DOM (отсутствующие текстовые альтернативы, некорректные ARIA-роли, структура заголовков, атрибуты форм).
- Провести аудит Lighthouse. Дополните анализ axe-core аудитом Google Lighthouse, который оценивает категорию «Accessibility» по 100-балльной шкале и указывает на типичные проблемы с предложениями по исправлению.
- Проверить визуальные критерии путём снятия скриншотов. Захватите ваши страницы в условиях доступности: масштаб 200%, ширина 320px, внедрённые интервалы WCAG (критерий 1.4.12), принудительный фокус клавиатуры. Сравните результаты с соответствующим baseline для обнаружения регрессий. Визуальное тестирование — наиболее надёжный метод для этого этапа.
- Протестировать навигацию с клавиатуры вручную. Пройдите каждую страницу исключительно с помощью клавиатуры (Tab, Shift+Tab, Enter, Пробел, стрелки). Убедитесь, что порядок табуляции логичен, каждый интерактивный элемент получает видимый фокус, и отсутствуют ловушки клавиатуры.
- Проверить совместимость с вспомогательными технологиями. Протестируйте ваши страницы с помощью скринридера (NVDA на Windows, VoiceOver на macOS/iOS, TalkBack на Android). Убедитесь, что контент корректно объявляется, landmarks регионов присутствуют, а формы удобны в использовании.
- Протестировать в нескольких браузерах и на разных устройствах. Проблемы доступности различаются в зависимости от движка рендеринга. Контраст, соответствующий стандартам в Chrome, может не соответствовать в Safari. Кросс-браузерное визуальное тестирование фиксирует эти различия.
- Задокументировать результаты и исправления. Для каждого обнаруженного нарушения укажите соответствующий критерий WCAG, применимую юрисдикцию, степень серьёзности и применённое исправление. Эта документация служит доказательством соответствия в случае проверки.
- Интегрировать тесты в CI/CD-пайплайн. Автоматизируйте этапы 2, 3 и 4 так, чтобы они выполнялись при каждом pull request. Любая регрессия блокируется до попадания в продакшен.
- Планировать регулярный аудит. Даже при полной автоматизации ручной аудит ежеквартально или раз в полгода экспертом по WCAG остаётся рекомендованным для покрытия неавтоматизируемых критериев.
Почему классические инструменты доступности недостаточны
Инструменты аудита доступности, такие как axe-core или Lighthouse, незаменимы. Они анализируют DOM, проверяют атрибуты ARIA, обнаруживают отсутствующие теги и сигнализируют о структурных нарушениях. Никто это не оспаривает.
Но у этих инструментов есть фундаментальное ограничение: они анализируют код, а не рендеринг. Они проверяют то, что объявляют HTML и CSS, а не то, что пользователь видит на самом деле.
Конкретный пример. Представьте кнопку с белым текстом на синем фоне и коэффициентом контрастности 5.2:1, который соответствует стандартам. При обновлении CSS разработчик делает фон кнопки светлее, не трогая текст. Коэффициент падает до 2.8:1. axe-core может обнаружить это в некоторых случаях, но только если таблица стилей корректно интерпретирована движком анализа. Визуальное тестирование же фиксирует эту регрессию немедленно, поскольку сравнивает реальный рендеринг кнопки до и после изменения.
Другой частый случай: индикатор фокуса задан в CSS, но обновление фреймворка удаляет или перезаписывает стиль outline. Функционально кнопка остаётся кликабельной. Структурно HTML не изменился. Но визуально фокус исчез. Ни один инструмент анализа DOM не обнаруживает эту проблему надёжно. Визуальное тестирование фиксирует разницу в рендеринге.
Эти инструменты также не обнаруживают проблемы, связанные с масштабированием. Когда пользователь увеличивает текст до 200%, переполнения, наложения и обрезанный текст — это чисто визуальные проблемы. Они не обнаруживаются при статическом анализе кода.
Классические инструменты доступности необходимы, но недостаточны. Они покрывают структурные критерии (текстовые альтернативы, структура заголовков, ARIA-роли), но оставляют слепую зону во всём, что касается визуального рендеринга.
Визуальное тестирование как страховочная сеть для доступности
Автоматизированное визуальное тестирование заключается в захвате скриншотов ваших страниц и компонентов с последующим сравнением с эталоном (baseline) для обнаружения любых непреднамеренных визуальных изменений. Применительно к доступности этот механизм становится мощной страховочной сеткой.
Вот почему.
Оно обнаруживает регрессии, а не только нарушения. Аудит доступности сообщает, соответствует ли ваш сайт стандартам в определённый момент. Визуальное тестирование предупреждает вас, как только изменение кода ухудшает визуальную доступность. Это разница между диагнозом и системой сигнализации.
Работает с реальным рендерингом. Визуальное тестирование фиксирует то, что браузер действительно отображает после применения всех таблиц стилей, JavaScript-скриптов и расчётов компоновки. Оно не интерпретирует CSS — оно констатирует результат.
Охватывает кросс-браузерные и мульти-разрешительные сценарии. Проблемы визуальной доступности различаются в зависимости от браузеров и размеров экрана. Контраст, соответствующий стандартам в Chrome, может не соответствовать в Safari, если шрифты рендерятся по-разному. Кросс-браузерное визуальное тестирование фиксирует эти различия.
Интегрируется в CI/CD. Запуская визуальные тесты при каждом pull request, вы обнаруживаете регрессии доступности до того, как они попадут в продакшен. Это профилактика, а не исправление.
Не требует экспертизы в области доступности для настройки. Любой член команды может настроить визуальный тест, который захватывает страницы с различными уровнями масштабирования или с принудительно включёнными стилями фокуса. Сравнение происходит автоматически.
Соответствие WCAG не должно стоить целое состояние Проверяйте доступность интерфейса визуально, без кода и без отправки данных в облако — Delta-QA работает локально и бесплатно в версии Desktop. Попробовать Delta-QA бесплатно →
Критерии WCAG, которые визуальное тестирование выявляет нативно
Рассмотрим по критериям аспекты WCAG, которые визуальное тестирование эффективно покрывает.
Критерии 1.4.3 и 1.4.6 — Контраст. Сочетая визуальное тестирование с фильтрами симуляции дальтонизма или извлекая цвета из скриншотов, вы можете проверять, что контраст остаётся соответствующим стандартам после каждого изменения. Изменение палитры, ухудшающее контраст, будет немедленно заметно при сравнении скриншотов.
Критерий 1.4.4 — Масштабирование текста. Захватывайте страницы при 200% масштабе. Любая регрессия (обрезанный текст, наложение элементов, переполнение контейнеров) будет обнаружена визуальным сравнением.
Критерий 1.4.10 — Reflow. Захватывайте страницы при ширине 320 CSS-пикселей. Адаптивное визуальное тестирование проверяет, что контент корректно адаптируется без горизонтальной прокрутки.
Критерий 1.4.12 — Интервалы в тексте. Внедрите стили интервалов, требуемые критерием (межстрочный интервал 1.5, интервал абзацев 2x, буквы 0.12em, слова 0.16em), и захватите результат. Сравните с baseline для обнаружения элементов, которые ломаются при этих ограничениях.
Критерии 2.4.7, 2.4.11, 2.4.12 — Видимый фокус. Принудительно установите фокус клавиатуры на каждый интерактивный элемент и захватите результат. Визуальное тестирование обнаруживает исчезновение или деградацию индикатора фокуса.
Критерий 1.4.11 — Контраст нетекстовых элементов. Иконки, границы полей форм, индикаторы состояния — все эти элементы должны иметь коэффициент контрастности не менее 3:1. Визуальное тестирование отслеживает их естественным образом.
Как организовать визуальный мониторинг доступности
Практическая реализация опирается на несколько простых принципов.
Создавайте baseline в условиях доступности. Не ограничивайтесь захватом страниц в их состоянии по умолчанию. Создавайте дополнительные baseline: при 200% масштабе, при ширине 320 пикселей, с внедрёнными стилями интервалов WCAG и с принудительным фокусом на интерактивных элементах.
Интегрируйте эти тесты в ваш CI/CD-пайплайн. Каждый pull request должен запускать визуальное сравнение по всем этим условиям. Если изменение CSS ухудшает визуальную доступность, тест блокирует merge.
Используйте адаптированные пороги допуска. Для тестов доступности уменьшите допустимый порог различий. Изменение в 2 пикселя на индикаторе фокуса может сделать его несоответствующим. Допуск должен быть строже, чем для обычного визуального теста.
Документируйте ваши baseline доступности. Каждый baseline должен быть связан с критерием WCAG, который он проверяет. Это упрощает аудит и обеспечивает прослеживаемость при проверках.
Сочетайте со средствами статического анализа. Визуальное тестирование не заменяет axe-core или Lighthouse. Оно их дополняет. Используйте инструменты анализа для структурных критериев (текстовые альтернативы, структура заголовков, ARIA), а визуальное тестирование — для критериев рендеринга. Вместе они покрывают практически все WCAG.
Такой инструмент, как Delta-QA, позволяющий настраивать визуальные тесты без написания кода, делает этот подход доступным для всей команды, включая ответственных за доступность, которые не являются разработчиками.
Визуальная доступность — не роскошь, а обязанность
С июня 2025 года European Accessibility Act (EAA) обязывает компании Европейского союза обеспечивать доступность своих цифровых продуктов и услуг. В США ADA и Section 508 устанавливают аналогичные требования. В Канаде Закон о доступности вступает в силу поэтапно. В Великобритании Public Sector Bodies Accessibility Regulations 2018 действуют с 2020 года.
Финансовые санкции существуют и растут. Но помимо юридических рисков, доступность — это конкурентное преимущество. По данным Всемирной организации здравоохранения, более миллиарда людей в мире живут с той или иной формой инвалидности. Стоимость визуальных багов в этом контексте не только финансовая — она ведёт к исключению людей.
Визуальная доступность — наиболее легко автоматизируемая часть этого обязательства. Вам не нужен эксперт по WCAG, чтобы делать скриншоты в различных условиях и сравнивать результаты. Вам нужен правильно настроенный инструмент визуального тестирования.
FAQ
Как протестировать соответствие WCAG по регионам?
Начните с определения применимой юрисдикции или юрисдикций к вашему продукту (ЕС, США, Канада, Великобритания или другая). Обратитесь к сравнительной таблице выше, чтобы узнать требуемый стандарт и уровень. Выполните автоматизированный тест с axe-core для структурных нарушений, дополните автоматизированным визуальным тестом (захват при 200% масштабе, ширине 320px, принудительном фокусе) для критериев рендеринга и завершите ручным аудитом с клавиатурой и скринридером. Задокументируйте каждый результат с указанием юрисдикции.
Обязательно ли тестирование WCAG в ЕС?
Да. European Accessibility Act (Директива 2019/882), действующий с июня 2025 года, требует соответствия стандарту EN 301 549, который основан на WCAG 2.1 уровень AA. Несоблюдение влечёт национальные санкции, варьирующиеся в зависимости от государства-члена. Область охвата включает цифровые продукты и услуги, предназначенные для потребителей: электронная коммерция, банковские услуги, транспорт, телекоммуникации, медиа.
Какой уровень WCAG требуется для законодательного соответствия?
Все четыре основные юрисдикции (ЕС, США, Канада, Великобритания) требуют уровень AA. Ни одна юридически не предписывает уровень AAA, хотя некоторые критерии AAA (в частности, усиленный контраст 7:1) рекомендуются для снижения риска судебных разбирательств. На практике ориентация на WCAG 2.1 AA покрывает обязательства всех регионов, перечисленных в данном руководстве.
Каков дедлайн European Accessibility Act?
EAA был принят в 2019 году (Директива 2019/882) и вступил в силу 28 июня 2025 года. Компании должны были соответствовать требованиям к этой дате. Государства-члены должны были транспонировать директиву в национальное законодательство — некоторые задержались, но обязательство применяется независимо от местной транспозиции. Микропредприятия (менее 10 сотрудников и оборот менее 2 миллионов евро) пользуются исключениями.
Насколько точны автоматизированные инструменты тестирования WCAG?
Автоматизированные инструменты, такие как axe-core, обнаруживают от 30 до 50% нарушений WCAG, согласно исследованиям Deque Systems и W3C WAI. Они эффективно покрывают структурные критерии (текстовые альтернативы, ARIA-роли, структура заголовков), но оставляют слепую зону по критериям визуального рендеринга и реального пользовательского опыта. Именно поэтому полный тест сочетает автоматизацию, визуальное тестирование и ручной аудит.
Заменяет ли визуальное тестирование полный аудит доступности WCAG?
Нет. Визуальное тестирование покрывает визуальные критерии WCAG (контраст, фокус, интервалы, масштабирование, reflow), но не структурные критерии — текстовые альтернативы, навигацию с клавиатуры, ARIA-роли. Оно дополняет аудит, а не заменяет его. Примерно 30–40% критериев WCAG 2.2 имеют прямой визуальный компонент.
Как тестировать визуальную доступность без технических навыков?
С помощью no-code инструмента, такого как Delta-QA, вы настраиваете страницы для тестирования, определяете условия (размер экрана, масштаб, браузер), и инструмент автоматически захватывает и сравнивает скриншоты. Ни одной строки кода не требуется. Интерфейс показывает визуальные различия, и вы решаете, приемлемы они или нет.
Как часто нужно проверять визуальную доступность?
При каждом изменении фронтенд-кода. Интеграция в CI/CD — лучший подход: каждый pull request автоматически запускает тесты. Если вы не можете автоматизировать на этом уровне, еженедельная проверка — приемлемый минимум для обнаружения регрессий до их накопления.
Обнаруживает ли визуальное тестирование проблемы доступности на мобильных устройствах?
Да, при условии настройки тестов для распространённых мобильных разрешений (360px, 375px, 414px ширины). Адаптивное визуальное тестирование фиксирует реальный рендеринг при каждом разрешении и обнаруживает проблемы с reflow, обрезанный текст, слишком маленькие для касания элементы и ухудшенный контраст при мобильном рендеринге.
Распространяется ли Европейский закон о доступности на мою компанию?
Если вы продаёте цифровые продукты или услуги потребителям в Евросоюзе — да. EAA действует с июня 2025 года для сайтов электронной коммерции, банковских услуг, СМИ, транспорта и телекоммуникаций, среди прочих. Микропредприятия с менее чем 10 сотрудниками и оборотом менее 2 миллионов евро пользуются исключениями, но остальные обязаны соответствовать.
- Визуальное тестирование в GitHub Actions: полное руководство по автоматизации обнаружения визуальных регрессий
- Визуальное тестирование Remix: почему full-stack фреймворк делает визуальное тестирование ещё более критичным
Заключение
Эффективный тест WCAG по регионам требует знания законодательных обязательств каждой юрисдикции, сочетания автоматизированного анализа и визуального тестирования, а также интеграции этих проверок в цикл разработки. Четыре основных региона (ЕС, США, Канада, Великобритания) сходятся на уровне WCAG AA, однако стандарты, дедлайны и области охвата различаются. Автоматизированное визуальное тестирование заполняет слепую зону инструментов статического анализа, проверяя реальный рендеринг — то, что видит пользователь, а не то, что объявляет код.
Вместо того чтобы рассматривать доступность как разовый аудит раз в год, интегрируйте визуальное тестирование в ваш пайплайн для непрерывного мониторинга. Это эффективнее, надёжнее и несоизмеримо дешевле позднего исправления.
Готовы превратить соответствие WCAG в непрерывный мониторинг? Снимите первый доступный baseline и позвольте Delta-QA блокировать каждую визуальную регрессию до продакшена — бесплатно и без регистрации. Попробовать Delta-QA бесплатно →