EN 301 549 Checklist: Scope, Test, and Document Accessibility (v4.1.1)

EN 301 549 v4.1.1 moves the web, document, and software requirements of Europe's accessibility standard to WCAG 2.2. Use this checklist to scope which clauses apply to your product, test each area, and keep the evidence that shows what you checked.

If you want to see the new version you can check the EN 301 549 v4.1.1 (PDF) which was published by ETSI on September 2, 2026.

Key points

• Six new WCAG 2.2 criteria come in with v4.1.1, covering focus visibility, dragging, target size, consistent help, redundant entry, and accessible authentication. 4.1.1 Parsing goes out.

• As of October 2026, no harmonised standard is cited under the EAA. v3.2.1 is cited under the Web Accessibility Directive, and v4.1.1, which maps its clauses to the EAA, is expected to be cited. Testing against WCAG 2.2 now prepares you for both.

• Most of the standard sits outside the web chapter. Documents, software, mobile apps, hardware, and real-time communication each have their own clauses.

• Evidence matters as much as fixes. Every result should be recorded with the version tested, the date, the scope, and the method.

EN 301 549 is the European standard for the accessibility of ICT products and services, and the technical reference most teams use for the European Accessibility Act (EAA).

What Changed in v4.1.1, and which Version Should you Test Against?

Version 4.1.1, published in September 2026, brings four main changes:

• Web pages, documents, and software move from WCAG 2.1 to WCAG 2.2: six new criteria at Level A and AA, and 4.1.1 Parsing removed.

• User preference requirements now cover web pages and documents, not only software.

• Real-time text requirements now include total conversation, where video, text, and voice run together.

• Its clauses are mapped directly to the EAA requirements (Annex ZB).

The EN 301 549 guide explains each change in detail.

Test against WCAG 2.2 Level AA now, and name the version you tested in every report.

• v3.2.1 uses WCAG 2.1. It's cited in the Official Journal of the European Union under the Web Accessibility Directive, which covers public sector websites and apps.

• As of October 2026, no harmonised standard has been cited under the EAA. EN 301 549 remains a useful technical reference, but it does not currently give a presumption of conformity under the EAA. v4.1.1 maps its clauses to the EAA (Annex ZB), and its citation is expected.

• If you're a public body reporting against v3.2.1, keep a result for 4.1.1 Parsing until v4.1.1 replaces it.

Before You Start: Which Clauses Apply to your Product?

EN 301 549 is organized by type of technology, so start by deciding which chapters apply. A website alone doesn't trigger the hardware or relay service clauses. A mobile banking app with video calls triggers several.

Clause 4 sets functional performance statements, such as use without vision or with limited reach, that apply across all chapters. For apps, software, and hardware, also decide which functions are open (they work with the user's own assistive technology, like a screen reader) and which are closed (like a ticket machine, where the user can't connect their own). Closed functions follow the clause 5.1 requirements, such as built-in speech output.

Write the scope down. It becomes the first line of your evidence.

How to Use This Checklist

Combine an automated scan with manual testing. A scan finds repetitive digital barriers fast, like missing text alternatives or low contrast. It can't judge whether alt text makes sense or whether a custom component works with a screen reader. Our comparison of manual and automated accessibility testing explains where each one stops.

Test your main user journeys, such as sign-up, login, search, checkout, and contact, rather than single pages.

Use a keyboard only, a screen reader (NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android), zoom, and magnification.

Give every item one of four results:

• Pass: tested, and it meets the requirement.

• Fail: a verified digital barrier exists.

• N/A: the requirement doesn't apply. Write down why.

• Not tested: evidence is still needed.

For each result, record:

• EN 301 549 and WCAG versions tested

• the scope

• the product and version

• the test date

• the tester

• the browser or device, and a screenshot or issue reference.

Website Checklist (clause 9)

Clause 9 applies WCAG 2.2 Level A and AA to web pages. WCAG 2.2 adds nine new success criteria. Six are at Level A or AA, and those are the ones EN 301 549 v4.1.1 includes. They're the rows marked New in v4.1.1, and the most likely gaps in an audit done against WCAG 2.1.

Documents checklist (clause 10)

Clause 10 applies most of the same criteria to downloadable documents, such as PDFs, Word files, and spreadsheets. Start with the documents people need to complete a task, like contracts, invoices, forms, and terms.

Our PDF accessibility solutions cover testing and remediation for large document sets.

Apps and software checklist (clause 11)

Native apps need testing on each platform with its own assistive technologies. For a real example, read our case study on Lavazza's apps.

Calls, video, and hardware checklist (clauses 5 to 8)

Hardware must be tested on the physical device in its real installation, not only on a drawing or simulator. Our hardware and software audits cover these checks.

Documentation and support checklist (clause 12)

Fix, retest, and keep your evidence up to date

Prioritize digital barriers that block a task, such as login, payment, or submitting a form, before cosmetic issues. Fix them, then retest the same journeys with the same method and update the result.

Update your accessibility statement and any Accessibility Conformance Report (ACR) based on the VPAT EU edition when you move to v4.1.1. Both should name the version they refer to.

Our guide on how to conduct a website accessibility audit walks through the full process, and our article on going from audit to fixes shows what happens next.

Our accessibility audit service adds remediation guidance for your developers, and user testing with people with disabilities finds barriers that expert testing still misses.

Frequently asked questions about EN 301 549 testing

Do I need an EN 301 549 checklist or an EAA checklist?

Usually both, for different jobs. An EN 301 549 checklist tests whether your product is technically accessible. An EAA checklist covers your business duties under the law, such as scope, the accessibility statement, feedback channels, and documentation. Start with the technical test, because the EAA work depends on its results.

Do we need to retest everything for v4.1.1?

Usually not. If you have a recent audit against WCAG 2.1 AA, test the rows marked "New in v4.1.1" and the v4.1.1 changes that apply to your product, then update the version in your reports.

How often should we repeat an EN 301 549 audit?

Run a full audit at least once a year, and retest the affected journeys after every major release that changes navigation, login, forms, or templates. Automated monitoring between audits catches new barriers as content changes.

When does EN 301 549 v4.1.1 become the legal reference?

When the European Commission cites it in the Official Journal of the European Union, which is expected in late 2026.

What should be done before EN 301 549 sign-off?

1. Every clause is marked as applying or N/A, with a reason for each N/A.

2. Every item that applies has been tested manually, not only with an automated scan.

3. All six rows marked "New in v4.1.1" have a result.

4. Barriers that block a task are fixed and retested.

5. Every result has its evidence recorded.

6. Your accessibility statement and ACR match the results.

Want a clear picture of where your site stands today? Start with a free assessment on our accessibility compliance platform, then talk to our team about a full EN 301 549 audit.