Accessibility и WCAG: принципы, критерии, тестирование

Accessibility (a11y) — это практика проектирования цифровых продуктов так, чтобы ими могли пользоваться люди с разными возможностями: с нарушениями зрения, слуха, моторики, когнитивными особенностями. По данным ВОЗ, около 1.3 миллиарда человек в мире живёт с какой-либо формой инвалидности. Игнорирование accessibility исключает значительную часть аудитории и в большинстве стран нарушает законодательство.

WCAG (Web Content Accessibility Guidelines) — основной международный стандарт, описывающий, как сделать веб-контент доступным. Текущая стабильная версия — WCAG 2.2, выпущенная в 2023 году. Параллельно идёт работа над WCAG 3.0 с более широким охватом. Эта статья описывает структуру стандарта, четыре фундаментальных принципа, уровни соответствия, основные критерии, инструменты тестирования и подходы к встраиванию accessibility в процесс разработки.

Кому нужна accessibility

Распространённое заблуждение — accessibility нужна только людям с тяжёлыми формами инвалидности. На практике это касается гораздо большей аудитории.

Постоянные ограничения

• Слабовидящие и слепые пользователи, работающие со screen readers
• Глухие и слабослышащие, нуждающиеся в субтитрах и транскриптах
• Люди с моторными ограничениями, использующие только клавиатуру или альтернативные устройства ввода
• Пользователи с когнитивными особенностями: дислексия, ADHD, аутизм
• Дальтоники — около 8% мужчин и 0.5% женщин с цветовой слепотой
• Эпилепсия — мерцающий контент может вызвать припадок

Временные ограничения

• Сломанная рука — временная невозможность использовать мышь
• Послеоперационное состояние с ограниченным зрением
• Громкая среда без возможности слышать звук
• Яркое солнце на экране, делающее контент плохо видимым

Ситуативные ограничения

• Управление одной рукой при держании ребёнка или сумки
• Использование медленного интернета или старого устройства
• Работа на маленьком экране смартфона
• Шумное окружение, требующее визуальной альтернативы звуку

Все эти категории расширяют целевую аудиторию accessibility далеко за пределы традиционного понимания инвалидности. По данным Microsoft, 1 из 5 людей в развитых странах сталкивается с накопленным эффектом постоянных, временных и ситуативных ограничений в повседневной жизни.

WCAG как стандарт

WCAG разрабатывается W3C (World Wide Web Consortium) рабочей группой WAI (Web Accessibility Initiative). Версии стандарта эволюционируют:

• WCAG 1.0 (1999) — устарел
• WCAG 2.0 (2008) — основа всех современных требований
• WCAG 2.1 (2018) — добавлены требования для мобильных и людей с низким зрением
• WCAG 2.2 (2023) — текущая стабильная версия
• WCAG 3.0 — в разработке, существенно расширенный подход

Большинство законодательных требований сейчас базируются на WCAG 2.1 AA. Зрелые компании постепенно переходят на 2.2 AA. WCAG 3.0 пока не считается production-ready.

Четыре принципа POUR

WCAG строится вокруг четырёх фундаментальных принципов, формирующих аббревиатуру POUR.

Под каждым принципом сгруппированы конкретные guidelines, под guidelines — измеримые success criteria. Success criteria — это то, что можно проверить на конкретной странице.

Уровни соответствия A, AA, AAA

WCAG определяет три уровня требований:

Большинство законодательных требований (ADA, EAA, GOV.UK Service Manual) фиксируют уровень AA как минимум. Достижение AAA для всего сайта обычно нецелесообразно — это исключает многие современные дизайн-практики (например, AAA-контраст 7:1).

Ключевые критерии Perceivable

1.1.1 Non-text Content (A)

Каждое нетекстовое содержимое должно иметь текстовую альтернативу. Изображения требуют alt-текста, описывающего их содержание или функцию. Декоративные изображения должны иметь пустой alt (alt=»») для пропуска screen reader’ом.

<!-- Информативное изображение -->
<img src="chart.png" alt="График показывает рост продаж на 30% за квартал" />

<!-- Декоративное изображение -->
<img src="divider.png" alt="" />

<!-- Функциональная иконка -->
<button>
  <svg aria-hidden="true">...</svg>
  <span class="visually-hidden">Удалить элемент</span>
</button>

1.3.1 Info and Relationships (A)

Информация, передаваемая визуально, должна быть доступна программно. Заголовки помечаются тегами h1–h6, списки — ul/ol, таблицы — table со scope для заголовков. Не использовать визуальное оформление вместо семантической разметки.

1.4.3 Contrast Minimum (AA)

Контраст текста к фону должен быть не менее 4.5:1 для обычного текста и 3:1 для крупного (18px bold или 24px обычного). На AAA-уровне требования жёстче: 7:1 для обычного, 4.5:1 для крупного.

1.4.11 Non-text Contrast (AA)

Контраст активных UI-элементов (кнопки, поля ввода, иконки) к фону должен быть не менее 3:1. Это правило часто нарушается современными «минималистичными» дизайнами с очень светлыми границами и плейсхолдерами.

Ключевые критерии Operable

2.1.1 Keyboard (A)

Вся функциональность должна быть доступна с клавиатуры. Это означает:

• Все интерактивные элементы получают фокус по Tab
• Действия выполняются по Enter или Space (для кнопок)
• Меню открываются и закрываются клавиатурой
• Модальные окна позволяют выход по Escape
• Карусели и сложные виджеты поддерживают arrow keys

2.1.2 No Keyboard Trap (A)

Фокус не должен «застревать» в одном элементе. Если пользователь зашёл в модальное окно или сложный виджет, он должен иметь возможность из него выйти клавиатурой.

2.4.7 Focus Visible (AA)

Видимый focus indicator должен показывать, какой элемент в фокусе в данный момент. Это критически важно для пользователей клавиатуры. Удаление focus outline без замены (outline: none без альтернативы) — одна из самых распространённых ошибок.

/* Плохо: убирает индикатор без замены */
button:focus {
  outline: none;
}

/* Хорошо: явный кастомный focus */
button:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

2.5.5 Target Size (AAA в 2.1, AA в 2.2)

Размер кликабельной области должен быть не менее 24×24 CSS-пикселей (AA в 2.2) или 44×44 (AAA в 2.1). Маленькие кнопки и ссылки сложны для пользователей с моторными ограничениями и для всех на сенсорных экранах.

Ключевые критерии Understandable

3.1.1 Language of Page (A)

Язык страницы должен быть указан в атрибуте lang. Screen reader использует эту информацию для правильного произношения слов.

<html lang="ru">
  <!-- Контент на русском -->
  <p>Это страница на русском.</p>
  <!-- Вставка на другом языке -->
  <p>Цитата: <span lang="en">Quality is not an act, it is a habit</span></p>
</html>

3.3.1 Error Identification (A)

Ошибки ввода должны быть чётко идентифицированы и описаны текстом. Подсветка красным недостаточна — это не работает для дальтоников и screen reader’ов.

3.3.2 Labels or Instructions (A)

Все поля ввода должны иметь видимые лейблы или инструкции. Placeholder не заменяет label — он исчезает при вводе и не озвучивается screen reader’ом корректно.

<!-- Плохо -->
<input type="email" placeholder="Email" />

<!-- Хорошо -->
<label for="email">Email</label>
<input type="email" id="email" required />

Ключевые критерии Robust

4.1.2 Name, Role, Value (A)

Каждый интерактивный элемент должен иметь программно определяемые name, role и value. Это означает использование семантической разметки или соответствующих ARIA-атрибутов.

4.1.3 Status Messages (AA)

Динамически обновляемые сообщения (notifications, toast, обновления статуса) должны быть доступны screen reader’у через aria-live regions без необходимости получать фокус.

ARIA — Accessible Rich Internet Applications

ARIA — набор атрибутов HTML для расширения семантики там, где базовые HTML-теги недостаточны. Используется в сложных компонентах: модальные окна, выпадающие меню, табы, accordion, drag-and-drop.

Базовые принципы использования ARIA

1. No ARIA is better than bad ARIA: неправильно применённое ARIA хуже, чем его отсутствие
2. Использовать семантический HTML перед ARIA. button лучше div role=»button»
3. ARIA меняет только семантику для assistive tech, не визуальное поведение
4. Активные элементы должны быть доступны с клавиатуры независимо от ARIA

Типичные ARIA-паттерны

Screen readers

Screen reader — программа, читающая контент экрана вслух или преобразующая его в Braille. Тестирование с screen reader — обязательная часть проверки accessibility.

Основные screen readers

Для тестирования веб-сайтов рекомендуется использовать минимум NVDA + Chrome или JAWS + Chrome (десктоп) и VoiceOver на iOS, TalkBack на Android для мобильных версий.

Focus management

Управление фокусом критично для клавиатурной навигации и screen reader-пользователей. Несколько ключевых практик:

Логичный порядок фокуса

Порядок Tab должен соответствовать визуальному порядку и логике страницы. Использование позитивных tabindex (tabindex=»1″, «2», …) почти всегда антипаттерн — он создаёт нелогичные перескакивания.

Skip links

Ссылка «Перейти к основному контенту» в начале страницы позволяет клавиатурным пользователям пропустить повторяющуюся навигацию. Стандартная практика для длинных страниц.

Focus trap в модалках

Когда модальное окно открыто, фокус должен быть заперт внутри него. Tab из последнего элемента возвращает на первый. Закрытие модального возвращает фокус к элементу, который его открыл.

Возврат фокуса после действий

После выполнения действия (удаления элемента, отправки формы) фокус должен переходить логично: на следующий элемент, на сообщение об успехе, на родительский элемент. Потеря фокуса дезориентирует пользователей клавиатуры.

Тестирование accessibility

Полная проверка accessibility сочетает автоматические инструменты, ручное тестирование и работу с реальными пользователями.

Автоматические инструменты

Важное ограничение: автоматические инструменты находят только 30–40% реальных проблем accessibility. Остальные требуют ручной проверки.

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

• Навигация только клавиатурой по всему сайту
• Тестирование с screen reader (NVDA, VoiceOver)
• Увеличение шрифта до 200% без потери функциональности
• Проверка работы при отключённом CSS
• Тестирование на разных размерах экранов
• Проверка с симуляторами цветовой слепоты (NoCoffee, Color Blind Simulator)

Тестирование с пользователями

Включение людей с инвалидностью в тестирование даёт инсайты, недостижимые автоматическими методами. Сервисы типа Fable, Userlytics с фильтрами по accessibility-требованиям помогают находить участников.

Юридические требования

Accessibility — не только моральный долг, но и юридическое требование во многих юрисдикциях.

США — ADA и Section 508

Americans with Disabilities Act применяется к коммерческим сайтам, обслуживающим публику. Section 508 распространяется на государственные сайты и подрядчиков федеральных агентств. Количество ADA-исков растёт: в 2023 году подано более 4000 исков по веб-доступности. Стандартом считается WCAG 2.1 AA.

ЕС — European Accessibility Act

EAA вступает в полную силу в июне 2025 года. Применяется к электронной коммерции, банковским услугам, транспорту, мобильным приложениям. Несоблюдение влечёт штрафы до миллиона евро в некоторых странах.

Великобритания — Equality Act 2010

Требует «разумных приспособлений» для людей с инвалидностью. Государственные сайты обязаны соответствовать WCAG 2.1 AA по Public Sector Bodies Accessibility Regulations 2018.

Россия и СНГ

В России есть ГОСТ Р 52872-2019, базирующийся на WCAG. Применяется в основном к государственным сайтам. В Беларуси аналогичных обязательных требований для коммерческих сайтов нет, но крупные международные компании следуют WCAG из общих практик и требований к продуктам, продаваемым на западных рынках.

Бизнес-кейс для accessibility

Помимо юридических требований, accessibility даёт измеримые бизнес-выгоды.

Расширение аудитории

15–20% пользователей в развитых странах имеют какие-либо ограничения, влияющие на использование цифровых продуктов. Игнорирование accessibility исключает этих пользователей из конверсий.

SEO-преимущества

Многие accessibility-практики совпадают с SEO best practices: правильная семантическая разметка, alt-тексты, заголовки в правильной иерархии, прозрачная структура страниц. Доступный сайт лучше ранжируется.

Лучший UX для всех

Видимые focus indicators помогают всем пользователям клавиатуры. Высокий контраст помогает читать на солнце. Простой язык понятен и носителям, и не-носителям. Accessibility делает продукт удобнее для всех, не только для пользователей с инвалидностью.

Снижение юридических рисков

В США средний ADA-иск стоит компании $50K–500K в settlement плюс repair-работы. В ЕС штрафы за нарушение EAA могут достигать миллионов евро. Инвестиции в accessibility окупаются избеганием этих рисков.

Встраивание accessibility в процесс

Эффективный подход — accessibility не как разовая проверка перед релизом, а как постоянная практика на всех этапах разработки.

Design

• Палитра с проверенным контрастом
• Минимальные размеры интерактивных элементов
• Понятная иерархия заголовков в макетах
• Не полагаться только на цвет для передачи информации
• Альтернативы для жестов и сложных взаимодействий

Development

• Семантический HTML по умолчанию
• Компоненты дизайн-системы с встроенной accessibility
• ARIA только когда необходимо
• Автотесты с axe-core в CI/CD
• Storybook с a11y-addon для проверки компонентов

QA

• Включение accessibility-чеклиста в test cases
• Регулярное тестирование с screen reader
• Клавиатурная навигация как обязательный шаг
• Периодические аудиты от внешних экспертов

Product

• Accessibility как часть DoD (Definition of Done)
• Обучение команды основам
• Включение пользователей с инвалидностью в исследования
• Метрики accessibility в продуктовом дашборде

Accessibility — это не функция, которую можно добавить в конце. Это качество, встроенное во весь процесс: от дизайна до разработки и тестирования. Попытка «починить» неаccessible-продукт стоит в 5–10 раз дороже, чем сделать его правильно с начала.

Типичные ошибки

Доверие только автоматическим инструментам

«Lighthouse показал 100% accessibility» не означает, что сайт доступен. Автоматические инструменты ловят 30–40% проблем. Остальное требует ручной проверки и работы с реальными пользователями.

Использование div вместо button

div с onclick не получает фокус клавиатурой, не активируется по Enter, не имеет правильной семантики для screen reader. Использовать button и a в их естественной функции.

Скрытие focus outline

«outline: none» без замены — одна из самых частых ошибок. Пользователи клавиатуры теряют возможность видеть, где они находятся.

Текст в изображениях

Текст, встроенный в изображения (баннеры, инфографика), не доступен screen reader’у и не масштабируется при увеличении шрифта. Использовать настоящий текст с CSS-стилизацией.

Низкий контраст плейсхолдеров

«Серый плейсхолдер на белом фоне» часто имеет контраст 2:1 или 3:1, что нарушает WCAG. Плейсхолдер должен соответствовать тем же требованиям, что и обычный текст.

Modals без правильного focus management

Модалки без trap focus, без возврата фокуса при закрытии, без aria-labelledby — типичный антипаттерн. Использовать готовые библиотеки (Radix UI, Headless UI, React Aria), решающие эти проблемы.

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

Можно ли достичь полной accessibility

WCAG AA достижима для большинства сайтов. AAA для всего контента редко практично из-за конфликтов с современным дизайном. Цель — соответствовать применимому уровню стандарта и постоянно улучшать опыт для разных групп пользователей. «Идеальная accessibility» — недостижимая цель, прогресс — достижимая.

Сколько стоит сделать сайт accessible

Зависит от стадии. Включение accessibility с начала добавляет 5–15% к стоимости разработки. Ретрофит существующего неaccessible сайта может стоить 30–100% от его первоначальной стоимости. Лучшая инвестиция — внедрить accessibility-практики с первых этапов проекта.

Чем accessibility отличается от usability

Usability — общее удобство использования продукта для широкой аудитории. Accessibility — обеспечение доступности для пользователей с разными возможностями. Они пересекаются: accessible продукт обычно usable, но не всегда наоборот. Хорошая usability для среднего пользователя может оставлять барьеры для пользователей с инвалидностью.

Нужна ли accessibility внутренним инструментам

Если в компании есть сотрудники с инвалидностью или вы хотите их нанимать — да. Многие компании теряют талантливых кандидатов из-за неaccessible внутренних систем. Также внутренние инструменты часто остаются в компании годами, и стоимость retrofit’а растёт со временем.

Что приоритизировать в первую очередь

Базовый чеклист для быстрых улучшений: контраст текста, alt-тексты на изображениях, клавиатурная навигация со видимым focus, labels на полях форм, семантическая разметка вместо div’ов. Эти изменения дают 50–70% improvement в accessibility-метриках при относительно низких затратах.

Какие компании-лидеры в accessibility

GOV.UK Service Manual — лучший публичный референс по accessibility-практикам. Apple, Microsoft, Google активно инвестируют в accessibility своих продуктов. BBC, GitHub, Slack публикуют свои гайдлайны и инструменты. Изучение их подходов даёт практические референсы для собственной работы.

Заключение

Accessibility — не дополнительная функция, а фундаментальное свойство качественного цифрового продукта. WCAG 2.1/2.2 AA — реалистичный целевой уровень для большинства проектов, обеспечивающий соответствие основным регуляторным требованиям и реальное расширение аудитории. Четыре принципа POUR — perceivable, operable, understandable, robust — дают структурную основу для проверки и улучшения accessibility.

Эффективная accessibility-практика встраивается во весь процесс разработки: от дизайн-токенов и компонент-библиотек до автотестов в CI/CD и тестирования с реальными пользователями. Попытка добавить accessibility в конце или решить её одним инструментом не работает. Инвестиции в accessibility окупаются расширением аудитории, лучшим SEO, снижением юридических рисков и улучшением UX для всех пользователей, не только для людей с инвалидностью. Регуляторное давление в ЕС и США растёт, что делает accessibility всё более актуальной темой для коммерческих продуктов на международных рынках.