Is each web page defined by a document type?
Without a DOCTYPE declaration, the browser switches to quirks mode — a compatibility mode inherited from the 1990s where each rendering engine applies its own non-standardized rules. The result: a potentially malformed DOM tree that screen readers and other assistive technologies attempt to interpret without any guarantee of consistency.
The DOCTYPE tells the browser which HTML grammar to use to parse the document. In HTML5, the declaration is minimal: <!DOCTYPE html>. Five words. No URL, no system identifier — the W3C deliberately designed a declaration that is memorable and backward-compatible with existing rendering engines.
Position matters as much as presence. The DOCTYPE must appear before the <html> tag — ideally as the very first line of the file. A syntactically valid DOCTYPE preceded by a comment, whitespace, or an invisible UTF-8 BOM is ignored by most browsers: the page falls back to quirks mode without any warning.
3 tests to verify the declaration of a valid document type
Presence and validity of DOCTYPE
- Open the raw page source (Ctrl+U or "View page source" — not DevTools).
- Verify that the very first instruction in the document is a DOCTYPE declaration, for example
<!DOCTYPE html>. - Verify that this declaration is positioned before the
<html>tag. - Verify that the declaration is syntactically valid (for HTML5:
<!DOCTYPE html>; for HTML 4.01 or XHTML: the complete and correct DOCTYPE string).
Test validated if all three conditions are met. Test failed if the DOCTYPE is missing, invalid, or placed after <html>.
Presence and validity of DOCTYPE (continued 1)
Methodology identical to test 8.1.1. Apply the same procedure to the audited page:
- Verify the presence of a DOCTYPE declaration at the very beginning of the document (before
<html>). - Verify that the declaration is valid.
Test validated if both conditions are met.
Presence and validity of DOCTYPE (continued 2)
Methodology identical to test 8.1.1. Apply the same procedure to the audited page:
- Verify the presence of a DOCTYPE declaration at the very beginning of the document (before
<html>). - Verify that the declaration is valid.
Test validated if both conditions are met.
Examples
❌ Non-compliant : HTML page without DOCTYPE declaration
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Home - My website</title>
</head>
<body>
<h1>Welcome</h1>
<p>Page content.</p>
</body>
</html>The absence of DOCTYPE switches the browser to quirks mode. CSS rules apply unpredictably depending on the rendering engine, and certain browser/screen reader combinations may construct an incoherent accessibility tree. Test 8.1.1 fails immediately.
✅ Compliant : HTML5 page with valid DOCTYPE in first position
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Home - My website</title>
</head>
<body>
<h1>Welcome</h1>
<p>Page content.</p>
</body>
</html><!DOCTYPE html> is the first instruction in the file, before even <html>. The browser parses the page in standards mode: CSS applies according to specifications, and assistive technologies receive a coherent DOM tree. Tests 8.1.1, 8.1.2, and 8.1.3 are validated.
Tips and pitfalls
⚠️ DevTools display a reconstructed DOM, not the raw source
This is the most common mistake when auditing this criterion. When you inspect a page in the browser's DevTools, the displayed DOM is the result of parsing — it includes automatic corrections. A missing DOCTYPE in the source may leave no visible trace in the inspector. Always use Ctrl+U or the W3C Nu validator to audit this criterion.
⚠️ An invisible UTF-8 BOM can invalidate a correct DOCTYPE
A file saved with BOM (Byte Order Mark) contains three invisible bytes before the first displayed character. These bytes precede the DOCTYPE in the HTTP stream, moving it from its mandatory position. The browser switches to quirks mode without any visible warning. Configure your editor to save as UTF-8 without BOM.
💡 In HTML5, <!DOCTYPE html> is the only declaration to use
Long HTML 4.01 doctypes (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">) and XHTML are valid in the sense of criterion 8.1, but obsolete since 2014. For all new development, <!DOCTYPE html> (case-insensitive) is the modern, valid, and unambiguous declaration.
⚠️ Each HTML document loaded in an iframe must have its own DOCTYPE
An iframe that loads a standalone HTML document (via src attribute) is audited independently. This document must carry its own DOCTYPE declaration. Conversely, an iframe whose content is dynamically injected via srcdoc inherits the parsing context of the attribute itself — verify that the injected content still includes a DOCTYPE.
⚠️ Partial HTML fragments are not covered
Criterion 8.1 applies to complete web pages, not HTML fragments returned by AJAX calls or included via partial server components. If your application assembles fragments on the server side, it is the final HTML document delivered to the browser that must have a DOCTYPE — check the complete HTTP response, not individual fragments.
Frequently asked questions
What is the case rule for <!DOCTYPE html> according to RGAA criteria?
No. <!DOCTYPE html>, <!doctype html>, and <!DOCTYPE HTML> are all equivalent in HTML5. The HTML5 specification explicitly states that the declaration is case-insensitive. By convention, we write <!DOCTYPE html> with DOCTYPE in uppercase — but this is a stylistic convention, not a technical requirement.
How do I quickly audit RGAA criterion 8.1 on a production page?
Two reliable methods. First method: Ctrl+U to display the raw source — the DOCTYPE must be the very first line, with nothing before it. Second method: submit the URL to the W3C Nu validator (validator.w3.org/nu) — a missing or invalid DOCTYPE generates an explicit error at the top of the report. Do not use the DevTools inspector for this criterion: the displayed DOM is reconstructed after parsing and masks source errors.
What alternative doctypes to HTML5 are acceptable to satisfy RGAA criterion 8.1?
Yes, strictly speaking, criterion 8.1 — a correctly written and positioned XHTML 1.0 Strict or HTML 4.01 Transitional DOCTYPE validates the test. But these declarations are obsolete, lengthy, and prone to typos. If you audit an older site with a valid XHTML doctype, criterion 8.1 is compliant. If you develop a new project, <!DOCTYPE html> is the only reasonable declaration.
How does RGAA criterion 8.1 apply to pages generated by React, Next.js, or Vue?
Yes. What matters is the HTML received by the browser, not the framework's source code. In Next.js, the DOCTYPE is managed in _document.tsx; in Vite or Create React App, in the index.html file. Check the final HTTP response — especially for server-rendered (SSR) or static (SSG) pages where the DOCTYPE must be present from the first byte delivered.
Why is a missing DOCTYPE still blocking for RGAA even if the site displays correctly?
This is the classic audit objection — and it doesn't hold. Criterion 8.1 is binary: DOCTYPE present and valid, or non-compliant. The fact that the site "works" visually in quirks mode guarantees nothing for assistive technologies, nor for less tolerant browsers. Quirks mode can produce inconsistencies on certain browser/screen reader combinations — precisely those used by people with disabilities.