Le formulaire que vous créez est destiné aux personnes. Les utilisateurs utilisent différents appareils. Certains utilisent une souris, d'autres un appareil tactile, d'autres le clavier, d'autres un appareil contrôlé par des mouvements oculaires. Certains utilisent un lecteur d'écran, d'autres un petit écran, d'autres un logiciel d'agrandissement du texte. Tout le monde souhaite 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 l'objectif d'une commande de formulaire.
Le texte <label> est associé visuellement à la commande de formulaire et lu à voix haute par les lecteurs d'écran.
En outre, si vous appuyez ou cliquez sur <label>, la commande de formulaire associée
ce qui en fait une cible plus large.
Utiliser du code HTML significatif 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 le faire ressembler à un <form> natif.
Quel est le problème
lorsque vous utilisez
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 dans l'exemple) et <div> se ressemblent.
Vous pouvez même insérer du texte pour les deux, car <div> a une
contenteditable.
Il existe toutefois de nombreuses différences entre l'utilisation d'un élément <input> approprié et d'un élément <div>.
qui ressemble à une <input>.
Un utilisateur de lecteur d'écran ne reconnaît pas <div> comme un élément d'entrée.
et ne peut pas
remplir le formulaire.
Tout ce que l'utilisateur du lecteur
d'écran entend est "Nom",
sans indiquer qu'il s'agit d'une commande de formulaire permettant d'ajouter du texte.
Cliquer sur <div>Name</div> ne sélectionne pas l'élément <div> correspondant, alors que les éléments <label> et
les <input> sont connectées à l'aide des attributs for et id.
Une fois le formulaire envoyé, les données saisies dans le <div> ne sont pas incluses dans la demande.
Bien qu'il soit possible d'associer
les données avec JavaScript,
une <input> le fait par défaut.
Les éléments de formulaire intégrés ont d'autres fonctionnalités.
Par exemple, avec les éléments de formulaire appropriés et le bon inputmode ou type,
un clavier à l'écran affiche les caractères appropriés. Utiliser l'attribut inputmode sur une <div>
ne peut pas le faire.
S'assurer que les utilisateurs connaissent le format de données attendu
Vous pouvez définir différentes règles de validation pour un contrôle de formulaire.
Par exemple, supposons qu'un champ de formulaire doit toujours comporter au moins huit caractères.
Vous devez utiliser l'attribut minlength, qui indique la règle de validation aux navigateurs.
Comment vous assurer que les utilisateurs connaissent également la règle de validation ? Dites-le-leur.
Ajoutez des informations sur le format attendu directement sous la commande de formulaire.
Pour préciser pour les
appareils d'assistance,
utiliser l'attribut aria-describedby sur la commande de formulaire ;
et un id sur le message d'erreur avec la même valeur, pour connecter les deux.
Aider les utilisateurs à identifier le message d'erreur d'un contrôle de formulaire
Dans un précédent module sur la validation, vous avez appris à afficher des messages d'erreur en cas de saisie de données non valide.
<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 s'affiche à côté du contrôle du 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:
Cet exemple nécessite d'autres modifications pour associer le message d'erreur à la commande de formulaire.
Une approche simple consiste à utiliser aria-describedby
de la commande de formulaire qui correspond au id de l'élément du message d'erreur.
Ensuite, utilisez aria-live="assertive" pour le message d'erreur.
Les régions actives ARIA annoncent une erreur aux utilisateurs de lecteurs d'écran dès qu'elle s'affiche.
Le problème avec cette approche
pour les formulaires à plusieurs champs,
est que aria-live n'annonce généralement la première erreur qu'en cas d'erreurs multiples.
Comme expliqué dans cet article concernant plusieurs annonces aria-live sur la même action, vous pouvez créer un seul message en concaténant toutes les erreurs. Une autre approche consisterait à annoncer qu'il y a des erreurs, puis à annoncer les erreurs individuelles lorsque le champ est sélectionné.
S'assurer 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 un succès,
vous ne devez jamais vous
fier uniquement à la couleur.
Pour les personnes atteintes
de daltonisme rouge-vert,
une bordure verte et une bordure rouge
ressemblent presque à la même chose.
Il est impossible de savoir si le message est associé à 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 à parcourir 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 (ordre DOM) est problématique pour les utilisateurs de lecteurs d'écran et de claviers.
Découvrez comment vous assurer l'ordre visuel sur la page suit l'ordre DOM.
Aider les utilisateurs à identifier la commande de formulaire actuellement sélectionnée
Naviguez dans votre clavier à l'aide de votre clavier
ce formulaire.
Avez-vous remarqué que le style des commandes de formulaire a changé après qu'elles étaient actives ?
Il s'agit du style de focus par défaut.
Vous pouvez le remplacer par le paramètre
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.
En savoir plus sur concevoir des indicateurs de focalisation.
Vérifier que votre formulaire est utilisable
Vous pouvez identifier de nombreux problèmes courants en remplissant le formulaire sur différents appareils. Utilisez uniquement votre clavier, un lecteur d'écran (comme NVDA sous Windows ou VoiceOver sur Mac), ou faites un zoom de 200 % sur la page. Testez toujours vos formulaires sur différentes plateformes, en particulier les appareils ou les 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 de texte ? Demandez-lui de remplir votre formulaire. Les examens de l'accessibilité sont excellents, les tests avec de vrais utilisateurs sont encore plus efficaces.
En savoir plus sur la réalisation d'une examen accessibilité et comment effectuer des tests auprès d'utilisateurs réels.