Проверка доступности отвечает на практический вопрос: может ли человек выполнить нужное действие при разных способах взаимодействия с сайтом. ИИ помогает разбирать код и формулировать гипотезы, но одного скриншота недостаточно для оценки клавиатуры, семантики и сообщений программы чтения с экрана. Начните с конкретного пользовательского маршрута.
Выберите сценарий
Возьмите поиск товара, отправку формы или изменение настроек. Укажите начало, успешное завершение и основные ошибки. Зафиксируйте целевой стандарт и уровень соответствия. WCAG 2.2 содержит проверяемые критерии, однако вывод о соответствии нельзя делать по одному удачному проходу одной страницы.
Соберите состояния интерфейса, HTML релевантных элементов и результаты автоматического инструмента. Состояние после ошибки формы может отличаться от исходного. Модальные окна, раскрытые меню и подтверждения операций часто содержат отдельные препятствия. Укажите, какие из этих состояний действительно доступны для проверки, а какие пока описаны только в макете.
Порядок работы
- Пройдите сценарий обычным способом и запишите шаги.
- Повторите его клавиатурой, наблюдая порядок и видимость фокуса.
- Проверьте названия полей, кнопок и ссылок в дереве доступности.
- Увеличьте масштаб и оцените, не теряются ли действия и содержимое.
- Проверьте ошибки формы: сообщение, связь с полем и возможность исправления.
- Сопоставьте автоматические находки с ручным воспроизведением.
Руководство W3C по оценке доступности рассматривает разные методы проверки. Автоматический отчёт является частью процесса. Отсутствие найденных инструментом ошибок не означает, что весь интерфейс доступен.
Пример с формой
Учебная форма содержит имя, почту и кнопку отправки. При пустой почте поле становится красным, но сообщение не появляется. Человек, который не различает цвет, может не понять причину отказа. Исправление должно добавить понятный текст и программную связь с полем, а не только изменить оттенок рамки.
Другой пример: после открытия диалога фокус остаётся на странице под ним. Пользователь клавиатуры перемещается по невидимым элементам. Запишите последовательность клавиш и ожидаемое поведение при открытии и закрытии. Общий совет «добавить ARIA» недостаточен: неправильные атрибуты способны усложнить ситуацию. Проверять нужно работающий сценарий целиком.
Промпт
Проверь маршрут и HTML на барьеры доступности. Для находки укажи затронутого пользователя, шаг воспроизведения, наблюдаемое поведение и критерий WCAG, если связь подтверждена. Раздели доказанные проблемы и гипотезы. Не объявляй соответствие стандарту по скриншотам. Предложи минимальное исправление и способ повторной проверки.Оформление находок
В карточке нужны адрес или состояние, элемент, действие, результат и влияние на задачу. Приоритет определяется тем, блокируется ли основной сценарий и существует ли доступный обход. Косметическое неудобство и невозможность отправить форму требуют разной срочности. Для контраста фиксируйте реальные цвета и состояние элемента, а не оценивайте его на глаз.
После исправления повторите исходный сценарий и соседние состояния. Управление фокусом должно корректно работать при отмене, успешном сохранении и ошибке. Проверьте возвращение фокуса к логичному месту. Сохраните короткую запись результата, чтобы будущий рефакторинг не вернул проблему. Если изменён общий компонент, проверьте хотя бы несколько разных способов его использования.
Границы выводов
Укажите страницы, браузеры и способы взаимодействия, которые проверялись. Если программа чтения с экрана не использовалась, не заявляйте, что этот сценарий проверен. Для серьёзной оценки полезно участие специалистов и пользователей с инвалидностью. ИИ ускоряет подготовку и систематизацию, но не подменяет их взаимодействие с продуктом.
Планируйте доступность вместе с разработкой. Требования к названию кнопки и фокусу проще реализовать в компоненте сразу. При этом библиотечный компонент не становится автоматически правильным: итог зависит от контекста, переданных свойств и окружающей страницы. Проверка после сборки остаётся необходимой.
Частые вопросы
Достаточно проверить контраст?
Нет. Доступность связана также с управлением, структурой, понятностью и передачей состояния. Контраст не исправит недоступную с клавиатуры кнопку.
Можно проверять только код?
Код помогает находить причины, но поведение наблюдают в работающем интерфейсе. Скрипты и динамические состояния могут менять результат.
Что отдавать разработчику?
Короткое воспроизведение, ожидаемое поведение и повторную проверку. Это полезнее требования «сделать доступно» без конкретного барьера.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.