Chaque page web est-elle définie par un type de document ?
Sans déclaration DOCTYPE, le navigateur bascule en mode quirks — un mode de compatibilité hérité des années 1990 où chaque moteur de rendu applique ses propres règles non standardisées. Le résultat : un arbre DOM potentiellement malformé, que les lecteurs d’écran et autres technologies d’assistance tentent d’interpréter sans garantie de cohérence.
Le DOCTYPE indique au navigateur quelle grammaire HTML utiliser pour analyser le document. En HTML5, la déclaration est minimaliste : <!DOCTYPE html>. Cinq mots. Pas d’URL, pas d’identifiant de système — le W3C a délibérément conçu une déclaration mémorisable et rétrocompatible avec les moteurs de rendu existants.
L’ordre compte autant que la présence. Le DOCTYPE doit apparaître avant la balise <html> — idéalement en toute première ligne du fichier. Un DOCTYPE syntaxiquement valide mais précédé d’un commentaire, d’un espace ou d’un BOM UTF-8 invisible est ignoré par la plupart des navigateurs : la page retombe en mode quirks sans le moindre avertissement.
3 tests pour vérifier la déclaration d'un type de document valide
Présence et validité du DOCTYPE
- Ouvrez le code source brut de la page (Ctrl+U ou « Afficher la source de la page » — pas les DevTools).
- Vérifiez que la toute première instruction du document est une déclaration DOCTYPE, par exemple
<!DOCTYPE html>. - Vérifiez que cette déclaration est positionnée avant la balise
<html>. - Vérifiez que la déclaration est syntaxiquement valide (pour HTML5 :
<!DOCTYPE html>; pour HTML 4.01 ou XHTML : la chaîne DOCTYPE complète et correcte).
Test validé si les trois conditions sont réunies. Test échoué si le DOCTYPE est absent, invalide ou placé après <html>.
Présence et validité du DOCTYPE (suite 1)
Méthodologie identique au test 8.1.1. Appliquez la même procédure sur la page auditée :
- Vérifiez la présence d’une déclaration DOCTYPE en tout début de document (avant
<html>). - Vérifiez que la déclaration est valide.
Test validé si les deux conditions sont réunies.
Présence et validité du DOCTYPE (suite 2)
Méthodologie identique au test 8.1.1. Appliquez la même procédure sur la page auditée :
- Vérifiez la présence d’une déclaration DOCTYPE en tout début de document (avant
<html>). - Vérifiez que la déclaration est valide.
Test validé si les deux conditions sont réunies.
Exemples
❌ Non conforme : Page HTML sans déclaration DOCTYPE
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Accueil - Mon site</title>
</head>
<body>
<h1>Bienvenue</h1>
<p>Contenu de la page.</p>
</body>
</html>L’absence de DOCTYPE fait basculer le navigateur en mode quirks. Les règles CSS s’appliquent de manière imprévisible selon le moteur de rendu, et certaines combinaisons navigateur/lecteur d’écran peuvent construire un arbre d’accessibilité incohérent. Le test 8.1.1 échoue immédiatement.
✅ Conforme : Page HTML5 avec DOCTYPE valide en première position
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Accueil - Mon site</title>
</head>
<body>
<h1>Bienvenue</h1>
<p>Contenu de la page.</p>
</body>
</html><!DOCTYPE html> est la première instruction du fichier, avant même <html>. Le navigateur analyse la page en mode standard : les CSS s’appliquent selon les spécifications, et les technologies d’assistance reçoivent un arbre DOM cohérent. Les tests 8.1.1, 8.1.2 et 8.1.3 sont validés.
Astuces et pièges
⚠️ Les DevTools affichent un DOM reconstruit, pas le source brut
C’est l’erreur la plus fréquente en audit de ce critère. Quand vous inspectez une page dans les DevTools du navigateur, le DOM affiché est le résultat du parsing — il inclut des corrections automatiques. Un DOCTYPE absent dans le source peut ne laisser aucune trace visible dans l’inspecteur. Utilisez toujours Ctrl+U ou le validateur W3C Nu pour auditer ce critère.
⚠️ Un BOM UTF-8 invisible peut invalider un DOCTYPE correct
Un fichier sauvegardé avec BOM (Byte Order Mark) contient trois octets invisibles avant le premier caractère affiché. Ces octets précèdent le DOCTYPE dans le flux HTTP, ce qui le déplace de sa position obligatoire. Le navigateur bascule en mode quirks sans aucun avertissement visible. Configurez votre éditeur pour sauvegarder en UTF-8 sans BOM.
💡 En HTML5, <!DOCTYPE html> est la seule déclaration à utiliser
Les longs doctypes HTML 4.01 (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">) et XHTML sont valides au sens du critère 8.1, mais obsolètes depuis 2014. Pour tout nouveau développement, <!DOCTYPE html> (insensible à la casse) est la déclaration moderne, valide et sans équivoque.
⚠️ Chaque document HTML chargé dans une iframe doit avoir son propre DOCTYPE
Une iframe qui charge un document HTML autonome (via attribut src) est auditée indépendamment. Ce document doit porter sa propre déclaration DOCTYPE. En revanche, une iframe dont le contenu est injecté dynamiquement via srcdoc hérite du contexte de parsing de l’attribut lui-même — vérifiez que le contenu injecté inclut quand même un DOCTYPE.
⚠️ Les fragments HTML partiels ne sont pas concernés
Le critère 8.1 s’applique aux pages web complètes, pas aux fragments HTML retournés par des appels AJAX ou inclus via des composants serveur partiels. Si votre application assemble des fragments côté serveur, c’est le document HTML final livré au navigateur qui doit avoir un DOCTYPE — vérifiez la réponse HTTP complète, pas les fragments individuels.
Questions fréquentes
Quelle est la règle de casse pour <!DOCTYPE html> selon les critères RGAA ?
Non. <!DOCTYPE html>, <!doctype html> et <!DOCTYPE HTML> sont tous équivalents en HTML5. La spécification HTML5 précise explicitement que la déclaration est insensible à la casse. Par convention, on écrit <!DOCTYPE html> avec DOCTYPE en majuscules — mais c’est une convention stylistique, pas une exigence technique.
Comment auditer le critère RGAA 8.1 rapidement sur une page en production ?
Deux méthodes fiables. Première méthode : Ctrl+U pour afficher la source brute — le DOCTYPE doit être la toute première ligne, sans rien avant. Deuxième méthode : soumettez l’URL au validateur W3C Nu (validator.w3.org/nu) — une absence ou un DOCTYPE invalide génère une erreur explicite en haut du rapport. N’utilisez pas l’inspecteur des DevTools pour ce critère : le DOM affiché est reconstruit après parsing et masque les erreurs de source.
Quels doctypes alternatifs à HTML5 sont acceptables pour satisfaire le critère RGAA 8.1 ?
Oui, au sens strict du critère 8.1 — un DOCTYPE XHTML 1.0 Strict ou HTML 4.01 Transitional correctement écrit et positionné valide le test. Mais ces déclarations sont obsolètes, longues, et sources d’erreurs de frappe. Si vous auditez un site ancien avec un doctype XHTML valide, le critère 8.1 est conforme. Si vous développez un nouveau projet, <!DOCTYPE html> est la seule déclaration raisonnable.
Comment le critère RGAA 8.1 s'applique-t-il aux pages générées par React, Next.js ou Vue ?
Oui. Ce qui compte, c’est le HTML reçu par le navigateur, pas le code source du framework. Dans Next.js, le DOCTYPE est géré dans _document.tsx ; dans Vite ou Create React App, dans le fichier index.html. Vérifiez la réponse HTTP finale — notamment pour les pages à rendu serveur (SSR) ou statique (SSG) où le DOCTYPE doit être présent dès le premier octet livré.
Pourquoi un DOCTYPE absent reste-t-il bloquant pour le RGAA même si le site s'affiche correctement ?
C’est l’objection classique en audit — et elle ne tient pas. Le critère 8.1 est binaire : DOCTYPE présent et valide, ou non-conforme. Le fait que le site « fonctionne » visuellement en mode quirks ne garantit rien pour les technologies d’assistance, ni pour les navigateurs moins tolérants. Le mode quirks peut produire des incohérences sur certaines combinaisons navigateur/lecteur d’écran, précisément celles utilisées par les personnes en situation de handicap.