Доступный веб-дизайн: практическое руководство по формам заявок

Доступный веб-дизайн даёт людям с разными возможностями зрения, движения и восприятия выполнить одну и ту же задачу. В форме заявки эта задача проста: понять поля, ввести данные, суметь исправить ошибку и убедиться, что запрос дошёл. Визуально завершённый вид формы не доказывает, что этот путь работает для всех.

Это руководство рассматривает формы заявки и обратной связи для владельцев корпоративных сайтов, дизайнеров и разработчиков. Технические заметки со ссылками на источники W3C и наш подход к организации работы над проектом изложены отдельно. Цифры на графиках — примеры, иллюстрирующие план аудита. Для прямого перехода к практике — пример подписи поля или тестовая матрица.

Оценивайте доступность через задачу

Легко начать проверку страницы с цветовой палитры или балла инструмента. Но пользователю нужен результат. Поэтому мы советуем сначала сформулировать задачу: «Посетитель должен уметь выбрать услугу, описать потребность и отправить запрос на консультацию». Затем разбейте, из каких шагов состоит задача. Найти форму, отличить обязательное поле и продолжить после ошибки — тоже часть этой задачи.

Например, если форма в выпадающей панели открывается только курсором, правильности подписей полей самой по себе недостаточно. Пользователь ещё не добрался до формы. Похожим образом, если сообщение об успехе после отправки появляется в другом месте экрана, завершение действия можно не заметить. Сценарий приёмки должен охватывать весь путь целиком.

Учебник W3C по формам рассматривает подписи, инструкции и обратную связь пользователю вместе. Это руководство не претендует на полный аудит соответствия сайта — это практический каркас для начала работы над потоками форм. Его можно использовать вместе с нашим руководством по B2B-лендингам для определения коммерческой цели и структуры запроса.

Подпись, подсказка и связь с полем

Подпись говорит пользователю, что писать в поле. Текст подсказки объясняет, зачем это нужно или какой формат ожидается. Placeholder не должен заменять постоянную подпись — он исчезает при вводе текста. W3C описывает связь подписи с соответствующим элементом управления; стандартный подход — сопоставить значение for у label со значением id поля. Подробности — в руководстве по подписям.

Пример ниже показывает структуру одного поля. Это не полная рабочая форма — отправку, серверную проверку и состояния ошибок нужно реализовать отдельно.

<label for="project-email">Ваш email (обязательно)</label>
<p id="project-email-help">
  Мы свяжемся с вами по этому адресу по поводу проекта.
</p>
<input
  id="project-email"
  name="email"
  type="email"
  autocomplete="email"
  aria-describedby="project-email-help"
  required
/>

Пересмотрите и содержание названия поля. Написать «Опишите проблему, которую хотите решить в проекте» вместо «Информация» направляет ответ. Но если подпись превращается в слишком длинное описание, сохраните короткий заголовок, а пример перенесите в текст подсказки. Пользователю не нужно перечитывать целый абзац при переходе между полями.

Не делайте автоматически обязательными такие поля, как рабочий телефон, текущий сайт и бюджет. Оцените, зачем каждое из них действительно нужно на первом контакте. Если назначение поля неясно, это проблема и для дизайна, и для качества данных. Запрашивать меньше данных не всегда правильно для любого проекта; но у каждого поля должно быть обоснование.

Порядок клавиатуры и видимый фокус

Проведите простой ручной тест: отпустите мышь, начиная с начала страницы, переходите по форме клавишей Tab, меняйте значения и отправляйте её. Затем вернитесь назад Shift+Tab. Отметьте каждый момент, когда трудно уследить за положением фокуса. Если визуальный порядок расходится с порядком клавиатуры, пересмотрите вёрстку.

Наша рекомендация — использовать стандартные кнопки и элементы управления формы как отправную точку. Если добавлять поведение кликабельного блока обычному текстовому элементу, нужно отдельно выстраивать взаимодействие с клавиатурой и передачу состояния. Добиться нужного внешнего вида реальными button или input в большинстве случаев более управляемое решение.

Не убирайте кольцо фокуса только потому, что оно не вписывается в дизайн. Вместо этого спроектируйте заметный в теме индикатор. Не перекрывает ли фиксированная нижняя панель контактов или верхняя навигация сфокусированную область, не переносит ли модальное окно пользователя случайно на предыдущую страницу, возвращается ли он к прежней позиции после закрытия формы? Это поведенческие проверки, которые не видны на скриншоте.

Сообщение об ошибке — это инструкция по исправлению

Фраза «Недопустимое значение» не говорит пользователю, что именно изменить. «Введите email в формате name@example.com» — более применимое сообщение. Отметить неверное поле только красной рамкой тоже недостаточно для коммуникации. Руководство W3C по уведомлениям рассматривает и объяснение ошибки, и возможность пользователя добраться до нужного поля.

Если ошибок несколько, можно использовать краткую сводку над формой и локальные сообщения рядом с полями. Проверьте, что ссылки в сводке действительно ведут к соответствующим полям. Состояние ошибки должно быть понятно и программно — например, для проблемного поля можно установить aria-invalid и связать описание. Не оставляйте эти атрибуты постоянно включёнными при отсутствии ошибки.

Используйте сообщение о сетевой ошибке из таблицы только если данные действительно сохраняются. Текст интерфейса должен точно описывать поведение приложения. Если пользователю приходится заново вписывать всё описание, фраза «ваши данные сохранены» подрывает доверие ещё сильнее.

Проектируйте успех и сетевую ошибку раздельно

В дизайн-макетах чаще всего есть пустой экран формы; состояния загрузки, ошибки и успеха дорабатываются позже, уже в разработке. Но с точки зрения пользователя самый важный момент — сразу после отправки. Принят ли запрос, нужно ли повторить попытку, создаёт ли повторное нажатие кнопки две записи?

Мы рекомендуем такой список состояний: начальное, ошибка валидации, отправка, принято и временная ошибка сервера. Для каждого состояния опишите отображаемый текст, поведение при повторной попытке и управление фокусом. Продумывая поведение кнопки в состоянии отправки, проверьте также, как человек, использующий вспомогательные технологии, поймёт изменение состояния.

Не показывайте экран успеха, пока сервер не принял запрос. Заявка, которая выглядит успешно отправленной в интерфейсе, но не доходит до email или CRM, — потеря и для бизнеса, и для пользователя. Не оставляйте ответственность за проверку только на браузере; проверка на стороне клиента улучшает удобство, но сервер должен заново проверить данные по своим правилам.

Мобильная вёрстка, масштабирование и размер цели

Проверить форму только на одном телефоне недостаточно. Доступны ли последнее поле и кнопка отправки при открытой экранной клавиатуре, обрезается ли длинный текст подсказки, теряется ли содержимое в горизонтальной ориентации? Свести двухколоночную вёрстку к одной колонке на маленьком экране может уменьшить часть этих проблем; проверять нужно на реальных текстах.

Критерий 2.5.8 размера цели в WCAG 2.2 определяет для уровня AA размер 24 × 24 CSS-пикселя и исключения вроде расстояния между элементами и встроенных в текст целей. Не воспринимайте это значение как комфортную цель для всего интерфейса. Наша дизайн-рекомендация — делать основные кнопки отправки и часто используемые мобильные элементы управления более крупными, отделёнными от окружения целями.

Критерий адаптации содержимого при увеличении рассматривает использование без потери информации и функций при ширине, эквивалентной 320 CSS-пикселям при вертикальной прокрутке; для содержимого, требующего двумерной раскладки, есть исключения. Отдельно проверьте укрупнение текста и масштабирование браузера в элементах формы. Сообщение об ошибке, которое нельзя прочитать в узкой области, не считается успешным.

Не запирайте информацию в одном канале

Если график различает две группы только цветом, это создаёт потерю информации для того, кто не различает этот цвет. Подписи, разные стили линий и текстовые описания можно использовать вместе. Кроме того, представление сложных числовых данных в виде таблицы одинаково подходит и для экранного диктора, и для читателя, который хочет внимательно сравнить значения.

Под графиками в этой статье есть раскрывающиеся таблицы данных. График предназначен для быстрого чтения общего распределения, таблица — для изучения отдельных значений. В описании также нужно указывать источник цифр. Представление примерного числа из тестового плана как отраслевого исследования приводит читателя к неверному выводу.

Это распределение не бюджет и не стандарт аудита. Если в вашем проекте есть многошаговая заявка, загрузка файлов или специальный выбор даты, план расширяется. Подсчёт проверок делает объём видимым с самого начала; настоящий критерий приёмки — выполнение задачи без препятствий.

Применимая тестовая матрица

Не ограничивайте тестовую матрицу списком устройств; добавьте задачу пользователя и ожидаемый результат. На одном и том же устройстве разные способы ввода могут выявить разные проблемы. Добавление к каждой находке шагов воспроизведения, затронутого раздела и ожидаемого поведения облегчает проверку исправления разработчиком.

В тесте с экранным диктором проверяйте не только чтение текста. Может ли пользователь найти, какое поле ошибочно, и вернуться к форме? Человек, проводящий тест и знающий приложение наизусть, может не заметить некоторые неясности. По возможности добавьте и наблюдение за человеком, использующим приложение впервые.

Автоматические инструменты полезны для определённых структурных проверок; но они сами по себе не решают, каким должно быть подходящее сообщение и понятна ли задача. Объедините автоматический отчёт с ручными находками в одном списке, отделите дубликаты и в приоритете держите то, что мешает пользователю.

Приоритет исправлений и повторное тестирование

Не расставляйте приоритет только по числу находок. Десять мелких проблем с описанием могут иметь более низкий приоритет, чем одна проблема, мешающая всем пользователям клавиатуры отправить форму. Затронутая задача, распространённость проблемы и наличие временного обходного пути должны оцениваться вместе.

В этом примере, несмотря на два оставшихся открытых пункта, находки, блокирующие задачу, закрыты. В реальном проекте оставшиеся пункты отслеживайте с ответственным и целевой датой, а не удаляйте. После исправления повторите те же шаги; особенно если изменился общий компонент формы, выберите примеры и на других страницах, которые его используют.

Как это встраивается в процесс поддержки

Если доступность остаётся разовой проверкой при первом запуске, она может регрессировать в новой форме кампании или языковой версии. Добавьте в дизайн-систему примеры подписей, ошибок, успеха и фокуса. Покажите команде контента, как писать названия полей и тексты подсказок. В приёмку разработки тоже включите короткое ручное повторение самых критичных задач.

Если вы переходите на новый дизайн, наш чек-лист по редизайну сайта поможет держать эту матрицу в том же файле сдачи. Для совместной оценки с производительностью наше руководство о быстром сайте — дополняющее чтение; быстрая загрузка и удобство использования требуют разных тестов.

Чтобы оценить существующий поток форм вместе с Piton Studios, поделитесь проектом через страницу контактов. Сначала мы определим задачу, которую должен выполнять пользователь, известные проблемы и используемые устройства, а затем составим применимый объём улучшений.