Как проверить доступность сайта перед запуском

Доступность сайта проверяют по единому стандарту: семантическая разметка, контраст, навигация с клавиатуры, alt-тексты и работающие формы. Автоматические сканеры находят часть нарушений, но окончательную проверку проходят вручную - клавиатурой и программой чтения экрана. Для компаний, которые работают на рынке ЕС, эта проверка с 2025 года превратилась из хорошей практики в юридическое требование.

WCAG (Web Content Accessibility Guidelines) - международный набор рекомендаций консорциума W3C по доступности сайтов для людей с ограничениями зрения, слуха, моторики и восприятия. С 28 июня 2025 года в силу вступил European Accessibility Act (EAA) - директива ЕС 2019/882, которая требует от цифровых продуктов и сайтов, работающих на рынке Евросоюза, соответствия базовому уровню доступности.

По ежегодному отчёту WebAIM Million, который сканирует доступность миллиона главных страниц интернета, автоматически выявляемые нарушения WCAG находят на 95-96% сайтов каждый год подряд. В проектах Exceltic.dev мы регулярно видим ту же картину на headless-сайтах: доступность закладывается в последнюю очередь, уже после вёрстки основных компонентов.

Дальше - что именно требует WCAG, где доступность чаще всего теряется в headless-архитектуре и какие ошибки автоматические сканеры физически не находят.

Типичный сценарий: команда запускает сайт на headless-стеке, проходит проверку Lighthouse на 90+ баллов и считает вопрос закрытым. Через несколько месяцев юридический отдел партнёра из ЕС присылает вопросник по доступности, или пользователь с нарушением зрения не может пройти форму заявки. Переделка семантики и фокус-менеджмента на готовом сайте обходится дороже, чем закладка этих требований на этапе вёрстки компонентов.

Почему доступность больше не опциональная задача

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

Помимо юридического риска есть коммерческий. B2B-закупщики в ЕС всё чаще включают вопросы о доступности в комплексную проверку поставщика и тендерную документацию - отсутствие внятного ответа снижает шансы пройти отбор. Для компаний, которые выходят на рынок ЕС через сайт как основной канал продаж, доступность становится частью технической архитектуры, а не отдельной задачей после запуска.

Это тот же тип технического риска, что и последовательное игнорирование cookie-согласия по GDPR на headless-сайте - обе задачи выглядят второстепенными, пока не оборачиваются штрафом или потерянной сделкой.

Репутационные последствия менее измеримы, но не менее реальны. Пользователь с нарушением зрения или моторики, который не может пройти форму заявки, уходит к конкуренту и не возвращается.

Что именно требует WCAG

WCAG делится на три уровня соответствия - A (минимальный), AA (стандартный, применяется в большинстве регуляций, включая EAA) и AAA (расширенный, для специализированных сервисов). Для большинства коммерческих сайтов практическая цель - уровень AA.

Все требования WCAG строятся вокруг четырёх принципов, сокращённых до аббревиатуры POUR:

• Воспринимаемость (Perceivable) - контент доступен минимум через один канал восприятия: текст читает программа чтения экрана, видео сопровождают субтитры.
• Управляемость (Operable) - весь функционал доступен с клавиатуры, без обязательного использования мыши.
• Понятность (Understandable) - интерфейс и текст предсказуемы, ошибки объясняются понятным языком.
• Надёжность (Robust) - разметка корректно интерпретируется разными браузерами и вспомогательными технологиями.

Технический стандарт, на который ссылается EAA (EN 301 549), в основе опирается на WCAG уровня AA. Чек-лист для соответствия закону и чек-лист для практического аудита доступности по сути один и тот же список.

Где доступность чаще всего теряется на headless-стеке

Headless-архитектура - Astro, Next.js, разделённый фронтенд поверх headless CMS - даёт скорость и гибкость, но создаёт три специфичных источника проблем с доступностью, которых нет на классических серверных сайтах.

Первый - динамически вставляемый контент. Модальные окна, табы и карусели часто собираются как кастомные JS-компоненты без нужных ARIA-атрибутов. Визуально всё работает, но программа чтения экрана не понимает, что открылось модальное окно или сменилась вкладка.

Второй - кастомные компоненты без семантики. <div> со стилями кнопки и обработчиком клика выглядит как кнопка, но не является ей для вспомогательных технологий: не получает фокус клавиатурой, не озвучивается как интерактивный элемент. Это системная проблема дизайн-систем, построенных поверх компонентных библиотек без встроенной доступности.

Третий - фокус-менеджмент на клиентских переходах. При переходе между страницами через client-side роутинг фокус клавиатуры остаётся на элементе со старой страницы, а пользователь программы чтения экрана не получает сигнал о смене контента. На классическом многостраничном сайте браузер сбрасывает фокус на <body> при полной перезагрузке - в headless-стеке с частичными обновлениями DOM это поведение нужно эмулировать вручную.

Отдельно стоит контент из headless CMS в виде rich text: если редактор блочного контента (Sanity, Contentful, Storyblok) отдаёт generic-разметку без семантических тегов, заголовки и списки в статьях теряют структуру ещё до попадания на фронтенд.

Пять пунктов чек-листа перед запуском

1. Семантическая разметка

Используйте нативные HTML-элементы вместо <div> с обработчиками: <button> для кнопок, <nav> для навигации, <main>, <header>, <footer> для навигационных областей страницы. Заголовки идут по иерархии без пропусков уровней - это требование доступности и одновременно сигнал структуры для поисковых систем.

<nav aria-label="Основная навигация">
  <ul>
    <li><a href="/blog/">Блог</a></li>
    <li><a href="/web-dev/">Веб-разработка</a></li>
  </ul>
</nav>
<main>
  <h1>Заголовок страницы</h1>
</main>

2. Контраст и цвет

Текстовый контраст должен быть не ниже 4,5:1 для обычного текста и 3:1 для крупного - по WCAG уровня AA. Информация не должна передаваться только цветом: ошибку в форме дублируют текстом и иконкой, а не только красной рамкой поля.

3. Навигация с клавиатуры

Все интерактивные элементы - ссылки, кнопки, поля форм, кастомные компоненты - получают фокус по Tab в логичном порядке и имеют видимый индикатор фокуса. Модальные окна удерживают фокус внутри себя, не выпуская его за пределы окна, и возвращают фокус на элемент, который открыл модальное окно, после закрытия.

4. Alt-тексты и ARIA

Каждое информативное изображение получает описательный alt, декоративное - пустой alt="", чтобы программа чтения экрана его пропускала. ARIA-атрибуты (aria-label, aria-expanded, aria-live) добавляют только там, где нативная HTML-семантика не покрывает поведение компонента - избыточная ARIA вредит не меньше, чем её отсутствие.

5. Формы и ошибки валидации

Каждое поле формы связано с <label> через for/id, обязательные поля помечены программно (aria-required), а ошибки валидации объявляются через aria-live регион, чтобы программа чтения экрана сообщила о них сразу, а не только визуально красным текстом.

Что находят автоматические инструменты, а что нет

Инструменты вроде axe и Lighthouse accessibility score быстро сканируют DOM и находят объективно проверяемые нарушения: отсутствующие alt-атрибуты, недостаточный контраст, незаполненные label. Это полезная первая линия проверки, которую стоит встроить в процесс сборки сайта.

Проблема в том, что автоматика, по оценкам, распространённым в индустрии тестирования доступности, находит порядка 30-40% нарушений WCAG. Остальное сканер не может оценить программно: логичен ли порядок фокуса, понятен ли текст ошибки человеку, действительно ли ARIA-атрибут описывает то, что происходит визуально.

По нашему опыту, на headless-сайте среднего размера - 30-50 страниц под управлением headless CMS - ручной аудит после автоматического сканирования обычно занимает 12-20 часов работы специалиста. Именно на этом этапе всплывают проблемы фокус-менеджмента и кастомных компонентов, которые сканеры физически не способны поймать: они не умеют оценивать поведение при реальной навигации клавиатурой.

Ручное тестирование минимум включает полный проход по сайту без мыши, проверку основных сценариев с включённой программой чтения экрана (NVDA или VoiceOver) и проверку при увеличении текста браузера до 200%.

Какие ошибки повторяются чаще всего

• Alt-текст есть у декоративных иконок, но отсутствует у информативных изображений - или дублирует соседний текст ссылки.
• Кастомные выпадающие списки реагируют только на клик мыши, не на клавиатуру.
• Модальные окна не удерживают фокус: Tab уводит пользователя на элементы фоновой страницы.
• Текст на градиентном или изображённом фоне визуально красив, но не проходит порог контраста 4,5:1.
• Индикатор фокуса убран через outline: none ради эстетики, без замены на альтернативный видимый стиль.

Кому эта проверка критична в первую очередь

В первую очередь - компаниям, которые продают товары или услуги потребителям в ЕС через сайт как основной канал: под EAA подпадает факт присутствия на европейском рынке, а не место регистрации бизнеса. Также критично для e-commerce и SaaS с большой долей трафика из ЕС, где сайт - транзакционный канал, а не визитка. Особенно если сайт уже мультиязычный и ориентирован на несколько стран ЕС одновременно.

Отдельная категория - компании с уже работающим сайтом, где доступность никогда не проверялась целенаправленно. Для них обычно не нужна пересборка сайта целиком - достаточно точечной доработки конкретных компонентов: навигации, форм и модальных окон, которые чаще всего создают основной риск.

Часто задаваемые вопросы

Что такое WCAG простыми словами?

WCAG (Web Content Accessibility Guidelines) - набор технических рекомендаций консорциума W3C о том, как сделать сайт доступным для людей с ограничениями зрения, слуха, моторики и когнитивных функций. Официальный текст опубликован на сайте W3C и служит ориентиром для большинства национальных законов о цифровой доступности, включая European Accessibility Act.

С какого уровня WCAG стоит начинать - A, AA или AAA?

Для подавляющего большинства коммерческих сайтов практическая цель - уровень AA: именно на него ссылается European Accessibility Act и большинство национальных регуляций. Уровень AAA избыточен для типового сайта и применяется точечно для специализированных сервисов.

Штрафуют ли реально за несоответствие European Accessibility Act?

Да, но механизм и размер штрафов устанавливает каждая страна ЕС по-своему в рамках национальной транспозиции директивы - единой фиксированной таблицы штрафов на уровне ЕС нет. Официальный текст директивы 2019/882 доступен на портале EUR-Lex.

Гарантирует ли Lighthouse score 100 полную доступность сайта?

Нет. Lighthouse и axe проверяют только критерии, которые можно оценить программно - примерно 30-40% требований WCAG, по оценкам, распространённым в индустрии тестирования доступности. Высокий автоматический балл не отменяет ручную проверку клавиатурой и программой чтения экрана перед запуском.

Сколько времени занимает аудит доступности headless-сайта перед запуском?

Для типового сайта на 30-50 страниц ручной аудит после автоматического сканирования обычно занимает 12-20 часов работы специалиста - точная цифра зависит от числа кастомных интерактивных компонентов и сложности форм. На крупных сайтах время растёт пропорционально числу уникальных шаблонов, а не общему количеству URL.

Что делать дальше

Доступность на headless-стеке - это не проверка перед релизом, а часть архитектуры компонентов: семантика, фокус-менеджмент и ARIA закладываются вместе с вёрсткой, а не добавляются поверх готового сайта. Автоматические сканеры стоит держать в процессе сборки, но финальную проверку всегда проходить вручную.

Если вы готовите сайт к выходу на рынок ЕС или получили запрос по доступности от партнёра - опишите ситуацию команде Exceltic.dev. Проведём технический аудит по чек-листу WCAG и оценим объём доработок.