Formulaires accessibles dans Drupal

Le formulaire est le point de friction par excellence d’un site web. C’est là que l’utilisateur passe de spectateur à acteur : il s’inscrit, prend rendez-vous, dépose un dossier, paie. Si ce moment échoue pour une personne qui navigue au clavier ou avec un lecteur d’écran, ce n’est pas un détail cosmétique, c’est une conversion perdue et, pour beaucoup d’organisations publiques ou parapubliques, une obligation légale non respectée. Les formulaires concentrent à eux seuls une part importante des non-conformités relevées lors des audits d’accessibilité.

La bonne nouvelle, c’est que Drupal part avec une longueur d’avance. Sa Form API génère un balisage propre et les modules de contribution comme Webform ont fait de l’accessibilité une priorité depuis des années. Mais l’outil ne fait pas tout : un thème custom, un champ mal configuré ou un message d’erreur approximatif suffisent à casser ce que le core avait bien construit. Cet article fait le tour des critères qui comptent, de ce que Drupal couvre nativement et des points à vérifier vous-même.

Ce que le RGAA exige des formulaires

Le RGAA (Référentiel général d’amélioration de l’accessibilité) consacre une section entière aux formulaires. Et pour une bonne raison : ce sont les composants les plus sensibles. Quatre familles d’exigences reviennent systématiquement.

Des labels associés à chaque champ. Tout champ de saisie doit avoir une étiquette visible et liée techniquement au champ. Un lecteur d’écran qui rencontre un champ sans label annonce « zone de texte » sans rien d’autre : l’utilisateur ne sait pas ce qu’on lui demande. L’association se fait par l’attribut for du <label> pointant vers l’id du champ ou par englobement.

Le caractère obligatoire signalé clairement. Un astérisque rouge seul ne suffit pas : la couleur n’est pas perçue par tout le monde et l’astérisque n’est pas toujours annoncé. L’information « obligatoire » doit être présente dans le label et portée par l’attribut required ou aria-required.

Des messages d’erreur explicites et reliés au champ. « Erreur de saisie » ne dit rien. Il faut indiquer quel champ est en cause et comment corriger (« Le code postal doit comporter 5 chiffres »). Le message doit être rattaché au champ concerné pour qu’un lecteur d’écran le restitue au bon moment.

Des champs de même nature regroupés. Une série de boutons radio, une question avec plusieurs cases à cocher, une adresse complète : ces groupes doivent être structurés avec <fieldset> et <legend> pour que la question d’ensemble soit annoncée avant les options.

Ces exigences ne sont pas des subtilités d’expert. Elles correspondent à ce dont une personne aveugle, malvoyante ou à mobilité réduite a besoin pour remplir un formulaire de façon autonome. Et elles recoupent largement le travail global de mise en conformité que je détaille dans la page accessibilité RGAA Drupal.

Ce que la Form API de Drupal fait nativement

Drupal a un atout structurel : on ne génère pas le HTML des formulaires à la main, on le déclare en PHP via la Form API et le rendu est centralisé. Cela veut dire que les bonnes pratiques d’accessibilité sont appliquées une fois, dans le core, pour tous les formulaires du site.

Concrètement, quand vous déclarez un champ ainsi :

$form['courriel'] = [
  '#type' => 'email',
  '#title' => $this->t('Adresse courriel'),
  '#required' => TRUE,
  '#description' => $this->t('Nous ne partagerons jamais votre adresse.'),
];

Drupal produit un balisage qui respecte déjà l’essentiel :

<label for="edit-courriel" class="form-required">Adresse courriel</label>
<input type="email" id="edit-courriel" name="courriel"
       required="required" aria-required="true" />

Le <label> est correctement associé via for. La propriété #required génère à la fois l’attribut required, aria-required="true" et la classe form-required qui porte l’indication visuelle. La #description est rattachée au champ avec aria-describedby. Le #type => 'email' produit le bon type HTML5, ce qui aide la saisie sur mobile et la validation.

La Form API gère aussi nativement les groupements. Un #type => 'fieldset' ou un #type => 'radios' génère un <fieldset> avec une <legend>, ce qui est exactement ce que le RGAA attend pour les regroupements de champs. Et la gestion des erreurs via setError() ou setErrorByName() produit des messages reliés au champ et déplace le focus, deux comportements essentiels pour la navigation au clavier et au lecteur d’écran.

Autrement dit, un formulaire construit proprement avec la Form API, sans surcharge hasardeuse, est accessible par défaut sur une grande majorité des critères. C’est un point fort de Drupal qu’il faut savoir exploiter plutôt que contourner.

Ce qu’il faut vérifier vous-même

Le « par défaut » de Drupal est solide, mais il ne couvre pas tout et certaines décisions de projet peuvent le défaire. Voici les points qui méritent une vérification systématique.

Les labels cachés visuellement. Pour des raisons de design, on masque parfois un label (un champ de recherche avec juste une icône loupe, par exemple). Le réflexe est de le supprimer : c’est une erreur. Il faut le conserver dans le DOM et le masquer visuellement avec la classe visually-hidden fournie par Drupal ou utiliser #title_display => 'invisible'. Le label reste alors disponible pour les technologies d’assistance.

Le placeholder n’est pas un label. Le texte d’invite dans un champ (placeholder) disparaît dès qu’on tape, n’est pas fiablement annoncé et présente souvent un contraste insuffisant. Il ne remplace jamais un <label>. Si vos maquettes utilisent le placeholder comme seule étiquette, c’est un point à corriger en amont.

La qualité des messages d’erreur. Drupal relie bien les erreurs au formulaire, mais le texte vient de vous. Un message générique de validation custom passe les tests techniques mais échoue sur le fond. Prenez le temps d’écrire des messages qui nomment le champ et indiquent l’action attendue.

Le thème et le contraste. Le balisage peut être parfait et le rendu inaccessible : contraste insuffisant entre le texte et le fond, indicateur de focus supprimé en CSS (outline: none sans alternative), erreurs signalées par la seule couleur rouge. Ces régressions se logent dans le thème, pas dans la Form API.

La navigation clavier de bout en bout. Testez chaque formulaire en n’utilisant que la touche Tab : l’ordre est-il logique ? Le focus est-il toujours visible ? Peut-on tout valider sans souris ? Les composants AJAX et les champs dynamiques de Drupal sont les endroits où la navigation clavier déraille le plus souvent.

Cette revue fait partie intégrante d’un audit Drupal sérieux, où l’on combine vérification automatisée du balisage et tests manuels au clavier et au lecteur d’écran, car aucun outil automatique ne détecte à lui seul un message d’erreur mal formulé ou un ordre de tabulation illogique.

Webform et l’accessibilité

Webform est le module de référence pour construire des formulaires complexes dans Drupal, du simple contact au formulaire multi-pages avec logique conditionnelle. Et c’est une bonne nouvelle pour l’accessibilité : ses mainteneurs en ont fait un engagement explicite et continu.

Webform s’appuie sur la Form API, il hérite donc de tout ce qui précède : labels associés, gestion native de l’obligatoire, fieldset et legend pour les sections, messages d’erreur reliés aux champs. Il ajoute des éléments propres et a fait l’effort de les rendre accessibles, y compris les composants riches comme les sélecteurs de date ou les champs de fichiers.

Quelques points d’attention restent à votre charge dans la configuration :

• Les éléments « Markup » et HTML libre. Webform vous laisse insérer du contenu libre entre les champs. C’est là qu’on retrouve des titres mal hiérarchisés ou des consignes inaccessibles. Le module ne peut pas valider ce que vous écrivez à la main.
• Les sections et fieldsets. Utilisez les éléments « Section » et « Fieldset » de Webform pour regrouper, plutôt que d’enchaîner des champs à plat avec des titres décoratifs.
• Les confirmations et redirections. Après soumission, l’utilisateur doit être informé du succès. Vérifiez que le message de confirmation est bien annoncé et que le focus est géré, en particulier sur les formulaires AJAX qui ne rechargent pas la page.
• La logique conditionnelle. L’affichage et le masquage de champs selon les réponses est puissant, mais l’apparition d’un champ doit rester perceptible au clavier et au lecteur d’écran.

Bien configuré, Webform permet de livrer des formulaires conformes au RGAA sans réinventer la roue. Mal configuré, il reproduit les mêmes écueils que n’importe quel formulaire. L’outil donne les bonnes briques, l’assemblage reste un travail de métier.

Les erreurs les plus courantes

Au fil des audits, certaines erreurs reviennent presque toujours. Les connaître permet de les éviter dès la conception.

Supprimer le label au lieu de le masquer. Pour un rendu épuré, on retire le <label> du DOM. Le champ devient muet pour les lecteurs d’écran. La solution est de le masquer visuellement, jamais de le supprimer.

Signaler l’obligatoire ou l’erreur par la seule couleur. Astérisque rouge seul, bordure rouge seule : invisibles pour une part des utilisateurs. Il faut toujours doubler l’information visuelle par du texte ou un attribut.

Retirer l’indicateur de focus. Un outline: none dans le thème, souvent pour des raisons esthétiques, rend la navigation clavier impossible à suivre. Si l’on retire l’outline par défaut, on doit fournir un style de focus alternatif visible.

Des messages d’erreur vagues ou hors contexte. « Champ invalide » sans préciser quel champ ni pourquoi. Le RGAA demande des messages explicites, rattachés au champ et orientés vers la correction.

Oublier de tester avec un vrai lecteur d’écran. La validation automatique attrape le balisage, pas l’expérience réelle. Un passage avec NVDA, VoiceOver ou un test au clavier seul révèle des problèmes qu’aucun outil ne signale.

La plupart de ces erreurs ne viennent pas de Drupal mais de choix de design ou d’intégration qui défont ce que le core avait bien fait. C’est précisément pour cela qu’une relecture experte du balisage généré, du thème et des messages fait toute la différence entre un formulaire qui passe les tests et un formulaire réellement utilisable par tous.

Drupal vous donne une base saine pour des formulaires accessibles. Le reste est une question de rigueur sur les labels, les messages, le contraste et la navigation clavier. Si vous voulez savoir où se situent vos formulaires aujourd’hui et ce qui sépare votre site d’une conformité solide, c’est exactement ce qu’un diagnostic ciblé permet de clarifier.

Vos formulaires Drupal sont-ils réellement accessibles à tous vos utilisateurs ? Parlons de votre projet pour un diagnostic et un plan d’action adapté à votre site.