Чтобы форма была доступной, каждому полю нужна понятная подпись, клавиатуре — предсказуемый порядок перехода, а пользователю — заметные инструкции и сообщения об ошибках. Проверять следует не только внешний вид: интерфейс должен сохранять смысл без цвета, мыши и визуальных подсказок.
Как правильно подписывать поля формы?
У каждого поля должна быть постоянная текстовая подпись, программно связанная с элементом ввода. Атрибут placeholder её не заменяет: подсказка исчезает после начала ввода, часто выглядит бледно и может не дать программе чтения с экрана достаточного контекста.
Подпись лучше размещать над полем или рядом с ним, сохраняя одинаковую схему во всей форме. Формулировка должна объяснять, что требуется: «Рабочая электронная почта» полезнее, чем одинокое слово «Почта». Если формат неочевиден, пример указывают отдельной подсказкой и связывают с полем через aria-describedby.
Обязательность нельзя обозначать только красным цветом. Добавьте текст «обязательное поле» или понятный символ с расшифровкой. Тогда требование останется заметным и на монохромном экране, и при нарушении цветовосприятия.
Какими должны быть ошибки и подсказки?
Сообщение об ошибке должно назвать проблему и подсказать исправление. Фразы «Некорректное значение» недостаточно: пользователь не понимает, где именно нарушено условие и какой результат примет система.
| Ситуация | Неудачное сообщение | Понятный вариант |
|---|---|---|
| Пустое поле | Ошибка ввода | Введите фамилию |
| Неверный формат | Недопустимые данные | Укажите адрес в формате [email protected] |
| Короткий пароль | Пароль не принят | Используйте не менее восьми символов |
После отправки фокус обычно переводят к сводке ошибок либо к первому проблемному полю. Само поле выделяют визуально и связывают с текстом ошибки программно. Одного красного контура мало: тонкая цветная рамка легко теряется на ярком экране.
Проверка во время ввода полезна не всегда. Слишком раннее предупреждение мешает, потому что система сообщает об ошибке до завершения ответа. Часто удобнее проверять значение после ухода из поля или при отправке формы.
Как обеспечить управление без мыши?
Все интерактивные элементы должны работать с клавиатуры, а фокус — оставаться заметным. Пользователь должен последовательно пройти поля, кнопки, раскрывающиеся панели и диалоговые окна клавишей Tab, не попав в ловушку.
- Проверьте логичный порядок фокуса сверху вниз и слева направо.
- Не удаляйте стандартную обводку фокуса без заметной замены.
- Используйте Enter и Space в соответствии с привычным поведением элемента.
- Позвольте закрыть модальное окно клавишей Escape, если это не нарушает сценарий.
- После закрытия окна возвращайте фокус на элемент, который его открыл.
- Не назначайте сочетания клавиш, конфликтующие с браузером или вспомогательными технологиями.
Проверка проста: временно уберите мышь и выполните весь сценарий. Если непонятно, где находится курсор, либо до кнопки нельзя добраться, интерфейс требует доработки. Особенно часто проблемы возникают у самодельных переключателей и выпадающих списков.
Когда нужны ARIA-атрибуты?
ARIA применяется, когда семантики обычного HTML недостаточно для передачи роли, состояния или связи элементов. При этом нативная кнопка <button> почти всегда надёжнее, чем <div role="button">, поскольку уже поддерживает фокус и клавиатурное управление.
Атрибуты aria-expanded, aria-selected и aria-invalid должны меняться вместе с реальным состоянием интерфейса. Статичная разметка, которая сообщает «раскрыто» после закрытия панели, дезориентирует сильнее, чем отсутствие дополнительного описания.
Сложные элементы проверяют не только инспектором кода. Нужен короткий тест с клавиатурой и хотя бы одной программой чтения с экрана: слышна ли подпись, объявляется ли состояние, понятен ли результат действия. Автоматический аудит обнаруживает часть ошибок, но не оценивает ясность инструкции или логичность переходов.
Нужно ли упрощать дизайн ради доступности?
Доступность обычно не требует примитивного оформления. Она требует достаточного контраста, различимых состояний, крупных зон нажатия и предсказуемого поведения. Эти свойства помогают всем пользователям, особенно на небольшом экране, при ярком солнце или временной травме руки.
Начинать лучше с нативных HTML-элементов, а затем добавлять визуальное оформление и необходимые состояния. Чем сложнее декоративная оболочка, тем тщательнее проверка. Хорошая форма не привлекает внимания к механике: подписи остаются на месте, фокус виден, а ошибка объясняет следующий шаг.