Перейти к содержанию

Формы

Форма — это элемент, который позволяет пользователю предоставлять данные в поле или группу полей. Формы могут быть как простыми с одним полем, так и сложными многошаговыми элементами с несколькими полями на странице, проверкой ввода и иногда CAPTCHA.

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

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

Ознакомьтесь с нашим курсом Изучение форм, чтобы узнать, как создавать лучшие формы. В этом курсе есть модуль доступность форм с дополнительным контентом, специфичным для доступности.

Поля

Основой форм являются поля. Поля — это небольшие интерактивные паттерны, такие как элемент input или радиокнопка, которые позволяют пользователям вводить контент или делать выбор. Существует широкое разнообразие полей форм на выбор.

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

Если ситуация требует от вас создания пользовательских полей формы, обязательно изучите модули ARIA и HTML, Фокус клавиатуры и JavaScript, чтобы понять, как сделать эти пользовательские поля формы максимально доступными.

Не рекомендовано, HTML + ARIA
1
2
3
<div role="form" id="sundae-order-form">
    <!-- содержимое формы -->
</div>

Рекомендовано, стандартный HTML
1
2
3
<form id="sundae-order-form">
    <!-- содержимое формы -->
</form>

В дополнение к выбору наиболее доступных паттернов полей формы, где это применимо, вы также должны добавлять атрибуты автозаполнения HTML к вашим полям. Добавление атрибутов автозаполнения позволяет более детально определить или идентифицировать назначение для пользовательских агентов и вспомогательных технологий (AT).

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<form id="sundae-order-form">
    <p>Имя: <input type="name" autocomplete="name" /></p>
    <p>
        Телефон: <input type="tel" autocomplete="tel" />
    </p>
    <p>
        Адрес электронной почты:
        <input type="email" autocomplete="email" />
    </p>
</form>

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

Метки

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
<form id="sundae-order-form">
    <p>
        <label
            >Имя (обязательно):
            <input type="name" autocomplete="name" required
        /></label>
    </p>
    <p>
        <label
            >Телефон (обязательно):
            <input type="tel" autocomplete="tel" required
        /></label>
    </p>
    <p>
        <label
            >Адрес электронной почты:
            <input type="email" autocomplete="email"
        /></label>
    </p>
</form>

Кроме того, связанные поля формы, такие как почтовый адрес, должны быть программно и визуально сгруппированы. Одним из методов является использование паттерна fieldset/legend для группировки похожих элементов.

Описания

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

Однако есть ситуации, в которых добавление дополнительной информации полезно для избежания ошибок формы, например, передача информации о минимальной длине ввода для поля пароля или указание пользователю, какой формат календаря использовать (например, ДД-ММ-ГГГГ).

Существует множество различных методов, которые вы можете использовать для добавления описаний полей к вашим формам. Одним из лучших методов является добавление атрибута aria-describedby к элементу формы, в дополнение к элементу <label>. Программа чтения с экрана прочитает как описание, так и метку.

Если вы добавите атрибут aria-labelledby к вашему элементу, значение атрибута переопределит текст внутри вашего <label>. Как всегда, обязательно протестируйте финальный код со всеми AT, которые вы планируете поддерживать.

Ошибки

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

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

Существуют различные методы для отображения сообщений об ошибках, такие как:

  • Всплывающее модальное окно, встроенное рядом с местом, где произошла ошибка
  • Коллекция ошибок, сгруппированная в одном большом сообщении в верхней части страницы

Обязательно обратите внимание на фокус клавиатуры и опции ARIA live region при объявлении ошибок.

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

  • Вы можете использовать HTML-атрибут required. Браузер предоставит общее сообщение об ошибке на основе параметров проверки поля.
  • Или вы можете использовать атрибут aria-required для передачи настроенного сообщения об ошибке в AT. Только AT получат сообщение, если вы не добавите дополнительный код, чтобы сделать сообщение видимым для всех пользователей.

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

Хотя WCAG 2.2 все еще находится в разработке, существует несколько предлагаемых критериев успеха, которые будут сосредоточены на более доступном опыте форм, таких как Минимальный размер цели, Последовательная помощь, Доступная аутентификация и Избыточный ввод, о которых следует знать для будущих проектов.

Источник — https://web.dev/learn/accessibility/forms

Комментарии