Pourquoi obliger un client à passer par la touche de tabulation d’un bout à l’autre d’un formulaire de commande découpé en plusieurs sections, dimensions, essence de bois, finition, alors que les flèches directionnelles suffiraient à circuler dans chacune d’elles ? C’est exactement le problème que vise à résoudre le mécanisme de regroupement de focus imbriqué, une piste encore en expérimentation dans certains moteurs de rendu, appliqué ici à un formulaire de commande sur mesure chez un artisan menuisier.
Ce mécanisme s’appuie sur une idée simple : marquer un conteneur comme groupe de focus permet de déplacer le focus entre ses enfants directs avec les flèches du clavier, sans écrire de gestionnaire d’événements maison, exactement ce que faisait déjà manuellement le motif de conception roving tabindex largement utilisé pour les barres d’outils et les listes d’onglets.
Fonctionnement interne du mécanisme
Un conteneur marqué comme groupe de focus expose ses enfants directs à la navigation par flèches, l’utilisateur passant de l’un à l’autre sans quitter le groupe tant qu’il n’appuie pas sur la touche de tabulation classique pour en sortir. La vraie nouveauté par rapport au roving tabindex manuel tient dans l’imbrication : un groupe peut contenir un autre groupe, avec une direction de navigation propre à chaque niveau, par exemple une disposition horizontale pour les sections principales du formulaire et une disposition verticale pour les champs à l’intérieur d’une section ouverte.
<div class="sections-formulaire">
<fieldset>
<legend>Dimensions</legend>
<input type="number" aria-label="Largeur en centimètres">
<input type="number" aria-label="Hauteur en centimètres">
</fieldset>
<fieldset>
<legend>Essence de bois</legend>
<input type="radio" name="essence" value="chene">
<input type="radio" name="essence" value="hetre">
</fieldset>
</div>
Sur ce type de structure, la navigation par flèches à l’intérieur de chaque fieldset et le passage à la section suivante par tabulation reproduisent exactement ce qu’un développeur devait auparavant recréer à la main avec des écouteurs de touches et une gestion soigneuse de l’attribut tabindex sur chaque élément.
Cas d’usage : le formulaire de commande à sections
Sur le formulaire de menuiserie mentionné plus haut, la gestion manuelle de la navigation par flèches entre les options de finition (mat, satiné, brillant) et entre les sections elles-mêmes représentait une vingtaine de lignes de script, avec une gestion d’état à synchroniser pour savoir quel élément devait recevoir le focus par défaut à chaque entrée dans un groupe. Un essai avec le mécanisme natif, disponible derrière un indicateur expérimental sur certains navigateurs au moment de la rédaction, a permis de retirer une bonne partie de cette logique, en particulier la synchronisation de l’état de focus par défaut, gérée nativement par le navigateur plutôt que par le script.
Ce qu’il ne faut pas en attendre pour l’instant
La disponibilité de ce mécanisme reste inégale d’un navigateur à l’autre à ce jour, ce qui exclut de s’y appuyer comme seule solution de navigation sur un formulaire public. La pratique la plus sûre consiste à conserver une gestion manuelle de repli fonctionnelle par défaut, et à activer le mécanisme natif en amélioration progressive lorsqu’il est détecté comme disponible, jamais comme condition indispensable au bon fonctionnement du formulaire.
- Le mécanisme ne remplace pas la nécessité d’un
fieldsetet d’unelegendpour donner du sens à chaque groupe. - Il ne gère pas non plus l’annonce vocale du passage d’un groupe à un autre, qui reste à la charge de la structure sémantique du formulaire.
- Il ne concerne aucun cadre de mise en forme visuelle : la disposition graphique en colonnes ou en grille reste entièrement indépendante de ce mécanisme de focus.
Conseil maison : testez ce mécanisme comme une amélioration, jamais comme un socle. Gardez toujours une gestion de repli qui fonctionne sans lui.
Notion à retenir
Le regroupement de focus imbriqué ne change rien à ce qu’un formulaire doit annoncer sémantiquement, mais il promet de simplifier fortement le code nécessaire à une navigation par flèches cohérente sur des interfaces à sections multiples. Pour un formulaire de commande découpé en étapes ou en groupes de champs liés, cette piste mérite d’être suivie de près, sans pour autant se précipiter à en dépendre tant que sa disponibilité reste partielle.
