Как провести тестирование доступности: практическое руководство с AI-промптами

Тестирование доступности (accessibility testing) оценивает, может ли цифровой продукт эффективно использоваться людьми с инвалидностью, включая тех, кто пользуется ассистивными технологиями: программами чтения с экрана, навигацией с клавиатуры, переключателями и экранными лупами. Метод сочетает автоматизированное сканирование на соответствие Руководству по доступности веб-контента (WCAG) с ручным экспертным обзором и тестовыми сессиями с реальными пользователями с инвалидностью, формируя приоритизированный список барьеров, препятствующих равному доступу. По данным отчёта WebAIM Million 2025 года, 94,8% из миллиона самых посещаемых сайтов не проходят базовые проверки доступности, что делает тестирование доступности одним из наиболее востребованных оценочных методов в UX-исследованиях.

На какой вопрос отвечает метод?

Может ли незрячий человек, использующий программу чтения с экрана, выполнить основные задачи на продукте (регистрация, покупка, навигация) без блокирующих препятствий?
Следует ли порядок навигации с клавиатуры логической последовательности, или фокус непредсказуемо прыгает между элементами?
Имеют ли все интерактивные элементы (кнопки, ссылки, поля форм, меню) достаточные подписи, коэффициенты контраста и индикаторы фокуса для соответствия критериям WCAG 2.1 AA?
Какие конкретные критерии успеха WCAG продукт в настоящее время не проходит, и какова серьёзность каждого нарушения?
После устранения выявленных барьеров работают ли исправления на практике для пользователей с различными типами инвалидности?

Когда использовать

Перед запуском нового продукта или крупной функции, чтобы выявить и устранить барьеры доступности, пока изменения ещё дёшевы — ретроспективное внедрение доступности после запуска обходится значительно дороже.
При подготовке к требованиям законодательства, таким как Закон об американцах с инвалидностью (ADA), Европейский акт о доступности (EAA) или Раздел 508 в США.
После редизайна или миграции платформы, чтобы убедиться, что новая реализация не привнесла регрессий — распространённая проблема при смене фреймворков или дизайн-систем.
На регулярной основе (ежеквартально или раз в полгода) в рамках постоянной программы доступности, поскольку сайты непрерывно меняются и новые барьеры появляются с каждым деплоем.
Когда данные службы поддержки указывают, что люди с инвалидностью сообщают о проблемах или отказываются от определённых сценариев чаще, чем основная аудитория.

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

Что вы получите (результаты)

Отчёт аудита соответствия WCAG: детальный документ с перечислением каждого протестированного критерия успеха WCAG, результатом (пройден/не пройден), серьёзностью нарушения (критическая, высокая, низкая) и затронутыми элементами.
Приоритизированный бэклог проблем: ранжированный список барьеров доступности, организованный по серьёзности и трудозатратам, готовый для импорта в Jira, GitHub Issues или другой инструмент управления проектами.
Матрица совместимости ассистивных технологий: таблица, показывающая, какие программы чтения с экрана (JAWS, NVDA, VoiceOver), браузеры и устройства были протестированы и какие проблемы специфичны для конкретных комбинаций.
Записи и заметки пользовательских тестовых сессий: видеозаписи (с согласия) и аннотированные заметки из сессий с участниками с инвалидностью, показывающие реальные затруднения с конкретными элементами.
Руководство по устранению: для каждого выявленного барьера — описание необходимых изменений (исправление кода, изменение дизайна или правка контента) с примерами кода.
Базовая оценка для лонгитюдного отслеживания: измеримый снимок (процент пройденных критериев WCAG, количество критических проблем), который служит точкой отсчёта для будущих аудитов.

Участники и сроки

Участники для пользовательского тестирования: 3-5 участников на категорию инвалидности (зрительная, моторная, когнитивная, слуховая). Типичное исследование включает 8-15 участников. Автоматизированные сканирования и ручной экспертный обзор не требуют участников.
Длительность сессии: Автоматизированные сканирования занимают минуты. Ручной экспертный обзор — 2-5 дней. Пользовательские тестовые сессии — 45-60 минут на участника.
Время подготовки: 1-2 дня на определение объёма, выбор инструментов, подготовку тестовых сценариев и набор участников (рекрутинг может занять 1-2 недели).
Время анализа: 1-3 дня для автоматизированных + ручных результатов. Анализ пользовательского тестирования добавляет 2-3 дня.
Общий срок: 2-4 недели для полного цикла тестирования доступности. Простое автоматизированное сканирование можно выполнить за один день.

Как провести тестирование доступности (пошагово)

1. Определите объём, стандарт и критерии успеха

Определите, какие страницы, пользовательские сценарии и компоненты будут тестироваться. Для первого аудита сфокусируйтесь на наиболее посещаемых страницах и критических пользовательских путях (главная, авторизация, оформление заказа, поиск). Выберите стандарт соответствия — WCAG 2.1 AA наиболее распространён и имеет юридическую ссылку. Установите, что значит «пройдено», до начала тестирования.

2. Проведите автоматизированное сканирование

Используйте автоматизированные инструменты (axe DevTools, WAVE, Lighthouse, Pa11y) для сканирования выбранных страниц. Эти инструменты выявляют около 30-40% проблем WCAG — прежде всего отсутствующий alt-текст, недостаточный контраст, отсутствующие подписи форм. Сканируйте в нескольких интерактивных состояниях (открытые меню, видимые модальные окна, состояния ошибок).

3. Проведите ручной экспертный обзор

Обученный специалист по доступности вручную тестирует страницы, используя навигацию только клавиатурой, программы чтения с экрана (NVDA на Windows, VoiceOver на macOS/iOS, TalkBack на Android) и экранное увеличение. Эксперт проверяет то, что пропускают автоматизированные инструменты: логический порядок чтения, иерархию заголовков, корректные ARIA-атрибуты, поведение пользовательских виджетов. Этот шаг выявляет оставшиеся 60-70% проблем.

4. Наберите участников с инвалидностью и подготовьте тестовые сессии

Наберите 8-15 участников по категориям: пользователи программ чтения с экрана (незрячие или слабовидящие), пользователи только клавиатуры (моторные нарушения), люди с когнитивными нарушениями, глухие или слабослышащие (для мультимедийного контента). Используйте специализированные рекрутинговые сервисы (Fable, AbilityNet, местные организации инвалидов). Подготовьте сценарии на основе реальных целей. Убедитесь, что формы согласия доступны.

5. Проведите пользовательские тестовые сессии

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

6. Консолидируйте результаты и приоритизируйте

Объедините результаты всех трёх уровней тестирования. Устраните дубликаты. Назначьте каждой проблеме приоритет: критическая (полностью блокирует задачу), высокая (задача выполнима, но со значительными затруднениями), низкая (неудобство, не блокирующее использование). Привяжите каждую проблему к критерию WCAG.

7. Напишите отчёт и план устранения

Структурируйте отчёт для нескольких аудиторий: резюме для руководства с общей картиной соответствия и бизнес-рисками; детальный раздел с скриншотами, ссылками на WCAG и руководством по исправлению кода; приоритизированный бэклог для планирования спринтов. Включите видеофрагменты пользователей, сталкивающихся с критическими барьерами.

8. Исправьте, перетестируйте, мониторьте

После устранения наиболее приоритетных проблем проведите целевое повторное тестирование. Настройте постоянный мониторинг с автоматизированным сканированием по расписанию (еженедельно или при каждом деплое) для раннего обнаружения регрессий.

Как AI меняет этот метод

AI-совместимость: частичная — AI-инструменты могут автоматизировать обнаружение более широкого спектра нарушений WCAG, чем традиционные сканеры на основе правил, а LLM помогают генерировать alt-текст, оценивать уровень читаемости и составлять руководства по устранению. Однако реальное тестирование с людьми с инвалидностью остаётся незаменимым.

Что может AI

Расширить охват автоматизированного сканирования: AI-инструменты (axe AI, UserWay) обнаруживают проблемы за пределами традиционных проверок — например, различают информативные и декоративные изображения.
Генерировать и оценивать alt-текст: по набору изображений LLM может создать черновой alt-текст, который человек-рецензент корректирует на точность и контекстуальность.
Оценивать уровень чтения и когнитивную доступность: AI анализирует контент на сложность (Flesch-Kincaid, SMOG), выявляет жаргон и предлагает упрощения — прямая поддержка критерия WCAG 3.1.5.
Составлять руководства по устранению: по списку нарушений WCAG LLM генерирует конкретные исправления кода для типичных проблем.
Обобщать результаты пользовательского тестирования: после сессий LLM может обработать транскрипты, кластеризовать проблемы по критериям WCAG и составить черновик резюме отчёта.

Что требует исследователя-человека

Тестирование с реальными пользователями ассистивных технологий: никакой AI не может воспроизвести опыт незрячего человека, навигирующего с JAWS, человека с тремором, использующего переключатель, или человека с СДВГ, пытающегося заполнить многоступенчатую форму.
Оценка реальной доступности контента в контексте: AI может проверить наличие alt-текста, но человек должен оценить, полезен ли текст «изображение графика» или данные следует предоставить в виде таблицы.
Тестирование пользовательских интерактивных компонентов: выпадающие меню, datepicker’ы, аккордеоны и drag-and-drop часто непредсказуемо ведут себя с ассистивными технологиями и требуют ручного тестирования.
Модерирование сессий с участниками с инвалидностью: исследователь должен адаптироваться в реальном времени — делать паузу, когда говорит программа чтения с экрана, предлагать альтернативные пути и считывать невербальные сигналы.

Рабочий процесс с AI

До появления AI написание alt-текста для крупного сайта — скажем, 500 изображений — занимало у контент-команды 2-3 полных рабочих дня. С LLM исследователь может пакетно сгенерировать черновой alt-текст менее чем за час, а оставшееся время потратить на проверку и редактирование. Это сокращает общие трудозатраты примерно на 70%.

Традиционные автоматизированные сканеры выявляли около 30% проблем WCAG. Сканеры с AI (axe AI) увеличивают этот показатель до 50-60%, обнаруживая полуавтоматические проблемы. Ручной экспертный обзор остаётся необходимым, но стартует с более полной базы, сокращая общее время аудита на 1-2 дня.

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

Инструменты

Автоматизированное сканирование:

axe DevTools (Deque) — расширение браузера и интеграция CI/CD для WCAG-сканирования; движок axe-core — отраслевой стандарт.
WAVE (WebAIM) — визуальное расширение браузера, показывающее ошибки доступности прямо на странице.
Google Lighthouse — встроен в Chrome DevTools; включает раздел аудита доступности.
Pa11y — инструмент с открытым кодом для автоматизированного тестирования доступности.

Ручное тестирование и программы чтения с экрана:

NVDA — бесплатная программа чтения с экрана для Windows с открытым кодом.
VoiceOver — встроенная программа чтения с экрана на macOS и iOS.
JAWS (Freedom Scientific) — коммерческая программа чтения с экрана для Windows.
Colour Contrast Analyser (TPGi) — инструмент для проверки контрастности.

Пользовательское тестирование с людьми с инвалидностью:

Fable — платформа, соединяющая продуктовые команды с людьми с инвалидностью.
AbilityNet — организация, предоставляющая услуги тестирования с тестировщиками с инвалидностью.
Level Access — комплексный аудит доступности и интеграция пользовательского тестирования.

С использованием AI:

axe AI (Deque) — AI-слой поверх axe-core для обнаружения полуавтоматических проблем.
ChatGPT / Claude — для генерации alt-текста, анализа уровня чтения, руководств по устранению и составления отчётов.

Сочетается с

Модерируемое юзабилити-тестирование (Ut): Проведение тестирования доступности наряду с юзабилити-сессиями позволяет оценить одни и те же сценарии на общую удобство и барьеры доступности за один исследовательский цикл.
First Click Testing (Fc): Сравнение, куда нажимают зрячие пользователи, с тем, куда попадают пользователи программ чтения с экрана, выявляет допущения навигационного дизайна, ставящие в невыгодное положение пользователей ассистивных технологий.
Бенчмаркинг (Bm): Бенчмаркинг доступности устанавливает базовую оценку соответствия, которую можно отслеживать во времени и сравнивать с конкурентами.
Journey Mapping (Jm): Карты пути, включающие точки касания доступности, делают барьеры видимыми для всей команды.
Интервью со стейкхолдерами (Si): Интервью с владельцами продукта, разработчиками и юристами перед аудитом помогает исследователю понять ограничения, сроки и историю усилий по доступности.

Пример из практики

Средняя европейская e-commerce компания получила жалобу от незрячего клиента, который не смог завершить покупку с помощью JAWS в Firefox. Клиент покинул оформление заказа после того, как программа чтения с экрана не озвучила обязательные поля и не смогла навигировать по форме оплаты. Юридическая служба компании отметила жалобу как потенциальный риск по Европейскому акту о доступности.

Исследовательская команда провела трёхуровневый аудит: автоматизированное сканирование axe выявило 87 проблем на 12 ключевых страницах. Ручной экспертный обзор обнаружил ещё 34 проблемы — включая полностью недоступный через клавиатуру datepicker, индикатор прогресса оформления без обратной связи для программ чтения с экрана и ошибки валидации форм, которые отображались визуально, но не озвучивались. Пользовательское тестирование с 10 участниками (3 пользователя программ чтения с экрана, 3 — только клавиатуры, 2 с когнитивными нарушениями, 2 слабовидящих) показало, что 4 из 5 критических сценариев имели хотя бы один блокирующий барьер.

Команда устранила 12 критических проблем за два спринта (4 недели), начав с оформления заказа. Повторное тестирование подтвердило разрешение всех трёх блокеров — пользователи программ чтения с экрана теперь могли полностью завершить покупку. Остальные проблемы были распределены на следующие два квартала. Через шесть месяцев мониторинг доступности показал снижение общего количества нарушений WCAG на 73%, а обращения в поддержку от пользователей с инвалидностью сократились на 61%.

Ошибки начинающих

Зависимость только от автоматизированных сканирований

Автоматизированные инструменты выявляют около 30-40% проблем WCAG. Начинающие часто запускают Lighthouse или WAVE, видят «прошедший» балл и заключают, что сайт доступен. Оставшиеся 60-70% проблем можно обнаружить только через ручное тестирование и реальные пользовательские сессии. Рассматривайте автоматизированные сканирования как отправную точку.

Тестирование без людей с инвалидностью

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

Исправление симптомов вместо системных причин

Когда сканирование показывает 47 изображений без alt-текста, начинающий может добавить alt-текст к этим 47 изображениям. Правильный вопрос — почему эти изображения без alt-текста: CMS не запрашивает его? Компонент рендерит изображения без атрибута alt? Исправление шаблона один раз предотвращает повторение проблемы.

Трактовка доступности как разового проекта

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

Игнорирование когнитивной доступности

Большинство тестирований фокусируется на программах чтения с экрана и клавиатуре — это важно, но неполно. WCAG также охватывает когнитивную доступность: ясный язык, последовательную навигацию, предотвращение ошибок и достаточное время. Включайте участников с когнитивными нарушениями и оценивайте уровень читаемости.

AI-промпты для этого метода

4 готовых AI-промптов с placeholder’ами — скопируйте и подставьте свой контекст. Все промпты для «тестирования доступности» →.