EN 301 549 functional performance: clause 4 explained

Clause 4 of EN 301 549 holds eleven statements about what a person has to be able to do with your product: use it without vision, without hearing, without perception of colour, with limited reach, without vocal capability, and so on through privacy at 4.2.11. They describe outcomes, not techniques. Nothing in clause 4 tells you to add an aria-label.

The part most people have wrong is their status. In V3.2.1, the version cited in the Official Journal today, clause 4 carries no weight in a conformance claim. Annex C.4 says so in one sentence: "Clause 4 is informative and does not contain requirements that require testing" (ETSI EN 301 549 V3.2.1). In V4.1.1, published this month, the same eleven items are renamed Functional Performance Criteria, every one of them gains the word "shall", Annex C gives each a pass/fail test, and they appear as the first eleven rows of the table used to evaluate a product against the European Accessibility Act (ETSI EN 301 549 V4.1.1). The statements you could safely skim became requirements you have to assess.

What are the EN 301 549 functional performance criteria?

Eleven user-outcome clauses at 4.2.1 to 4.2.11. The list has been stable across versions:

Each is self-scoping, so it opens with a condition. Clause 4.2.5 only bites "where ICT provides auditory modes of operation", and 4.2.8 only where the ICT is stationary, free-standing or installed. A ticketing machine answers all eleven; a web app answers far fewer.

Clause 4.2.11 is the one teams read twice. Privacy says that if you ship an accessibility feature, using it must not cost the user privacy that other users keep. The standard's own example is not reading masked characters aloud through a kiosk speaker. I have never seen that requirement in a ticket queue, and it is the single most common way a well-meant accessibility mode betrays the person using it.

Were the functional performance statements ever testable?

Not in V3.2.1. The wording gives it away before the annex does. Clause 4.2.1 there reads "the ICT provides at least one mode of operation that does not require vision" — present tense, descriptive, no modal verb. Clause 14 of that version sets the rule for what counts: "Conformance to the present document is achieved by meeting all the applicable requirements, these are clauses containing the word 'shall'." No "shall" in clause 4, so no requirement, and Annex C.4 confirms it with the informative sentence quoted above.

That is why EN 301 549 conformance reports written against V3.2.1 have a row for every clause from 5.1.2.1 onward and nothing for clause 4. The auditor was not being lazy. There was no test to run. What clause 4 did instead was explain why the testable requirements exist, through the mapping table in Annex B, where each requirement in clauses 5 to 13 is marked P for a primary relationship to a functional performance statement or S for a secondary one.

What changed in EN 301 549 V4.1.1?

Start with the modal verb. Every criterion in 4.2 now uses "shall", so clause 4.2.1 reads "the ICT shall provide at least one mode of operation that does not require vision". Under the same clause 14 rule, that makes it an applicable requirement.

Then the tests arrived. Annex C.4 is no longer one sentence. Only C.4.1, covering the introductory clause, stays informative; C.4.2.1 through C.4.2.11 each carry a full procedure, with type of assessment Inspection, a precondition, two checks and a pass/fail result. Check one is "check if the ICT meets all requirements marked with a P or S in column WV of Annex B". Check two is "check if there is evidence that the ICT provides at least one mode of operation that does not require vision". Either one passing is enough.

The third change is the one that reaches your paperwork. Clause A.2 splits EAA evaluation into five tables by what the ICT is, and Table A.5, headed "All ICT", is the last one everybody has to consider. Its first eleven rows are 4.2.1 to 4.2.11, each with its condition and each pointing at its C.4.2.x assessment.

The wording moved too. Clause 4.2.9 now asks that the safe mode be the default, with an advance warning as an option for audiovisual material, and clause 4.2.10 gained a precondition it never had, so it no longer applies unconditionally.

The foreword lists five significant changes since V3.2.1: real-time text and total conversation in clause 6, WCAG 2.2 alignment in clauses 9 to 11, the new Annex ZA, the new Annex ZB, and the new clause A.2. Clause 4 becoming normative is not on that list. If you are diffing versions from the foreword, you will miss it. That is the whole reason this post exists.

V4.1.1 was adopted on 24 August 2026 and is not yet cited in the Official Journal, so V3.2.1 still carries the presumption of conformity (Commission Implementing Decision (EU) 2021/1339). The version timeline is in our V4 post. Report against V3.2.1 today; design against V4.1.1 if your product will still be selling in 2028.

Do the functional performance criteria apply to my website?

Under the Web Accessibility Directive, no. Annex ZA of V4.1.1 holds the two tables that decide conformity for public sector websites and mobile apps, and neither contains a single clause 4 row. Those tables are built from clauses 9, 10 and 11 with some of 5, 6, 7 and 12.

Under the EAA, yes, because Table A.5 applies to all ICT in scope. A web service with no enclosure is out of scope for 4.2.8 and answers the rest wherever its own precondition is met: 4.2.4 and 4.2.5 only if it plays audio, 4.2.6 only if it takes voice input.

For a web-only service, clause 4 rarely changes the work. The C.4.2.x test passes on its first check when the Annex B rows for that column already pass, and those rows are the clause 9 requirements you were doing anyway. Where it does change the work is the hybrid case: a bank with an app and a fleet of ATMs, a retailer with a checkout page and a self-service terminal. There, clause 4 is the row that asks whether the whole thing works for one person end to end, rather than whether each piece passed its own audit. Clause 8 hardware requirements are covered in our post on EN 301 549 beyond the web.

How do the EAA and Section 508 treat the same list?

Both made these criteria binding long before EN 301 549 did.

The EAA has them in Annex I, Section VII, as points (a) to (k), matching 4.2.1 to 4.2.11 item for item. The introduction sets them up as a gap-filler: "when the accessibility requirements, set out in Sections I to VI of this Annex, do not address one or more functions of the design and production of products or the provision of services those functions or means shall be accessible by complying with the related functional performance criteria" (Directive (EU) 2019/882). They can also substitute for a specific technical requirement, but only where the result is equivalent or increased accessibility.

The US Revised 508 Standards do the same with nine criteria in Chapter 3, numbered 302.1 to 302.9. E204.1 states the trigger: where the requirements in Chapters 4 and 5 do not address one or more functions of the ICT, those functions conform to Chapter 3 instead (US Access Board). Nine rather than eleven, because Section 508 has no separate photosensitivity or privacy criterion in that chapter.

So the same eleven user outcomes were legally binding in EU and US law while the European standard that serves them treated them as commentary. V4.1.1 closes that gap. The obligation was already there in the directive. What V4.1.1 adds is a documented way for an auditor to record it.

How do you test clause 4 in practice?

Read the C.4.2.x procedure and take the second check seriously, because the first one is generous. Passing every P and S row in an Annex B column is a strong signal, and it is the route most reports will take. It is also a claim about requirements, not about people.

The second check asks for evidence that the mode actually exists and works. That is a person with a screen reader completing the task, a keyboard-only run through checkout, a session with the audio off. Our scanner will not produce that evidence and no scanner will. Automated testing finds roughly 30% to 57% of accessibility issues (Deque), and clause 4 sits mostly outside that range by design, because it asks about outcomes rather than markup. More on that split in our manual versus automated testing post.

A workable order: run the technical clauses first and fix what has a selector attached, then walk each applicable 4.2.x criterion once as a real task and write the result down against the clause number. The EN 301 549 checklist has the clause structure if you want it open beside the report, and Annex C explains how the pass/fail column works.

Frequently asked questions

What is clause 4 of EN 301 549?

Clause 4 is the functional performance section. It holds eleven criteria at 4.2.1 to 4.2.11 describing what users with different abilities have to be able to do with the ICT, from usage without vision through to privacy, and the user needs behind them are the basis for the technical requirements in clauses 5 to 13.

Are the EN 301 549 functional performance statements testable?

In V3.2.1, no. Annex C.4 states that clause 4 is informative and contains no requirements that require testing. In V4.1.1 they are testable: each criterion uses "shall" and Annex C.4.2.1 to C.4.2.11 give a pass/fail inspection procedure.

What is the difference between clause 4 and clauses 5 to 13?

Clause 4 describes the outcome a user needs; clauses 5 to 13 give the specific technical criteria that deliver it. Annex B maps the two, marking each requirement P for a primary relationship to a functional performance criterion or S for a secondary one.

Do the functional performance criteria apply to a website?

Under the EAA, yes. Table A.5 of V4.1.1 applies to all ICT in scope and opens with clauses 4.2.1 to 4.2.11; only 4.2.8, usage with limited reach, needs physical hardware. Under the Web Accessibility Directive, no. The Annex ZA tables for public sector sites and apps contain no clause 4 rows.

Is EN 301 549 clause 4 the same as Section 508 Chapter 3?

They cover the same ground with different counts. Section 508 has nine functional performance criteria at 302.1 to 302.9, applying under E204.1 where Chapters 4 and 5 do not address a function. EN 301 549 has eleven, adding photosensitive seizure triggers and privacy.

See which clause 9 requirements you already pass

Clause 4 is answered largely by the technical rows underneath it, and on a web product most of those are clause 9. Run a free scan to get the machine-detectable ones with the exact selector, fix those, then walk the eleven criteria yourself as real tasks and record what a person actually experienced. That second part is the audit. The scan just stops you paying an auditor to find a missing form label.

Pavel Charkasau, founder, wcagc.com. Last updated 18 September 2026.

Sources

• EN 301 549 V3.2.1 (2021-03), ETSI — clause 4.1 and the eleven functional performance statements at 4.2.1 to 4.2.11; clause 14 on "shall" determining conformance; Annex C.4 "Clause 4 is informative and does not contain requirements that require testing"; Annex B Table B.1 and the P and S relationship markers. Accessed 18 September 2026.
• EN 301 549 V4.1.1 (2026-09), ETSI — clause 4 renamed Functional Performance Criteria with "shall" in 4.2.1 to 4.2.11 and the revised 4.2.8, 4.2.9 and 4.2.10 wording; Annex C.4.1 informative and C.4.2.1 to C.4.2.11 inspection procedures; clause A.2 and Table A.5 "All ICT"; Annex ZA tables for Directive (EU) 2016/2102; the foreword's list of significant changes and the 24 August 2026 adoption date. Accessed 18 September 2026.
• Directive (EU) 2019/882, EUR-Lex — the European Accessibility Act, Annex I Section VII functional performance criteria (a) to (k) and the conditions under which they apply. Accessed 18 September 2026.
• Revised Section 508 Standards, US Access Board — Chapter 3 functional performance criteria 302.1 to 302.9 and the E204.1 trigger for applying them. Accessed 18 September 2026.
• Commission Implementing Decision (EU) 2021/1339, EUR-Lex — cites EN 301 549 V3.2.1 in the Official Journal for Directive (EU) 2016/2102. Accessed 18 September 2026.
• Automated testing identifies 57% of accessibility issues, Deque — automated coverage measured across more than 2,000 audits. Accessed 18 September 2026.