Accessibility testing — проверка того, могут ли люди с разными возможностями восприятия и управления пользоваться продуктом. Среди них пользователи программ экранного доступа, клавиатуры, увеличения, голосового ввода и других вспомогательных средств. Недоступная кнопка может полностью блокировать оплату, даже если мышью сценарий проходит идеально.
Для QA доступность — свойство пользовательской цепочки. Нужно найти действие, понять его назначение, выполнить его и получить результат. Поэтому проверка отдельных атрибутов полезна, но не заменяет прохождение задачи целиком.
Как использовать WCAG
WCAG описывает проверяемые критерии доступности веб-контента. Версия и уровень должны быть названы явно, например WCAG 2.2 AA. Уровни A, AA и AAA обозначают наборы требований; оценка «в целом доступно» не заменяет конкретный критерий и область проверки.
Четыре принципа помогают организовать работу: информация должна восприниматься, интерфейс — управляться, поведение — быть понятным, а разметка — поддерживать совместимость со вспомогательными технологиями. Соответствие стандарту оценивают по применимым критериям и полным процессам, а не по среднему баллу сканера.
Клавиатура и видимый фокус
Отложите мышь и пройдите основной сценарий. Используйте Tab и Shift+Tab для перемещения, Enter, Space и стрелки — там, где это соответствует типу элемента. Кнопка и список выбора имеют разные клавиатурные модели, поэтому требовать один набор клавиш от всех компонентов неправильно.
Проверьте логичный порядок, видимый фокус и отсутствие ловушки, из которой нельзя выйти. При открытии диалога фокус должен попадать в понятное место, а после закрытия возвращаться в подходящий контекст. Sticky-панель не должна полностью скрывать сфокусированный компонент: это отдельный критерий WCAG 2.2 AA, 2.4.11.
Семантика и программа экранного доступа
Screen reader получает информацию из дерева доступности: роли, названия, состояния и отношения элементов. Если кликабельный div выглядит кнопкой, но не имеет нужной семантики и управления, пользователь может не обнаружить действие.
Проверьте заголовки, области страницы, доступные имена ссылок и кнопок, подписи полей. У иконки удаления должно быть понятное имя с контекстом, особенно если одинаковых иконок много. Alt-текст передаёт назначение значимого изображения; декоративному изображению обычно нужен пустой alt, чтобы не создавать лишний шум.
Формы, ошибки и динамика
Название поля должно оставаться понятным после ввода. Обязательность и ошибка сообщаются текстом, а не только красной рамкой. Пользователь должен обнаружить ошибку, понять способ исправления и продолжить без потери допустимых данных.
После добавления товара, изменения результата поиска или появления серверной ошибки проверьте, получает ли screen reader нужную обратную связь. Не каждое обновление требует переноса фокуса: неожиданный прыжок может мешать. Выбор между статусным сообщением и изменением фокуса зависит от задачи и характера события.
Контраст, цвет и размер цели
Для обычного текста WCAG 2.2 AA требует контраст не ниже 4,5:1, для крупного — 3:1. Крупным считается текст от 18 pt либо от 14 pt при полужирном начертании. Предусмотрены исключения, например логотипы и неактивные элементы. Цвета измеряют инструментом на фактическом фоне, учитывая состояния.
Цвет не должен быть единственным способом объяснить ошибку или статус. Критерий 2.5.8 AA устанавливает минимальную цель указателя 24×24 CSS-пикселя с оговорёнными исключениями, включая достаточное расстояние. Значение 44×44 относится к усиленному критерию AAA и не является универсальным минимумом AA.
Увеличение и перестроение
Увеличьте текст и масштаб браузера. Проверьте, сохраняются ли подписи, действия, сообщения и порядок чтения. В обычном вертикальном контенте при ширине, эквивалентной 320 CSS-пикселям, не должна требоваться прокрутка сразу по двум направлениям; для объективно двумерного содержимого есть исключения.
Проверяйте диалоги, меню, таблицы и длинные ошибки, а не только статичный абзац. Интерфейс может успешно переносить текст, но обрезать единственную кнопку подтверждения на увеличенном масштабе.
Практический пример: доступная запись на приём
Пусть пользователь выбирает специалиста, дату и подтверждает запись. Проверку проводим в поддерживаемой комбинации браузера и вспомогательной технологии.
- 1.Пройдите цепочку клавиатурой. Ожидается доступ ко всем действиям с видимым и логичным фокусом.
- 2.С screen reader выберите дату. Ожидаются понятные название календаря, текущий выбор и недоступные даты; одного произнесения чисел недостаточно.
- 3.Отправьте форму без обязательного телефона. Ожидается доступное сообщение, связь с полем и возможность исправления.
- 4.Увеличьте масштаб и повторите подтверждение. Ожидается доступ к кнопке и результату без потери существенной информации.
- 5.Имитируйте занятый слот после отправки. Ожидается объяснение изменения и понятный путь к новому выбору, включая невизуальный режим.
Автоматизация и границы проверки
Сканеры находят часть структурных проблем: некоторые отсутствующие имена, ошибки ARIA, измеримые нарушения контраста. Они не определяют полноту смысла alt-текста и удобство целой задачи. Результат без обнаруженных нарушений не доказывает полное соответствие WCAG.
Комбинируйте автоматический анализ, ручную клавиатурную проверку, screen reader и оценку применимых критериев. Фиксируйте протестированные страницы, состояния, инструменты и версии. Это делает вывод ограниченным и воспроизводимым.
Как описывать дефект и чего избегать
Укажите пользовательский барьер, шаги, окружение и критерий, если он установлен. «После закрытия диалога фокус попадает в начало страницы, пользователь теряет выбранную строку» полезнее, чем «сломана accessibility». Добавьте ожидаемый способ восстановления.
Частые ошибки — ставить ARIA повсюду вместо корректных HTML-элементов, считать мышиный сценарий достаточным и выдавать сканерный отчёт за сертификат. Цель QA — доказать доступность важных действий и точно назвать оставшиеся барьеры.