EN 301 549 5.2 -- Activation of Accessibility Features
What It Is
Clause 5.2 of EN 301 549 v3.2.1 states that where ICT has documented accessibility features, it must be possible to activate those features required to meet a specific need without relying on a method that does not support that need[1]. The clause sits in the generic requirements (clause 5) and applies to any ICT in scope of the standard that ships with documented accessibility features -- not only closed-functionality hardware. It closes the chicken-and-egg loop: if turning on the screen reader requires navigating a visual settings menu, the feature exists but is unreachable by the user who needs it[2].
Why It Matters
Accessibility features are load-bearing only if the activation path is itself usable without the capability the feature compensates for. A blind user onboarding a new phone cannot read a visual wizard to enable speech output. A deaf user configuring a kiosk cannot hear an audio prompt to turn on captions. A user with limited dexterity cannot perform a precision multi-touch gesture to enable sticky keys. Clause 5.2 forces vendors to design an activation path that a user with the target disability can traverse from cold start: a triple-press hardware shortcut, an accessibility wizard that speaks at first boot, a headphone-jack trigger that switches to audio mode, a Narrator-from-lock-screen pattern, or a physical accessibility button with a tactile symbol.
How It Relates to WCAG
WCAG assumes the assistive technology is already running. Web content is open -- the user brings a screen reader, magnifier, or switch interface from their own device -- so WCAG 2.x success criteria describe what the content must expose to an already-active AT. EN 301 549 clause 5 covers the access path to the AT, and clause 5.2 is the specific rule that the path cannot itself be the barrier[1]. This is one of the clearest places where EN 301 549 extends beyond WCAG: a product can pass every WCAG 2.2 Level AA criterion in its running state and still fail 5.2 if the out-of-box setup flow locks a disabled user out before the AT can be turned on.
Practical Implications
- Operating systems and devices must expose at least one activation method per documented accessibility feature that does not require the capability the feature is designed to replace -- for example, a hardware shortcut or first-boot accessibility wizard that announces itself audibly.
- Self-service kiosks, ATMs, ticket machines, and point-of-sale terminals -- which fall under the closed-functionality requirements in clause 5.1 -- must combine 5.2 with tactile discovery: a raised accessibility symbol, a known-location jack, or a consistent activation gesture learnable across a vendor's product line[2].
- Activation methods must be documented so users and procurers can find them, which ties 5.2 to the product documentation requirements in clause 12.1.
- Pure web applications rarely trigger 5.2 on their own, because the browser and OS supply the AT activation path. Embedded browsers running on kiosks, in-flight entertainment, and set-top boxes inherit 5.2 obligations from the host device.