Forms

Un formulaire est un élément qui permet à un utilisateur de fournir des données dans un champ ou un groupe de champs. Les formulaires peuvent être aussi simples qu'un seul champ ou aussi complexes qu'un élément de formulaire en plusieurs étapes avec plusieurs champs par page, la validation des entrées et parfois un captcha.

Les formulaires sont considérés comme l'un des éléments les plus difficiles à exploiter du point de vue de l'accessibilité, car ils nécessitent de connaître tous les éléments que nous avons déjà abordés, ainsi que des règles supplémentaires spécifiques aux formulaires. Avec un certain temps et une certaine compréhension, vous pouvez créer un formulaire accessible pour vous et vos utilisateurs.

Forms est le dernier module de ce cours consacré aux composants. Ce module se concentre sur les consignes propres aux formulaires, mais toutes les autres consignes que vous avez étudiées dans les modules précédents, telles que la structure du contenu, le ciblage au clavier et le contraste des couleurs, s'appliquent également aux éléments du formulaire.

Champs

Les champs constituent l'épine dorsale des formulaires. Les champs sont de petits modèles interactifs, tels qu'une entrée ou une case d'option, qui permettent aux utilisateurs de saisir du contenu ou de faire un choix. Vous pouvez faire votre choix parmi une grande variété de champs de formulaire.

Par défaut, nous vous recommandons d'utiliser des modèles HTML établis au lieu de créer un élément personnalisé avec ARIA, car certaines fonctionnalités (états, propriétés et valeurs des champs, par exemple) sont intrinsèquement intégrées aux éléments HTML, alors que vous devez ajouter manuellement des éléments ARIA personnalisés.

ARIA

<div role="form" id="sundae-order-form">
  <!-- form content -->
</div>

HTML

<form id="sundae-order-form">
  <!-- form content -->
</form>

En plus de choisir les modèles de champ de formulaire les plus accessibles, le cas échéant, vous devez également ajouter des attributs de saisie semi-automatique HTML à vos champs. L'ajout d'attributs de saisie semi-automatique permet d'identifier ou d'identifier l'objectif plus précisément pour les user-agents et les technologies d'assistance (TA).

Les attributs de saisie semi-automatique permettent aux utilisateurs de personnaliser des présentations visuelles, par exemple en affichant une icône de gâteau d'anniversaire dans un champ auquel l'attribut de saisie semi-automatique d'anniversaire (bday) est attribué. Plus généralement, les attributs de saisie semi-automatique permettent de remplir les formulaires plus facilement et plus rapidement. Cette fonctionnalité est particulièrement utile pour les personnes souffrant de troubles cognitifs et de la lecture, ainsi que pour les personnes utilisant des TA, comme les lecteurs d'écran.

<form id="sundae-order-form">
  <p>Name: <input type="name" autocomplete="name"></p>
  <p>Telephone: <input type="tel" autocomplete="tel"></p>
  <p>Email address: <input type="email" autocomplete="email"></p>
</form>

Enfin, les champs de formulaire ne doivent pas générer de modifications contextuelles lorsqu'ils reçoivent un curseur ou une entrée utilisateur, sauf si l'utilisateur a été averti de ce comportement avant d'utiliser le composant. Par exemple, un formulaire ne doit pas être envoyé automatiquement lorsqu'un champ est sélectionné ou qu'un utilisateur y ajoute du contenu.

Étiquettes

Les étiquettes informent l'utilisateur de la finalité d'un champ, le cas échéant, et peuvent également fournir des informations sur les exigences applicables aux champs, telles que le format de saisie. Les libellés doivent être visibles en permanence et décrire précisément le champ du formulaire aux utilisateurs.

L'un des principes fondamentaux des formulaires accessibles consiste à établir un lien clair et précis entre un champ et son étiquette. Cela est vrai à la fois visuellement et programmatiquement. Sans ce contexte, un utilisateur pourrait ne pas comprendre comment remplir les champs du formulaire.

<form id="sundae-order-form">
  <p><label>Name (required): <input type="name" autocomplete="name" required></label></p>
  <p><label>Telephone (required): <input type="tel" autocomplete="tel" required></label></p>
  <p><label>Email address: <input type="email" autocomplete="email"></label></p>
</form>

En outre, les champs de formulaire associés, tels qu'une adresse postale, doivent être regroupés de façon programmatique et visuelle. Une méthode consiste à utiliser le modèle de jeu de champs/légend pour regrouper les éléments similaires.

Descriptions

Les descriptions de champ sont similaires aux libellés dans la mesure où elles permettent de fournir plus de contexte sur le champ et les exigences. Les descriptions de champs ne sont pas nécessaires pour des raisons d'accessibilité si les étiquettes ou les instructions du formulaire sont suffisamment descriptives.

Toutefois, dans certains cas, il est utile d'ajouter des informations supplémentaires pour éviter les erreurs de formulaire, par exemple pour transmettre des informations sur la longueur minimale de saisie d'un champ de mot de passe ou indiquer à un utilisateur le format d'agenda à utiliser (par exemple, MM-JJ-AAAA).

Il existe de nombreuses méthodes différentes pour ajouter des descriptions de champs à vos formulaires. L'une des meilleures méthodes consiste à ajouter un attribut aria-describedby à l'élément du formulaire, en plus d'un élément <label>. Le lecteur d'écran lira à la fois la description et le libellé.

Si vous ajoutez l'attribut aria-labelledby à votre élément, la valeur de l'attribut remplace le texte dans votre <label>. Comme toujours, veillez à tester le code final avec toutes les TA que vous prévoyez de prendre en charge.

Erreurs

Lorsque vous créez des formulaires accessibles, vous pouvez prendre de nombreuses mesures pour empêcher les utilisateurs de créer des erreurs. Précédemment dans ce module, nous avons vu clairement le balisage des champs, la création de libellés d'identification et l'ajout de descriptions détaillées chaque fois que possible. Toutefois, même si vous pensez que votre formulaire est clair, un utilisateur finira par commettre une erreur.

Lorsqu'un utilisateur rencontre une erreur de formulaire, la première étape consiste à la faire connaître. Le champ où l'erreur s'est produite doit être clairement identifié et l'erreur elle-même doit être décrite à l'utilisateur sous forme de texte.

Il existe différentes méthodes pour afficher les messages d'erreur, telles que:

  • Fenêtre modale pop-up intégrée à proximité de l'endroit où l'erreur s'est produite
  • Ensemble d'erreurs regroupées dans un message plus complet en haut de la page

Faites attention au ciblage au clavier et aux options de région en direct ARIA lorsque vous annoncez des erreurs.

Dans la mesure du possible, proposez à l'utilisateur une suggestion détaillée sur la manière de corriger l'erreur. Deux attributs permettent de signaler les erreurs aux utilisateurs.

  • Vous pouvez utiliser l'attribut HTML obligatoire. Le navigateur affiche un message d'erreur générique en fonction des paramètres de validation renseignés.
  • Vous pouvez également utiliser l'attribut aria-required pour transmettre un message d'erreur personnalisé aux TA. Seules les TA recevront le message, sauf si vous ajoutez du code supplémentaire pour rendre le message visible par tous les utilisateurs.

Lorsqu'un utilisateur pense que toutes les erreurs ont été résolues, autorisez-le à renvoyer le formulaire et à fournir des commentaires sur les résultats de son envoi. Un message d'erreur indique à l'utilisateur qu'il a d'autres mises à jour à effectuer, tandis qu'un message de réussite confirme qu'il a résolu toutes les erreurs et envoyé le formulaire avec succès.

Testez vos connaissances

Testez vos connaissances sur les formulaires accessibles

Laquelle des réponses ci-dessous est le formulaire de saisie le plus accessible ?

Email address: <input type="email" required>
Aucune étiquette n'associe "Adresse e-mail" à l'entrée.
<label>Email address: <input type="email" required></label>
Il manque l'attribut de saisie semi-automatique, qui permet de définir ou d'identifier la finalité aux user-agents et aux technologies d'assistance (TA).
<label>Email address: <input type="email" required autocomplete="email"></label>
Il s'agit d'un libellé de champ accessible, mais il n'est pas le plus accessible sur cette liste.
<label>Email address (required): <input type="email" required aria-describedby="email-validation"> <span id="email-validation" class="validation-message">Please provide a valid email address using the format name@place.com</span></label>
L'attribut aria-describedby ajoute du contexte à une erreur que l'utilisateur peut recevoir si le champ est mal renseigné. Bien que cet attribut ne soit pas obligatoire, il peut être utile pour les utilisateurs de TA.