Formulaires

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, une validation des entrées et parfois un CAPTCHA.

Les formulaires sont considérés comme l'un des éléments les plus difficiles à mettre en place d'un point de vue d'accessibilité, car ils nécessitent la connaissance de tous les éléments que nous avons déjà abordés, ainsi que des règles supplémentaires propres aux formulaires. Avec un peu de compréhension et de temps, vous pouvez créer un formulaire accessible qui vous convient, ainsi qu'à vos utilisateurs.

Les formulaires sont le dernier module spécifique aux composants de ce cours. Ce module se concentrera sur les consignes spécifiques aux formulaires, mais toutes les autres consignes que vous avez apprises dans les modules précédents, telles que la structure du contenu, la mise au point du clavier et le contraste des couleurs, s'appliquent également aux éléments de formulaire.

Champs

Les champs constituent l'ossature des formulaires. Les champs sont de petits modèles interactifs, tels qu'un élément de saisie ou un bouton radio, qui permettent aux utilisateurs de saisir du contenu ou de faire un choix. Vous pouvez choisir parmi une grande variété de champs de formulaire.

La recommandation par défaut est d'utiliser des modèles HTML établis plutôt que de créer quelque chose de personnalisé avec ARIA, car certaines fonctionnalités et fonctions, telles que les états, les propriétés et les valeurs des champs, sont intrinsèquement intégrées aux éléments HTML. Pour les champs personnalisés, vous devez ajouter manuellement l'ARIA.

Non recommandé : code HTML personnalisé avec ARIA

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

Recommandé : HTML standard

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

En plus de choisir les modèles de champs 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 une définition ou une identification plus précise de l'objectif pour les agents utilisateur et les technologies d'assistance.

Les attributs de saisie semi-automatique permettent aux utilisateurs de personnaliser les 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 facilitent et accélèrent le remplissage des formulaires. Cette fonctionnalité est particulièrement utile pour les personnes souffrant de troubles cognitifs et de lecture, ainsi que pour celles qui utilisent des technologies d'assistance, telles que 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 produire de modifications contextuelles lorsqu'ils reçoivent la sélection ou l'entrée de l'utilisateur, sauf si l'utilisateur a été averti du 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 ajoute du contenu à ce champ.

Étiquettes

Les libellés indiquent à l'utilisateur l'objectif d'un champ, s'il est obligatoire, et peuvent également fournir des informations sur les exigences du champ, comme le format d'entrée. 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 une connexion claire et précise entre un champ et son libellé. Cela est vrai à la fois visuellement et de manière programmatique. Sans ce contexte, un utilisateur peut 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 manière programmatique et visuelle. Une méthode consiste à utiliser le modèle de fieldset et de légende pour regrouper les éléments similaires.

Descriptions

Les descriptions de champ sont similaires aux libellés dans le sens où elles servent à donner plus de contexte au champ et aux exigences. Les descriptions des champs ne sont pas obligatoires pour l'accessibilité si les libellés ou les instructions du formulaire sont suffisamment descriptifs.

Toutefois, il existe des situations où ajouter des informations supplémentaires est utile pour éviter les erreurs de formulaire, par exemple pour indiquer la longueur minimale de saisie pour un champ de mot de passe ou pour indiquer à un utilisateur le format de calendrier à utiliser (par exemple, JJ/MM/AAAA).

Il existe de nombreuses méthodes différentes pour ajouter des descriptions de champ à vos formulaires. L'une des meilleures méthodes consiste à ajouter un attribut aria-describedby à l'élément de formulaire, en plus d'un élément <label>. Le lecteur d'écran lit à 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 AT que vous prévoyez de prendre en charge.

Erreurs

Lorsque vous créez des formulaires accessibles, vous pouvez faire beaucoup de choses pour éviter aux utilisateurs de commettre des erreurs. Plus tôt dans ce module, nous avons vu comment marquer clairement les champs, créer des libellés d'identification et ajouter des descriptions détaillées dans la mesure du possible. Mais aussi clair que vous pensez que votre formulaire est, un utilisateur finira par faire une erreur.

Lorsqu'un utilisateur rencontre une erreur de formulaire, la première étape consiste à l'indiquer. Le champ dans lequel 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 des messages d'erreur, par exemple:

  • Une fenêtre modale intégrée à proximité de l'emplacement où l'erreur s'est produite
  • Ensemble d'erreurs regroupées dans un message plus long en haut de la page

Veillez à prêter attention au focus du 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 pour résoudre l'erreur. Deux attributs sont disponibles pour avertir les utilisateurs des erreurs.

  • Vous pouvez utiliser l'attribut HTML required (obligatoire). Le navigateur fournit un message d'erreur générique en fonction des paramètres de validation du champ.
  • Vous pouvez également utiliser l'attribut aria-required pour partager un message d'erreur personnalisé avec les AT. Seuls les AT recevront le message, sauf si vous ajoutez du code supplémentaire pour le rendre visible par tous les utilisateurs.

Une fois qu'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 doit apporter d'autres modifications, tandis qu'un message de réussite confirme qu'il a résolu toutes les erreurs et envoyé le formulaire.

Critères de réussite supplémentaires

La norme WCAG 2.2 a introduit les critères de réussite suivants, qui se concentrent sur des expériences de formulaire plus accessibles:

Vérifier vos connaissances

Tester vos connaissances sur les formulaires accessibles

Parmi les éléments suivants, lequel est le plus accessible ?

Email address: <input type="email" required>
Aucun libellé n'associe "Adresse e-mail" à la saisie.
<label>Email address: <input type="email" required></label>
L'attribut "autocomplete" est manquant. Il offre une définition ou une identification de l'objectif aux agents utilisateur et aux technologies d'assistance (AT).
<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 de 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 supplémentaire à une erreur que l'utilisateur peut recevoir si le champ n'est pas correctement rempli. Bien que cet attribut ne soit pas obligatoire, il peut être utile pour les utilisateurs d'AT.