EN 301 549 Chapter 9 is the web clause of the European ICT accessibility standard. It requires a web page to satisfy every WCAG Level A and AA success criterion, one clause per criterion, plus the five WCAG conformance requirements in clause 9.6. In v3.2.1, the version cited in the Official Journal today, that means the 50 criteria of WCAG 2.1 (ETSI EN 301 549 v3.2.1, clause 9). In V4.1.1, published in September 2026, it means the 55 criteria of WCAG 2.2, and a new clause 9.7 on user preferences that has no WCAG equivalent (ETSI EN 301 549 V4.1.1, clauses 9.0 to 9.7).
So if your site meets WCAG 2.1 AA, it meets Chapter 9 of v3.2.1. The standard says exactly that in clause 9.0. The parts worth reading closely are the edges: what counts as a web page, what 9.6 asks of a whole checkout flow, and what 9.7 says about your CSS.
Chapter 9 is the part of EN 301 549 that a website under the European Accessibility Act or the Web Accessibility Directive is measured against.
What does EN 301 549 Chapter 9 contain?
Eight sub-clauses. Here is the V4.1.1 layout:
| Clause | Content | Normative? |
|---|---|---|
| 9.0 | General: scope, WCAG equivalence, how "satisfies" works | No (informative) |
| 9.1 | Perceivable: WCAG 1.1.1 to 1.4.13 | Yes |
| 9.2 | Operable: WCAG 2.1.1 to 2.5.8 | Yes |
| 9.3 | Understandable: WCAG 3.1.1 to 3.3.8 | Yes |
| 9.4 | Robust: WCAG 4.1.2 and 4.1.3 | Yes |
| 9.5 | Table 9.1, a list of the 31 WCAG 2.2 AAA criteria | No (informative) |
| 9.6 | The five WCAG conformance requirements at Level AA | Yes |
| 9.7 | User preferences for web pages (new in V4.1.1) | Yes |
Each clause in 9.1 to 9.4 is one sentence. Clause 9.1.1.1 reads, in full: "Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content." The other 54 follow the same pattern.
How do Chapter 9 clause numbers map to WCAG?
Put "9." in front of the WCAG number. WCAG 1.4.3 Contrast (minimum) is clause 9.1.4.3. WCAG 2.4.7 Focus visible is 9.2.4.7. WCAG 4.1.2 Name, role, value is 9.4.1.2.
To keep that mapping intact, the standard inserts "Void" clauses where WCAG has a AAA criterion. Clause 9.1.4.6 is Void because WCAG 1.4.6 Contrast (enhanced) is AAA. Note 5 of clause 9.0 explains that the Void entries exist "to maintain alignment with the numbering" of WCAG. V4.1.1 has 14 of them in clauses 9.1 to 9.4. v3.2.1 had 5.
One Void is different. Clause 9.4.1.1 used to be Parsing, and in V4.1.1 it is Void because WCAG 2.2 removed 4.1.1 Parsing. The note under it quotes W3C's reason: the problems it targeted "either no longer exist or are addressed by other criteria" (W3C WCAG 2.2). If your audit reports still carry a column of 4.1.1 failures for duplicate IDs, that column goes away under V4.1.1. Under v3.2.1 it is still a clause.
This numbering is also why clauses 10 and 11 line up. Clause 10.1.4.3 and clause 11.1.4.3 are both contrast, for documents and software.
Is meeting WCAG enough to meet Chapter 9?
For clauses 9.1 to 9.4 and 9.6, yes. Clause 9.0 states the equivalence for three WCAG versions:
- WCAG 2.2 Level AA "is equivalent to conforming with all of clauses 9.1 to 9.4" and clause 9.6 (V4.1.1).
- WCAG 2.1 AA covers the same, except the six clauses that came from WCAG 2.2: 9.2.4.11, 9.2.5.7, 9.2.5.8, 9.3.2.6, 9.3.3.7 and 9.3.3.8.
- WCAG 2.0 AA covers a shorter list again, without the 2.1 additions such as reflow and text spacing.
Clause 9.7 is outside all three. A site can conform to WCAG 2.2 AA and still fail V4.1.1 Chapter 9 because of one stylesheet rule. More on that below.
Clause 9.0 also explains how to read "satisfies". A criterion that sets a condition on a feature is satisfied when the page doesn't have that feature. The standard's own example: a page with no pre-recorded audio in synchronised media automatically meets 9.1.2.2 captions. So a page with no video isn't "partially conformant" on media. It passes those clauses.
What counts as a web page in EN 301 549?
More than a marketing site. Note 1 of clause 9.0 says websites are evaluated as individual pages, and that web applications, "including mobile web applications", are covered because the definition of a web page "is quite broad and covers all web content types". Your React single-page app is a set of web pages for Chapter 9.
V4.1.1 adds two boundaries that v3.2.1 didn't spell out.
The first is wording. v3.2.1 says "Where ICT is a web page". V4.1.1 says "Where ICT is, or includes, a web page". A product that bundles a web interface with something else, say a kiosk running a browser, now clearly picks up Chapter 9 for the web part.
The second is web views inside apps. Note 3 of clause 9.0 says a web view embedded in a native mobile app does not meet the definition of a web page, so clause 11 (software) applies instead. It is blunt about it: "There are no circumstances in which clause 9 requirements and the corresponding clause 11 requirements are both applicable." If your app's settings screen is a web view, test it against clause 11. Our post on EN 301 549 for mobile apps covers what that means.
Downloadable files sit outside Chapter 9 too. A PDF behind a download link is clause 10, which the Chapter 10 explainer covers.
What does clause 9.6 require?
The five WCAG conformance requirements, copied in: conformance level, full pages, complete processes, accessibility-supported technologies, and non-interference. Note 1 of 9.6 says they "are to be applied when checking conformance of all requirements in clauses 9.1 to 9.4". They are not a separate checklist you tick at the end.
Two of them change how you scope a test.
Full pages. Conformance is for the whole page and "cannot be achieved if part of a web page is excluded" (Note 3). A third-party chat widget or cookie banner is part of the page. You can't carve it out of the claim because you didn't write it.
Complete processes. If a page is one step in a sequence, every step has to conform. W3C's example is a shop: all pages "from start to finish (checkout)" must conform for any page in that process to conform (W3C WCAG 2.2, conformance requirement 3). A clean product page doesn't count for much if the payment step fails.
This is where I have a firm opinion. Homepage scans miss 9.6. The page that breaks complete processes is usually behind a login or three clicks into a form, and a crawler that only sees public URLs never reaches it. We built authenticated journey scans for that reason. Even then, a scanner tells you which steps have machine-detectable failures. Whether the whole process works with a screen reader is a human test.
What is the new clause 9.7 on user preferences?
It is the one requirement in V4.1.1 Chapter 9 that isn't a WCAG criterion. A web page "shall not block the user agent's mode(s) of operation that present the web page according to user preference settings", or explicitly override settings for documented platform accessibility features, "unless this is essential to the information or function of the web page" (ETSI EN 301 549 V4.1.1, clause 9.7).
Note 4 names the CSS property: forced-color-adjust. Note 5 lists the kinds of preferences meant, including colour filters, contrast, text size, pointer size and text cursor.
In code, this is the pattern to look for:
/* Fails the intent of 9.7 unless essential */
body { forced-color-adjust: none; }
That one line turns off Windows high-contrast mode for the whole site. Setting it on a single colour swatch in a product picker, where the colour is the information, is the kind of case the "essential" exception covers. The Annex C test, C.9.7, asks the tester to check each override and decide whether honouring the preference would "fundamentally alter" the page. That's a judgment call, so plan for a person to make it.
How is Chapter 9 tested?
Through Annex C. Every clause from 9.1.1.1 to 9.7 has a matching test, C.9.1.1.1 to C.9.7, and each is typed as an inspection. Most say: check that the page "does not fail" the WCAG criterion "according to WCAG Conformance Requirements stated in clause 9.6". The result can be Pass, Fail, or Not applicable when the page has no relevant content. Clause 9.5 has no test because it is informative (ETSI EN 301 549 V4.1.1, clause C.9). Table A.1 in clause A.2 lists the same clauses as the ones that apply "where ICT is, or includes, a web page". Our Annex C explainer goes through the format.
Automation helps with part of this. Deque's study of real audit data found automated tests identified 57% of issues by volume (Deque). The same post cites the older estimate of 20 to 30%, which counted success criteria rather than issues. Either way, a large share of Chapter 9 needs a person. A rule engine can tell you an image has no alt. It can't tell you alt="chart" fails 9.1.1.1, and it can't judge 9.7's "essential" test. The WCAG checklist lists the criteria with what to check by hand.
Which version of Chapter 9 applies right now?
v3.2.1, with WCAG 2.1. The Commission's AccessibleEU centre said on 7 September 2026 that "the current reference remains EN 301 549 v3.2.1 (2021)" until V4.1.1 is formally cited in the Official Journal (AccessibleEU). When I checked on 9 October 2026, I found no implementing decision citing V4.1.1. The v3.2.1 citation is Commission Implementing Decision (EU) 2021/1339.
My practical advice is to test against WCAG 2.2 AA plus 9.7 now. Everything that passes V4.1.1 Chapter 9 also passes v3.2.1 Chapter 9, except Parsing, which v3.2.1 still lists. The V4.1.1 explainer has the full list of changes.
Frequently asked questions
What is EN 301 549 Chapter 9?
EN 301 549 Chapter 9 is the web clause of the standard. It requires web pages to satisfy the WCAG Level A and AA success criteria (WCAG 2.1 in v3.2.1, WCAG 2.2 in V4.1.1) and the five WCAG conformance requirements in clause 9.6.
Does WCAG 2.2 AA conformance mean I meet Chapter 9?
For clauses 9.1 to 9.4 and 9.6, yes, as clause 9.0 states. V4.1.1 also has clause 9.7 on user preferences, which is not part of WCAG, so you need to check it separately.
Why are some Chapter 9 clauses marked Void?
Void clauses keep the numbering aligned with WCAG. They sit where WCAG has a Level AAA criterion, and in V4.1.1 at 9.4.1.1, where WCAG 2.2 removed Parsing.
Does Chapter 9 apply to mobile apps?
Not to native apps. Mobile web applications in a browser are covered by Chapter 9, but V4.1.1 says web views embedded in a native app fall under clause 11 instead.
Is clause 9.5 (WCAG AAA) required?
No. Clause 9.5 is informative and lists the 31 WCAG 2.2 Level AAA criteria for teams that want to go further. Annex C has no test for it.
Check your pages against Chapter 9
Run a free scan to see which machine-detectable Chapter 9 failures your pages have, with the selector for each one. Then do the manual checks: keyboard through your checkout, turn on forced colours, and listen to the flow with a screen reader. Full conformance needs that human review, and your accessibility statement is where you record what you found.
Pavel Charkasau, founder, wcagc.com. Last updated 9 October 2026.
Sources
- EN 301 549 V4.1.1 (2026-09), ETSI/CEN/CENELEC: clause 9.0 notes 1 to 5; clauses 9.1 to 9.4 including Void clauses and 9.4.1.1; clause 9.5 Table 9.1; clause 9.6 notes 1 to 7; clause 9.7 notes 1 to 5; Table A.1; Annex C clauses C.9.0 to C.9.7. Accessed 9 October 2026.
- EN 301 549 v3.2.1 (2021-03), ETSI/CEN/CENELEC: clause 9, including 9.0, 9.4.1.1 Parsing, 9.5 and 9.6. Accessed 9 October 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation: conformance requirements 1 to 5 and the removal of 4.1.1 Parsing. Accessed 9 October 2026.
- The European accessibility standard EN 301 549 has been updated, AccessibleEU (European Commission), 7 September 2026: v3.2.1 remains the reference until V4.1.1 is cited. Accessed 9 October 2026.
- Commission Implementing Decision (EU) 2021/1339, EUR-Lex: citation of EN 301 549 v3.2.1. Accessed 9 October 2026.
- Automated testing identifies 57% of accessibility issues, Deque: automated coverage by issue volume. Accessed 9 October 2026.