Création de formulaires accessibles

Creating Accessible Forms

Les formulaires en ligne sont le fondement de la communication à l'ère moderne. Sans formulaires, tout ce que nous aurions serait des sites Web de texte statique avec des photos de chats à regarder. Bien sûr, cela ne semble pas trop mal, mais sans formulaires, comment pourrions-nous discuter et partager des photos de chats avec tous nos amis et notre famille ? Que diriez-vous de faire des achats en ligne, de réserver un vol, de commander une pizza tard le soir ou de fixer un rendez-vous sur ce site de rencontres ?

C'est pourquoi une structure et une conception de formulaire bien écrites sont essentielles au succès de tout site Web ou application. Jetons un coup d'œil à quelques domaines sur la façon dont nous pouvons augmenter l'accessibilité en matière de conception de formulaires.

Étiquettes

Des étiquettes de formulaire très visibles, claires et précises sont essentielles au succès de toute personne capable de remplir un formulaire. Sans étiquette, personne ne saurait à quoi servirait chaque champ de formulaire !

Examinons quelques considérations de conception lors de l'ajout d'étiquettes à nos formulaires.

Espaces réservés

Les champs de formulaire HTML comportent un attribut appelé placeholder . La valeur de l'attribut place le texte dans le champ et, lorsque quelqu'un commence à taper, le texte de l'espace réservé est automatiquement supprimé.

L'objectif initial de cet attribut est de placer un texte d'aide ou d'astuce dans l' input . Cependant, des espaces réservés sont parfois utilisés à la place d'un véritable élément d' label HTML. Ceci est problématique pour plusieurs raisons :

  • Sans élément d' label associé à l' input , certains lecteurs d'écran peuvent ne pas être en mesure de transmettre l'objectif de l' input .
  • Lorsque quelqu'un commence à taper et que le texte de l' placeholder est supprimé de la vue, le contexte de l' input peut être perdu, obligeant quelqu'un à supprimer le texte saisi afin de se rappeler à quoi servait l' input .
  • Afin de répondre aux exigences de contraste des couleurs, le texte gris par défaut doit être assombri. Ce faisant, cela peut confondre certaines personnes en leur faisant croire que le texte a déjà été saisi dans le input .

Il y a plus de problèmes avec l'attribut d' placeholder , mais avec ces quelques éléments à l'esprit, il est clair que l' placeholder ne doit pas être utilisé en remplacement d'un véritable label .

Étiquettes flottantes

La technique de "l'étiquette flottante" semble gagner en popularité ces derniers temps. Selon la façon dont il est implémenté, l'idée de base est d'utiliser CSS pour positionner le texte de l' label (ou parfois l' placeholder ) au-dessus de l'élément input associé. Lorsque quelqu'un commence à taper, le texte de l' label est "flotté" et placé au-dessus de l'entrée.

L'avantage de cette approche est qu'elle économise de l'espace entre les entrées lorsque l'espace de l'écran est restreint. L'association d'un élément label à son élément input présente également l'avantage évident que les lecteurs d'écran transmettent l'objectif de l' input .

L'inconvénient de cette approche est le résultat direct de sa raison d'être; lorsque l' label flotte au-dessus de l' input , l'espace disponible ne permet généralement qu'une taille de texte inférieure à la taille idéale. Cela pourrait entraîner des difficultés à lire le texte de l'étiquette pour toute personne malvoyante . Bien sûr, ils pourraient simplement zoomer sur l'écran, mais pourquoi créer plus de travail pour nos utilisateurs ?

Ensuite, l'autre préoccupation concerne la mise en œuvre proprement dite. Si la technique finit par utiliser l'attribut d' placeholder au lieu d'une véritable label , cela entraînerait des problèmes évoqués précédemment, principalement l'absence d'objectif véhiculé lors de l'interaction avec un lecteur d'écran.

Étiquettes toujours visibles

La conception idéale des étiquettes de formulaire en matière d'accessibilité est l'étiquette "toujours visible". Tout comme il semble, cette technique comporte une étiquette de texte qui est toujours présente tout au long de l'expérience de remplissage du formulaire.

Les avantages de cette approche sont assez clairs :

  • L'étiquette de texte est dans une position cohérente et prévisible
  • L' label est toujours visible, ne nécessitant aucune charge cognitive d'avoir à se souvenir du but de l'entrée
  • Les lecteurs d'écran transmettront le but de l' input lorsqu'ils interagissent avec le texte de l'étiquette est grand avec suffisamment d'espace blanc pour être lisible

Avec tout cela à l'esprit, il est fortement recommandé de garder les étiquettes visibles. Éliminez toute conjecture requise de la part de vos utilisateurs et permettez-leur d'accomplir la tâche à accomplir avec facilité et confiance.

Étiquettes masquées visuellement

Un autre type d'étiquette dont nous devons discuter est l'étiquette "visuellement masquée". Ceux-ci apparaissent souvent dans de minuscules entrées de formulaire uniques telles que les composants de sélection de recherche ou de langue où l'espace est limité.

Comme nous le savons, les éléments input de formulaire doivent toujours inclure une label afin de partager son objectif avec l'utilisateur. Que faire lorsqu'un dessin nécessite une label non visible ? Voyons comment appliquer une étiquette masquée visuellement de deux manières différentes, chaque méthode conduisant au même résultat au final.

Remarque : les utilisateurs de dictée vocale peuvent avoir des difficultés à trouver la bonne incitation à l'action lorsqu'ils accèdent à chaque commande avec une étiquette masquée visuellement. Procéder avec prudence.

La classe .visuallyhidden

L'application de la définition de classe .visuallyhidden (également parfois appelée .sr-only ) directement à l'élément label supprimera l'étiquette pour les utilisateurs voyants, mais restera disponible pour les utilisateurs de lecteurs d'écran.

 <label for="lang-selector" class="visuallyhidden">Select a language</label> <select id="lang-selector"> <!-- ... --> </select>

L'approche aria-label

Une autre option consiste à appliquer l'attribut aria-label directement sur l'élément d' input afin de fournir une étiquette "cachée".

 <select aria-label="Select a language"> <!-- ... --> </select>

Tout comme l'approche .visuallyhidden , cela fournira une label pour l' input et, lors de la mise au point de l' input , la valeur aria-label sera annoncée par les lecteurs d'écran.

Champs obligatoires

Lorsque seuls des champs spécifiques sont obligatoires ou facultatifs pour remplir un formulaire, il est préférable d'indiquer cette exigence avec des signaux visuels et sonores. Cela aide les gens à savoir quels champs ils doivent absolument remplir, ce qui, à son tour, les rassure lorsqu'ils remplissent le formulaire.

Repère visuel

Lors du marquage comme Requis , cela se fait généralement avec un astérisque ou une icône placée à côté de l' label du formulaire . Que vous utilisiez l'astérisque ou une autre forme d'icône, ce qui est important ici est :

  • Le placement de l'icône est cohérent dans tout le formulaire

  • L'icône présente un rapport de contraste suffisamment élevé pour être visible ( 3.0:1 pour les éléments non textuels)

 <label for="email"> Email <svg class="required-icon" role="presentation" aria-hidden="true" focusable="false" … > <!-- … --> </svg> </label>

Lorsque vous marquez un champ comme Facultatif , il suffit de placer ce contexte sous forme de texte brut dans l' label .

 <label for="email">Email (Optional)</label>

Signal sonore

Afin d'informer un utilisateur de lecteur d'écran d'un champ obligatoire, nous pouvons simplement ajouter l'attribut aria-required à l'élément d' input . Cela informera l'utilisateur que ce champ est obligatoire, mais n'ajoute rien d'autre en termes de validation de champ.

 <label for="email">Email</label> <input type="email" id="email" name="email" aria-required="true" />

Lorsqu'un lecteur d'écran rencontre cette input , il peut annoncer quelque chose comme "E-mail, modifier le texte, requis".

Instructions additionnelles

En plus du repère visuel pour chaque champ obligatoire à côté du texte de l' label , il est également recommandé de placer des instructions en haut, informant l'utilisateur de chaque type de champ. Quelque chose du genre :

<!-- When marking as Required… --> <p aria-hidden="true">* denotes a required field</p>​ <!-- When marking as Optional… --> <p>All fields required unless described otherwise.</p>

Avec cette note en texte brut, les personnes ayant des troubles cognitifs , les générations plus âgées ou les nouveaux utilisateurs d'Internet auront moins de mal à comprendre quels champs sont obligatoires et, par conséquent, passeront moins de temps et d'efforts à remplir le formulaire.

L'attribut required

Maintenant, en tant que développeur, vous pensez peut-être : "Pourquoi ne pas simplement utiliser l'attribut required HTML intégré ? Cela n'annonce-t-il pas également un champ obligatoire ?"

Il est vrai que l'inclusion de l'attribut required donne un résultat similaire à l'utilisation de aria-required , informant l'utilisateur du lecteur d'écran d'un champ obligatoire. La différence est que l'utilisation d' aria-required permet au développeur d'inclure des règles de validation personnalisées.

Éviter la validation native

L'utilisation de la validation personnalisée au lieu de la validation intégrée du navigateur est fortement préférée pour plusieurs raisons :

  • Meilleur contrôle sur les messages d'erreur
  • Les messages peuvent être traduits en plusieurs langues
  • Mise en œuvre cohérente et prévisible de la messagerie
  • Les messages ne sont pas supprimés de la vue après une courte période de temps

Pour ces raisons, il est fortement recommandé d'implémenter une validation de formulaire personnalisée.

Critères de réussite WCAG

Cela revient à 3.3.2 Étiquettes ou Instructions qui stipule :

"Des étiquettes ou des instructions sont fournies lorsque le contenu nécessite une entrée de l'utilisateur."

les erreurs

La conception des messages d'erreur de formulaire peut être assez délicate. L'idée est de faire prendre conscience de l'état actuel du formulaire sans être écrasant. Malheureusement, il est très facile de provoquer de la frustration ou du chagrin lors de l'affichage d'états d'erreur, en particulier pour ceux qui ne sont pas si férus de technologie et qui sont déjà très prudents et nerveux à l'idée d'utiliser un ordinateur en premier lieu.

En tant que concepteurs et développeurs, il est de notre responsabilité de faciliter l'intégration de nos utilisateurs dans les systèmes que nous créons, en les guidant sur le chemin que nous leur avons tracé.

Message d'erreur

Dans cet esprit, considérons une esthétique de conception qui est informelle et fait de son mieux pour ne pas être envahissante en même temps.

Trois éléments à examiner dans cette section :

  • Texte d'erreur
  • Styles d'entrée
  • Liste d'erreurs

Texte d'erreur

Le texte d'erreur est essentiel lors de la transmission d'un état d'erreur. Sans ce texte, les gens pourraient ne pas se rendre compte que le formulaire est dans un état dans lequel il ne peut pas être soumis. Bien sûr, nous pourrions changer la couleur de l'élément d' input , peut-être modifier ses propriétés de border ou d' background -plan en quelque chose de reconnaissable comme un état d'erreur. Cependant, comme nous l'avons déjà vu, se fier uniquement à la couleur pour transmettre du sens n'est pas idéal.

Alors, comment s'assurer que l'état d'erreur d'entrée est correctement transmis ? Quelques choses que nous pouvons faire sont :

  • Texte de sortie significatif et qui ne submerge pas l'utilisateur de jargon technique ( troubles cognitifs ).
  • Affichez le texte sous l'entrée associée ( basse vision ).
  • Assurez-vous que le texte est lisible en testant son contraste de couleur .
  • Inclure éventuellement une icône pour aider à attirer l' attention des utilisateurs sur le texte.

Connexion du texte d'erreur à son entrée

Lorsqu'une personne utilisant un lecteur d'écran entre en contact avec un élément d' input dans un état d'erreur, cette information doit être annoncée à côté de son texte d' label . Sinon, il y a de fortes chances que le contexte d'erreur soit perdu lors de la navigation dans un formulaire.

Il existe plusieurs façons d'y parvenir, mais la plus robuste serait d'inclure l'attribut aria-describedby dedicatedby sur l'élément input . L'ajout de cet attribut place le texte d'erreur dans la "file d'attente" d'annonce de l'élément sur le focus clavier.

Afin d'établir la connexion par programmation, la valeur aria-describedby doit correspondre à l' id du conteneur de texte d'erreur.

Par exemple, examinons un élément d' input dans un état d'erreur.

Pas de connection

 <label for="fname">First name</label> <input type="text" id="fname" name="fname" /> <span id="error-fname" class="error">First name is required</span>

Cette input comporte une label et un texte d'erreur directement en dessous. Cependant, le texte n'est pas inclus avec l'annonce du label car il n'y a pas de connexion programmatique établie.

Établissons la connexion en utilisant aria-describedby , un attribut qui est utilisé pour aider à fournir plus d'informations pour le contexte donné.

Utiliser aria décrit par

 <label for="fname">First name</label> <input type="text" id="fname" name="fname" aria-invalid="true" aria-describedby="error-fname" /> <span id="error-fname" class="error">First name is required</span>

Avec l'attribut aria-describedby dedicatedby appliqué à l' input et sa valeur correspondant à l' id du conteneur de texte d'erreur, l'annonce d'un lecteur d'écran ressemblerait à :

"Prénom, invalide, modifier le texte. Le prénom est requis."

L'un des avantages de l'utilisation spécifique d' aria-describedby est qu'il ajoute une courte pause entre le texte de l' label et le texte d'erreur, ce qui lui donne un peu de distinction dans l'annonce.

Liste d'erreurs

Présenter une liste d'erreurs lorsqu'un formulaire est dans un état d'erreur est particulièrement utile sur les formulaires volumineux. Ce contenu est composé d'un titre, expliquant l'état actuel du formulaire, suivi d'une liste de liens non ordonnés.

L'en-tête, généralement un élément h2 , est la principale méthode pour attirer l'attention des utilisateurs sur l'état d'erreur. Les utilisateurs voyants verront le texte volumineux et les utilisateurs non visuels verront le focus du clavier être amené automatiquement sur cette partie de l'écran à l'aide de la gestion du focus ; lorsque l'en-tête est présenté à l'utilisateur, envoyez le focus à l'élément d'en-tête à l'aide de la méthode JavaScript focus() ainsi qu'en appliquant tabindex="-1" à l'élément d'en-tête afin qu'il reçoive le focus.

La partie liste est composée d'un élément ul contenant des liens. Chaque lien représente une seule erreur dans le formulaire. Le texte du lien doit correspondre à celui de la sortie du texte d'erreur sous l' input associée. Lorsqu'il est activé, le focus du clavier passe du lien à l' input associée, permettant à l'utilisateur de se concentrer sur le problème en cours et de le résoudre.

 <h2 class="form-message__title" tabindex="-1"> Please adjust the following: </h2> <ul> <li> <a href="#fname" class="form-message__link"> First name is required </a> </li> <!-- ... --> </ul> <!-- ... --> <label for="fname">First name</label> <input type="text" id="fname" name="fname" aria-invalid="true" aria-describedby="error-fname" /> <span id="error-fname" class="error">First name is required</span>

Le positionnement idéal de la liste d'erreurs est directement au-dessus du formulaire qui est pour la commodité de l'utilisateur. Par exemple, si une personne utilisant un lecteur d'écran devait dépasser la liste d'erreurs, elle serait amenée au formulaire avec ses éléments d' input . Chaque input serait accompagnée de son propre texte d'état d'erreur qui informerait l'utilisateur sur la façon d'ajuster le contenu d' input pour répondre à ses exigences de validation.

La liste d'erreurs, en combinaison avec le texte d'erreur sous l' input , garantit que l'utilisateur est informé des erreurs actuelles qui nécessitent une attention et supprime la charge cognitive de ne pas avoir à se souvenir de chaque erreur qui doit être corrigée ; le message d'erreur sera disponible lorsqu'ils arriveront à l'élément input .

Critères de réussite WCAG

Cela revient à 3.3.1 Identification des erreurs qui indique :

"Si une erreur de saisie est automatiquement détectée, l'élément erroné est identifié et l'erreur est décrite à l'utilisateur sous forme de texte."

Messagerie de réussite

Tout aussi important, mais parfois oublié, est le message de réussite. Lorsqu'une personne remplit complètement le formulaire correctement, un texte doit être mis en place pour informer l'utilisateur de l'état actuel.

Comme pour l'en-tête de la liste d'erreurs, le message de réussite doit également être conçu pour inclure un texte long et accrocheur. De plus, le focus du clavier doit être géré au nom de l'utilisateur et défini sur l'élément d'en-tête du message de réussite. Avec cela, l'utilisateur sera informé de la soumission du formulaire et pourra passer en toute confiance à une autre tâche.

L'attribut autocomplete -automatique

La saisie semi-automatique HTML aide les utilisateurs à remplir des formulaires en utilisant les données stockées dans le navigateur. Ceci est particulièrement utile pour les personnes handicapées motrices ou cognitives qui peuvent avoir des difficultés à remplir des formulaires en ligne.

Par exemple, une entrée de formulaire demandant l'adresse e-mail de quelqu'un doit inclure l'attribut de autocomplete -automatique afin d'envoyer un indice au navigateur ou à d'autres agents utilisateurs pour interroger ces données :

 <label for="email">Email</label> <input type="email" id="email" name="email" autocomplete="email" ... />

Avec cela en place, les utilisateurs auront une expérience utilisateur beaucoup plus facile et confortable lorsque le navigateur de leur choix les invitera à entrer leur adresse e-mail en leur nom.

Consultez la section « W3C HTML 5.12 – 4.10.18.7. Remplissage automatique » pour tous les autres types d'entrée et leurs valeurs d'attribut de saisie semi-automatique correspondantes.

Validation en ligne et signification du bouton Soumettre

Dans la conception et le développement de formulaires modernes, particulièrement courants dans les démos d'applications SPA, il existe deux tendances en particulier : la validation en ligne des contrôles de formulaire après qu'ils ont été "touchés" (essentiellement lorsque l'utilisateur s'éloigne de l' input ) et le maintien de l'option Soumettre bouton dans un état désactivé (via l'attribut disabled ) jusqu'à ce que chaque test de validation ait été satisfait.

Validation en ligne

Lorsqu'il s'agit de créer des formulaires hautement utilisables et accessibles, en particulier pour les personnes handicapées, il est recommandé de ne pas utiliser la validation en ligne. Ce modèle peut parfois causer un peu de confusion ou de frustration à l'utilisateur. Voici quelques exemples illustrant cela :

  • Lorsqu'une personne utilisant un lecteur d'écran navigue dans un formulaire pour obtenir un aperçu général, essaie de lire ce qu'est chaque champ et les données attendues
  • Quelqu'un qui pourrait vouloir remplir les champs du formulaire dans un ordre différent
  • Quand quelqu'un quitte un champ pour aller chercher quelque chose pour être certain des données à placer dans le contrôle de formulaire

Ces actions simples déclenchent le message d'erreur et le résultat peut être assez irritant

Au cours des études d'utilisabilité, les gens grognent ou jurent souvent à haute voix lorsque des messages d'erreur apparaissent avant même d'avoir commencé à remplir des formulaires !

Des problèmes d'accessibilité supplémentaires apparaissent lorsque l'utilisateur quitte un champ ; le message d'erreur s'affiche visuellement mais, généralement, pas sur la technologie d'assistance. Pour entendre le message d'erreur, l'utilisateur doit revenir en arrière dans le formulaire. Il s'agirait d'une action requise inattendue pour entendre et comprendre l'état d'erreur.

État désactivé

Lorsque le button Soumettre est disabled par défaut, ce n'est qu'une fois que toutes les règles de validation du formulaire ont été satisfaites que le contrôle devient disponible à l'utilisation. La mise en place de ce modèle peut entraîner une expérience utilisateur déroutante ou frustrante ; il n'y a aucune indication quant à la raison pour laquelle le contrôle serait désactivé après avoir rempli le formulaire lors du premier passage.

Par conséquent, les contrôles désactivés peuvent présenter deux défis supplémentaires pour les individus :

  • Les personnes malvoyantes peuvent ne pas être en mesure de percevoir le texte du bouton dans l'état grisé.
  • Certaines technologies d'assistance ignorent les éléments disabled ; les utilisateurs de lecteurs d'écran peuvent ne pas avoir une image complète de ce qui est disponible dans l'interface, ce qui entraîne un sentiment d' incertitude ou de doute .

Prise en compte de l'accessibilité avec ce modèle

Pour atténuer certains de ces problèmes potentiels pour les utilisateurs, il est recommandé d'adopter une approche hybride légèrement différente. Envisagez d'apporter les modifications suivantes à votre workflow de formulaire :

  • Lorsqu'une input est dans un état d'erreur, sortez le texte du message d'erreur comme décrit précédemment. Cela servira de rappel de l'erreur et de la valeur attendue lors de la navigation vers le contrôle, ainsi que de tout autre contrôle dans un état d'erreur lorsque l'utilisateur avance dans le contenu du formulaire.
  • Lorsque l'utilisateur s'éloigne de la input du formulaire, lancez le test de validation. Si le test échoue, affichez visuellement le texte d'erreur pour les utilisateurs voyants, mais évitez d'annoncer le nouvel état aux utilisateurs de lecteurs d'écran.
  • Lors de la saisie d'une input qui est dans un état d'erreur, supprimez tout texte d'erreur ; afficher uniquement le texte d'erreur lorsque le focus s'éloigne de l' input .
  • Autorisez l'exécution de la validation complète du formulaire lors de la soumission du formulaire en gardant le button Soumettre activé . Cela permettra à l'utilisateur d'explorer facilement le formulaire et de se familiariser avec la structure du formulaire lors de la première exécution. Même si les champs du formulaire contiennent des erreurs, autorisez les utilisateurs à soumettre le formulaire selon leurs conditions, lorsqu'ils se sentent à l'aise de le faire.

Avec ces changements en place, toute personne qui s'appuie sur une technologie d'assistance ou qui a besoin d'un peu plus de conseils pour remplir un formulaire aura une meilleure compréhension de la façon dont le formulaire est structuré et de l'état actuel du formulaire, ainsi que s'il y a des erreurs. et comment les aborder.

S'il y a des modifications à apporter lors de la soumission, l'accent sera mis sur la liste d'erreurs. À partir de là, les liens d'erreur déplaceront le focus directement vers l' input de formulaire en question. À partir de ce moment, des messages d'erreur seront annoncés lors de la navigation dans le formulaire, et toute modification des données pourra facilement être effectuée avec une plus grande confiance de la part de l'utilisateur.

Ressources:

Retour au blog