Version imprimable
Bonjour,
tout d'abord, ne trouvant pas de forum adapté, je pose ma question ici :
Un déficient visuel me dit que le formulaire de cette page wordpress est non accessible aux lecteurs d'écran. Comment faire ?
https://vercorshandisport.org/event/...du-06-09-2025/
bonjour,
J'irai dans le sens de ce qu'on t'a dit : ce n'est pas accessible.
Dans ce genre de cas, il faut reprendre la page avec l'aide de quelqu'un qui peut vérifier l'accessibilité. Et surtout voir si les corrections sont possibles : Wordpress ou le template utilisé permettent-ils de faire les modifications ?
Je pense que oui si l'on parle de la hiérarchisation des titres (les hx). Mais probablement moins pour :
- la définition des régions, et les liens d'accès rapide,
- le fonctionnement du dynamique, p.ex. les menus déroulants qui ne sont absolument pas standards (voir les pratiques ARIA, et là on parle de codage javascript),
- la bonne gestion des attributs ARIA : le menu principal est affublé d'un aria-expanded="false" alors qu'il est bien affiché, mais la balise ul ne possède pas d'aria-label, etc.
Bref, il faut revoir le code et les "bonnes pratiques" avec laide d'un d'un spécialiste.
bonne journée
Merci pour ta réponse.
Je vais me tourner vers un spécialiste (j'en connais).
Par contre,
1- tu me parles de voir avec quelqu'un à même de vérifier l'accessibilité. Serait-il utile de passer du temps pour apprendre à utiliser la version gratuite de jaws et tester moi-même l'accessibilité ?
2- tu confirmes la non accessibilité du formulaire : comment le constates tu ?
3- tu mentionnes des menus déroulants. Où les vois tu ? Il n'y en a pas dans le formulaire...
Bonjour,
Je n'ai pas pu obtenir les détails spécifiques sur les problèmes d'accessibilité du formulaire sur la page que vous avez fournie. Cependant, je peux vous donner des conseils généraux sur la façon de rendre un formulaire WordPress accessible aux lecteurs d'écran.
Pour améliorer l'accessibilité d'un formulaire WordPress pour les lecteurs d'écran, voici les points clés à vérifier et à implémenter :
Libellés explicites (<label> pour les champs) : Chaque champ de formulaire (texte, case à cocher, bouton radio, etc.) doit avoir un libellé (<label>) qui lui est explicitement associé en utilisant l'attribut for qui correspond à l' id du champ. Cela permet aux lecteurs d'écran de lire le libellé pour que l'utilisateur sache à quoi sert le champ.
Code:
2
Champs obligatoires : Indiquez clairement les champs obligatoires, idéalement avec un texte visible (ex: "Champ obligatoire") et en utilisant l'attribut aria-required="true".
Messages d'erreur clairs et accessibles : Lorsque des erreurs de validation se produisent, les messages doivent être clairs, descriptifs et annoncés aux lecteurs d'écran. Utilisez aria-live="assertive" sur un conteneur de message d'erreur pour que les lecteurs d'écran annoncent immédiatement les erreurs. Les erreurs doivent être associées au champ concerné via aria-describedby.
Instructions et aide contextuelle : Si un champ nécessite des instructions spécifiques (ex: format de date), fournissez-les de manière accessible, par exemple avec aria-describedby pointant vers un élément d'aide.
Ordre de tabulation logique : Assurez-vous que l'ordre de tabulation (lorsque l'utilisateur navigue avec la touche Tab) est logique et suit l'ordre visuel des champs.
Boutons descriptifs : Les boutons de soumission doivent avoir un texte clair et descriptif (ex: "Envoyer le message", "S'inscrire") plutôt que des termes génériques comme "Cliquez ici".
Regroupement de champs (<fieldset> et <legend>) : Pour les groupes de champs liés (comme les boutons radio ou les cases à cocher), utilisez les éléments <fieldset> et <legend> pour les regrouper sémantiquement. La balise <legend> fournit un titre pour le groupe.
Code:
2
3
4
5
6
7
Accessibilité des éléments personnalisés : Si le formulaire utilise des éléments de formulaire personnalisés (par exemple, des sélecteurs de date, des sliders), assurez-vous qu'ils implémentent correctement les attributs ARIA (comme role, aria-labelledby, aria-controls, aria-expanded, etc.) et qu'ils sont navigables au clavier.
Tests avec des lecteurs d'écran : La meilleure façon de s'assurer de l'accessibilité est de tester le formulaire avec de vrais lecteurs d'écran (NVDA, JAWS sur Windows ; VoiceOver sur macOS ; TalkBack sur Android).
Si vous utilisez un plugin de formulaire WordPress, vérifiez ses options d'accessibilité. Les plugins populaires comme Gravity Forms, WPForms, ou Contact Form 7 ont souvent des fonctionnalités d'accessibilité intégrées ou des extensions pour améliorer cela.
Merci pour ces conseils. Je vais les traiter un par un. Cependant, dès le premier (les libellés), vous me donnez un code html. J'utilise pour créer les formulaires l'extension la plus connue : CF7. Et pour l'utiliser, ce n'est pas du code html, mais un code spécial. Par exemple :
<p><label> Votre nom :
[text* votre-nom placeholder "votre nom"] </label>
</p>
avec l'extension contact form 7 vous pouvez rajouter un identifiant comme cela :
Code:
2
3
4
vous pouvez voir la documentation officielle là :
https://contactform7.com/docs/
Bonjour,
Je sais, mais en fin de compte c'est un code HTML qui sera généré (ou converti) par la syntaxe de CF7Citation:
Envoyé par laurentSc
Bonsoir,
voici le code actuel du formulaire. Pouvez-vous le corriger ?
Dans vos conseils, Toufik, vous parlez souvent de la balise aria, il serait sympa d'en tenir compte.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Je ne vous lirai que demain car je me lève très tôt donc :zzz:
Bonjour,
Les balises <label> pour associer vos champs de formulaire est une bonne pratique pour l'accessibilité ! Cependant, il y a quelques ajustements à faire, notamment en ce qui concerne l'utilisation des attributs aria et la structure de certains champs.
Corrections et améliorations du code du formulaire
Voici le code corrigé et amélioré, avec des explications pour chaque modification.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Explications des corrections et ajouts :
- Champs "Nom" et "Prénom" ([text*]) : placeholder amélioré : J'ai capitalisé la première lettre des placeholders pour une meilleure clarté ("Votre nom" au lieu de "votre nom"). C'est un détail, mais cela rend le formulaire plus professionnel.
- Champs Radio ([radio]) :
- Suppression de use_label_element : Pour les groupes de boutons radio, l'attribut use_label_element n'est pas la méthode la plus robuste pour l'accessibilité, surtout si le texte de votre label est distinct des options individuelles.
- Utilisation de aria-labelledby : J'ai ajouté un id à la balise <label> qui contient le texte de la question pour les groupes de radios (par exemple, <label id="label_vous_faites">Vous faites :</label>). Ensuite, j'ai utilisé aria-labelledby sur le contrôle du formulaire ([radio]) pour faire référence à cet id.
- Pourquoi aria-labelledby ? Cela permet d'associer le texte de la question (le label) au groupe entier de boutons radio. Les lecteurs d'écran liront la question avant de proposer les différentes options, ce qui améliore considérablement la compréhension pour les utilisateurs ayant des déficiences visuelles.
- Suppression de id:champ_vous_faites et similaires sur les radios : Un id sur le groupe de radios n'est pas nécessaire et peut être source de confusion pour les lecteurs d'écran, car chaque bouton radio au sein du groupe devrait avoir son propre id pour être associé à son propre <label> si vous utilisiez cette méthode. Avec aria-labelledby, nous associons le label à l'ensemble du groupe.
- Champs "Commentaire" ([textarea]) : Ajout d'un placeholder : J'ai ajouté un placeholder pour guider l'utilisateur ("Votre commentaire (facultatif)"). C'est une petite aide visuelle qui peut encourager les utilisateurs à remplir le champ.
Emplacement du champ hidden.
- Champs "hidden your-subject" : J'ai déplacé aussi le champ [hidden your-subject "inscription - sortie du 06/09/2025"] à la fin du formulaire. Bien que son emplacement n'ait pas d'impact fonctionnel, il est souvent plus logique de placer les champs cachés à la fin, après les éléments interactifs.
Ces modifications visent à rendre votre formulaire plus sémantique et plus accessible, en particulier pour les utilisateurs de lecteurs d'écran, tout en conservant une structure claire.
N'hésitez pas si vous avez d'autres questions !
@laurentSc :
1. Oui, je pense qu'apprendre à utiliser un lecteur d'écran, ne serait-ce qu'en mode grand débutant est un plus. Nous utilisons NVDA, et je propose (voire j'insiste ?) aux devs et aux chefs de projet une initiation dessus. Cela permet de se rendre compte beaucoup plus tôt des problèmes/besoins. J'ai aussi appris VoiceOver sur iOS (mais sur smartphone, on a d'autres préoccupations si on est en "natif").
2. Je confirme la non-accessibilité de la page par test. Grosso-modo la manière de consulter :
- Le visuel, et en particulier les contrastes. Que se passe-t-il au survole à la souris ? Ai-je les informations permettant de comprendre rapidement ?
- La navigation au clavier : elle doit être complète, sans piège, et standardisée. C'est un point que beaucoup de devs ont oublié (ou : ils ont trop la pression sur les délais).
- La navigation au lecteur d'écran : il y a plusieurs manières de naviguer, et à chaque fois je dois avoir l'information correcte et rapide à comprendre. Attention : dès que l'on dit "on voit bien que…" on a tout perdu.
Ah, et pour bien tester au lecteur d'écran, descend ta fenêtre de navigateur en bas d'écran, de manière à ne voir que le bandeau du navigateur. :-)
- Une inspection du code HTML permet de mieux comprendre pourquoi tu n'as pas les bonnes infos au bon moment.
3. Menu déroulant : "Handiscoop".
Le développement accessible est basé sur ce qu'on appelle des bonnes pratiques, qui deviennent des réflexes. Exemple typique : on me dit de mettre une image dans le html ? alors je place aussitôt un attribut alt à la balise d'image.
Pour l'accessibilité, on a un référentiel officiel en France, qui est le RGAA. Tu pourras en particulier parcourir les critères et tests. Leur lecture donne une idée des contrôles à faire, de ce qui peut être attendu dans le code.
Ensuite, il y a le côté dynamique, donc le javascript. Le comportement doit être de préférence standardisé, même si certains disent "oui mais j'ai une autre manière de faire" : faut-il apprendre un mode d'emploi pour chaque site ? Pour cette dynamique, il y a le standard ARIA, et en particulier différents cas répertoriés (les patterns) tels le fil d'ariane, le bouton, le menu déroulant (actuellement 30 cas).
Le référentiel RGAA c'est surtout une obligation pour le commerce et les fournisseurs de service, et on parle de conformité. Mais cette conformité est insuffisante, il faut se pencher sur l'utilisabilité. D'où des bonnes pratiques de développement qui facilitent la vie des utilisateurs d'aides.
La mise en œuvre pratique dépend souvent/beaucoup de ton socle technique. Là, c'est WordPress, et ce sont les spécialistes WordPress qui pourront (ont déjà commencé à) t'aider.
C'est impressionnant lorsque tu découvres, mais c'est passionnant. Comme d'habitude, tout est une question d'équilibre.
Bonne aventure !
Merci pour vos interventions très intéressantes.
J'ai pris le code proposé par Toufik et demandé à mon utilisateur de lecteur d'écran (en réalité, ils sont plusieurs) de tester ce nouveau formulaire et voici ce qu'il dit :
Qu'en pensez vous ?Citation:
Bonjour Laurent et merci de te pencher sur le pb que j’ai évoqué. Avec ce nouveau lien j’ai les mêmes soucis, lorsque je fais « s’inscrire » il me dit que un ou plusieurs champs n'ont pas été renseignés, or ce n’est pas le cas.
En fait, lorsque j’arrive sur le formulaire dans la zone avec des cases à cocher, il me dit que par défaut toutes les cases le sont or, je ne pense pas que ce soit le cas. Du coup lorsque je coche la case je ne sais jamais si le résultat est OK. Je me demande si je me retrouve réellement sur la case qu’il annonce ???
est ce qu'il est toujours question du formulaire de la page suivante ?
https://vercorshandisport.org/event/...du-06-09-2025/
je demande cela parce qu'il n'y a pas de case à cocher dans ce formulaire.
et d'après ce que j'ai vu dans le code source, les boutons radios ont bien un seul choix par défaut sélectionné qui correspond à ce que je vois dans le navigateur donc cela a l'air correct.
C'est bien de ce formulaire qu'il s'agit et si cet utilisateur parle de case à cocher, ça doit être une erreur car ce sont des boutons radio...
Bonjour,
En inspectant le formulaire, je vois ceci
Pièce jointe 668345.
Le soulignement rouge sous les label et input indique bien qu'ils y'a des avertissements/erreurs, apparemment tu utilises un seul <label> pour plusieurs boutons radios, alors qu'il faudrait un label pour chaque bouton.
En cliquant sur View Issue, j'obtiens l'explication des avertissements
Pièce jointe 668346.
En maintenant Shift et cliquant sur les balises <input> radio soulignés en rouge, le navigateur pointe sur une erreur : Form elements must have labels: Element has no title attribute Element has no placeholder attribute
Utilisez fieldset et legend pour grouper les boutons radios, rajoutez l'attribut for aux labels et faites en sorte que le code html généré soit similaire à ceci :
Code:
2
3
4
5
6
7
8
9
10
11
La même chose pour les autres boutons...
Bonjour,
en fait, le souci a été résolu depuis un moment (je crois me souvenir que ça venait d'une extension).
