Accessibilité web : Comment développer un formulaire conforme WCAG & RGAA ?

Pour poursuivre notre dossier spécial développeurs, notre deuxième épisode s’attarde cette fois-ci sur la mise en accessibilité d’un formulaire.

Particulièrement répandus, notamment dans les tunnels d’achat ou dans les inscriptions aux newsletters dans le e-commerce, les formulaires peuvent être assez ardus à traiter si les recommandations ne sont pas explicites. 

Alors, afin d’éclaircir le sujet, voici en quelques étapes clés, tout ce qu’il faut savoir afin de développer des formulaires accessibles conformes WCAG 2.1 et RGAA 4.1.

Voici un formulaire à titre d’exemple :

Recommandations générales

1. Tous les champs doivent avoir un label explicite.
2. Tous les champs doivent recevoir le focus, et il doit être visible.
3. Si un placeholder est utilisé, assurez vous que l’information transmise par le placeholder (aide à la saisie) reste visible lorsque l’utilisateur commence à taper. À noter tout de même que le placeholder ne remplace pas le label. Il faut donc ajouter un aria label pour que le label soit visible au lecteur d’écran.
4. Tous les labels doivent être explicitement associés aux champs du formulaire :<label for= »p1″>First Name</label><input id= »p1″ …>
5. Tous les éléments obligatoires doivent avoir une étoile et aria-required= »true ».
6. S’il y a un label flottant, ne pas utiliser le placeholder, ajouter l’information au label : exemple :<label for …>Telephone (e.g., 0123456789)</label>
7. Vérifier que les checkmarks sont vocalisées par le lecteur d’écran :<img src= »checkmark.jpg” alt= »green checkmark » ..>
8. Ajouter l’autocomplete et le token :Web Content Accessibility Guidelines (WCAG) 2.1
9. Pour le champ Select, suivre cette implémentation :HTML select tag

La gestion des erreurs

1. Messages d’erreurs : associer le message d’erreur au champ adéquat via aria-describedby, et ajouter un lien en dessous du message d’erreur pour que les personnes qui utilisent des lecteurs d’écran n’aient pas à chercher le champ où l’erreur s’est produite.
2. Messages d’erreurs : Mettre aria-live= »polite » pour avertir l’utilisateur de l’apparition d’un message d’erreur. 
3. Messages d’erreurs : Mettre aria-invalid lorsqu’une erreur est saisie, attention le aria-invalid ne doit apparaître dans le champ input que lorsque le champ est erroné.
4. Assurez-vous que visuellement le message d’erreur et le champ du formulaire soient visibles.

Aria-live=polite et aria-live=assertive

De manière générale, aria-live=polite est le plus souvent utilisé car le lecteur d’écran vocalise le message d’erreur une fois l’action de l’internaute terminée.

Pourtant, on peut retrouver l’attribut aria-live=assertive dans certaines situations précises. Il n’est utilisé de manière exceptionnelle que pour prévenir le lecteur d’un message qui arrive pendant son parcours de navigation classique car il va bloquer la lecture de l’utilisateur.

Pour aller plus loin, n’hésitez pas à contacter notre équipe experte en accompagnement Accessibilité Numérique et continuez à lire nos articles !

Si vous avez loupé, le contenu précédent sur la mise en conformité d’un player vidéo, c’est par ici : https://blog.ipedis.com/tech-comment-developper-un-player-video-e-accessible-en-5-etapes