Scott
Порядок фокуса — это последовательность элементов, к которым человек переходит, управляя интерфейсом с клавиатуры. Проектируйте её для целого сценария: заполнить форму, открыть диалог, исправить ошибку и вернуться в нужное место. Нумерация элементов на исходном экране помогает начать обсуждение, но не объясняет, что произойдёт после изменения этого экрана.
Работая в редакторе интерфейсов для совместной работы, описывайте фокус рядом с видимыми состояниями. На примере формы заказа поставщику разберём, что нужно отметить в макете, какие решения относятся к компоненту и что разработчику предстоит проверить на работающей странице.
Начните с задачи, а не с зигзага из номеров
Представьте сотрудника отдела закупок, который оформляет заказ. На странице есть поставщик, адрес доставки, строки товаров, необязательный комментарий и переход к проверке заказа. На большом экране сводка расположена рядом с формой, на телефоне — под ней. Пользователь должен выбрать поставщика, подтвердить адрес, добавить товары и проверить заказ, не перескакивая неожиданно в сводку между связанными полями.
Перед нумерацией выделите группы. Поставщик и адрес относятся к доставке; товар, количество и цена за единицу — к одной позиции заказа. Промежуточная сумма сообщает информацию, но не обязательно должна получать фокус при нажатии Tab. Ссылка на сведения о поставщике, напротив, доступна для действия, и ей нужно место в маршруте. Если включить в последовательность каждую видимую подпись, простая задача потребует лишних переходов.
В пояснении WCAG о порядке фокуса (на английском) требуется последовательность, сохраняющая смысл и возможность работы. Единого визуального порядка для всех интерфейсов оно не задаёт. Учитывайте это при изменении компоновки: важно, понимает ли человек происходящее и может ли завершить задачу, а не образуют ли номера идеально прямую линию.
Отделите порядок Tab от перемещения внутри элемента
Tab обычно переводит фокус между элементами управления. Внутри некоторых составных элементов для перемещения используются клавиши со стрелками. Например, для поля выбора поставщика нужно описать открытие подсказок, перемещение между вариантами, подтверждение выбора и выход без выбора. Не превращайте каждую подсказку в постоянную остановку в общей последовательности Tab.
| Элемент формы заказа | Что описать | Типичная ошибка |
|---|---|---|
| Поле выбора поставщика | Получение фокуса, ввод текста, перемещение по вариантам, выбор и поведение Escape | Переход по каждой подсказке клавишей Tab |
| Поле количества | Видимый фокус и следующий элемент после редактирования | Перемещение фокуса при пересчёте суммы |
| Изменение адреса доставки | Начальную точку фокуса в диалоге и точку возврата | Потеря текущего места после закрытия диалога |
| Сводка заказа | Порядок чтения и действительно доступные ссылки или кнопки | Фокус на каждой сумме только потому, что она визуально выделена |
Индикатор фокуса, выбранное значение и состояние наведения передают разную информацию. Покажите их в макете отдельно. Поставщик остаётся выбранным, даже когда фокус перешёл к количеству товара. Если оба состояния оформлены одинаково, при проверке легко перепутать сохранённый выбор с текущим положением клавиатурного фокуса.
Опишите вход в диалог и выход из него
Пользователь активирует «Изменить адрес доставки». Для диалога нужно определить подходящую начальную точку фокуса, порядок перемещения внутри и точку возврата после закрытия. В короткой форме таким началом может быть первое поле. В длинном диалоге сначала может потребоваться заголовок или пояснение. Решение зависит от задачи и содержания, а не от правила «всегда выбирать первую кнопку».
Паттерн модального диалога WAI-ARIA (на английском) описывает удержание клавиатурной навигации внутри открытого модального окна и корректный возврат фокуса после закрытия. Отдельно укажите поведение сохранения, отмены и Escape. После сохранения адреса пользователь должен продолжить работу с заказом, а после отмены — увидеть прежний адрес.
Для нашего примера запись может быть такой: «Открытие: фокус на поле “Адрес, строка 1”. Отмена или Escape: возврат на “Изменить адрес доставки”, сводка не меняется. Сохранение: обновить сводку, закрыть диалог, вернуть фокус на “Изменить адрес доставки”». Если после сохранения эта кнопка исчезает, определите другую точку, которая остаётся на странице. Стрелка к уже удалённому элементу не заменяет решения для разработки.
Учтите новые строки, ошибки и узкий экран
В заказе есть действие «Добавить товар». Решите, переводит ли оно фокус в поле новой позиции или оставляет на кнопке добавления. Переход к новой строке удобен, когда пользователь сразу вводит данные и понимает, куда попал. Сохранение фокуса на кнопке может подходить для добавления нескольких строк подряд. Выберите поведение осознанно и объясните, какой сценарий оно поддерживает.
Удаление требует такой же точности. Если кнопка удаления, находившаяся в фокусе, исчезает вместе со строкой, нужна полезная точка продолжения: аналогичная кнопка следующей строки, предыдущей строки, если следующей нет, или «Добавить товар», когда список пуст. Опишите все три случая вместо неопределённого «вернуть фокус».
Если проверка заказа выявила несколько ошибок, определите, как пользователь узнает о них и доберётся до нужных полей. В сводке ошибок могут быть ссылки на отсутствующего поставщика и неверное количество. Исправление одного значения не должно неожиданно переносить человека к следующей ошибке. Обновляйте обратную связь, не сбивая текущую работу.
На телефоне сводка заказа перемещается под поля. Вместе с разработчиком сопоставьте порядок чтения и порядок фокуса. CSS может изменить визуальное положение, не изменяя порядок элементов в документе. Файл макета не доказывает, как браузер будет обходить готовую страницу, а один скриншот узкого экрана не выявляет этого расхождения.
Подготовьте спецификацию фокуса в Pixso
Разместите в одном файле Pixso исходную форму заказа, диалог адреса, состояние с добавленной строкой, состояние после удаления и форму с ошибками. Во всех фреймах используйте одного поставщика и один набор товаров: тогда обсуждение будет касаться навигации, а не меняющихся данных. Добавьте номера рядом с интерактивными элементами, не перекрывая их подписи.
Для каждого перехода укажите действие, точку назначения и сохраняемые данные. Например: «Удаление средней строки → кнопка удаления следующей строки; количества остальных товаров не меняются». Для перемещения внутри составного элемента используйте другой вид обозначений, чтобы его нельзя было принять за общий порядок Tab. Соедините видимые состояния в прототипе для обсуждения сценария, а клавиатурное поведение явно опишите для реализации.
Привязывайте нерешённые вопросы к конкретному компоненту или экрану. Комментарий «Куда перейдёт фокус после удаления последней строки?» помогает принять решение. «Сделать доступным» не задаёт ни поведения, ни способа его проверки.
Проверьте маршрут в работающем интерфейсе
Начните оформление заказа с клавиатуры, не выбирая поле мышью заранее. Пройдите вперёд и назад, откройте и закройте диалог, добавьте и удалите строку, отправьте неполную форму. Наблюдайте, где оказывается фокус и остаётся ли его индикатор видимым. Повторите проверку в узком окне и при увеличенном масштабе: закреплённые кнопки не должны закрывать элемент в фокусе.
Описывайте сбой так, чтобы его можно было воспроизвести: начальное состояние, нажатые клавиши, ожидаемая и фактическая точки фокуса, влияние на задачу. Проверка возврата из диалога в браузере убедительнее стрелки на скриншоте. Аннотации помогают согласовать поведение, а работающий интерфейс — установить, реализовано ли оно.
