Тестирование доступности (A11y): как проверить продукт для людей с ограниченными возможностями

Представьте: вы запускаете онлайн-магазин. Маркетинг работает отлично, трафик растёт. Но 15% посетителей не могут оформить заказ. Не потому что не хотят. Потому что не могут нажать кнопку "Купить".

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

Это не гипотетическая ситуация. По данным ВОЗ, около 16% населения мира имеют значительные ограничения возможностей. Это 1.3 миллиарда человек. В России — более 12 миллионов.

Доступность (accessibility, сокращённо a11y — потому что между 'a' и 'y' 11 букв) — это не просто про "помощь инвалидам". Это про качество продукта, охват аудитории и, честно говоря, про базовый профессионализм.

В 2025 году многие страны ужесточили законы. В Европе — European Accessibility Act. В США — ADA и Section 508. Компании получают иски. Domino's Pizza проиграла дело на $4000 за недоступный сайт. Target заплатила $6 млн. Это уже не "было бы неплохо", это требование.

Эта статья — практическое руководство. Как тестировать доступность, какие инструменты использовать, что проверять в первую очередь и как внедрить это в процесс разработки.

1. Что такое доступность простыми словами

Доступность (accessibility, A11y) — это когда продуктом могут пользоваться все, независимо от физических или когнитивных особенностей.

Представьте пандус у входа в здание. Он нужен для людей на колясках. Но им пользуются и родители с колясками, и курьеры с тележками, и пожилые люди с тростью. Хорошее решение для одних помогает многим.

Так же и в цифровых продуктах. Субтитры нужны глухим — но ими пользуются в метро. Голосовое управление создали для людей с проблемами моторики — а получили Siri. Контрастные цвета помогают слабовидящим — но всем лучше видно на солнце.

Основные категории пользователей:

Важно: ограничения бывают постоянными, временными и ситуативными. Человек может быть слепым. Может сломать руку (временно). Может держать ребёнка на руках (ситуативно). Доступный интерфейс работает для всех сценариев.

2. Почему это важно: бизнес и законы

Бизнес-аргументы

• Альтернативы для нетекстового контента (изображения, видео)

• Контент можно представить по-разному без потери информации

• Контент легче увидеть и услышать

2. Operable (Управляемость)

Компоненты интерфейса должны быть управляемыми.

• Вся функциональность доступна с клавиатуры

• Достаточно времени для чтения и использования

• Контент не вызывает приступов (мигание, вспышки)

• Навигация проста и предсказуема

3. Understandable (Понятность)

Информация и управление интерфейсом должны быть понятны.

• Текст читаем и понятен

• Поведение предсказуемо

• Помощь при ошибках

4. Robust (Надёжность)

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

• Совместимость с текущими и будущими технологиями

• Валидная разметка

• Правильное использование ARIA

Уровни соответствия:

Большинство законов требуют WCAG 2.1 AA. Это реалистичная цель для большинства проектов.

4. Инструменты автоматического тестирования

Автоматические инструменты находят 30-40% проблем доступности. Это хороший старт, но не замена ручному тестированию.

Браузерные расширения

Командная строка и CI/CD

• Pa11y — автоматизация через CLI, можно интегрировать в CI

• axe-core — библиотека для интеграции в тесты

• Lighthouse CI — проверка в pipeline

• AccessLint — проверка PR в GitHub

Онлайн-сервисы

• WebAIM WAVE — бесплатный онлайн-чекер

• AChecker — проверка по WCAG

• Siteimprove — платформа с мониторингом

• Deque — enterprise решение

Как использовать:

1. Установите axe DevTools или WAVE

2. Откройте страницу

3. Запустите проверку

4. Изучите найденные проблемы

5. Исправьте критичные

6. Повторите

Важно: инструменты не найдут проблемы с навигацией, понятностью контента, контекстом использования. Нужно ручное тестирование.

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

Тестирование клавиатурой — самый важный вид ручного тестирования. Скринридеры используют клавиатуру. Многие пользователи не могут использовать мышь.

Базовые клавиши:

Чек-лист клавиатурного тестирования:

• ☑ Все интерактивные элементы доступны через Tab

• ☑ Порядок фокуса логичен (слева направо, сверху вниз)

• ☑ Фокус видим (outline или другой индикатор)

• ☑ Фокус не попадает на скрытые элементы

• ☑ Модальные окна ловят фокус

• ☑ После закрытия модалки фокус возвращается

• ☑ Можно пропустить повторяющиеся блоки (skip links)

• ☑ Dropdown открываются и управляются клавишами

• ☑ Формы заполняются и отправляются с клавиатуры

• ☑ Нет keyboard trap (можно выйти из любого элемента)

Типичные проблемы:

div или span как кнопка — не получают фокус. Решение: используйте <button> или добавьте tabindex="0" и обработчики клавиш.

Outline убрали CSS — фокус невидим. Решение: не убирайте outline или замените кастомным стилем.

Неправильный порядок в HTML — фокус прыгает хаотично. Решение: DOM-порядок должен соответствовать визуальному.

6. Тестирование со скринридерами

Скринридеры читают контент вслух. Это основной инструмент для незрячих пользователей.

Популярные скринридеры:

Начните с NVDA или VoiceOver

NVDA (Windows) — бесплатный, популярный. VoiceOver (Mac) — встроенный, не нужно устанавливать.

Базовые команды VoiceOver (Mac):

• Cmd + F5 — включить/выключить

• VO + A — начать чтение (VO = Ctrl + Option)

• VO + → — следующий элемент

• VO + ← — предыдущий элемент

• VO + U — список элементов (заголовки, ссылки, формы)

Базовые команды NVDA (Windows):

• Ctrl + Alt + N — запустить

• Insert + ↓ — читать всё

• Insert + F7 — список элементов

• H — следующий заголовок

• K — следующая ссылка

Что проверять:

• Скринридер читает всё важное

• Порядок чтения логичен

• Alt-тексты изображений осмысленны

• Ссылки понятны вне контекста ("Подробнее" — плохо, "Подробнее о продукте X" — хорошо)

• Заголовки структурированы (h1, h2, h3)

• Формы имеют метки (label)

• Ошибки форм озвучиваются

• Динамический контент анонсируется (ARIA live regions)

«Тестирование со скринридером — это не просто про чтение текста. Это про понимание контекста, навигацию и возможность выполнить задачу.»

7. Тестирование цвета и контраста

Около 8% мужчин и 0.5% женщин имеют дальтонизм. Многие люди имеют слабое зрение. Контраст критичен.

Требования WCAG:

Крупный текст — 18pt+ обычный или 14pt+ жирный (примерно 24px и 19px).

Инструменты проверки контраста:

• WebAIM Contrast Checker — онлайн, простой

• Contrast (Mac app) — нативное приложение

• Color Contrast Analyzer (Windows) — от TPGi

• Stark (Figma plugin) — для дизайнеров

• axe DevTools — автоматически проверяет контраст

Типичные проблемы:

Серый текст на белом — популярный дизайн-выбор, но часто не проходит. #767676 на белом — минимум для AA.

Цвет как единственный индикатор — "красные поля обязательны". Дальтоники не различат. Нужно добавить иконки или текст.

Прозрачность — светлый текст на полупрозрачном фоне может не пройти на некоторых экранах.

Тестирование дальтонизма:

• Chrome DevTools — Rendering → Emulate vision deficiencies

• Figma — Color Blind plugin

• Sim Daltonism (Mac) — live preview

Проверьте сайт в режиме протанопии (красно-зелёный дальтонизм). Вся информация должна быть понятна.

8. Семантический HTML и ARIA

Правильный HTML — основа доступности. Скринридеры полагаются на семантику.

Используйте правильные теги:

Структура документа:

• <header> — шапка сайта

• <nav> — навигация

• <main> — основной контент (один на странице)

• <article> — независимая единица контента

• <section> — тематическая группировка

• <aside> — боковая информация

• <footer> — подвал

ARIA (Accessible Rich Internet Applications)

ARIA добавляет семантику, когда HTML недостаточно. Но правило номер один: не используйте ARIA, если можно использовать нативный HTML.

Когда нужна ARIA:

• Кастомные виджеты (табы, аккордеоны, слайдеры)

• Динамический контент (live regions)

• Скрытый контент (но доступный для скринридеров)

• Состояния элементов (развёрнут, выбран)

Основные ARIA атрибуты:

Ошибки с ARIA:

• Использовать ARIA вместо нативного HTML

• Конфликтующие роли (button на ссылке)

• Отсутствие label у кастомных элементов

• aria-hidden на фокусируемых элементах

• Неправильные значения состояний

9. Тестирование форм

Формы — критичная точка доступности. Если пользователь не может заполнить форму — он не может купить, зарегистрироваться, связаться.

Чек-лист доступных форм:

Метки (labels):

• ☑ Каждое поле имеет <label>

• ☑ Label связан с полем через for и id

• ☑ Placeholder не заменяет label

• ☑ Label видим всегда, не только при фокусе

Ошибки и валидация:

• ☑ Ошибки показываются рядом с полем

• ☑ Ошибки озвучиваются скринридером (aria-describedby)

• ☑ Ошибочные поля выделены не только цветом (иконка, текст)

• ☑ Есть общий список ошибок вверху формы

• ☑ Ошибки понятны ("Обязательное поле" лучше чем "Ошибка")

Группировка:

• ☑ Связанные поля в <fieldset>

• ☑ Группа имеет <legend>

• ☑ Radio buttons и checkboxes сгруппированы логично

Обязательные поля:

• ☑ Помечены визуально (звёздочка, текст "обязательно")

• ☑ Имеют атрибут required или aria-required="true"

• ☑ В инструкции указано, что обязательно

Автокомплит:

Используйте autocomplete для стандартных полей:

• autocomplete="name" — имя

• autocomplete="email" — email

• autocomplete="tel" — телефон

• autocomplete="address-line1" — адрес

Это помогает автозаполнению браузера и пользователям с когнитивными особенностями.

Типичные проблемы:

Placeholder вместо label — исчезает при вводе, скринридер не читает.

Ошибка только в цвете — красная рамка недостаточна. Нужен текст.

Таймауты на формах — пользователям со скринридером нужно больше времени.

10. Мобильная доступность

Мобильные устройства имеют свои особенности доступности.

Размер touch-targets:

Минимум 44×44 пикселя (iOS) или 48×48dp (Android). Меньше — сложно попасть пальцем.

Spacing:

Между кликабельными элементами минимум 8px. Иначе легко промахнуться.

Ориентация:

Контент должен работать в портретной и ландшафтной ориентации. Не блокируйте rotation.

Масштабирование:

Не отключайте pinch-to-zoom. user-scalable=no — плохая практика.

VoiceOver (iOS) и TalkBack (Android):

• Тестируйте с нативными скринридерами

• Жесты отличаются от desktop

• Кастомные элементы нуждаются в правильных ролях

Focus на мобильных:

Многие сайты убирают outline на мобильных. Это ошибка — пользователи с клавиатурами (Bluetooth) существуют.

11. Когнитивная доступность

Это сложная область, но критичная. Люди с дислексией, СДВГ, аутизмом, возрастными изменениями нуждаются в простоте и предсказуемости.

Принципы:

Простота:

• Короткие предложения

• Простые слова

• Списки вместо абзацев

• Иллюстрации к сложным концепциям

Предсказуемость:

• Последовательная навигация

• Кнопки в ожидаемых местах

• Похожие действия выглядят похоже

• Без неожиданных изменений контекста

Время:

• Достаточно времени для чтения

• Возможность продлить таймауты

• Автосохранение прогресса

• Отключаемые анимации (prefers-reduced-motion)

Помощь:

• Инструкции до формы, а не после

• Подсказки в контексте

• Возможность отменить действие

• Подтверждение важных действий

Типографика:

• Размер шрифта минимум 16px

• Межстрочный интервал 1.5+

• Ширина строки 50-75 символов

• Выравнивание по левому краю (не по ширине)

• Избегайте CAPS — читается хуже

12. Внедрение в процесс разработки

Доступность должна быть частью процесса с самого начала. "Добавим позже" — не работает.

Этап дизайна:

• Проверяйте контраст в Figma (Stark plugin)

• Используйте семантические названия слоёв

• Продумывайте клавиатурную навигацию

• Проектируйте состояния фокуса

• Документируйте интерактивность

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

• Используйте семантический HTML

• Добавьте axe-core в unit тесты

• Проверяйте с клавиатуры каждую фичу

• Code review включает доступность

• Используйте ESLint плагины (jsx-a11y для React)

Этап тестирования:

• Автоматические тесты (axe, Pa11y) в CI/CD

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

• Скринридер на критичных флоу

• Чек-лист WCAG для релизов

Приоритизация:

Обучение команды:

• Воркшопы по WCAG

• Демо скринридеров

• Пригласите пользователей с ограничениями

• Чемпион доступности в команде

13. Чек-лист доступности

Базовый уровень (обязательный минимум):

Клавиатура:

• ☑ Вся функциональность доступна с клавиатуры

• ☑ Фокус видим

• ☑ Порядок фокуса логичен

• ☑ Нет keyboard trap

Визуальное:

• ☑ Контраст текста минимум 4.5:1

• ☑ Информация не только через цвет

• ☑ Текст можно увеличить до 200%

• ☑ Контент адаптируется к 320px ширине

Контент:

• ☑ Изображения имеют alt-тексты

• ☑ Видео имеют субтитры

• ☑ Структура заголовков логична (h1→h2→h3)

• ☑ Язык страницы указан (lang="ru")

Формы:

• ☑ Каждое поле имеет label

• ☑ Ошибки ясны и связаны с полями

• ☑ Обязательные поля помечены

• ☑ Формы работают с клавиатуры

Интерактивность:

• ☑ Ссылки понятны вне контекста

• ☑ Кнопки имеют понятные названия

• ☑ Модалки ловят и возвращают фокус

• ☑ Динамический контент анонсируется

Продвинутый уровень:

• ☑ Автоматические тесты в CI/CD

• ☑ Тестирование со скринридером

• ☑ AAA контраст где возможно

• ☑ Респект к prefers-reduced-motion

• ☑ Качественные alt-тексты (не просто описание)

• ☑ Skip links для быстрой навигации

• ☑ Breadcrumbs для сложной навигации

• ☑ Транскрипты для аудио

• ☑ Регулярные аудиты доступности

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

14. Что запомнить

Доступность — это не опция и не nice-to-have. Это требование к качественному продукту, юридическая необходимость и возможность охватить миллионы пользователей.

Ключевые принципы:

• Начинайте с малого. Не пытайтесь достичь AAA сразу. Начните с клавиатуры и контраста.

• Автоматизируйте что можно. 30-40% проблем находят инструменты. Это база.

• Тестируйте вручную. Автоматизация недостаточна. Клавиатура и скринридер обязательны.

• Встраивайте в процесс. "Добавим позже" означает "никогда". Доступность с первого спринта.

• Думайте о пользователях. Это не чек-бокс для комплаенса. Это реальные люди с реальными потребностями.

«Плохой дизайн неудобен. Недоступный дизайн исключает.» — Microsoft Inclusive Design

Практические шаги:

1. Установите axe DevTools или WAVE сегодня

2. Проверьте главную страницу и оформление заказа

3. Пройдите сайт с клавиатуры

4. Включите скринридер на 15 минут

5. Исправьте топ-5 проблем

6. Добавьте автоматические тесты в CI/CD

7. Сделайте доступность частью Definition of Done

Помните:

Доступность помогает не только людям с ограниченными возможностями. Она помогает всем:

• Пожилым людям со слабым зрением

• Людям с временными ограничениями (сломанная рука)

• Людям в неудобных ситуациях (яркое солнце на экране)

• Людям с медленным интернетом (структурированный контент загружается быстрее)

• Роботам (SEO любит семантический HTML)

Хороший дизайн — это инклюзивный дизайн. Доступность — это не ограничение креативности, а расширение возможностей. Когда вы проектируете для всех, вы создаёте лучший продукт для каждого.

Начните сегодня. Даже маленькие изменения имеют значение. Добавьте alt к изображениям. Проверьте контраст. Протестируйте с клавиатурой. Каждый шаг делает ваш продукт доступнее для миллионов людей.