Le formulaire que vous créez est destiné aux personnes. Les gens utilisent différents appareils. Certains utilisent une souris, d'autres un appareil tactile, d'autres un clavier, d'autres encore un appareil contrôlé par des mouvements oculaires. Certains utilisent un lecteur d'écran, d'autres un petit écran, d'autres utilisent un logiciel d'agrandissement du texte. Tout le monde veut utiliser votre formulaire. Découvrez comment rendre votre formulaire accessible et utilisable par tous.
S'assurer que les utilisateurs comprennent l'objectif d'un champ de formulaire
Vous pouvez faire votre choix parmi de nombreuses commandes de formulaire.
Qu'ont-ils tous en commun ?
Chaque commande de formulaire doit être associée à un élément <label>.
L'élément <label> décrit la fonction d'une commande de formulaire.
Le texte <label> est associé visuellement à la commande de formulaire et lu par les lecteurs d'écran.
En outre, en appuyant ou en cliquant sur le <label>, vous activez la commande de formulaire associée, ce qui en fait une cible plus grande.
Utilisez un code HTML pertinent pour accéder aux fonctionnalités intégrées du navigateur.
En théorie, vous pouvez créer un formulaire en utilisant uniquement des éléments <div>.
Vous pouvez même donner l'impression qu'il s'agit d'une <form> native.
Quel est le problème lié à l'utilisation d'éléments non sémantiques ?
Les éléments de formulaire intégrés offrent de nombreuses fonctionnalités intégrées. Examinons un exemple.
Visuellement, <input> (le premier de l'exemple) et <div> se ressemblent.
Vous pouvez même insérer du texte pour les deux, car <div> possède un attribut contenteditable.
Cependant, il existe de nombreuses différences entre l'utilisation d'un élément <input> approprié et l'utilisation d'un <div> ressemblant à un <input>.
Un utilisateur de lecteur d'écran ne reconnaît pas <div> en tant qu'élément d'entrée et ne peut pas remplir le formulaire.
Tout ce que l'utilisateur entend par lecteur d'écran est "Nom", sans aucune indication qu'il s'agit d'une commande de formulaire permettant d'ajouter du texte.
Cliquer sur <div>Name</div> ne sélectionne pas le <div> associé, tandis que <label> et <input> sont connectés à l'aide des attributs for et id.
Une fois le formulaire envoyé, les données saisies dans le champ <div> ne seront plus incluses dans la demande.
Bien qu'il soit possible d'associer les données avec JavaScript, <input> le fait par défaut.
Les éléments de formulaire intégrés ont d'autres caractéristiques.
Par exemple, avec les éléments de formulaire appropriés et les bonnes inputmode ou type, un clavier à l'écran affiche les caractères appropriés. Cela n'est pas possible avec l'attribut inputmode sur une <div>.
S'assurer que les utilisateurs connaissent le format de données attendu
Vous pouvez définir différentes règles de validation pour une commande de formulaire.
Par exemple, supposons qu'un champ de formulaire doive toujours comporter au moins huit caractères.
Vous utilisez l'attribut minlength, qui indique la règle de validation aux navigateurs.
Comment pouvez-vous vous assurer que les utilisateurs sont également informés de la règle de validation ? Dites-le.
Ajoutez des informations sur le format attendu directement sous la commande de formulaire.
Pour clarifier les choses pour les appareils d'assistance, utilisez l'attribut aria-describedby sur la commande de formulaire et un id sur le message d'erreur avec la même valeur, afin de connecter les deux.
Aider les utilisateurs à trouver le message d'erreur concernant une commande de formulaire
Dans un module précédent sur la validation, vous avez appris à afficher des messages d'erreur en cas de saisie de données non valides.
<label for="name">Name</label>
<input type="text" name="name" id="name" required>
Par exemple, si un champ comporte un attribut required et que des données non valides sont saisies, le navigateur affiche un message d'erreur à côté de la commande de formulaire lors de l'envoi du formulaire. Les lecteurs d'écran annoncent également le message d'erreur.
Vous pouvez également définir votre propre message d'erreur:
D'autres modifications sont nécessaires dans cet exemple pour associer le message d'erreur à la commande de formulaire.
Une approche simple consiste à utiliser l'attribut aria-describedby sur la commande de formulaire qui correspond à id sur l'élément de message d'erreur.
Utilisez ensuite aria-live="assertive" pour le message d'erreur.
Les régions actives ARIA annoncent une erreur aux utilisateurs de lecteurs d'écran au moment où elle s'affiche.
Le problème avec cette approche pour les formulaires comportant plusieurs champs est que aria-live n'annonce généralement que la première erreur en cas d'erreurs multiples.
Comme expliqué dans cet article sur plusieurs annonces aria-live pour la même action, vous pouvez créer un seul message en concaténant toutes les erreurs. Une autre approche consiste à annoncer qu'il y a des erreurs, puis à annoncer des erreurs individuelles lorsque le champ est sélectionné.
Vérifier que les utilisateurs reconnaissent les erreurs
Parfois, les concepteurs colorent l'état non valide en rouge à l'aide de la pseudo-classe :invalid.
Cependant, pour communiquer une erreur ou une réussite,
vous ne devez jamais compter uniquement sur la couleur.
Pour les personnes daltoniennes rouge-vert, une bordure verte et rouge sont presque identiques.
Il est impossible de savoir si le message est lié à une erreur.
En plus de la couleur, utilisez une icône ou ajoutez le type d'erreur en préfixe à vos messages d'erreur.
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
Aider les utilisateurs à naviguer dans votre formulaire
Vous pouvez modifier l'ordre visuel des commandes de formulaire avec CSS. Une déconnexion entre l'ordre visuel et la navigation au clavier (DOM) est problématique pour les utilisateurs de lecteurs d'écran et de claviers.
Découvrez comment vous assurer que l'ordre visuel sur la page suit l'ordre DOM
Aider les utilisateurs à identifier la commande de formulaire actuellement sélectionnée
Utilisez votre clavier pour parcourir ce formulaire.
Saviez-vous que le style des commandes du formulaire a changé une fois qu'elles étaient actives ?
Il s'agit du style de focus par défaut.
Vous pouvez la remplacer par la pseudo-classe CSS :focus.
Quels que soient les styles que vous utilisez dans :focus, assurez-vous toujours que la différence visuelle entre l'état par défaut et l'état de sélection est reconnaissable.
Découvrez comment concevoir des indicateurs d'objectif.
Vérifier que votre formulaire est utilisable
Vous pouvez identifier de nombreux problèmes courants en remplissant le formulaire avec différents appareils. N'utilisez que le clavier, un lecteur d'écran (tel que NVDA sous Windows ou VoiceOver sur Mac) ou effectuez un zoom sur la page à 200%. Testez toujours vos formulaires sur différentes plates-formes, en particulier sur des appareils ou des paramètres que vous n'utilisez pas tous les jours. Connaissez-vous quelqu’un qui utilise un lecteur d’écran, ou quelqu’un qui utilise un logiciel d’agrandissement du texte ? Demandez-lui de remplir votre formulaire. Les examens de l'accessibilité sont excellents, les tests effectués auprès d'utilisateurs réels sont encore mieux.
Découvrez comment effectuer un examen de l'accessibilité et comment effectuer des tests auprès d'utilisateurs réels.