Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ?
Un validateur W3C qui remonte 47 erreurs sur votre page, c'est 47 occasions pour un lecteur d'écran de se retrouver face à un code qu'il interprète différemment de ce que vous aviez prévu. Les technologies d'assistance s'appuient sur la structure du DOM : des balises mal fermées, des id en doublon ou des attributs dupliqués peuvent provoquer des comportements erratiques — navigation désordonnée, annonces incorrectes, éléments ignorés.
Ce critère impose que le code source généré soit valide selon la déclaration de type de document. En HTML5, cela signifie cinq règles concrètes : les balises, attributs et valeurs d'attributs respectent les règles d'écriture ; l'imbrication est conforme (pas de <p> contenant un <div>) ; chaque balise ouverte est correctement fermée ; chaque valeur id est unique dans la page ; aucun attribut n'est dupliqué sur le même élément.
L'outil de référence est le W3C Nu Markup Checker, accessible directement depuis l'extension web-a11y dans le menu « Check ». Il analyse le DOM généré — pas le source statique — ce qui est crucial pour les applications React, Vue ou Angular qui construisent le HTML en JavaScript.
Code invalide ne veut pas dire site inaccessible dans tous les cas. Mais c'est la seule façon de s'en assurer.
Un test pour contrôler la validité du code source
Validité du code source
- Ouvrez la page à tester dans le navigateur.
- Dans l'extension web-a11y, menu « Check », activez « W3C Nu markup checker (all frames) ».
- Dans la page de résultats du validateur, vérifiez les cinq points suivants :
- Les balises, attributs et valeurs d'attributs sont conformes aux spécifications HTML.
- L'imbrication des balises est correcte (ex : pas de
<p>contenant un<div>). - Toutes les balises ouvertes sont correctement fermées.
- Aucune valeur d'attribut
idn'apparaît deux fois dans la même page. - Aucun attribut n'est dupliqué sur un même élément HTML.
- Si les cinq conditions sont réunies, le test est validé. Une seule erreur sur l'un de ces points suffit à faire échouer le test.
Exemples
❌ Non conforme : Attribut id dupliqué et attribut dupliqué sur le même élément
<nav id="navigation">
<a href="/accueil" id="lien-accueil">Accueil</a>
<a href="/contact" id="lien-accueil">Contact</a>
</nav>
<button type="button" type="submit" aria-label="Envoyer">Envoyer</button>Deux problèmes distincts ici. L'id « lien-accueil » est utilisé deux fois : un lecteur d'écran qui navigue par repères, ou un script JavaScript qui cible cet id, atteindra toujours le premier élément et ignorera le second. L'attribut type dupliqué sur le <button> crée une ambiguïté : selon le navigateur, l'un des deux sera ignoré de façon imprévisible.
✅ Conforme : Code source valide avec id uniques et attributs corrects
<nav id="navigation-principale">
<a href="/accueil" id="lien-accueil">Accueil</a>
<a href="/contact" id="lien-contact">Contact</a>
</nav>
<button type="submit" aria-label="Envoyer le formulaire">Envoyer</button>Chaque id est unique, les attributs ne sont pas dupliqués, les balises sont correctement fermées. Le validateur Nu ne remonte aucune erreur. Un lecteur d'écran qui cible #lien-contact atteindra exactement l'élément attendu, sans ambiguïté.
❌ Non conforme : Imbrication de balises non conforme
<ul>
<p>Introduction à la liste</p>
<li>Premier élément</li>
<li>Deuxième élément</li>
</ul>
<p>Un paragraphe avec un <div>bloc imbriqué</div> à l'intérieur.</p>Un <p> enfant direct d'un <ul> est invalide selon la spécification HTML. Un <div> dans un <p> l'est aussi. Certains navigateurs corrigent silencieusement ces erreurs en restructurant le DOM, mais pas tous de la même façon. Le DOM réel peut alors différer de ce que le développeur a écrit, avec des conséquences imprévisibles sur la navigation au lecteur d'écran.
Astuces et pièges
⚠️ Valider le source statique au lieu du DOM généré
Coller le fichier HTML dans validator.w3.org ne suffit pas pour une SPA ou une page avec hydratation JavaScript. Le critère 8.2 porte sur le code source généré, c'est-à-dire le DOM tel qu'il existe dans le navigateur après exécution des scripts. Utilisez le Nu Checker via l'extension web-a11y ou via l'option « Check serialized DOM of current page » — pas le source statique.
⚠️ Confondre avertissements et erreurs dans le rapport Nu
Le Nu Checker distingue les erreurs (violations de spécification) des avertissements (recommandations). Seules les erreurs font échouer le critère 8.2. Un avertissement sur un attribut aria-* non reconnu ou sur un usage expérimental ne constitue pas un échec au sens du RGAA.
💡 L'attribut title sur un élément non-interactif n'invalide pas 8.2
Un usage répandu en audit consiste à signaler l'attribut title sur un <span> ou un <p> comme une erreur de validation. C'est incorrect. L'attribut title est un attribut global en HTML, utilisable légalement sur n'importe quel élément. Son usage n'invalide pas le critère 8.2. En revanche, sa valeur comme alternative accessible peut être contestée via d'autres critères.
⚠️ Les composants web et les attributs custom data-*
Les attributs data-* sont valides en HTML5 et ne déclenchent aucune erreur dans le Nu Checker. En revanche, des attributs inventés sans préfixe (<div myattr="valeur">) sont invalides. Vérifiez que vos composants React ou Vue n'injectent pas d'attributs non standard dans le DOM final.
⚠️ WCAG 4.1.1 obsolète depuis WCAG 2.2, mais RGAA 4.1.2 maintient le critère
Le critère de succès WCAG 4.1.1 Parsing a été marqué obsolète dans WCAG 2.2, car les navigateurs modernes gèrent mieux les erreurs de parsing. Le RGAA 4.1.2 maintient néanmoins le critère 8.2 dans son référentiel. En contexte d'audit de conformité RGAA français, le critère reste applicable et opposable.
Questions fréquentes
Comment gérer les attributs HTML auto-générés par Angular ou React pour RGAA 8.2 ?
Seul le DOM final compté par le Nu Checker est pertinent. Les attributs internes aux frameworks (_ngcontent-xxx, data-reactid) sont généralement valides ou ignorés par le validateur. Si des erreurs apparaissent, elles sont réelles et doivent être corrigées. Un id dupliqué généré par un composant réutilisé plusieurs fois sur la même page est une erreur courante — chaque instance doit produire un id unique.
Combien d'erreurs de validation W3C sont tolérées pour satisfaire le critère RGAA 8.2 ?
Zéro. Le critère 8.2 ne prévoit pas de seuil de tolérance : le code est valide ou il ne l'est pas. En pratique, lors d'un audit, certaines erreurs issues de scripts tiers (analytics, chat en ligne) peuvent être documentées comme hors périmètre si elles ne sont pas maîtrisables par l'équipe. Mais cette exception doit être explicitement justifiée dans le rapport d'audit.
Comment auditer rapidement la conformité au critère RGAA 8.2 sur une page existante ?
Méthode la plus directe : ouvrez la page dans Chrome ou Firefox, activez l'extension web-a11y, menu « Check » → « W3C Nu markup checker (all frames) ». Vous obtenez le rapport sur le DOM live en quelques secondes. Alternative sans extension : copiez l'URL dans https://validator.w3.org/nu/ et sélectionnez « Check by address » — mais vérifiez que la page est accessible publiquement et que le DOM statique correspond au DOM rendu.
Quel impact une double fermeture de balise a-t-elle sur la validation RGAA 8.2 ?
Oui. Une balise de fermeture orpheline (sans ouverture correspondante) ou une ouverture sans fermeture sont des erreurs de parsing au sens du critère 8.2. Le navigateur corrige souvent ces erreurs, mais le DOM reconstruit peut différer de l'intention du développeur. Le Nu Checker les signale systématiquement.
Comment les erreurs de validation du code source RGAA 8.2 affectent-elles les lecteurs d'écran ?
C'est concret. Un id dupliqué sur deux éléments fait que aria-labelledby pointe sur le mauvais élément. Des attributs ARIA dupliqués (aria-label écrit deux fois) peuvent être ignorés ou interprétés de façon incohérente selon le lecteur d'écran. L'imbrication invalide peut produire un DOM restructuré par le navigateur que le lecteur d'écran traverse dans un ordre inattendu. Ce ne sont pas des cas théoriques — ce sont les erreurs trouvées en audit de production.