Identifiants en double : une petite erreur de balisage aux grandes conséquences

Un attribut id sert à identifier de façon unique un élément dans une page : rien d'autre n'est censé le partager. Lorsque deux éléments partagent un id - souvent à cause d'un composant copié-collé, d'un gabarit d'élément de liste répété, ou d'un CMS qui affiche deux fois le même bloc -, tout code ou balisage faisant référence à cet id devient ambigu : navigateurs et technologies d'assistance retiennent généralement l'élément correspondant qui apparaît en premier dans le DOM, et ignorent silencieusement les autres.

C'était le critère de succès 4.1.1 (Analyse syntaxique) dans les WCAG 2.0 et 2.1 - il faut noter que le 4.1.1 a été entièrement retiré des WCAG 2.2, la tolérance aux erreurs des navigateurs modernes rendant sans objet la plupart des problèmes de validité du balisage. Les identifiants en double, eux, provoquent toujours des défaillances fonctionnelles réelles au titre du 4.1.2 (Nom, rôle et valeur) dès lors que l'identifiant dupliqué sert effectivement à une étiquette, une référence ARIA ou un lien de fragment : le retrait du 4.1.1 ne signifie pas que les doublons sont devenus inoffensifs, seulement que « le HTML n'est pas techniquement valide » a cessé d'être le mode de défaillance qui compte.

Ce que cela casse concrètement

Un <label for="..."> pointant vers un id dupliqué - l'étiquette peut se rattacher au mauvais champ, ou à celui qui vient en premier, laissant l'autre totalement dépourvu d'étiquette du point de vue d'un lecteur d'écran, alors même que le balisage semble correct au premier coup d'œil.

<!-- Deux champs dans la page, tous deux id="email" après un copier-coller -->
<label for="email">E-mail de facturation</label>
<input id="email" name="billing_email">

<label for="email">E-mail de livraison</label>
<input id="email" name="shipping_email">
<!-- Les deux étiquettes peuvent se rattacher au PREMIER champ seulement -->

Les attributs ARIA comme aria-labelledby ou aria-describedby qui référencent un id : si celui-ci n'est pas unique, la référence se résout de façon imprévisible, et le nom ou la description annoncés par les technologies d'assistance peuvent ne pas correspondre à ce que voit une personne voyante.

Les liens d'ancrage internes (<a href="#section-2">) : avec un id cible dupliqué, le navigateur se rend à la première correspondance, qui n'est pas forcément celle que le texte du lien annonçait.

Comment le corriger

Rendez chaque id réellement unique à l'échelle de la page entière, et pas seulement à l'intérieur d'un composant. Cela suppose le plus souvent d'examiner les composants affichés plusieurs fois sur une même page (une carte répétée dans une liste, un gabarit de fenêtre modale réutilisé pour plusieurs dialogues) et de remplacer un id écrit en dur par un identifiant intégrant une valeur propre à l'instance : la clé d'un élément en base, ou un suffixe unique généré par le composant.

<!-- Avant : id écrit en dur, cassé dès que le composant se répète -->
<div id="card-title">...</div>

<!-- Après : unique par instance -->
<div id={`card-title-${item.id}`}>...</div>

La correction est mécanique une fois le problème trouvé, mais facile à manquer visuellement, puisque rien ne paraît anormal à l'écran : elle ne se manifeste que comme une défaillance fonctionnelle, pour la fonctionnalité dépendant des technologies d'assistance qui s'appuie sur la référence cassée.

Références officielles

• Deque University : duplicate-id
• Technique W3C F77
• Technique W3C H93