EN 301 549 Checklist: 8 Steps for EU Accessibility

Your bid is live, your platform is in scope, and the procurement team is waiting for proof. If the contract is with an EU public authority, the reviewer isn't asking whether your site “feels accessible.” They're looking for evidence against EN 301 549, the harmonized European accessibility standard for ICT, and they'll expect more than a WCAG-only checklist because the standard covers websites, mobile apps, hardware, software, telecommunications equipment, and non-web documents across the full ICT stack. That's why this EN 301 549 checklist needs to be operational, not decorative. EN 301 549's broad scope and checklist structure make it the right benchmark for EU-facing teams that need one compliance model they can apply across Member States.

Use this list to get to the point fast. Start with scope, map each asset to the right chapter, test with real assistive technology, and document every finding. If you sell into the public sector, manage procurement, or own a product roadmap that has to survive audit, this is the version that keeps you out of avoidable trouble and keeps deals moving.

TLDR

EN 301 549 is the standard to work from, not WCAG alone. Chapter 9 maps to WCAG 2.1 Level A and AA, but full compliance also requires the chapters beyond web content, including hardware, software, documents, and communication services as stated by the German federal accessibility portal.

Public procurement teams should ask for evidence, not promises. The European Commission's change tables call out Chapter 5 items that WCAG does not cover, including activation of accessibility features, biometrics, and preservation of accessibility information during conversion in the Commission's latest changes page.

Compliance needs both automation and human testing. Start with baseline scans, then add manual keyboard review, screen reader checks, and user testing with people with disabilities, because EN 301 549 is built for conformance evidence, not page-level defect lists as described in the operational guidance from UserWay.

Document everything. Under the EAA, a complete EN 301 549 record set supports a presumption of conformance, but only when all 12 chapters are covered and evidence stays current per the EAA compliance overview.

Use a chapter-by-chapter checklist, not a vague accessibility statement. Tie each requirement to the right WCAG AA checklist item, then map what sits outside WCAG, such as software behavior, hardware controls, and document handling, so procurement, product, and QA teams are checking the same standard.

1. Chapter 9 Web Content and Software

Chapter 9 is the anchor point for web content and software interfaces. It maps those interfaces to WCAG 2.1 Level A and AA, and the German federal accessibility portal states that those success criteria are binding under EN 301 549, while AAA items remain informative or extended criteria source. A WCAG pass is necessary, but it does not satisfy the standard by itself.

Treat Chapter 9 as the baseline, then test the extras

Start with automated scanning, then move straight to manual checks. EN 301 549 Chapter 9 is built around headings, labels, visible focus, and other WCAG-aligned patterns, so the key question is whether the portal, app, or software shell works for keyboard users, screen reader users, and people who depend on visible focus states. Procurement teams should ask for proof of those behaviors, not a generic accessibility statement.

Manual review has to cover what scanners miss. Focus order, focus visibility, text spacing, and interaction states can pass a machine check and still fail real use, especially in software where the interface changes by state, not just by page.

Practical rule: if a defect only shows up during actual use, put it in your manual test script, not only in your automated report.

A strong workflow is to connect Chapter 9 testing to your WCAG AA checklist, then assign every failed criterion to a named owner and a retest date. That gives procurement reviewers a clean paper trail. It also gives compliance teams a usable view of risk for EU government portals, telecom customer portals, and fintech interfaces, where legal exposure and customer churn often move together.

Make audit evidence usable

Auditors need a clear map from requirement to implementation. Include screenshots of focus states, screen reader transcripts, keyboard paths, and remediation notes for any workaround you used. Keep the history too, because repeated regressions matter more than a single clean snapshot.

• Automated scan first: use it to catch obvious failures in headings, labels, and contrast.
• Manual keyboard review next: verify every task without a mouse.
• Assistive tech verification last: test with screen readers and real users, not internal assumptions.
• Governance link: connect findings to your core compliance checklist and compliance dashboard so procurement and legal can reuse the evidence.

If you use WebAbility.io, its 24/7 scanning and historical reporting fit this chapter well because they help you catch Chapter 9 drift as code and content change. That matters when a release train can break focus order or labeling overnight.

2. Chapter 5 Generic Requirements

Chapter 5 catches teams off guard because it sits above page design and tests the parts of a system that users never see. The European Commission's change tables make that clear by listing Chapter 5 items such as activation of accessibility features, biometrics, and preservation of accessibility information during conversion as requirements not covered by WCAG. source If your audit stops at the visible interface, you will miss the business-logic barriers that block users at sign-in, during data transfer, and at system handoff points.

Audit the system, not just the interface

Authentication flows need direct scrutiny. If a user has to clear a biometric gate, the product must provide an accessible alternative, and that alternative must be documented as part of the design rather than added later as an exception. The same standard applies to closed functionality and to data conversion steps, where accessibility metadata can disappear as files move between formats, systems, or support channels.

Compliance teams should work with product, security, and support on this chapter. Banking portals, ID verification tools, and payment workflows often combine identity proofing with accessibility barriers, so the review has to cover the full transaction path. Telecommunication services also need attention beyond the browser, because Chapter 5 reaches into two-way voice communication and accessible support paths that do not depend on a single sensory channel.

Build Chapter 5 into procurement and change control

For procurement officers, the right question is simple. Do not ask, “Does it say accessible?” Ask for the alternative path, the preservation controls, and the test evidence. Put that language into vendor questionnaires and acceptance criteria, then reject any implementation that cannot demonstrate it.

A system with closed functionality needs built-in accessibility by design. If users cannot install their own assistive tech, the product has to carry the accessibility burden itself.

Use vendor documentation to confirm the accessible alternatives exist, then use your own audit to verify that the path works as intended. For SaaS admin panels, payment terminals, and identity verification systems, that means documenting each point where a user can get blocked, then validating the fallback with keyboard, speech, and screen reader testing.

3. Chapter 6 ICT With Two-Way Voice Communication

Chapter 6 is where voice products stop being “nice to have” and become compliance work. The Canadian technical summary of EN 301 549 v3.2.1 notes requirements for text communication in real time, simultaneous speech and text, speaker identification, and real-time speech activity indicationsource. That's the level of detail your conferencing, telehealth, or contact-center team needs to document if the product supports real-time communication.

Prioritize live communication that actually works

If you run VoIP, conferencing, telephony, or customer service platforms, start with real-time text and captions. Then verify that speaker identification stays accurate enough to be useful in multi-person calls, because without that, captions can become noisy instead of helpful. Hearing aid compatibility also matters, and it should be tested with real users who rely on it, not guessed from a vendor spec sheet.

This chapter affects meeting culture too. A company can buy Microsoft Teams, Zoom, Google Meet, or SIP-based systems and still fail if it never turns on captions, never trains staff to use them, and never checks whether the setup supports people who need accessible communication in actual meetings.

Make the support model visible

Support tickets and meeting notes aren't enough. Build user-facing documentation that shows where RTT, captions, and speech-to-text live, how people turn them on, and what to do when they fail. That documentation becomes part of your compliance story and your adoption story at the same time.

• Test real calls: check captions during a live meeting, not just a demo file.
• Use actual assistive devices: validate hearing aid compatibility with users who depend on them.
• Capture transcript quality: record when speaker identification breaks and why.
• Train managers and hosts: people won't use a feature they don't know exists.

If your team owns telehealth or customer care, this chapter is a direct CRO issue too. Clear communication reduces abandoned calls, confusion, and repeat contacts because users can complete the interaction the first time.

4. Chapter 7 ICT With Video Content

Chapter 7 is where accessibility meets your content library. Video platforms, training portals, and embedded players need synchronized captions, audio descriptions, keyboard-operable controls, and live accessibility for streams. The plan is straightforward, captions for dialogue and relevant sound, descriptions for visual information that carries meaning, and player controls that screen reader and keyboard users can operate without friction.

Build the video workflow around accessibility

Don't bolt accessibility on after publishing. Put captions, transcripts, and description fields into the CMS template so every new asset starts in a compliant state. For live sessions, use professional CART or a hybrid human-plus-automation workflow when the event matters, because live content fails fast when no one owns the caption pipeline.

The examples in the market are instructive. Netflix publishes captions and audio descriptions across large libraries, BBC iPlayer treats captioning and audio description as broadcast standards, and public institutions like the European Parliament use real-time accessibility for plenary sessions. Those aren't decoration features. They're operating requirements for content that has to reach everyone.

Audit the player, not just the file

A compliant video file can still fail in a bad player. Keyboard-only access, visible focus, transcript links, caption toggles, and audio description controls all need manual review. If the player breaks screen reader navigation, the video might as well be missing.

Don't trust a caption badge in the CMS. Open the published page, tab through the controls, and confirm the player still works after embed, theme, and tracking scripts load.

Use automated captioning as the starting point, then review the output. Manual correction matters because speaker names, punctuation, and sound cues affect comprehension. Keep a content inventory tied to your compliance dashboard, and make video owners responsible for remediation just like page owners.

If your organization publishes training, investor updates, or support explainers, Chapter 7 is also a retention tool. Accessible video keeps users moving through the content instead of bouncing when the player becomes unusable.

5. Chapter 8 Hardware Accessibility

Chapter 8 is the chapter many digital teams ignore until procurement forces the issue. It applies to ICT hardware such as computers, terminals, peripherals, and smart devices, and it expects multi-modal input, tactile and visual feedback, connectivity for assistive technology, and operability with single-hand or adaptive inputs. For public access devices, this isn't optional, it's a design requirement.

Demand hardware evidence before purchase

Procurement officers should ask for hardware accessibility specifications up front. That means reach ranges, control spacing, force requirements, tactile identification for key controls, and confirmation that the device works with relevant assistive technology connections such as USB, Bluetooth, or APIs. If the vendor can't produce those details, the buying team should treat the device as incomplete.

This matters in ATMs, kiosks, office workstations, and library terminals. It also matters in government buying, where the hardware often ships with the software and support obligations bundled together. A kiosk that looks polished but fails in accessible mode is not usable in practical scenarios.

Test the physical interaction path

Use actual users with motor disabilities, wheelchair users, and people relying on canes or mobility aids during acceptance testing. Measure how the controls feel, not just how they look. Make sure audio output is private enough for the context, and verify that the accessibility mode is independently discoverable instead of hidden behind a support call.

The German government's office hardware requirements and European public terminal deployments show where the market is going. Hardware compliance is becoming a baseline expectation, not a premium feature.

For closed-function devices, the built-in path has to do the work. There's no room to assume users will bring their own workaround.

Put Chapter 8 into your procurement contract language, your acceptance checklist, and your asset inventory. If you own a fleet, make the compliance record part of the purchase file so you can prove what was bought, what was deployed, and what accessibility mode each unit supports.

6. Chapter 10 Non-Web Documents and PDF Accessibility

Chapter 10 is where document sprawl turns into compliance risk. PDFs, Office files, and ePubs need accessible structure when they're published or distributed, which means semantic headings, labels, table headers, language metadata, and reflowable layouts where applicable. A document that looks fine on a laptop can still be unusable to a screen reader, a keyboard user, or someone who needs a reflowable format on mobile.

Put document creation on rails

The best fix is not cleanup, it's prevention. Train staff to use accessible templates in Word, PowerPoint, and Excel, then require review before publication. For scanned PDFs, OCR is a starting point, not the finish line, because the output still needs human verification.

Prioritize the documents that people use. Forms, policies, support guides, contracts, and regulatory notices should get remediated first because they affect customer journeys and operational risk. If a document supports onboarding, billing, or legal disclosure, it belongs high on the queue.

Govern the whole document lifecycle

You need a born-accessible workflow, a remediation process, and a publication gate. That includes version control, review notes, and an owner for each document family. The European Commission's official document publishing practices show how much this discipline matters in public-facing environments.

If your team produces high-volume legal or policy documents, tools like LegesGPT's AI legal document generator can fit into a broader document workflow, but only if the output still goes through accessibility review before release.

For practical remediation guidance, anchor your team to practical PDF accessibility methods and then enforce the same checklist across every new file type. Tie the document checklist to your main accessibility program so PDFs don't become the one place compliance disappears.

7. Chapter 11 Software Accessibility

Chapter 11 is where desktop software, mobile apps, enterprise platforms, and APIs get pulled into the same accessibility conversation. The rule is simple, users need keyboard access, screen reader compatibility, correct names and states, focus management, high contrast support, scalable text, and direct use of platform accessibility APIs. If the software is hybrid or web-based, it can trigger both Chapter 9 and Chapter 11 expectations.

Test native behavior, not just overlays

Desktop and mobile apps need native testing with the assistive tech people use. That means screen readers built into the platform, not just a proxy tool that gives the development team a false sense of confidence. If the app ships on Windows, macOS, iOS, or Android, the product team needs to prove that it speaks the platform's accessibility language correctly.

Salesforce, SAP, and Microsoft Office are useful references because they show what broad enterprise accessibility needs to support, including keyboard navigation, state management, and compatibility across multiple endpoints. Your product won't look like those platforms, but it should meet the same expectation, which is that a user can complete the workflow without guessing.

Put accessibility in vendor scoring

For enterprise software procurement, add Chapter 11 to vendor evaluation and acceptance testing. Ask for keyboard shortcuts, accessibility API usage, and native screen reader results. For internal tools, make development teams document focus order, state changes, and accessible naming as part of the release checklist.

If your app only works for mouse users, it's not enterprise-ready. It's only browser-ready or pointer-ready, and that's a weaker standard.

Use impactful AT for accessibility as a reminder that assistive tech isn't a single category. Screen readers, magnifiers, switch control, and voice input all expose different defects, so one test pass doesn't cover the chapter. That's why your audit environment should include multiple tools and actual users, not just one happy-path script.

8. Presumption of Conformance Under the EAA

The EAA gives organizations a real incentive to do the hard work properly. When a business fully meets EN 301 549 across all 12 chapters and keeps the evidence in order, it can rely on a presumption of conformance under the European Accessibility Act. That doesn't make the file invisible to scrutiny, but it does give legal and commercial protection when your documentation is complete and current as outlined in the EAA compliance guidance.

Build the evidence file like you expect review

Treat accessibility as governance, not a one-off remediation project. Create a chapter-by-chapter matrix with requirements, test methods, evidence links, remediation status, and owner names. Then add user feedback, retest records, and an accessibility statement encompassing the full standard instead of only Chapter 9.

The important trade-off is clear. A clean statement with weak evidence is fragile. A documented system with repeatable testing and change control is much stronger, because it helps you answer regulator questions, procurement questions, and customer questions with the same file.

Keep the record alive after launch

Presumption of conformance depends on ongoing discipline. New releases, new documents, new hardware, and new integrations all create fresh risk. That means your audit trail should include testing dates, tool names, issues found, fixes made, and verification results, plus a channel for users to report barriers.

For legal and compliance teams, you should align EAA review with your broader governance calendar. Bring the dashboard to executives, review open issues quarterly, and keep the evidence set ready for procurement or market-surveillance review. Teams that do that can move faster because they're not rebuilding proof every time a buyer asks.

EN 301 549: 8-Chapter Conformance Checklist

Putting the EN 301 549 Checklist into Action

Use this EN 301 549 checklist as an operating model, not a theory piece. Start with scope inventory, then map each asset to the right chapter, then test with automation and people who rely on assistive technology. That sequence matters because it stops teams from mistaking a clean scan for full compliance.

The fastest wins usually come from Chapter 9, Chapter 10, and Chapter 11, because most organizations already touch web content, documents, and software every day. But you can't stop there. Chapter 5, Chapter 6, Chapter 7, and Chapter 8 are where procurement, hardware, communication systems, and closed-function devices either pass cleanly or create the kind of gap that derails a contract review.

For compliance leaders, the trade-off is straightforward. A narrow WCAG project is cheaper to start, but it leaves major parts of the standard uncovered. A full EN 301 549 program takes more coordination, yet it gives you better procurement readiness, better legal defensibility, and a cleaner path to the EAA presumption of conformance when the evidence is complete.

Keep the documentation machine running. That means baseline audits, issue triage by user impact, retesting after fixes, and a compliance dashboard that shows what changed over time. If you already use WebAbility.io, its scanning, reporting, and centralized dashboard fit that workflow because they help teams track regressions, retain history, and keep accessibility tied to governance instead of scattered across departments.

For procurement officers, add EN 301 549 language to RFPs, vendor questionnaires, acceptance tests, and renewal reviews. For product teams, build the chapter checks into release gates and design reviews. For both, the rule is the same, if you can't prove it, don't claim it.

A CTA for WebAbility.io.