Посетитель заполнил форму и дошёл до выбора даты. Календарь открывается, но с клавиатуры день выбрать невозможно. Человек вынужден искать другой способ связаться с компанией. Такая ошибка легко остаётся незамеченной на показе сайта, где разработчик уверенно щёлкает мышью по знакомым местам.
Проверить доступность формы можно уже на приёмке. Уберите мышь в сторону и пройдите путь клиента клавиатурой. Для первого прохода достаточно формы обращения, отдельной тестовой заявки и сотрудника, который подтвердит её получение. Ниже шесть сценариев с признаками удачного результата и примерами замечаний.
Эта проверка охватывает управление с клавиатуры. Полную оценку доступности проводят шире, включая чтение страницы вспомогательными программами и другие способы взаимодействия. Но обнаруженный здесь тупик уже даёт команде конкретную задачу и понятный способ проверить исправление.
1. Дойдите до формы с начала страницы
Откройте страницу в новом окне, поставьте курсор в адресную строку и перейдите к содержимому. Затем нажимайте Tab и следите, куда попадает выделение. Последовательность должна давать понятный путь к форме через элементы страницы. Для движения назад обычно используют Shift вместе с Tab.
Сначала проверьте настройки браузера и операционной системы. Некоторые сочетания настроек меняют поведение клавиатурной навигации. Попросите разработчика показать ожидаемый режим на вашем устройстве и запишите его в протокол. После этого проходите сценарий самостоятельно, иначе демонстрация останется привязанной к рабочему компьютеру исполнителя.
Обратите внимание на меню, закреплённую шапку и всплывающую панель согласия. Они могут перехватить внимание ещё до формы. Если панель перекрывает страницу, у посетителя должна быть возможность обработать её с клавиатуры и продолжить маршрут. Запишите момент, когда продвижение остановилось, и название элемента, на котором это случилось.
У длинной страницы полезен быстрый переход к основному содержимому. Его конкретное устройство согласует разработчик, а заказчик проверяет результат: человеку доступна форма без многократного прохода по одинаковым ссылкам меню. Во время повторной проверки начинайте с той же точки и сравнивайте путь.
Сам принцип управления описан в пояснении W3C к критерию Keyboard. Для обычной формы действия должны быть доступны через клавиатурный интерфейс. В проектном списке приёмки запишите, какие действия вы проверяете, например выбор услуги и отправку обращения.
2. Убедитесь, что выделение видно на каждом шаге
Элемент в фокусе получает ввод с клавиатуры. Его положение на странице можно обозначить рамкой вокруг поля или обводкой кнопки. Когда выделение исчезает, посетителю приходится угадывать, что произойдёт после следующего нажатия. На светлом экране едва заметная серая линия особенно легко теряется.
Пройдите по каждому полю в обе стороны. Сравните выделение на белом фоне, цветной подложке и внутри раскрытого списка. Оно должно оставаться различимым при прокрутке. Если закреплённая панель закрывает активное поле, зафиксируйте размеры окна и положение страницы, при котором это воспроизводится.
Проверяйте реальные состояния. Заполненное поле, поле с ошибкой и поле после возврата с другого шага иногда выглядят по-разному. Красная рамка ошибки может заменить обводку фокуса, и человек потеряет ориентир. Снимок экрана покажет разработчику, какие два состояния столкнулись.
Требование видимого индикатора изложено в пояснении W3C к Focus Visible. В приёмке лучше описывать наблюдение простыми словами. Например, «после перехода с телефона на кнопку отправки выделение пропадает; следующий Tab выделяет ссылку под формой». Это точнее замечания «плохая доступность».
Такой проход удобно включить в общую приёмку сайта заказчиком. Он занимает отдельную строку рядом с проверкой мобильного вида и доставки обращения. Ответственным за исправление останется разработчик, результат повторно проверит тот, кто нашёл препятствие.
3. Заполните поля и дополнительные элементы
Введите имя, телефон и комментарий. Перемещайтесь между полями, меняйте уже введённые значения, возвращайтесь к началу. Маска телефона, которая автоматически переставляет курсор, может мешать исправить одну цифру. Проверяйте именно исправление, поскольку первый ввод часто проходит без затруднений.
У каждого поля должна быть понятная подпись. Текст внутри пустого поля исчезает после ввода, поэтому человек может забыть, какую информацию от него ждут. Сравните пустую и заполненную форму. Назначение поля и требование к формату должны оставаться доступны, когда в нём уже есть значение.
Дальше переходите к календарю, выбору филиала и загрузке файла, если они входят в сценарий. У этих элементов бывают собственные клавиши управления. Разработчик должен объяснить ожидаемое поведение и сделать подсказку доступной там, где она нужна. Сам факт открытия списка ещё не означает, что посетитель сумеет выбрать значение.
Для учебной формы записи в мастерскую проверка может включать такой маршрут. Клиент выбирает филиал, открывает даты, переходит к следующей неделе и подтверждает удобный день. Потом возвращается к филиалу и выбирает другой адрес. Форма должна объяснить, сохранилось ли время и требуется ли выбрать новый доступный интервал.
Сохраните итоговую комбинацию и попросите сотрудника сравнить её с полученной заявкой. Иногда видимый выбор меняется, а в обращении остаётся прежнее значение. Эту часть стоит проходить вместе с проверкой пропадающих заявок, чтобы отделить удобство заполнения от доставки данных.
Если форма уже требует нескольких обходных действий, включите её переработку в задачу на разработку сайта. Для оценки пригодится запись экрана с полным маршрутом и перечень полей, которые бизнесу действительно нужны.
