Fieldset et RGAA : quand regrouper des champs (11.5/11.6)

« Dans le doute, mets un fieldset. » Le conseil part d'une bonne intention et produit des formulaires bavards, où chaque champ isolé est emballé dans son propre regroupement. Le critère RGAA ne demande rien de tel. Un <fieldset> n'est pas une bonne pratique à appliquer partout : c'est un outil sémantique précis, avec un déclencheur précis. Voici comment trancher, et l'anti-pattern à fuir quand on croit bien faire.

Le déclencheur : plusieurs champs, une seule question

Un <fieldset> se justifie quand plusieurs champs répondent ensemble à une même question, et que cette question ne peut pas être portée par les labels individuels. Sa <legend> énonce cette question commune. Trois cas typiques :

• Un groupe de boutons radio : « Civilité : Mme / M. / Autre ». Chaque radio a son label, mais la question « Civilité » fédère le groupe.
• Un groupe de cases à cocher sous une consigne unique : « Centres d'intérêt : … ».
• Un champ en plusieurs parties : une adresse postale, une date découpée en trois sélecteurs jour/mois/année.

C'est exactement le périmètre du critère RGAA 11.5, qui demande si « les champs de même nature sont regroupés, si nécessaire ». Le « si nécessaire » est le cœur du sujet : le regroupement n'est dû que lorsqu'il porte du sens. Et quand il a lieu, le critère 11.6 exige que chaque regroupement ait une <legend>. Les deux s'appuient sur le critère WCAG 1.3.1 (Information et relations).

Le coût de la sur-utilisation

Pourquoi ne pas en mettre partout « par sécurité » ? Parce que le fieldset n'est pas neutre à l'oreille. Les lecteurs d'écran annoncent la <legend> avant l'intitulé de chaque champ du groupe, pour rappeler le contexte commun. C'est précieux sur un vrai groupe ; c'est du bruit sur un champ unique.

A11y Weekly relève l'absurde de cette habitude dans Not every form field needs to be in a fieldset : une zone de texte seule demandant de décrire un handicap, dans son propre fieldset ; un champ email isolé, dans son propre fieldset. À l'écoute, l'email devient « Email, Email », et la confiance dans la structure s'érode. Les équipes, note l'article, n'ont pas appris quand utiliser un fieldset, seulement à en utiliser. La nuance est toute la différence.

Un champ isolé n'a pas besoin de regroupement : il lui faut un label correct, ce que détaille notre guide labels des champs de formulaire. Pour la vue d'ensemble d'un formulaire conforme, voir formulaires accessibles : le guide.

L'anti-pattern : le faux groupe en <div> + aria-label

Quand <fieldset> paraît trop rigide à styler, la tentation est de bricoler un groupe avec une <div aria-label="…">. C'est une erreur sémantique, pas seulement esthétique.

Manuel Matuzović l'explique dans Don't put aria-label on generic elements : la spécification ARIA range le rôle générique (celui d'une <div> ou d'un <span>) parmi les rôles qui ne peuvent pas être nommés. Un aria-label posé là n'a aucune garantie d'effet. Les tests le confirment : JAWS, NVDA et Narrator ignorent le plus souvent le label et n'annoncent que le contenu texte, pendant que VoiceOver annonce « groupe ». Le support est trop fragmenté pour s'y fier.

<!-- À éviter : rôle générique, label non garanti -->
<div aria-label="Civilité">
  <input type="radio" id="mme" name="civ"> <label for="mme">Mme</label>
  <input type="radio" id="m" name="civ"> <label for="m">M.</label>
</div>

<!-- Correct : regroupement natif, légende annoncée de façon fiable -->
<fieldset>
  <legend>Civilité</legend>
  <input type="radio" id="mme" name="civ"> <label for="mme">Mme</label>
  <input type="radio" id="m" name="civ"> <label for="m">M.</label>
</fieldset>

La règle générale dépasse les formulaires : on ne nomme pas un élément générique avec ARIA, on choisit l'élément sémantique qui porte le sens. Pour un regroupement de champs, c'est <fieldset>/<legend>. Pour une section de page, un <section aria-label="…"> devient un repère nommé (rôle region), parce que <section> n'a pas le rôle générique. Notre guide complet d'aria-label revient sur ces usages corrects et leurs limites.

Tableau de décision : fieldset ou pas

La ligne de partage est nette : on regroupe quand une question commune relie plusieurs champs, et on regroupe alors avec l'élément natif. Le reste du temps, un label par champ suffit.

Ce qu'un scan détecte, et ce qui reste humain

Un scan repère des signaux fiables : un <fieldset> sans <legend> (échec direct du critère 11.6), un groupe de boutons radio de même name sans regroupement, un aria-label sur un élément qui ne peut pas être nommé. Ce sont des contrôles déterministes sur le code.

En revanche, la question centrale du critère 11.5, « ce regroupement est-il nécessaire ? », demande de comprendre l'intention du formulaire. Trois champs peuvent former une adresse ou rester indépendants selon le sens métier ; seul un humain le tranche. C'est la réalité du RGAA, dont une majorité de critères ne s'automatise pas entièrement. Un outil ne prononce donc jamais la conformité, et un score élevé sur les formulaires est un jalon de progression, pas une déclaration légale.

L'automatisation reste un excellent point de départ : un audit RGAA gratuit signale en quelques secondes les fieldsets sans légende et les groupes de champs mal structurés, ce qui vous laisse arbitrer ce qui demande du jugement, à savoir la nécessité réelle de chaque regroupement. Détectez d'abord, décidez ensuite.