For each web page, is the generated source code valid according to the specified document type?
A W3C validator that reports 47 errors on your page is 47 opportunities for a screen reader to encounter code it interprets differently from what you intended. Assistive technologies rely on DOM structure: unclosed tags, duplicate id values, or duplicate attributes can cause erratic behavior — disorderly navigation, incorrect announcements, ignored elements.
This criterion requires that generated source code be valid according to the document type declaration. In HTML5, that means five concrete rules: tags, attributes, and attribute values follow the writing conventions; nesting is compliant (no <p> containing a <div>); each open tag is properly closed; each id value is unique on the page; no attribute is duplicated on the same element.
The reference tool is the W3C Nu Markup Checker, accessible directly from the web-a11y extension in the "Check" menu. It analyzes the generated DOM—not the static source—which is crucial for React, Vue, or Angular applications that build HTML in JavaScript.
Invalid code does not always mean an inaccessible site. But it is the only way to ensure it is not.
Un test to check the validity of the source code
Validity of source code
- Open the page to test in your browser.
- In the web-a11y extension, "Check" menu, activate "W3C Nu markup checker (all frames)".
- In the validator results page, verify these five points:
- Tags, attributes, and attribute values conform to HTML specifications.
- Tag nesting is correct (e.g., no
<p>containing a<div>). - All open tags are properly closed.
- No
idattribute value appears twice on the same page. - No attribute is duplicated on any single HTML element.
- If all five conditions are met, the test is validated. A single error on any of these points is enough to fail the test.
Examples
❌ Non-compliant : Duplicate id attribute and duplicate attribute on the same element
<nav id="navigation">
<a href="/home" id="link-home">Home</a>
<a href="/contact" id="link-home">Contact</a>
</nav>
<button type="button" type="submit" aria-label="Send">Send</button>Two distinct problems here. The id "link-home" is used twice: a screen reader navigating by landmarks, or a JavaScript script targeting this id, will always reach the first element and ignore the second. The duplicate type attribute on the <button> creates ambiguity: depending on the browser, one of the two will be ignored unpredictably.
✅ Compliant : Valid source code with unique ids and correct attributes
<nav id="main-navigation">
<a href="/home" id="link-home">Home</a>
<a href="/contact" id="link-contact">Contact</a>
</nav>
<button type="submit" aria-label="Send the form">Send</button>Each id is unique, attributes are not duplicated, tags are properly closed. The Nu validator reports no errors. A screen reader targeting #link-contact reaches exactly the intended element, without ambiguity.
❌ Non-compliant : Non-compliant tag nesting
<ul>
<p>Introduction to the list</p>
<li>First item</li>
<li>Second item</li>
</ul>
<p>A paragraph with a <div>block nested</div> inside.</p>A <p> as a direct child of a <ul> is invalid according to HTML specification. A <div> inside a <p> is too. Some browsers silently correct these errors by restructuring the DOM, but not all in the same way. The actual DOM can then differ from what the developer wrote, with unpredictable consequences for screen reader navigation.
Tips and pitfalls
⚠️ Validating static source instead of generated DOM
Pasting the HTML file into validator.w3.org is not enough for a SPA or a page with JavaScript hydration. Criterion 8.2 concerns generated source code, that is, the DOM as it exists in the browser after scripts execute. Use the Nu Checker via the web-a11y extension or via the "Check serialized DOM of current page" option—not the static source.
⚠️ Confusing warnings and errors in the Nu report
The Nu Checker distinguishes errors (specification violations) from warnings (recommendations). Only errors fail criterion 8.2. A warning about an unrecognized aria-* attribute or experimental usage does not constitute a failure under RGAA.
💡 The title attribute on a non-interactive element does not invalidate 8.2
A common practice in auditing is to flag the title attribute on a <span> or <p> as a validation error. This is incorrect. The title attribute is a global attribute in HTML, legally usable on any element. Its use does not invalidate criterion 8.2. However, its value as an accessible alternative can be challenged through other criteria.
⚠️ Web components and custom data-* attributes
The data-* attributes are valid in HTML5 and trigger no errors in the Nu Checker. Conversely, invented attributes without a prefix (<div myattr="value">) are invalid. Verify that your React or Vue components do not inject non-standard attributes into the final DOM.
⚠️ WCAG 4.1.1 obsolete since WCAG 2.2, but RGAA 4.1.2 maintains the criterion
The WCAG 4.1.1 Parsing success criterion was marked obsolete in WCAG 2.2 because modern browsers better handle parsing errors. RGAA 4.1.2 nevertheless maintains criterion 8.2 in its framework. In the context of French RGAA conformance auditing, the criterion remains applicable and enforceable.
Frequently asked questions
How to handle HTML attributes auto-generated by Angular or React for RGAA 8.2?
Only the final DOM counted by the Nu Checker is relevant. Attributes internal to frameworks (_ngcontent-xxx, data-reactid) are typically valid or ignored by the validator. If errors appear, they are real and must be corrected. A duplicate id generated by a reused component multiple times on the same page is a common error—each instance must produce a unique id.
How many W3C validation errors are tolerated to satisfy RGAA criterion 8.2?
Zero. Criterion 8.2 provides no tolerance threshold: code is either valid or it is not. In practice, during an audit, some errors from third-party scripts (analytics, live chat) can be documented as outside the scope if they are not controllable by the team. But this exception must be explicitly justified in the audit report.
How to quickly audit conformance to RGAA criterion 8.2 on an existing page?
Most direct method: open the page in Chrome or Firefox, activate the web-a11y extension, "Check" menu → "W3C Nu markup checker (all frames)". You get the report on the live DOM in seconds. Alternative without extension: paste the URL into https://validator.w3.org/nu/ and select "Check by address"—but verify that the page is publicly accessible and that the static DOM matches the rendered DOM.
What impact does a double tag closure have on RGAA 8.2 validation?
Yes. An orphan closing tag (without a corresponding opening) or an opening without closure are parsing errors under criterion 8.2. Browsers often correct these errors, but the reconstructed DOM can differ from the developer's intention. The Nu Checker reports them systematically.
How do source code validation errors in RGAA 8.2 affect screen readers?
It is concrete. A duplicate id on two elements causes aria-labelledby to point to the wrong element. Duplicate ARIA attributes (aria-label written twice) can be ignored or interpreted inconsistently depending on the screen reader. Invalid nesting can produce a DOM restructured by the browser that the screen reader traverses in an unexpected order. These are not theoretical cases—they are errors found in production audits.