Пользователи клавиатуры не могут пройти веб-форму, хотя функциональные тесты проходят. Какой механизм делает это дефектом доступности, а не обычной функциональной ошибкой?
Это дефект доступности, потому что функция формально работает, но часть пользователей не может взаимодействовать с ней допустимым способом. Функциональное тестирование проверяет корректность результата и бизнес-логики, а тестирование доступности — возможность воспринимать интерфейс, управлять им и получать результат с учётом ограничений пользователя и используемых вспомогательных технологий.
По мере распространения цифровых продуктов стало недостаточно проверять только корректность вычислений и выполнение пользовательских сценариев в стандартных условиях. Продукт должен быть пригоден для людей с разными способами взаимодействия: клавиатурой, экранным диктором, увеличением интерфейса или альтернативными устройствами ввода.
Так сформировалось понимание доступности как отдельного атрибута качества. Оно дополняет функциональное тестирование: продукт может правильно выполнять операцию, но оставаться фактически непригодным для части аудитории.
Функциональный тест формы обычно проверяет, что корректные данные принимаются, некорректные отклоняются, а результат сохраняется. Такой тест может выполняться мышью и не обнаружить, что фокус нельзя перевести на поле, кнопка недоступна с клавиатуры или сообщение об ошибке не объявляется экранным диктором.
Неверное решение — считать успешное выполнение обычных сценариев доказательством доступности. Это приводит к исключению части пользователей из ключевого процесса, росту количества обращений и дорогостоящим исправлениям после выпуска.
Механизм дефекта состоит в разрыве между функциональной возможностью и доступным способом её использования. Форма может правильно отправлять данные, но если пользователь не может последовательно попасть в поля, понять их назначение, исправить ошибку или активировать кнопку без мыши, требуемая возможность для него отсутствует.
Проверка должна включать как минимум:
Автоматические средства полезны для поиска части известных проблем, например отсутствующих подписей или нарушений структуры. Однако они не заменяют ручную проверку: автоматизация обычно не может надёжно оценить логичность порядка фокуса, понятность текста ошибки и удобство полного сценария.
Ограничение подхода в том, что доступность не сводится к одному чек-листу и не гарантирует одинаковый опыт для всех пользователей. Поэтому разумный компромисс — сочетать автоматические проверки на каждой сборке с ручными проверками критических пользовательских потоков на этапе разработки и перед выпуском.
В интернет-магазине оформление заказа успешно проходит функциональные тесты, если использовать мышь. При проверке только клавиатурой фокус после поля адреса перескакивает в шапку сайта, а сообщение о неверном индексе не связано с полем.
Рассматривались три варианта. Полагаться только на функциональные тесты было бы быстро, но проблема осталась бы незамеченной. Использовать только автоматический сканер дешевле, однако он мог не обнаружить неправильный порядок фокуса и непонятное сообщение. Проводить только ручную полную проверку надёжнее, но это дорого и плохо масштабируется на каждое изменение.
Выбранное решение — добавить автоматические проверки доступности в сборочный процесс и выполнять ручной клавиатурный и экран-дикторный сценарий для оформления заказа. Такой вариант сочетает раннее обнаружение типовых ошибок с проверкой реального пользовательского опыта; в результате дефект был найден до выпуска, а исправление не потребовало переделки всей формы.
Нет. Нужно проверить весь сценарий взаимодействия: достижимость и активацию элементов, видимость фокуса, корректность его порядка, ввод, открытие компонентов, исправление ошибок и завершение операции. Некоторые элементы требуют проверки клавишами активации и закрытия, а не только последовательного перехода по фокусу.
Техническая разметка может сообщать вспомогательной технологии название и роль элемента, но не гарантирует правильный порядок взаимодействия, понятный текст, доступное состояние и корректную обработку ошибок. Доступность проверяется на уровне полного сценария, а не существования отдельных атрибутов.
Автоматический анализ выявляет только формализуемые признаки и имеет ограниченное покрытие. Он не оценивает, может ли пользователь понять инструкцию, предсказуемо пройти сценарий, восстановиться после ошибки и получить тот же значимый результат, что и пользователь без ограничений. Поэтому отрицательный результат сканера снижает риск, но не заменяет проверку человеком и вспомогательными технологиями.