1. Определите масштаб проверки
Начинайте с полных результатов, а не с случайных URL. Пропишите карту: главная страница, ключевой контент, поиск, контакт, аккаунт, бронирование или чек-аут, подтверждение и вся встроенная служба, используемая по пути. Включите повторно используемую навигацию, модальные окна, управление cookie и формы, потому что одна ошибка может повторяться по всему сайту.
Зафиксируйте версию и уровень WCAG, охват, браузеры, устройства и известные исключения.
Проверьте каждый шаг и состояние, включая режимы после входа, пустые состояния и страницы с ошибками.
2. Проверьте путь с клавиатуры
Выполняйте каждую выбранную задачу без указателя мыши. Пройдите Tab и Shift+Tab по ссылкам, элементам управления, диалогам, меню, фильтрам, календарям, медиа и виджетам поставщиков. Фокус должен быть видимым, идти в логическом порядке, никогда не застревать и возвращать пользователя в полезное место после закрытия диалога. Управление с клавиатуры — центральный элемент WCAG; не предполагая, что пользовательский элемент управления мышью работает с клавиатурой.
Предоставьте и протестируйте способ добраться до основного содержимого без последовательного табирования по повторной навигации.
Если интерфейс требует перетаскивания, проверьте, доступна ли альтернативная операция без перетаскивания.
3. Проверьте структуру и понятность
Давайте страницам описательные заголовки и используйте заголовки для иерархии, а не для внешнего вида. Убедитесь, что элементы управления предоставляют полезное имя, роль и состояние для вспомогательных технологий; нативные HTML‑элементы часто снижают риск. Значимые изображения должны иметь краткий альтернативный текст, соответствующий их назначению, а декоративные изображения не должны добавлять шума. Не используйте только цвет для передачи статуса или инструкций и указывайте язык страницы.
Сделайте назначения или действия понятными в контексте; повторяющиеся расплывчатые ссылки создают неоднозначность.
Когда меняется макет или стили недоступны, содержимое и элементы управления всё равно должны читаться логично.
4. Проверяйте текст, макет, цвет и медиа при стресс‑тесте
Увеличьте масштаб браузера и размер текста, затем повторите ключевые задачи. Содержимое должно оставаться читаемым и удобным в использовании, а не сталкиваться, исчезать или требовать ненужного горизонтального поиска. Проверьте реальные пары цветов для текста, элементов управления, фокуса, ошибок и диаграмм в релевантных состояниях. Для записанного медиа предоставьте субтитры для необходимой аудиоинформации и текстовые альтернативы, соответствующие содержанию.
Включайте hover, focus, disabled, error и любые тёмные или альтернативные визуальные состояния.
Проверьте проигрыватель с клавиатуры, а также субтитры, стенограммы и важную визуальную информацию.
5. Сделайте формы и задачи в аккаунтах восстанавливаемыми
Отправьте формы с отсутствующими, неверными и валидными данными через ваши наиболее важные формы. Поля ввода должны иметь постоянные, программно связанные метки; плейсхолдеры сами по себе ненадёжны. Указывайте обязательные поля до отправки, объясняйте ошибки понятным языком, указывайте на соответствующее поле и по возможности сохраняйте введённые данные. Тестируйте вход, сброс пароля, одноразовые коды, оформление заказа и подтверждение как целостные сценарии.
Сопоставляйте цвет ошибки с текстовым сообщением понятным языком и однозначно идентифицируемым полем.
Протестируйте передачу управления, редирект, путь отказа и возврат из платёжных или идентификационных провайдеров с клавиатуры.
6. Комбинируйте инструменты с людьми и ручной проверкой
Запустите автоматический сканер на представительских страницах и используйте его результаты как подсказки, а не как сертификат прохождения. Инструменты не могут оценить, является ли альтернативный текст информативным, логичен ли порядок, понятны ли инструкции или работает ли сценарий с вспомогательными технологиями. Добавьте ручные проверки с клавиатурой и масштабированием плюс целенаправленную проверку со скринридером. По возможности привлекайте людей с релевантным жизненным опытом на ранних стадиях и справедливо оплачивайте их работу.
Сохраняйте выводы инструментов, заметки рецензентов, принятые решения, исправления и результаты повторных проверок в одном записи задачи.
Привлекайте квалифицированного оценщика для формальных заявлений, регулируемых сервисов, сложных приложений или спорных результатов.
7. Встраивайте исправления в релизы
Доступность может регрессировать после смены темы, кампании, плагина, скрипта, дизайн‑токена или поставщика. Добавьте пропорциональную проверку в процессы дизайна, контента, контроля качества и запуска. SIU ориентирован на проактивную оптимизацию доступности и исправление ошибок: поддерживайте предрелизный путь, выявляйте дефекты, влияющие на клиентов, делайте безопасные исправления и имейте план отката при необходимости. Проверка доступности дополняет эту работу; её не заменяют проверки доступности сайта или оповещения о простоях.
Блокируйте релиз, если основная задача не может быть выполнена с клавиатуры или критическую ошибку невозможно понять.
Проверьте исходную задачу, мобильные и ошибочные состояния после исправления перед закрытием задачи.