We’ve already covered why U.S. companies should pay attention to the European Accessibility Act, why overlay widgets fall short, and what practical next steps look like.
For most digital teams, those practical steps begin with WCAG, and that’s the right place to start. WCAG is an essential baseline for websites, apps, and digital content.
But for companies providing EAA-covered products and services to EU customers, WCAG alone won’t get you there.
That’s because the EAA addresses accessibility across the broader user experience: login and authentication, media playback, content conversion, and customer support.
WCAG simply wasn’t designed to cover that much ground.
That’s where EN 301 549 comes in – the European technical standard for Information and Communication Technology (ICT) accessibility. Draft EN 301 549 v4.1.0, the next major revision, is being finalized to align the standard with the EAA’s requirements. 1
So what does EN 301 549 require that WCAG doesn’t? Below are seven examples – hardly a complete checklist, but enough to show why WCAG conformance on its own isn’t sufficient for EAA readiness.
1. Accessibility features must be reachable, not just present
Reference EN 301 549 draft v4.1.0 clause 5.2 (“Activation of accessibility features“)
An accessibility feature only helps if the person who needs it can turn it on.
That sounds obvious, but it’s easy to miss. Imagine the only way to switch on speech output is to read an on-screen menu – the very thing a blind user needs speech output for. Similarly, if larger-text settings sit behind a setup flow that requires users to read small text, then the product may technically contain accessibility features. Users just won’t be able to reach them.
That kind of circular trap is what this requirement is meant to prevent.
A WCAG review may catch an inaccessible button or menu on a web or app surface. EN 301 549 asks the product-level question: can users activate an accessibility feature without relying on the very ability that feature is meant to support?
Bottom line: Test the activation, not just the feature.
Product team check:
- If documented accessibility features exist, can users reach and activate them without first needing the feature itself?
- Are setup, login, preferences, and recovery flows tested with relevant assistive technologies?
- Does any flow require sight, hearing, speech, or precise touch before reaching accessibility settings?
2. Biometric authentication must offer another route
Reference EN 301 549 draft v4.1.0 clause 5.3 (“Biometrics”)
Face ID, fingerprint login, and voice recognition may be convenient for many users, but they’re not universally accessible.
If biometrics are the only way to log in, approve an action, or control a function, a user whose face, voice, or fingerprints can’t be reliably recognized may be locked out of the service entirely. A banking app, travel account, or loyalty program could unintentionally block customers because of it.
WCAG addresses some authentication barriers, such as flows that depend on memorization, puzzles, or cognitive tests. EN 301 549 adds an additional question: where ICT uses a biological characteristic for identification or control, does the user have another – fully functional, non-biometric – way through?
Bottom line: A face, finger, or voice check shouldn’t be the only route to get in or get things done.
Product team check:
- Does any login, approval, identity-verification, or account-recovery flow rely only on biometrics?
- What fallback non-biometric route is available when a particular biometric doesn’t work for a user group?
- Have security, identity, product, and accessibility teams reviewed authentication flows together?
3. Accessibility must survive content conversion
Reference EN 301 549 draft v4.1.0 clause 5.4 (“Preservation of accessibility information during conversion”)
Accessibly created content doesn’t always survive conversion to another format.
A document may start out WCAG-aligned, with proper headings, alt text, table headers, and logical reading order. Then it’s exported to PDF, and that structure gets scrambled. A video may include subtitles and audio description, but a transcoding step may drop those accessibility tracks or fail to carry them through.
A WCAG audit focuses on the artifact the user receives: the published PDF, the streamed video. EN 301 549 asks what happens during conversion: does the accessibility information survive in the new format, as far as that format supports it?
Bottom line: Test what leaves the pipeline, not just what enters it.
Product team check:
- Does your product generate, export, compress, transcode, or transform customer-facing content?
- Do exported files and media outputs preserve key accessibility information– headings, reading order, table structure, alt text, subtitles, audio description – where the new format supports it?
- Does QA test the final output, not only the source files?
4. Voice-based service paths must offer non-voice alternatives
Reference EN 301 549 draft V4.1.0 clause 6.4 (“Alternatives to voice-based services”)
Many digital services still assume users can hear prompts and speak responses.
That assumption can show up in automated, voice-based parts of services where customers still get things done: paying a bill, retrieving a balance, or confirming an appointment. When options are only spoken, customers who are Deaf or hard of hearing can be shut out; when a step only accepts a spoken reply, customers who are non-speaking – or whose speech is atypical – may not be able to get past it.
A classic WCAG audit reviews the website or app. It may not reach the phone-based service path. EN 301 549 addresses that gap: when ICT provides voicemail, auto-attendants, or IVR systems, customers must be able to complete the same tasks without relying on hearing or speech.
Bottom line: Don’t make hearing or speech the only way through.
Product team check:
- Which customer workflows still depend on hearing audio prompts or giving spoken responses?
- Is there a non-voice route – web, in-app, real-time text – to get the same information and finish the same task?
- Does the alternative mode solve the task, or does it just send the user somewhere else?
5. Security and custom components must not break accessibility
Reference: EN 301 549 draft v4.1.0 clause 11.6.2 (“No disruption of accessibility features”)
Some accessibility failures can be introduced by tools that were added for good reasons.
Banking or fintech apps often add anti-fraud controls, screen-capture blocking, a custom secure keyboard, or a session-protection overlay. Any one of these can suppress or interfere with platform accessibility features if not implemented carefully. Imagine a customer who relies on their OS’s screen reader, magnifier, switch control, or voice control suddenly finding out those familiar features don’t work inside your app.
A WCAG-only review may not catch this, especially in native apps and other non-web software. EN 301 549 sets a clear rule: non-web software must not disrupt documented platform accessibility features, except when the user specifically requests it.
Bottom line: The security layer should not disable the accessibility layer.
Product team check:
- Do any security, anti-fraud, or hardening layers in your app interfere with documented platform accessibility features?
- Have you tested the app with the screen reader, magnifier, and switch/voice control active – not just with automated tools?
- When a custom component replaces a native one (say, a secure keypad), do the platform’s documented accessibility features still work normally?
6. Media accessibility controls must be as easy to reach as main player controls
Reference: EN 301 549 draft v4.1.0 clause 7.3 (“User control of audiovisual accessibility features“)
Turning on captions (subtitles) shouldn’t take five taps when turning up the volume takes one.
On most media players, volume is easy to find – often on the main control bar or directly on the remote. But switching on audio description or captions may require hunting through a menu and selecting from a sub-list. For viewers who depend on those features, that extra friction matters.
This is about equal effort. WCAG addresses whether captions and audio descriptions are provided. EN 301 549 asks the product-level follow-up: if the player offers controls for those features, can a viewer switch them on with a single action, at the same level as the volume control? Or are they buried several steps deeper?
Bottom line: Check how deep captions and audio description are placed, not just whether they exist.
Product team check:
- Where the player controls subtitles, audio description, or spoken subtitles, can users activate them with a single action – at the same level as the volume control (not several steps deeper in a settings menu)?
- Does that activation path also meet the other applicable accessibility requirements – for example, can it be used by keyboard, screen reader, and switch users where relevant?
7. Simultaneous inputs must not be the only path
Reference EN 301 549 draft v4.1.0 clause 5.9 (“Simultaneous user actions“)
Some controls only work when the user does two things at once, but not every user can.
A confirmation that requires a two-finger pinch, a control that requires pressing two keys at the same time, or a payment approval that requires holding one control while pressing another: each of these can shut out a user who operates a device one-handed, with a single finger, a head pointer, or a switch. The interface can be visually polished and still be impossible to operate.
WCAG covers part of this for web pointer gestures. EN 301 549 goes further: if one way of operating something requires simultaneous actions, there has to be at least one other way that doesn’t.
Bottom line: Anything that requires two inputs at once needs a one-at-a-time path.
Product team check:
- Does any task in your product – checkout, payment approval, confirmation, or media control – require simultaneous inputs as the only path?
- Is there an alternative way to complete the same task through sequential actions, rather than simultaneous ones?
- Have core flows been tested with one-finger, one-handed, switch, and voice-control operation where relevant?
The takeaway
WCAG compliance remains essential, and no digital accessibility program can properly function without it. But for companies selling covered products or services to EU consumers, treating WCAG as the entire roadmap creates a serious readiness gap.
Special thanks to Susanna Laurin, Chair of the ETSI/CEN/CENELEC Joint Technical Body on eAccessibility – which develops and maintains EN 301 549, the standard underpinning EAA conformance – and Managing Director of the Funka Foundation in Sweden, for her comments.
- Version note: The current published version, v3.2.1, is harmonized under the EU Web Accessibility Directive (WAD) – the law covering public-sector websites and apps – and is the practical benchmark available today. Draft V4.1.0 is the current working draft of the EAA-focused revision, prepared under the Commission’s standardisation request M/587 to support the European Accessibility Act. It updates some clauses to align with WCAG 2.2 and maps its clauses to the EAA’s essential requirements. Once a finalized V4 version is cited in the EU’s Official Journal, conformance with the relevant normative clauses will provide a presumption of conformity for the products, services, and requirements those clauses cover. All seven clauses covered in this blog appear in both versions; draft V4.1.0 refines several of them. ↩︎