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