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 saisies et parfois un CAPTCHA.
Les formulaires sont considérés comme l'un des éléments les plus difficiles à maîtriser 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 peu de temps et de connaissances, vous pouvez créer un formulaire accessible qui vous convient, à vous et à vos utilisateurs.
Forms est le dernier module spécifique à un composant de ce cours. Ce module se concentre 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 sélection au clavier et le contraste des couleurs, s'appliquent également aux éléments de formulaire.
Champs
Les champs sont l'épine dorsale des formulaires. Les champs sont de petits modèles interactifs, tels qu'un élément de saisie ou une case d'option, 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 consiste à utiliser des modèles HTML établis au lieu 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. Les champs personnalisés nécessitent que vous ajoutiez manuellement l'ARIA.
Déconseillé : 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, vous devez également ajouter des attributs HTML de saisie semi-automatique à vos champs, le cas échéant. L'ajout d'attributs de saisie semi-automatique permet une définition ou une identification de l'objectif plus précise pour les agents utilisateurs 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 est attribué l'attribut de saisie semi-automatique d'anniversaire (bday). 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 la lecture, ainsi que pour celles qui utilisent des technologies d'assistance, 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 produire de changements contextuels lorsqu'ils reçoivent le focus ou une entrée utilisateur, à moins que l'utilisateur n'ait é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 lorsqu'un utilisateur y ajoute du contenu.
Étiquettes
Les libellés informent l'utilisateur sur l'objectif d'un champ et sur le fait qu'il est obligatoire. Ils 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 un lien clair et précis entre un champ et son libellé. C'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>
De plus, 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 fieldset et legend pour regrouper les éléments similaires.
Descriptions
Les descriptions de champs ont un objectif similaire à celui des libellés, car elles sont utilisées pour fournir plus de contexte sur le champ et les exigences. Les descriptions de champ ne sont pas requises pour l'accessibilité si les libellés ou les instructions du formulaire sont suffisamment descriptifs.
Toutefois, dans certaines situations, il est utile d'ajouter des informations supplémentaires pour éviter les erreurs de formulaire. Par exemple, vous pouvez indiquer la longueur minimale d'un mot de passe ou le format de calendrier à utiliser (JJ-MM-AAAA, par exemple).
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 de formulaire, en plus d'un élément <label>. Le lecteur d'écran lira la description et le libellé.
Si vous ajoutez l'attribut aria-labelledby à votre élément, la valeur de l'attribut remplace le texte de votre <label>. Comme toujours, veillez à tester le code final avec toutes les technologies d'assistance que vous prévoyez de prendre en charge.
Erreurs
Lorsque vous créez des formulaires accessibles, vous pouvez faire beaucoup de choses pour éviter que les utilisateurs ne fassent des erreurs. Plus tôt dans ce module, nous avons vu comment baliser clairement les champs, créer des libellés d'identification et ajouter des descriptions détaillées chaque fois que possible. Mais même si vous pensez que votre formulaire est clair, un utilisateur finira par faire une erreur.
Lorsqu'un utilisateur rencontre une erreur de formulaire, la première étape consiste à l'identifier. 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 les messages d'erreur, par exemple :
- Une fenêtre modale intégrée à l'endroit 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 aux options de sélection au clavier et de région live ARIA lorsque vous annoncez des erreurs.
Dans la mesure du possible, proposez à l'utilisateur une suggestion détaillée sur la façon de corriger l'erreur. Deux attributs sont disponibles pour informer les utilisateurs des erreurs.
- Vous pouvez utiliser l'attribut HTML required. Le navigateur fournira un message d'erreur générique basé sur les paramètres de validation des champs.
- Vous pouvez également utiliser l'attribut aria-required pour partager un message d'erreur personnalisé avec les technologies d'assistance. Seuls les technologies d'assistance recevront le message, sauf si vous ajoutez du code pour le rendre visible par tous les utilisateurs.
Une fois qu'un utilisateur pense avoir résolu toutes les erreurs, autorisez-le à renvoyer le formulaire et fournissez-lui des commentaires sur les résultats de son envoi. Un message d'erreur indique à l'utilisateur qu'il doit effectuer 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
WCAG 2.2 a introduit les critères de réussite suivants, qui se concentrent sur des formulaires plus accessibles :