Les formulaires comptent parmi les éléments les plus importants de la plupart des sites web ; sans eux, nous ne pourrions pas nous connecter, nous inscrire, effectuer des achats, laisser des commentaires, publier des contenus ni réaliser bon nombre des actions en ligne que nous considérons chaque jour comme allant de soi. Compte tenu de l’importance des formulaires, il est assez choquant de constater que l’on peut se rendre sur le site web de presque n’importe quelle entreprise du classement Fortune 100 – y compris de nombreux sites de services financiers – et y trouver des formulaires présentant les problèmes d’accessibilité les plus élémentaires. C’est pourquoi, lorsque nous avons organisé notre récent jQuery Accessibility Summit, j’ai insisté pour qu’une session soit consacrée aux formulaires et à leur validation, et comme personne d’autre ne s’est proposé pour l’animer, j’ai décidé de faire cette présentation moi-même.
Cet article a été initialement publié sur mon blog personnel, Unobfuscated.
Vous pouvez consulter les diapositives de la présentation sur Slideshare ou directement ci-dessous, au bas de cet article. Je vais publier ici une série d’articles de blog qui apporteront les précisions que les diapositives ne permettent pas de transmettre. Ce premier article de la série traite de…
Les directives WCAG 2.0 de niveau AA les plus fréquemment enfreintes dans les formulaires
Tout d'abord, je tiens à préciser que TOUTES les directives des WCAG 2 s'appliquent potentiellement aux formulaires, mais certaines sont plus couramment utilisées. Il s'agit notamment des suivantes :
-
Perceptible
-
1.3.1 (A) Associer les étiquettes à leurs champs de saisie par programmation
-
1.3.1 (A) Associer par programmation les messages d'erreur à leurs champs de saisie correspondants
-
1.4.1 (A) Ne pas utiliser uniquement la couleur pour signaler les différences entre les champs (champs obligatoires, erreurs, etc.)
-
1.4.3 (AA) Veiller à ce qu’il y ait un contraste suffisant entre le premier plan et l’arrière-plan (libellés, instructions, messages d’erreur, etc.)
-
Bonnes pratiques : associer visuellement les libellés, les instructions et les messages d'erreur à leurs champs de saisie correspondants
-
-
Fonctionnel
-
2.1.1 (A) Si vous mettez en place des mesures permettant aux utilisateurs de souris d'identifier facilement les champs comportant des erreurs, une solution équivalente doit être proposée aux utilisateurs qui utilisent uniquement le clavier.
-
2.1.1 (A) Tout doit pouvoir être commandé uniquement à l'aide du clavier
-
2.1.2 (A) Absence de « piège de clavier »
-
2.4.3 (A) Les messages d'erreur qui s'affichent et concernent l'ensemble du formulaire doivent être lus automatiquement
-
2.4.3 (A) Les instructions qui changent ou s'affichent de manière dynamique doivent être annoncées automatiquement
-
2.4.3 (A) L'ordre de priorité des éléments du formulaire doit correspondre à leur ordre d'affichage
-
2.4.7 (AA) Un indicateur visuel de focus doit être présent pour indiquer à tout moment aux utilisateurs du clavier où se trouve le focus
-
-
Compréhensible
-
3.2.1 (A) Les événements « On Focus » ne doivent pas entraîner de confusion ou de désorientation chez l'utilisateur
-
3.2.2 (A) Les changements qui surviennent en fonction des données saisies ne doivent pas dérouter ni désorienter l'utilisateur
-
3.3.3 (AA) Les messages d'erreur doivent, dans la mesure du possible et sans compromettre la sécurité, fournir des suggestions sur la manière de corriger les erreurs.
-
3.3.4 (AA) Si le formulaire se trouve sur un site financier ou dédié à des tests, ou s'il a des implications juridiques, l'utilisateur doit avoir la possibilité de vérifier les informations saisies avant de valider le formulaire.
-
-
Robuste
-
4.2.1 (A) L'attribut « role », la valeur, le nom et l'état de tous les éléments du formulaire doivent être exacts dans tous les états dynamiques du formulaire
-
Vous pouvez me suivre sur Twitter @dylanbarrell
