Полное руководство по тестированию доступности

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks 

Многие, услышав слово «доступность», представляют только скринридеры или слабовидящих пользователей. На самом деле это гораздо шире — доступность касается всех, у кого есть ограничения в восприятии или взаимодействии с цифровыми продуктами. QA специалистам важно это понимать, чтобы тесты реально улучшали опыт всех пользователей.

Распространенные заблуждения о доступности

Цель доступности — сделать цифровые продукты удобными для всех, независимо от того, с какими ограничениями человек сталкивается — постоянными, временными или ситуативными.

Доступность охватывает широкий спектр потребностей пользователей, включая:

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

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

Развенчиваем миф «Доступность = скринридеры»

Хотя скринридеры вроде NVDA (NonVisual Desktop Access — это бесплатный и открытый скринридер для Windows) или JAWS (Job Access With Speech — один из самых известных платных скринридеров для Windows.) важные инструменты, они лишь одна часть большой картины. Доступность — это не галочка напротив одной функции, а комплексный пользовательский опыт, который обеспечивает инклюзивность для разных категорий пользователей. Это означает, что нужно тестировать:

• корректную работу клавиатурной навигации для тех, кто не может пользоваться мышью
• контрастность цветов для пользователей с нарушенной чувствительностью к цвету
• наличие субтитров и транскриптов для пользователей с нарушениями слуха
• понятную структуру и оформление контента для пользователей с когнитивными особенностями

Понимая, что доступность это широкая и инклюзивная практика, QA специалисты смогут лучше планировать тестирование, выявлять проблемы и отстаивать создание по-настоящему доступных цифровых продуктов.

Метрики и модели измерения доступности

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

Давайте разберём, как измеряется доступность и что считать «успехом».

Почему доступность нужно измерять

Чтобы улучшить доступность, её нужно уметь измерять. Так же, как и в случае с тестированием производительности или безопасности, здесь важны:

Количественные показатели. Доступность должна давать измеримые данные, которые можно отслеживать:

• количество нарушений, выявленных инструментами вроде Axe, Lighthouse или Pa11y
• уровни серьёзности проблем (critical, serious, moderate, minor)
• итоговый показатель доступности (например, Lighthouse Score из 100)
• статус Pass/Fail для определённых тест-кейсов

Эти метрики дают QA командам базовую точку отсчёта, чтобы отслеживать прогресс и включать доступность в регулярные отчёты.

Повторяемые процессы тестирования.

Как и функциональное тестирование, проверка доступности должна быть:

• одинаковой на разных билдах и окружениях
• повторяемой в CI-пайплайнах и ручных тестовых циклах
• максимально автоматизированной, но дополненной структурным ручным тестированием

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

Стандарты для оценки соответствия.

Стандарты вроде WCAG 2.1 Level AA (международный стандарт доступности веб-контента, разработанный W3C (World Wide Web Consortium)) служат общепринятым ориентиром в индустрии. Оценка доступности даёт:

• юридическую и этическую защиту
• качественную основу для инклюзивного дизайна
• общую цель, с которой могут работать продуктовые, дизайнерские и QA команды

С чёткими стандартами становится проще понять, достаточно ли продукт доступен для релиза или нужно доработать.

Критерии успеха в тестировании доступности

Очень важно задавать чёткие и практичные цели по доступности. Такие критерии успеха помогают QA командам понять, когда продукт «достаточно доступен» для релиза и где требуются доработки.

1. Соответствие стандартам

• достаточный цветовой контраст
• чёткие индикаторы фокуса
• доступные формы, ссылки и медиа
• предсказуемую навигацию и стабильное поведение интерфейса

2. Ноль критических ошибок в автоматических проверках

Инструменты вроде Axe, Pa11y или Lighthouse выявляют ошибки. Сильный критерий успеха:

• отсутствие критических и серьёзных проблем
• допускаются только незначительные баги — при условии, что они обоснованы и задокументированы
• проверка на отсутствие ложных срабатываний

3. Полная доступность ключевых пользовательских сценариев

Важные действия (например, логин, оформление заказа, отправка формы) должны быть:

• полностью выполнимы только с клавиатурой
• понятны и удобны для скринридеров (NVDA, VoiceOver)
• корректно отображены и промаркированы для всех вспомогательных технологий

Такое ручное тестирование подтверждает то, что автоматизация уловить не может.

4. Порог по Lighthouse Score

Google Lighthouse можно использовать для быстрой оценки. Хорошим показателем считается:

• балл от 90 и выше в категории Доступность
• при этом оценку нужно рассматривать в контексте реальной юзабилити, а не как сухое число

Ручные метрики доступности

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

Скринридер: логичный порядок чтения, обновления динамической области, наличие информативных лейблов.

Клавиатура: правильный порядок переходов Tab, видимость фокуса, отсутствие «ловушек» клавиатуры.

Контраст: соответствие стандарту WCAG (минимум 4.5:1 для обычного текста).

Индикаторы фокуса: чёткая визуальная подсветка для интерактивных элементов.

Масштабирование: сохранение целостности интерфейса при зуме 200% и выше.

Ошибки: формы должны выдавать понятные и доступные сообщения об ошибках.

ARIA: делаем динамический контент доступным

Современные веб-приложения активно используют динамический контент: попапы, модальные окна, раскрывающиеся меню, табы и прочее. Такие элементы повышают интерактивность, но нередко ломают доступность, если реализованы неправильно. Для решения этой проблемы используется ARIA (Accessible Rich Internet Applications).

Что такое ARIA?

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

Основные роли и свойства ARIA:

• aria-label — задаёт доступное имя, если нет видимой подписи.
• Пример: <button aria-label="Закрыть">X</button>
• aria-hidden — скрывает контент от вспомогательных технологий, полезно для декоративных элементов.
• Пример: <span aria-hidden="true">*</span>
• aria-live — сообщает об изменениях динамического контента без перезагрузки страницы.
• Применимо, например, для обновлений в чате или сообщений об ошибках.
• aria-expanded — показывает текущее состояние (раскрыто/свернуто) у меню или аккордеона.
• Пример: <button aria-expanded="true">Меню</button>
• aria-describedby / aria-labelledby — связывают элементы с их описанием или подписью для скринридеров.

Когда использовать ARIA, а когда не стоит?

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

• лучше использовать <button>, чем <div role="button">;
• лучше <fieldset> и <legend> для группировки полей формы, чем aria-labelledby.

Почему? Потому что у нативных элементов встроена поддержка доступности, а с ARIA её нужно воспроизводить вручную, что чревато ошибками.

Типичные ошибки при использовании ARIA

• Чрезмерное применение aria-hidden="true" и скрытие важного контента.
• Попытки «навязать» поведение через ARIA вместо исправления неверной HTML-структуры.
• Добавление ARIA без полноценной поддержки клавиатурной навигации.
• Использование ARIA там, где она не нужна (например, для статичного контента).

Разработка семантичных компонентов с поддержкой скринридеров

Чтобы сделать компоненты доступными:

• начинайте с семантического HTML (<button>, <nav>, <form> и т. д.)
• используйте ARIA, чтобы восполнить пробелы, особенно в кастомных UI-элементах
• регулярно тестируйте с помощью скринридеров (NVDA, VoiceOver) и инструментов вроде Axe или Accessibility Insights

Быстрый пример: доступный аккордеон

<button aria-expanded="false" aria-controls="section1">Details</button>
<div id="section1" hidden>
         <p>This is hidden content revealed when expanded.</p>
</div>

Практика: пошаговое тестирование доступности

Тестирование доступности — это не просто запуск инструмента и исправление найденных ошибок. Это системная проверка того, как продукт воспринимают пользователи с разными возможностями. Вот как QA специалистам можно организовать процесс.

Настройка окружения для тестирования доступности

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

Рекомендуемые сочетания ОС и браузеров:

• Windows + Chrome — отлично подходит для инструментов Axe DevTools, Lighthouse и скринридера NVDA.
• macOS + Safari — встроенная поддержка VoiceOver, критически важна для пользователей Apple.
• Linux + Firefox/Chrome — для проверки совместимости в open-source-средах.
• Мобильное тестирование:
• Android: используйте TalkBack и Chrome.
• iOS: используйте VoiceOver и Safari.

💡Совет: тестируйте как минимум на одном десктопе и одном мобильном устройстве, чтобы охватить все ключевые сценарии.

Ручные методы тестирования

Ручное тестирование доступности дополняет автоматические проверки и необходимо для оценки реального пользовательского опыта. Основные методы:

Тестирование навигации только с клавиатуры

• убедитесь, что все интерактивные элементы (ссылки, кнопки, поля форм) доступны и работают только через клавиатуру (Tab, Shift+Tab, Enter, Space, стрелки)
• фокус должен быть заметным и чётким — пользователи клавиатуры должны понимать, где они находятся на странице
• проверьте логичный порядок переходов (tab order) — навигация должна следовать осмысленной последовательности
• исключите «ловушки клавиатуры», когда фокус застревает и не может быть перемещён

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

• используйте популярные скринридеры для навигации и взаимодействия со страницей:
• NVDA (Windows)
• VoiceOver (macOS/iOS)
• проверяйте правильный порядок чтения, наличие описательных alt-тегов для изображений, корректное использование заголовков, областей (landmarks) и ролей ARIA
• убедитесь, что у полей форм есть связанные метки, а сообщения об ошибках корректно озвучиваются

Симуляция дальтонизма

• используйте симуляторы или расширения браузеров, чтобы просмотреть интерфейс глазами пользователей с разными типами нарушений цветового восприятия (протанопия, дейтеранопия, тританопия и др.)
• убедитесь, что цвет не является единственным способом передачи информации (например, ошибки в формах)
• проверьте, что коэффициенты контраста соответствуют WCAG:
• 4.5:1 для обычного текста
• 3:1 для крупного текста

Автоматизация тестирования доступности

Инструменты автоматизации позволяют быстро выявить многие проблемы и хорошо интегрируются в пайплайн тестирования.

1. Lighthouse (Chrome DevTools) — встроенный инструмент для быстрых аудитов с отчётами и оценками.
2. Axe DevTools (расширение и CLI) — находит подробные проблемы доступности, интегрируется в автотесты и CI/CD.
3. Pa11y — лёгкий CLI-инструмент для запуска проверок по URL или файлам, удобен для CI/CD.
4. Tenon — API-сервис с детализированными отчётами, подходит для интеграции в процессы разработки.
5. WAVE — расширение браузера с визуальной подсветкой проблем прямо на странице.
6. Siteimprove — корпоративный инструмент для постоянного мониторинга и отслеживания соответствия стандартам.

Типичные дефекты доступности и как их выявить

Отсутствующие или некорректные метки

• Проблема: Поля форм или интерактивные элементы без правильных меток сбивают с толку пользователей скринридеров
• Как обнаружить:
  • Проверьте, что каждое поле ввода имеет связанный с ним <label> или доступное имя (через aria-label или aria-labelledby).
  • Используйте программы чтения с экрана (NVDA, VoiceOver), чтобы убедиться, что метки озвучиваются корректно.

Некорректный порядок фокуса или отсутствующие индикаторы фокуса

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

«Ловушки» клавиатуры или недоступность взаимодействия

• Проблема: Элементы, которые «запирают» фокус клавиатуры или требуют взаимодействия только с помощью мыши, блокируют пользователей клавиатуры.
• Как обнаружить:
  • Пройдитесь по странице с помощью Tab, чтобы определить, не застревает ли фокус внутри какого-либо компонента.
  • Подтвердите, что всеми интерактивными элементами можно управлять только с клавиатуры.

Недостаточный цветовой контраст

• Проблема: Текст или элементы интерфейса с низкой контрастностью трудно читать пользователям с нарушениями зрения.
• Как обнаружить:
  • Используйте инструменты проверки контрастности (например, WebAIM Contrast Checker или Axe).
  • Смоделируйте дальтонизм, чтобы убедиться, что информация не передается только с помощью цвета.

Отсутствующий или нерелевантный alt — текст

• Проблема: Изображения без описательного alt — текста или с бессмысленным текстом вводят в заблуждение пользователей программ чтения с экрана.
• Как обнаружить:
  • Проверьте все изображения на наличие осмысленных атрибутов alt.
  • Убедитесь, что декоративные изображения используют пустой alt (alt=""), чтобы программы чтения с экрана их пропускали.

Неправильное использование ARIA-атрибутов

• Проблема: Некорректные или ненужные ARIA-роли могут мешать корректной работе вспомогательных технологий.
• Как обнаружить:
  • Проверьте корректность использования ARIA (с помощью инструментов вроде Axe или вручную через инспекцию кода).
  • Убедитесь, что ARIA-роли соответствуют назначению элемента и не конфликтуют.

Нарушения при увеличении масштаба или на разных разрешениях

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

Недоступные сообщения об ошибках в формах

• Сообщения об ошибках, не связанные программно с полями форм, пропускаются программами чтения с экрана
• Как обнаружить:
  • Убедитесь, что сообщения об ошибках связаны с полями ввода (например, с помощью aria-describedby).
  • Подтвердите, что ошибки озвучиваются при их появлении, используя скринридер.

Тестирование доступности в Agile и DevOps (роль QA)

Интеграция доступности в Agile и DevOps гарантирует, что она не останется «довеском», а будет частью каждого спринта и релиза.

Добавьте доступность в Definition of Done (DoD)

• обязательные проверки перед завершением задачи: автоматические сканы, ручное тестирование клавиатурой и скринридером, исправление критических дефектов.

Интеграция Axe и Lighthouse в CI-пайплайн

• запускайте автоматические проверки на каждом билде
• останавливайте сборку при новых критических проблемах

Автоматическая валидация доступности перед релизом

• используйте отчёты как обязательное условие для мерджа
• комбинируйте автоматизацию и ручное тестирование ключевых сценариев

Ручные проверки в каждом спринте

• QA должен регулярно выполнять тесты клавиатурой и скринридерами
• особое внимание — формам, навигации и обработке ошибок

Роль QA в Agile церемониях:

• Ежедневные стендапы: поднимать блокеры по доступности
• Планирование спринта: закладывать время на тестирование и исправления
• Спринт ревью: показывать улучшения и собирать обратную связь
• Ретроспектива: обсуждать, что сработало и что улучшить

Сравнение лучших инструментов для тестирования доступности

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

• axe DevTools (Deque) — один из самых популярных инструментов, известен интеграцией с браузером, точным выявлением нарушений WCAG и совместимостью с фреймворками автоматизации тестирования, такими как Cypress и Selenium.
• Lighthouse — встроенный в Chrome open-source-инструмент, проверяющий не только доступность, но и производительность, SEO и лучшие практики; удобен для быстрых аудитов.
• WAVE (WebAIM) — расширение браузера, предоставляющее визуальную обратную связь о проблемах доступности; простое в использовании, подходит новичкам.
• Pa11y — CLI-инструмент с поддержкой CI/CD; требует настройки, но отлично подходит для автоматизации и непрерывной интеграции.
• Tenon — API-инструмент для тестирования с настраиваемыми правилами; идеален для крупных проектов, но платный.
• Accessibility Insights — инструмент для пошаговой ручной проверки пользовательских сценариев; помогает выявить сложные проблемы, которые автоматизация может пропустить.
• AChecker — простой онлайн инструмент для проверки HTML по выбранным стандартам доступности; может показаться устаревшим.

Для корпоративных пользователей подходят комплексные платформы вроде Siteimprove или Deque WorldSpace, предлагающие:

• подробные дашборды
• командное взаимодействие
• интеграцию с Jira, Azure DevOps и другими инструментами

Наконец, для проверки реальной удобности сайта используют скринридеры NVDA, JAWS, VoiceOver, позволяющие команде испытать сайт так же, как пользователи с нарушениями зрения. Это ключевой шаг для создания по-настоящему инклюзивного цифрового продукта.

Проблемы и ограничения тестирования доступности

Ограничения автоматизации:

• Автоматические инструменты быстро находят множество проблем, но не способны выявить все вопросы доступности, особенно связанные с контекстом, смыслом или пользовательским опытом.
• Логический порядок чтения, осмысленный alt-текст и удобство работы со вспомогательными технологиями часто требуют ручной проверки.

Ложноположительные и ложноотрицательные результаты

• Некоторые инструменты могут выдавать проблемы, которых нет (false positives), что создаёт лишнюю работу.
• Другие могут пропускать критические ошибки (false negatives), создавая ложное ощущение соответствия стандартам.
• Комбинация нескольких инструментов и ручной проверки снижает такие ошибки.

Сложность языка и контента

• Страницы с динамическим контентом, сложным языком или мультимедиа представляют дополнительные трудности.
• Правильное применение ARIA, субтитров и транскриптов часто требует экспертизы и ручной работы.

Ограничения по времени и ресурсам

• Полноценное тестирование доступности требует времени и опытных специалистов, знакомых со вспомогательными технологиями.
• Сжатые сроки и ограниченный бюджет могут привести к неполной проверке или игнорированию доступности.
• Раннее внедрение доступности в разработку и автоматизация проверок помогают смягчить эти проблемы.

Заключение: формирование культуры инклюзивного качества

Доступность начинается с shift-left подхода — интеграции с самого начала разработки. Формируйте культуру непрерывного улучшения, чтобы ваши продукты оставались инклюзивными и качественными для всех пользователей.

Перевод статьи «How to Do Accessibility Testing A Complete Guide for QA Professionals».