Aller au contenu principal
Mynto
AccessibiliteRGAA 8.2Niveau AÉléments obligatoires

Code source HTML non valide

Le critère RGAA 8.2, niveau A, exige que le code HTML d'une page soit valide selon le type de document déclaré. Des erreurs de syntaxe peuvent déstabiliser les lecteurs d'écran et produire des comportements imprévisibles selon les navigateurs.

C'est quoi

La validation du code HTML vérifie que la structure respecte la spécification HTML : balises ouvertes et fermées dans le bon ordre, attributs uniques, imbrication correcte des éléments, valeurs d'attributs valides.

Les erreurs les plus impactantes pour l'accessibilité :

  • id dupliqués : les références ARIA (aria-labelledby, aria-describedby, for) ciblent un id. Si deux éléments partagent le même id, le comportement est imprévisible selon le navigateur et le lecteur d'écran.
  • Balises mal imbriquées : <ul><p>...</p></ul> crée une structure DOM invalide que les navigateurs corrigent différemment.
  • Éléments interactifs imbriqués : un <a> dans un <button> est invalide et produit des comportements incohérents au clavier.

Les navigateurs tolèrent beaucoup d'erreurs et corrigent à la volée, mais pas toujours de la même façon. Les technologies d'assistance s'appuient sur le DOM corrigé : si deux navigateurs corrigent différemment, l'accessibilité varie selon l'environnement de l'utilisateur.

Qui est touché

  • Les personnes utilisant des lecteurs d'écran : elles sont les plus sensibles aux incohérences du DOM causées par du HTML invalide, en particulier les id dupliqués qui cassent les références ARIA.
  • Les personnes qui naviguent au clavier : un ordre de focus cassé peut résulter d'une mauvaise imbrication des éléments interactifs.

Impact business

L'impact des erreurs HTML sur l'accessibilité est variable selon la nature de l'erreur. La plupart des erreurs mineures ont peu d'effet. Mais les id dupliqués et les imbrications incorrectes d'éléments interactifs peuvent rendre des composants inutilisables par les technologies d'assistance.

Le critère est autant préventif que correctif : un code propre limite les comportements imprévisibles entre navigateurs et lecteurs d'écran.

Sources des chiffres

Comment le détecter

  • Validateur W3C : colle l'URL de ta page sur https://validator.w3.org. Les erreurs "Error" sont à corriger en priorité.
  • Audit Mynto : le scanner lance une validation HTML et signale les erreurs bloquantes pour l'accessibilité (id dupliqués, imbrications invalides, éléments interactifs mal imbriqués).
  • DevTools : dans l'onglet Console, certains navigateurs affichent des avertissements pour les erreurs HTML graves, notamment les id dupliqués.

Comment corriger

Avant - HTML
<!-- id dupliqué : deux éléments distincts portent le même identifiant -->
<p id="info">Livraison gratuite dès 50 euros</p>
...
<button aria-describedby="info">En savoir plus</button>
<span id="info">Mentions légales applicables</span>
Après - HTML
<!-- id uniques : la référence ARIA pointe sans ambiguïté sur le bon élément -->
<p id="info-livraison">Livraison gratuite dès 50 euros</p>
...
<button aria-describedby="info-livraison">En savoir plus</button>
<span id="info-mentions">Mentions légales applicables</span>

Lance la validation sur https://validator.w3.org et traite les erreurs par ordre de gravité :

  1. id dupliqués : renomme chaque id pour le rendre unique dans la page. Mets à jour toutes les références ARIA (aria-labelledby, aria-describedby, for).

  2. Imbrication incorrecte : corrige l'ordre de fermeture des balises. Exemple : "texte" devient "texte".

  3. Éléments invalides dans un contexte : un "

    " dans un "

      " doit devenir un "
    • ".

Sur WordPress, les erreurs HTML viennent souvent des plugins. Identifie le plugin responsable via les erreurs du validateur, puis cherche une mise à jour ou un bug report connu.

Questions fréquentes

WordPress génère-t-il du HTML valide par défaut ?

Le coeur de WordPress génère généralement du HTML valide. Les sources d'erreurs sont les thèmes et les plugins, en particulier les constructeurs de page (Elementor, Divi, Bricks) qui génèrent du HTML complexe. Lance le validateur sur les pages les plus riches en blocs.

WCAG 2.2 a-t-il supprimé le critère sur le parsing HTML ?

Oui. WCAG 2.2 a supprimé le critère 4.1.1 Parsing : il est désormais considéré comme toujours satisfait, car les analyseurs HTML modernes gèrent les erreurs de syntaxe de façon prévisible. Le W3C recommande de le traiter comme satisfait y compris pour les conformités WCAG 2.1 et 2.0. RGAA 4.1 conserve néanmoins le critère 8.2 avec ses propres tests. En France, c'est le RGAA qui fait référence pour la conformité légale.

Dois-je viser zéro erreur au validateur W3C ?

Vise zéro erreur "Error". Les "Warning" et les erreurs liées à des usages ARIA non reconnus par le validateur HTML peuvent être acceptables avec justification. Priorise les erreurs qui impactent l'arbre d'accessibilité.

À lire aussi

Cette erreur est-elle sur ton site ?

Lance un audit Mynto gratuit. Tu sauras en quelques minutes si ton site est concerné, sur quelles pages, et avec quel impact.