Accessibility

title: EN 301 549 framework reference description: European EN 301 549 V3.2.1 harmonised ICT accessibility standard packaged as an accessibility assessment knowledge base

EN 301 549 framework reference

This skill packages the European EN 301 549 V3.2.1 harmonised standard as an accessibility assessment knowledge base. It covers the nine normative clause groups that bind ICT accessibility under European policy (most prominently the Web Accessibility Directive and the European Accessibility Act): Clause 5 (generic), Clause 6 (two-way voice communication), Clause 7 (ICT with video capabilities), Clause 8 (hardware), Clause 9 (web), Clause 10 (non-web documents), Clause 11 (software), Clause 12 (documentation and support services), and Clause 13 (ICT providing relay or emergency services). Clauses 9, 10, and 11 carry WCAG 2.1 Level A and AA success criteria by reference into web, document, and software contexts respectively, so most rows below carry WCAG cross-references that link into the sibling wcag-22 skill's per-guideline reference files (anchored at #sc-<n>-<m>-<k>).

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. EN 301 549 reference text is reproduced strictly under the paraphrase-only posture defined in accessibility-license-posture.instructions.md; every clause summary in this skill is paraphrased in the authors' own words and cites the ETSI portal as the authoritative source for the normative wording. When that instruction content is unavailable, apply the paraphrase-only posture stated here and do not reproduce normative wording verbatim.

Version Status

ETSI published EN 301 549 V4.1.1 in September 2026. V3.2.1 remains the version cited in the Official Journal of the European Union, so it stays the legal reference for presumption of conformity under the Web Accessibility Directive and the European Accessibility Act until V4.1.1 is cited there. This reference therefore stays on V3.2.1.

When V4.1.1 is cited, the main changes to carry over are:

• The web, document, and software clauses move from WCAG 2.1 to WCAG 2.2. Six new Level A and AA rows appear in clauses 9 and 10, and five in clause 11, where consistent help is void.

• The Parsing rows (9.4.1.1, 10.4.1.1, and 11.4.1.1) become void, following its removal from WCAG 2.2.

• Authoring tool requirements move from 11.8 to a new 5.10, and new clauses add user-preference requirements for web pages (9.7) and non-web documents (10.7).

• Clause 12 is reorganised, 13.2 becomes void, and new Annexes ZA, ZB, and ZC map requirements to the Web Accessibility Directive, the European Accessibility Act, and other directives.

Sources: ETSI deliverable directory, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/; AccessibleEU, "The European accessibility standard EN 301 549 has been updated", https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en.

Clause Roll-up

How to use this skill

Use the roll-up table to identify the EN 301 549 clauses that apply to a given product context (web, document, software, hardware, voice, video, support, or relay/emergency). Follow each reference link to the per-clause-group file for the paraphrased requirement, applicability scope, WCAG cross-reference, and assessment heuristics. When a row carries a sc-<n>-<m>-<k> cross-reference, consult the sibling wcag-22 skill for the underlying technical detail — Clauses 9, 10, and 11 inherit WCAG 2.1 Level A and AA wholesale into web, non-web document, and software contexts respectively, so most accessibility implementation work happens against the WCAG criterion text with the EN 301 549 clause adding only the regulatory framing.

For the precise normative wording of any clause, consult the official ETSI document at https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. The paraphrased summaries in this skill are not a substitute for the upstream standard when a regulator, procurement authority, or court requires verbatim conformance text.

Clause 5: Generic Requirements

Clause 5 of EN 301 549 V3.2.1 collects ICT-wide generic requirements that apply across product categories (web, software, hardware, voice, video). It covers closed functionality, including private access to personal data spoken by closed-function ICT (5.1.3.9), activation of accessibility features, biometrics, preservation of accessibility information during conversion, operable parts, locking and toggle controls, key repeat and double-strike handling, and simultaneous user actions. These clauses set the baseline that more specialised clauses (6 through 13) build on or refine.

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 5, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. Summaries below are paraphrased; consult the official document for normative wording.

clause-5-1

5.1 Closed functionality

Where ICT has closed functionality, meaning users cannot attach or install their own assistive technology, the ICT itself shall provide the accessibility that assistive technology would otherwise supply. Its sub-clauses cover non-visual access (5.1.3), use when text cannot be enlarged (5.1.4), visual output for auditory information (5.1.5), operation without a keyboard interface (5.1.6), and access without speech (5.1.7). Closed functionality shall not require users to attach, connect, or install assistive technology (5.1.2.2).

Applies to: ICT with closed functionality, such as kiosks, ticket machines, payment terminals, and fixed-function devices, which must satisfy accessibility through built-in alternative modes.

WCAG cross-reference: n/a (closed-functionality requirement rather than a WCAG success criterion).

Assessment heuristics:

• Enumerate every closed-function mode (operation without vision, operation with limited vision, operation without hearing, operation without speech, operation with limited manipulation, operation with limited reach) and verify each is supported.

• Capture the closed-functionality test plan as part of the product accessibility conformance report.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-1-3-9

5.1.3.9 Private access to personal data

Where closed functionality provides auditory output as non-visual access, and that output contains data the applicable privacy policy treats as private, the output shall go only through a private listening mechanism that can be connected without vision, such as a headphone jack, or through another mechanism the user explicitly chooses. The requirement does not apply when no privacy policy defines the data as private.

Applies to: Closed-function ICT that speaks private data, especially public-use ICT such as kiosks, ATMs, and ticket machines.

WCAG cross-reference: n/a.

Assessment heuristics:

• Confirm a private audio channel (headphone jack, Bluetooth pairing) is offered alongside speaker-based screen reader output.

• Where the user may choose non-private output (for example, at home), confirm the ICT warns about the privacy implications before switching.

• Document the privacy preservation approach as part of the conformance report.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-2

5.2 Activation of accessibility features

Where the ICT has documented accessibility features, those features shall be activatable without requiring the user to first use a feature that is itself inaccessible.

Applies to: All ICT that ships with accessibility settings (high-contrast, screen-reader mode, sticky keys, captioning toggle, magnification).

WCAG cross-reference: n/a.

Assessment heuristics:

• Walk through first-run setup with each accessibility persona and verify the user can turn on the relevant feature without dependence on another inaccessible feature.

• Provide at least one always-available activation surface (hardware button, voice command, OS shortcut) for the most critical features.

• Document the activation paths in the support documentation referenced by Clause 12.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-3

5.3 Biometrics

Where biometric authentication is offered, the ICT shall not rely on a single biological characteristic as the only means of authentication; an accessible non-biometric alternative or a second biometric modality shall be provided so users who cannot present that characteristic can still authenticate.

Applies to: Devices and services that offer fingerprint, face, iris, voice, or other biometric authentication.

WCAG cross-reference: n/a.

Assessment heuristics:

• Verify that at least one alternative authentication path (PIN, hardware token, alternative biometric) is offered alongside the primary biometric.

• Confirm that the alternative is described in setup flows and is reachable without first completing biometric enrolment.

• Test the fallback flow with users who have conditions affecting the relevant biometric (low-vision face capture, amputation, voice impairment).

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-4

5.4 Preservation of accessibility information during conversion

When ICT converts information from one form, format, or medium to another (for example, exporting a document, re-encoding a video, copying captions), it shall preserve the accessibility metadata (alternative text, captions, semantic structure, language tags) unless the target format cannot represent it.

Applies to: Conversion, export, transcoding, and synchronisation tools across document, media, and communication ICT.

WCAG cross-reference: n/a.

Assessment heuristics:

• For each export path, diff the source accessibility metadata against the exported artifact and confirm parity (or document the unavoidable loss in user-visible release notes).

• Cover captions, audio descriptions, alt text, heading structure, table semantics, and language tags in the regression test plan.

• Confirm that lossy conversions issue a clear warning at the time of conversion.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-5

5.5 Operable parts

Operable parts (buttons, switches, dials, latches) shall be discernible by touch without activation, shall not require tight grasp, pinch, or twist of the wrist, and shall be operable with one hand and with a force of no more than 22.2 N.

Applies to: Hardware ICT with physical controls (kiosks, payment terminals, ticket machines, telephones).

WCAG cross-reference: sc-2-5-5.

Assessment heuristics:

• Confirm tactile discernibility of each operable part by haptic inspection (raised symbols, distinct shape, separation gaps).

• Measure activation force with a calibrated gauge against the 22.2 N ceiling.

• Verify single-hand operation for the full task path (insert card → enter PIN → confirm → take receipt).

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-6

5.6 Locking or toggle controls

Locking and toggle controls (Caps Lock, Num Lock, Scroll Lock and equivalents on hardware) shall have a discernible non-visual indicator (audible tone, tactile state, or both) so blind users can determine the control state.

Applies to: Keyboards, hardware keypads, and physical toggle switches.

WCAG cross-reference: n/a.

Assessment heuristics:

• Verify each toggle exposes either an audible state cue or a tactile-state cue (raised LED with tactile cap, mechanical detent).

• For software-controlled hardware (laptop Caps Lock LEDs), confirm the state can also be read through the platform accessibility API.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-7

5.7 Key repeat

Where ICT keyboards offer key-repeat behaviour, users shall be able to disable the feature or adjust both the delay before repeat and the repeat rate.

Applies to: Keyboards, on-screen keyboards, and other key-based input methods.

WCAG cross-reference: n/a.

Assessment heuristics:

• Confirm settings expose a "disable repeat" option and adjustable delay/rate sliders.

• Verify the settings persist across sessions and across user accounts where applicable.

• Test with users who have tremor or limited dexterity to confirm the configuration meaningfully reduces accidental repeats.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-8

5.8 Double-strike key acceptance

Where ICT accepts keyboard input, users shall be able to configure a minimum interval between presses of the same key before a second activation is registered, so that involuntary double-strikes do not produce duplicate input.

Applies to: Keyboards, on-screen keyboards, and key-based input modes on operating systems.

WCAG cross-reference: n/a.

Assessment heuristics:

• Confirm the OS or application provides a "filter keys" or "bounce keys" style configuration with adjustable threshold.

• Test that the configured threshold meaningfully suppresses accidental double-strikes without introducing perceived input lag.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-5-9

5.9 Simultaneous user actions

Operation of the ICT shall not require simultaneous actions (chorded key combinations, multi-touch gestures, simultaneous press-and-hold) unless an equivalent single-action alternative is provided.

Applies to: All input surfaces including hardware keys, touch screens, and pointer gestures.

WCAG cross-reference: n/a (related to Clause 9.2.1 keyboard requirements).

Assessment heuristics:

• Inventory every gesture or key combination that requires simultaneity (Ctrl+Alt+Del, two-finger pinch, two-button hold) and confirm an equivalent sequential path exists.

• Verify the sequential alternative is documented in the help content.

• Test with single-hand and switch-access users.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

Clause 6: ICT with Two-Way Voice Communication

Clause 6 of EN 301 549 V3.2.1 covers accessibility requirements that apply when ICT enables real-time, bidirectional voice conversation between two or more users. Its sub-clauses address audio bandwidth for intelligible speech, real-time text (RTT) as a parallel channel to voice, caller identification across modalities, accessible alternatives to voice-only services, the picture quality of video used to support sign-language communication, and alternatives to the automated answering and response features of video-based services. Access to emergency services is covered in Clause 13. These requirements build on the generic provisions in Clause 5 and apply to voice telephony, internet calling, unified-communications clients, and video-conferencing endpoints.

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 6, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. Summaries below are paraphrased; consult the official document for normative wording.

clause-6-1

6.1 Audio bandwidth for speech

Where ICT provides two-way voice communication, the audio path shall carry a frequency range wide enough to preserve the intelligibility cues of human speech, including the consonant frequencies that users with hearing loss depend on. Narrowband telephony alone is not sufficient; the clause expects wideband or super-wideband speech coding when the underlying network and endpoints support it.

Applies to: Voice communication endpoints and services, including IP telephony, mobile clients, unified-communications applications, and video-conferencing tools whose voice path is used as a substitute for in-person speech.

WCAG cross-reference: n/a (audio-channel quality requirement with no WCAG equivalent).

Assessment heuristics:

• Measure the end-to-end frequency response of the voice path and confirm it extends at least into the wideband range expected by the negotiated codec.

• Verify that wideband-capable codecs (for example G.722, Opus, EVS) are advertised and negotiated whenever both endpoints support them rather than silently downgrading to narrowband.

• Test intelligibility with hard-of-hearing users on representative network conditions to confirm consonant clarity in noisy environments.

• Document any conditions (network fallback, gateway transcoding) that force a narrowband downgrade and surface them in the conformance report.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.1).

clause-6-2

6.2 Real-time text functionality

Where ICT supports real-time text alongside voice, characters shall be transmitted as soon as they are entered so that the conversation flows in step with speech rather than after a send action. RTT shall be available in parallel with the voice channel so that a user can switch between or combine speaking and typing within the same call, and the implementation shall align with the recognised RTT transport profiles (for example RFC 4103 for SIP-based calls).

Applies to: Voice ICT that offers a text channel intended to complement or substitute for speech during a call, including softphones, mobile dialer apps, unified-communications clients, and gateways that bridge voice and text users.

WCAG cross-reference: n/a (real-time communication modality with no direct WCAG SC mapping).

Assessment heuristics:

• Confirm that text is transmitted character-by-character (or in small bursts) with sub-second latency end-to-end rather than buffered until the user presses send.

• Verify that voice and RTT can be active simultaneously within the same session and that switching between them does not tear down the call.

• Test interoperability with at least one independent RTT-capable endpoint to confirm conformance with the negotiated transport profile.

• Confirm that incoming RTT is presented visibly while a call is ringing, in progress, and being torn down.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.2).

clause-6-3

6.3 Caller identification

Where ICT presents caller identification (incoming-call display, in-call participant list, missed-call log), the information shall be available in both visual and auditory forms so that users who cannot rely on a screen and users who cannot rely on audio cues both receive it. The same applies to other call-status cues that the system signals through caller-ID metadata, such as withheld-number indications or organisation labels.

Applies to: Voice communication endpoints and services that display or announce caller-identity information for incoming, in-progress, or historical calls.

WCAG cross-reference: n/a (multi-modal output requirement bound to the voice-ICT context).

Assessment heuristics:

• Verify that incoming caller-ID information can be rendered as on-screen text and as spoken or otherwise audible output, with the user able to enable either channel.

• Confirm that the in-call participant list and missed-call log expose the same identity information through the platform accessibility API so screen readers can announce it.

• Test the auditory presentation in realistic ambient conditions to confirm it is loud and clear enough to be perceived during a typical call setup.

• Confirm that withheld, blocked, or unknown-caller states are surfaced through the same dual-channel path as identified callers.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.3).

clause-6-4

6.4 Alternatives to voice-based services

Where a service depends on a voice interaction to be completed (for example interactive voice response menus, voicemail retrieval, voice-only support hotlines), the provider shall offer an equivalent non-voice channel so that users who cannot speak or hear can reach the same outcome. The alternative channel shall provide comparable functionality and timeliness rather than being limited to a deferred email response.

Applies to: Voice-driven services exposed to end users, including IVR systems, contact centres, voicemail, and any service whose primary completion path is a spoken interaction.

WCAG cross-reference: n/a (service-design requirement rather than an interface-level WCAG SC).

Assessment heuristics:

• Inventory every user-facing service that uses voice as the primary completion path and confirm at least one functionally equivalent non-voice channel exists (RTT, text chat, web form with real-time agent, video relay).

• Verify that the alternative channel can complete the same set of tasks (menu navigation, authentication, account changes, escalation) as the voice path.

• Confirm that response timeliness on the alternative channel is comparable to the voice channel during the same operating hours.

• Document the alternative channel in the support documentation referenced by Clause 12 so users can discover it without already using the inaccessible voice path.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.4).

clause-6-5

6.5 Video communication

Where ICT supports real-time video as part of a two-way voice call (for example to enable sign-language conversation or lip-reading), the video stream shall meet the resolution, frame rate, dynamic range, and audio-video synchronisation needed for those visual cues to be perceived. The clause is concerned with the picture quality of the live video itself rather than with prerecorded captions or descriptions, but it shares failure modes with the WCAG synchronised-media criteria, which is why the roll-up cross-references the prerecorded-captions and audio-description success criteria as related context.

Applies to: Video calls within voice-communication ICT, including video-relay services, video-conferencing endpoints used for accessibility purposes, and any product that offers a video lane alongside voice.

WCAG cross-reference: sc-1-2-2, sc-1-2-5.

Assessment heuristics:

• Confirm the negotiated video profile delivers a frame rate and resolution sufficient for sign-language perception (commonly cited as at least 20 frames per second at a resolution that preserves hand and facial detail).

• Measure end-to-end audio-video synchronisation and verify lip-reading remains viable within the tolerance the codec advertises.

• Test the call under typical network conditions (constrained uplink, packet loss) and confirm the system degrades gracefully rather than dropping frame rate below the sign-language threshold without warning.

• Verify the user can choose to enable the video lane without losing the voice or RTT channels in the same call.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.5).

clause-6-6

6.6 Alternatives to video-based services

Where ICT provides real-time video-based communication together with answering machine, auto attendant, or interactive response facilities, it should let users reach the information and complete the tasks those facilities offer without hearing (for audible information), without speech (for spoken commands), and without vision (for visual information). This clause is a recommendation ("should"), not a requirement. Real-time captions or RTT handling are examples of solutions that can meet it.

Applies to: Video calling and video contact-centre ICT that includes video voicemail, auto attendants, or interactive video response menus.

WCAG cross-reference: n/a (communication-service recommendation with no WCAG equivalent).

Assessment heuristics:

• Inventory the answering, auto-attendant, and interactive response features available in video calls.

• Confirm audible prompts are also presented visually (captions or text), spoken commands have a non-speech alternative (keypad, RTT, on-screen selection), and visual prompts have a non-visual alternative.

• Walk each automated video flow without hearing, without speech, and without vision, and record any task that cannot be completed.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 6.6).

Clause 7: ICT with Video

Clause 7 of EN 301 549 V3.2.1 covers accessibility requirements for ICT that plays back video content with synchronised audio. It focuses on the playback path: how captions render, how audio description tracks are presented alongside the programme audio, and how the player exposes user controls for those alternative tracks. Authoring of captions and audio description for the underlying media falls under Clause 9 (web) and Clause 10 (non-web documents); Clause 7 governs the playback surface that exposes those tracks to the viewer.

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 7, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. Summaries below are paraphrased; consult the official document for normative wording.

clause-7-1

7.1 Captioning playback

ICT that plays video with synchronised audio shall play back captions when the source media carries a caption track, render them synchronised with the corresponding audio, and preserve the visual styling and positioning that the caption author specified. The playback surface shall not strip, re-time, or visually obscure caption text during normal playback.

Applies to: Video playback.

WCAG cross-reference: sc-1-2-2, sc-1-2-4.

Assessment heuristics:

• Play a sample asset that carries a caption track and confirm captions render automatically when the user has captions enabled.

• Measure caption-to-audio synchronisation under normal and seek-resumed playback; flag drift greater than a few hundred milliseconds.

• Verify that author-specified caption positioning and styling (line breaks, speaker labels, italics) survive the playback pipeline.

• Confirm captions do not get cropped, overlapped by player chrome, or hidden behind on-screen controls.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 7.1).

clause-7-2

7.2 Audio description playback

ICT that plays video with synchronised audio shall play back an audio description track when the source media provides one, mix it cleanly with the programme audio without clipping or muting the original soundtrack outside the described intervals, and keep the description timing aligned with the visual content it describes.

Applies to: Video playback.

WCAG cross-reference: sc-1-2-3, sc-1-2-5.

Assessment heuristics:

• Play media that carries both an audio description track and a standard track and confirm the player can select and mix the description channel.

• Confirm description narration falls in the intended pauses and does not collide with programme dialogue.

• Verify that selecting audio description does not silence or unduly attenuate the original programme audio outside the described intervals.

• Test that the description track remains available on platform-specific output paths (HDMI, Bluetooth, AirPlay) and not just on the local speaker.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 7.2).

clause-7-3

7.3 User controls for captions and audio description

The video player UI shall expose discoverable controls that let the user turn captions and audio description on and off independently of one another, and those controls shall be as easy to reach as the player's primary playback controls (play, pause, volume). User preference for each track type shall persist so that the next time the user opens compatible media the same selection applies.

Applies to: Video player UI.

WCAG cross-reference: sc-1-2-2, sc-1-2-3.

Assessment heuristics:

• Open the player UI and confirm the caption toggle and the audio description toggle are reachable from the same surface and at the same depth as the play/pause and volume controls.

• Verify that the captions toggle and the audio description toggle operate independently — neither requires the other to be enabled or disabled.

• Toggle each control, close the player, reopen with a different compatible asset, and confirm the previous selection persists.

• Confirm the controls expose accessible names through the platform accessibility API so that screen readers and switch-access users can operate them.

• Where caption styling (font size, colour, background opacity) is configurable, confirm the styling controls are reachable from the same player UI surface and that the chosen styling persists across sessions.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/ (Clause 7.3).

Clause 8: Hardware

Clause 8 of EN 301 549 V3.2.1 collects accessibility requirements that apply to hardware ICT (kiosks, payment terminals, ticket machines, telephones, set-top boxes, peripheral devices). It builds on the generic operable-parts and locking rules from Clause 5 and adds hardware-specific requirements for spoken output, stationary public-use ICT, mechanically operable parts including keys, tickets, and fare cards whose orientation must be discernible by touch (8.4.3), and tactile indication of how to start speech output on shared-use ICT (8.5).

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 8, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. Summaries below are paraphrased; consult the official document for normative wording.

clause-8-1

8.1 General

Hardware ICT shall meet the accessibility requirements that follow in Clause 8, in addition to the generic requirements in Clause 5 that apply whenever the hardware exposes operable parts, locking or toggle controls, key input, multi-action input, or accessibility activation. Clause 8 narrows the generic rules to physical product form factors and adds requirements that only make sense for hardware.

Applies to: All hardware ICT products and the hardware aspects of mixed hardware/software systems.

Assessment heuristics:

• Maintain a single conformance matrix that covers both the relevant Clause 5 rows and the Clause 8 rows for the hardware under test, so reviewers can see at a glance which generic and hardware-specific rules apply.

• Identify which hardware mode each Clause 8 subsection targets (speech output, stationary public ICT, mechanical controls, identification cards) and confirm the matrix marks each as "applicable", "not applicable with rationale", or "non-conformant with mitigation".

• Document the relationship between Clause 5 operable-parts findings and Clause 8.4 mechanical hardware findings so the same physical control is not double-counted or split between reports.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-8-2

8.2 Hardware products with speech output

Where hardware provides built-in speech output as part of an accessibility mode (for example, a self-service kiosk that speaks the on-screen content), the speech shall be in the same language as the visible content where that language is supported, the user shall be able to adjust the volume independently of any other audio, and a private listening option (such as a standard headphone jack) shall be provided so confidential content is not exposed to bystanders.

Applies to: Hardware ICT with built-in speech output, including ATMs, ticket machines, voting machines, and information kiosks.

Assessment heuristics:

• Verify the speech output language tracks the visible content language and that switching the on-screen language also switches the speech voice or pronunciation.

• Confirm an independent volume control for the speech channel, with at least one increment loud enough for a user with mild hearing loss in a noisy public environment.

• Confirm a standard headphone jack (or equivalent private listening surface) is present, reachable from the operating position, and routes the speech output without exposing it on the speaker.

• Test that the private listening surface mutes the public speaker automatically when the jack is engaged.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-8-3

8.3 Stationary ICT

Stationary ICT installed in public spaces (kiosks, ATMs, ticket machines, information terminals) shall be positioned and dimensioned so that users in wheelchairs and users of short stature can reach all operable parts, view all displays, and complete every essential task without assistance. Where the device displays text or symbols, the visual presentation shall meet the contrast requirements that apply to the relevant viewing distance.

Applies to: Kiosks and other stationary devices installed for public use.

WCAG cross-reference: sc-1-4-3.

Assessment heuristics:

• Verify that the highest operable part is within the forward or side reach range specified for seated users, and that the lowest operable part is reachable without forcing the user to crouch.

• Confirm clear floor space in front of the device for a wheelchair approach (frontal or parallel) and that the approach is not blocked by a kick plate, fixed bollard, or queue rail.

• Measure the contrast ratio of on-screen text and critical status indicators at the typical viewing distance and angle for a seated user.

• Confirm displays are tilted or mounted so glare from overhead lighting does not obscure content for a seated viewer.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-8-4

8.4 Mechanical hardware (locks and operable parts)

Mechanical hardware such as locks, latches, hinges, paper trays, card slots, and removable panels shall be operable without requiring tight grasping, pinching, or twisting of the wrist, shall be operable with one hand, and shall not require simultaneous activation of multiple operable parts. The activation force for any mechanical operable part shall stay within the ceiling defined for generic operable parts in Clause 5.5.

Applies to: Physical controls and mechanical operable parts on hardware ICT, including service-door locks, paper jam access panels, and consumable replacement mechanisms that an end user is expected to operate.

WCAG cross-reference: sc-2-1-1.

Assessment heuristics:

• Inspect each user-facing mechanical control and confirm it can be operated with a closed fist or single finger (no pinch, twist, or tight grasp required).

• Measure activation force against the Clause 5.5 ceiling and document any mechanism that requires more than the permitted force.

• Verify single-hand operation for each consumable replacement path (paper roll, card stack, receipt drawer) end to end.

• Confirm no maintenance task expected of the end user requires simultaneous activation of two separated controls.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-8-4-3

8.4.3 Keys, tickets and fare cards

Where ICT provides keys, tickets, or fare cards whose orientation matters for later use, their correct orientation shall be discernible by touch.

Applies to: Identification media that the user must insert, swipe, or tap with a specific orientation, including transit fare cards, hotel keycards, parking tickets, and access badges.

Assessment heuristics:

• Inspect each card design for a tactile orientation feature that is distinguishable from the card edge by touch alone.

• Confirm the tactile feature unambiguously indicates the correct insertion or tap orientation for every reader the card is used with.

• Test card orientation discovery with users who are blind or have low vision and confirm they can insert the card on the first attempt without sighted assistance.

• For systems that issue cards on demand (ticket machine), confirm the issued card preserves the tactile orientation feature regardless of which print path generated it.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-8-5

8.5 Tactile indication of speech mode

Where ICT is designed for shared use and speech output is available, it shall provide a tactile indication of how to start the speech mode of operation, for example Braille instructions next to the control that activates speech.

Applies to: Shared-use ICT with speech output, such as kiosks, ticket machines, ATMs, and information points.

WCAG cross-reference: n/a (hardware requirement with no WCAG equivalent).

Assessment heuristics:

• Locate the control or action that starts speech output and confirm a tactile indication identifies it.

• Confirm a blind user can find the indication and start speech mode without sighted assistance.

• Where Braille is used, check that it is legible and describes the action accurately.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

Clause 9: Web

Clause 9 of EN 301 549 V3.2.1 adopts WCAG 2.1 Level A and AA success criteria wholesale and reapplies them to web pages, web applications, and web content delivered through user agents. Each sub-clause is the EN 301 549 web-context obligation that procurement and conformance reports map to: the requirement is the WCAG criterion, and the assessment work is to demonstrate, document, and evidence that the website meets it. Sub-clauses are organised by WCAG principle (1 perceivable, 2 operable, 3 understandable, 4 robust) and inherit the criterion numbering directly, so 9.X.Y.Z always corresponds to WCAG X.Y.Z.

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 9, https://www.etsi.org/deliver/etsi_en/301500_301599/301549/. Summaries below are paraphrased; consult the official document for normative wording and the linked WCAG 2.2 reference files for criterion-level technical detail.

clause-9-1-1-1

9.1.1.1 Non-text content

Every non-text element on the page (images, icons, charts, image-based form controls, decorative ornaments, CAPTCHA, sensory content) shall expose a programmatic text alternative that conveys equivalent information or function. Decorative-only graphics shall be marked so assistive technology can skip them.

Applies to: Images and media.

WCAG cross-reference: sc-1-1-1.

Assessment heuristics:

• Run an automated scan that flags every <img>, <svg>, <canvas>, CSS background-as-content, and image-based control that lacks an accessible name, then triage manually.

• Confirm decorative graphics use alt="", role="presentation", or aria-hidden="true" so screen readers skip them rather than announce filenames.

• Capture the alt-text policy and the list of CAPTCHA/sensory alternatives in the accessibility conformance report so procurers can verify coverage.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-2-1

9.1.2.1 Audio-only and video-only (prerecorded)

Prerecorded audio-only content shall have an equivalent text transcript, and prerecorded video-only (silent) content shall have either a text description or an equivalent audio track. The alternative shall be reachable from the same context as the media.

Applies to: Prerecorded media.

WCAG cross-reference: sc-1-2-1.

Assessment heuristics:

• Inventory every audio-only and silent-video asset and verify each links to a transcript or descriptive alternative in the same page region.

• Confirm transcripts capture speaker turns, non-speech audio that carries meaning, and time markers where helpful.

• Verify alternatives are exposed as page content (not stranded behind a "download" link the screen reader cannot locate without instructions).

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-2-2

9.1.2.2 Captions (prerecorded)

Prerecorded video with synchronized audio shall include captions for all dialogue and meaningful non-speech audio. Captions shall be synchronized with the soundtrack and shall identify speakers when ambiguity would otherwise arise.

Applies to: Prerecorded video.

WCAG cross-reference: sc-1-2-2.

Assessment heuristics:

• Confirm every prerecorded video bundles a caption track (WebVTT, TTML, or open captions burned into the video) and that the player exposes a caption toggle.

• Spot-check caption timing, accuracy, and speaker identification against the audio.

• Reject auto-generated captions that fall below the procurement quality bar (typical thresholds: >95% word accuracy, <3 second latency, correct punctuation and speaker labels).

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-2-3

9.1.2.3 Audio description or media alternative (prerecorded)

Prerecorded video with synchronized audio shall provide either an audio description of essential visual content or a full text media alternative covering both the audio and visual tracks. Audio descriptions shall be inserted during natural pauses in dialogue.

Applies to: Prerecorded video.

WCAG cross-reference: sc-1-2-3.

Assessment heuristics:

• For each prerecorded video, confirm either a descriptive audio track or a full media-alternative document is available and discoverable from the video page.

• Verify the media alternative covers setting, on-screen text, actions, and speaker cues sufficient for a non-sighted user to follow the narrative.

• Confirm the alternative is rendered in accessible HTML or a tagged document rather than only in an image or scanned PDF.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-2-4

9.1.2.4 Captions (live)

Live video that carries synchronized audio shall be accompanied by live captions covering all spoken content as it is delivered.

Applies to: Live video.

WCAG cross-reference: sc-1-2-4.

Assessment heuristics:

• Confirm the live-streaming platform supports a live-caption track and that the production workflow assigns either a stenographer, re-speaker, or vetted automated service.

• Measure end-to-end caption latency against the procurement target (typically under 3 seconds) and accuracy during fast or technical speech.

• Verify the caption display does not occlude key visual content and remains visible on small viewports.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-2-5

9.1.2.5 Audio description (prerecorded)

Prerecorded video with synchronized audio shall provide an audio description track that narrates essential visual information not conveyed through the existing soundtrack.

Applies to: Prerecorded video.

WCAG cross-reference: sc-1-2-5.

Assessment heuristics:

• Verify each prerecorded video offers either an alternate "with audio description" version or an in-player audio-description toggle.

• Confirm descriptions cover essential setting, character actions, on-screen text, and visual cues, and that they fit within natural dialogue pauses without extending the video timeline.

• Capture the audio-description coverage policy (in-house, vendor, automated) in the conformance report.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-3-1

9.1.3.1 Info and relationships

Information, structure, and relationships conveyed visually (headings, lists, tables, form labels, regions, emphasis) shall also be exposed in the page's markup so assistive technology can present the same relationships. Use semantic HTML elements or correct ARIA roles rather than styling alone.

Applies to: Page structure.

WCAG cross-reference: sc-1-3-1.

Assessment heuristics:

• Validate the page outline (headings, landmarks, lists, tables, form groupings) against the visual design and reject any element that conveys structure only through styling.

• Confirm data tables identify header cells; complex tables additionally use scope, headers, or id associations.

• Verify form fields use <label> (or aria-labelledby/aria-label) so screen readers announce field purpose without relying on placeholder text.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-3-2

9.1.3.2 Meaningful sequence

Where the sequence in which content is presented affects meaning, the reading order in the DOM (or the source order used by assistive technology) shall match the intended sequence.

Applies to: Content order.

WCAG cross-reference: sc-1-3-2.

Assessment heuristics:

• Disable CSS and confirm the unstyled page still reads in a logical order that preserves meaning.

• Inspect any layout that relies on order, float, position: absolute, or grid-area reordering and confirm the DOM order matches the intended reading order.

• Verify screen-reader reading order with NVDA, VoiceOver, and JAWS on representative templates.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-3-3

9.1.3.3 Sensory characteristics

Instructions for understanding and operating content shall not rely solely on sensory characteristics such as shape, colour, size, visual location, orientation, or sound.

Applies to: Instructions.

WCAG cross-reference: sc-1-3-3.

Assessment heuristics:

• Search content for purely sensory references ("click the round button", "the menu on the right", "the green item", "after the beep") and require a non-sensory companion cue (label, name, position in list).

• Verify form-error guidance references field names or descriptive text rather than colour or shape only.

• Confirm onboarding and tutorial copy survives a screen-reader read-through without losing instructional meaning.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-3-4

9.1.3.4 Orientation

Content shall not restrict its view and operation to a single display orientation (portrait or landscape) unless a specific orientation is essential.

Applies to: Responsive pages.

WCAG cross-reference: sc-1-3-4.

Assessment heuristics:

• Rotate the device or emulator through portrait and landscape on representative pages and confirm the page remains usable in both orientations.

• Inspect the markup for screen.orientation.lock() calls or CSS that hides content based on orientation and require a documented essential-use justification.

• Confirm responsive breakpoints accommodate both orientations without requiring horizontal scrolling beyond the reflow allowance.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-3-5

9.1.3.5 Identify input purpose

Form fields that collect information about the user shall expose the field's purpose programmatically (typically through HTML autocomplete tokens) so user agents and assistive technology can pre-fill or relabel them.

Applies to: Form fields.

WCAG cross-reference: sc-1-3-5.

Assessment heuristics:

• Inventory all fields covered by WCAG's user-information list (name, email, address, phone, payment, etc.) and verify each carries the correct autocomplete token.

• Confirm autofill works with browser and password-manager extensions on representative forms.

• Reject fields that disable autocomplete without a documented security justification, since this directly breaks the criterion.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-1

9.1.4.1 Use of color

Colour shall not be the sole visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Applies to: Visual design.

WCAG cross-reference: sc-1-4-1.

Assessment heuristics:

• Render representative screens in greyscale and confirm every status, link, validation cue, chart series, and required-field indicator remains distinguishable.

• Verify links inside body copy carry a non-colour distinguishing affordance (underline, weight, icon) in addition to colour.

• Confirm charts and data visualisations layer pattern, label, or shape on top of colour encoding.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-2

9.1.4.2 Audio control

Audio that plays automatically for more than three seconds shall provide a user-accessible mechanism to pause, stop, or independently control its volume, separate from the overall system volume.

Applies to: Sound and media.

WCAG cross-reference: sc-1-4-2.

Assessment heuristics:

• Inventory every page that emits audio on load and confirm either the audio is under three seconds, muted by default, or paired with a visible pause/stop control.

• Verify the control is reachable by keyboard and announced by screen readers.

• Confirm the volume control is independent of system volume so screen-reader users can lower the page audio without losing the assistive-technology track.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-3

9.1.4.3 Contrast (minimum)

Visual presentation of text and images of text shall meet a contrast ratio of at least 4.5:1 against the background, or 3:1 for large-scale text (typically 18pt regular or 14pt bold).

Applies to: Text and graphics.

WCAG cross-reference: sc-1-4-3.

Assessment heuristics:

• Run a contrast analyser across the design system tokens and every text-on-image, text-on-gradient, and disabled-state combination.

• Confirm hover, focus, and active states (and any seasonal or branded theming) still pass the threshold rather than only the default state.

• Capture the contrast-token matrix in the conformance report so future theme changes can be regression-tested.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-4

9.1.4.4 Resize text

Text shall be resizable up to 200% without loss of content or functionality and without requiring assistive technology (other than browser zoom).

Applies to: Text sizing.

WCAG cross-reference: sc-1-4-4.

Assessment heuristics:

• Zoom representative pages to 200% in the browser and confirm no text is clipped, overlapped, or pushed off-screen and that no interactive control becomes unreachable.

• Verify the design uses relative units (rem, em, %) rather than fixed px values for body text and form controls.

• Confirm components such as modals, sticky headers, and toasts continue to behave at 200% zoom.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-5

9.1.4.5 Images of text

Where text can be presented as text, images of text shall be avoided. Logos and decorative essential text are the only permitted exceptions.

Applies to: Text presentation.

WCAG cross-reference: sc-1-4-5.

Assessment heuristics:

• Scan the page for <img> elements that contain rendered text (banners, hero graphics, infographic labels) and replace with real text wherever the visual treatment does not require an image.

• Confirm any remaining text-in-image carries an alt attribute that exactly matches the depicted text.

• Verify localisation pipelines produce text rather than re-rendered image variants per locale.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-10

9.1.4.10 Reflow

Content shall be presentable without loss of information or functionality and without requiring scrolling in two dimensions at a viewport width equivalent to 320 CSS pixels (or height of 256 CSS pixels for content that scrolls horizontally as intended).

Applies to: Layout and scrolling.

WCAG cross-reference: sc-1-4-10.

Assessment heuristics:

• Resize the browser to a 320 CSS-pixel-wide viewport (or zoom to 400% on a 1280-pixel display) and confirm the page reflows to a single column without horizontal scrolling.

• Identify any element that requires two-dimensional scrolling (data tables, charts, code blocks, maps) and confirm it qualifies under the "essential by usage" exception.

• Verify fixed headers, footers, and side panels do not collapse content area below a usable size at the reflow viewport.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-11

9.1.4.11 Non-text contrast

Visual presentation of user-interface components (boundaries, focus indicators, states) and graphical objects required to understand content shall have a contrast ratio of at least 3:1 against adjacent colours.

Applies to: UI components and graphics.

WCAG cross-reference: sc-1-4-11.

Assessment heuristics:

• Audit the design system for control boundaries (buttons, inputs, checkboxes, focus rings) and confirm each state meets the 3:1 ratio.

• Confirm meaningful chart, infographic, and icon strokes pass the threshold against their background.

• Reject low-contrast "ghost" buttons and decorative focus indicators that fall below 3:1.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-12

9.1.4.12 Text spacing

When users override text spacing (line height to 1.5×, paragraph spacing to 2×, letter spacing to 0.12×, word spacing to 0.16× the font size), no content shall be lost and no functionality shall break.

Applies to: Content spacing.

WCAG cross-reference: sc-1-4-12.

Assessment heuristics:

• Apply a bookmarklet or user stylesheet that injects the four required spacing overrides and confirm representative pages still render without clipped or overlapping text.

• Verify fixed-height containers expand or scroll rather than truncate text when spacing increases.

• Confirm form controls, navigation, and modals retain readable layout under the overrides.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-1-4-13

9.1.4.13 Content on hover or focus

Additional content that appears on hover or keyboard focus (tooltips, popovers, custom menus) shall be dismissible, hoverable, and persistent until dismissed, focus moves away, or the information is no longer valid.

Applies to: Dynamic content.

WCAG cross-reference: sc-1-4-13.

Assessment heuristics:

• Inventory tooltips, popovers, and hover menus and confirm Esc dismisses them without moving focus.

• Verify the user can move the pointer onto the new content (to read or interact) without it disappearing.

• Confirm the new content remains visible until the user dismisses it, moves focus, or it becomes invalid; reject auto-hide timers under five seconds.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-1-1

9.2.1.1 Keyboard

All functionality of the content shall be operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement (drawing, gesture).

Applies to: Input methods.

WCAG cross-reference: sc-2-1-1.

Assessment heuristics:

• Unplug the mouse and complete every primary user journey using only the keyboard, including custom components, modals, drag-and-drop, and rich editors.

• Confirm mouse-only handlers (onmousedown, onclick without keyboard equivalents) have keyboard counterparts (onkeydown/onkeyup or native interactive elements).

• Document any path-dependent operation that legitimately resists keyboard access and confirm an alternative is offered.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-1-2

9.2.1.2 No keyboard trap

If keyboard focus can be moved to a component, focus shall also be removable from that component using only the keyboard, using standard exit keys (Tab/Shift+Tab or Esc) or a documented mechanism.

Applies to: Navigation.

WCAG cross-reference: sc-2-1-2.

Assessment heuristics:

• Tab through every page region (modals, embedded media, custom widgets, iframes) and confirm focus can leave each one without resorting to the mouse.

• Test embedded third-party content (video players, ad slots, payment iframes) for trapping behaviour and document mitigations.

• Confirm modal dialogs implement an Esc-to-close handler and restore focus to the triggering element.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-1-4

9.2.1.4 Character key shortcuts

If a keyboard shortcut is implemented using only letter, punctuation, number, or symbol characters, the user shall be able to turn the shortcut off, remap it, or restrict it to fire only when focus is on a relevant control.

Applies to: Keyboard bindings.

WCAG cross-reference: sc-2-1-4.

Assessment heuristics:

• Inventory all single-key shortcuts in the application and verify each is either off by default, remappable, or scoped to focused elements.

• Confirm a settings surface exists to disable or rebind shortcuts and that the setting persists across sessions.

• Test with speech-input users (Dragon, Voice Access) where stray dictation can otherwise trigger destructive shortcuts.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-2-1

9.2.2.1 Timing adjustable

For each time limit set by the content, the user shall be able to turn off, adjust, or extend the limit, with documented exceptions for real-time events, essential limits, and limits longer than 20 hours.

Applies to: Timed content.

WCAG cross-reference: sc-2-2-1.

Assessment heuristics:

• Inventory session-timeout, form-completion, quiz, and inactivity-warning timers and confirm each offers a turn-off, adjust, or extend mechanism.

• Verify users receive a warning before the timer expires with at least 20 seconds to extend.

• Document essential time limits (auctions, exam clocks) and confirm they are flagged in the conformance report.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-2-2

9.2.2.2 Pause, stop, hide

Moving, blinking, scrolling, or auto-updating content that starts automatically, lasts more than five seconds, and is presented alongside other content shall provide a mechanism for the user to pause, stop, or hide it.

Applies to: Animated content.

WCAG cross-reference: sc-2-2-2.

Assessment heuristics:

• Inventory carousels, marquees, animated banners, ticker feeds, and auto-refreshing widgets and confirm each exposes a pause/stop control.

• Verify the control is operable by keyboard and announced by screen readers.

• Confirm essential animations (loading spinners, video playback) are excluded only with documented justification.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-3-1

9.2.3.1 Three flashes or below threshold

Web pages shall not contain anything that flashes more than three times in any one-second period, or shall ensure the flashing area falls below the general and red-flash thresholds defined in WCAG.

Applies to: Animation safety.

WCAG cross-reference: sc-2-3-1.

Assessment heuristics:

• Run flashing content (animated GIFs, video segments, motion graphics) through PEAT or an equivalent analyser and document any failures.

• Confirm policy gates upload paths so user-generated video that fails the threshold is rejected or muted.

• Document any approved high-risk content behind an explicit warning and a click-through gate.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-1

9.2.4.1 Bypass blocks

A mechanism shall be provided to bypass blocks of content that are repeated on multiple web pages (typically a "skip to main content" link or properly structured landmark regions).

Applies to: Navigation aids.

WCAG cross-reference: sc-2-4-1.

Assessment heuristics:

• Confirm the page exposes either a visible skip link as the first focusable element or correct ARIA landmarks (banner, navigation, main, contentinfo).

• Verify the skip link is announced and focusable, even if visually hidden by default, and that activating it moves focus into the main region.

• Test landmark navigation in NVDA, VoiceOver, and JAWS to confirm regions are reachable.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-2

9.2.4.2 Page titled

Web pages shall have titles that describe their topic or purpose.

Applies to: Page identification.

WCAG cross-reference: sc-2-4-2.

Assessment heuristics:

• Crawl the site and confirm every page sets a <title> element that is unique, descriptive, and front-loaded with the most distinguishing information.

• Verify single-page-application route changes update the document title programmatically.

• Reject placeholder titles ("Untitled", "Document", template strings) in the production build.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-3

9.2.4.3 Focus order

When users navigate sequentially through content, focus shall move in an order that preserves meaning and operability.

Applies to: Keyboard navigation.

WCAG cross-reference: sc-2-4-3.

Assessment heuristics:

• Tab through every page region and confirm focus follows the visual reading order without unexpected jumps.

• Reject positive tabindex values that override natural document order except where rigorously justified.

• Confirm modals, drawers, and inline panels trap focus appropriately and restore focus to a logical location on close.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-4

9.2.4.4 Link purpose (in context)

The purpose of each link shall be determinable from the link text alone or from the link text together with its programmatically determined context (sentence, paragraph, list item, table cell, or section heading).

Applies to: Link text.

WCAG cross-reference: sc-2-4-4.

Assessment heuristics:

• Extract every link's text and immediate context and confirm the purpose is clear when read in isolation by a screen reader's links list.

• Replace generic "click here", "read more", and "learn more" text with descriptive equivalents or supplement with aria-label/aria-labelledby.

• Verify icon-only links carry an accessible name from aria-label, visually-hidden text, or the surrounding text.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-5

9.2.4.5 Multiple ways

More than one way shall be available to locate a web page within a set of web pages, except where the page is the result of, or a step in, a process.

Applies to: Navigation options.

WCAG cross-reference: sc-2-4-5.

Assessment heuristics:

• Confirm the site provides at least two of: a search, a sitemap, a table of contents, related-pages list, or a navigation menu that exposes every page.

• Verify the alternative navigation methods are themselves accessible (keyboard, screen reader) and reach the same destination pages.

• Document process-step pages (checkout, wizards) that are properly excluded.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-6

9.2.4.6 Headings and labels

Headings and form labels shall describe the topic or purpose of the section or field they introduce.

Applies to: Content structure.

WCAG cross-reference: sc-2-4-6.

Assessment heuristics:

• Read the heading outline of each page in isolation and confirm it summarises the page contents.

• Confirm every form field carries a unique, descriptive label that explains what to enter (not just a generic "Field 1" pattern).

• Reject duplicate or ambiguous labels and headings that obscure rather than describe the section.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-4-7

9.2.4.7 Focus visible

Any keyboard-operable user-interface component shall have a visible focus indicator when it receives focus.

Applies to: Focus indication.

WCAG cross-reference: sc-2-4-7.

Assessment heuristics:

• Tab through representative pages and confirm every interactive element shows a clearly visible focus indicator that is not removed by outline: none without a replacement.

• Verify focus indicators remain visible in dark mode, high-contrast mode, and against busy backgrounds.

• Confirm custom widgets (menubars, listboxes, comboboxes) render a focus ring on the active descendant.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-5-1

9.2.5.1 Pointer gestures

All functionality that uses multipoint or path-based gestures (pinch, two-finger swipe, drag-along-a-path) shall also be operable with a single pointer without a path-based gesture, unless such a gesture is essential.

Applies to: Gesture interactions.

WCAG cross-reference: sc-2-5-1.

Assessment heuristics:

• Inventory gestures (pinch-zoom on maps and images, swipe-to-delete on lists, drag-to-reorder, custom touch interactions) and verify each offers a single-point alternative (button, menu, keyboard control).

• Confirm the alternative is reachable on both touch and desktop and is announced to assistive technology.

• Document essential gestures (signature capture, drawing) that legitimately retain a path requirement.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-5-2

9.2.5.2 Pointer cancellation

For functionality operated with a single pointer, the down-event shall not execute the action; the action shall fire on the up-event, be abortable before up, or be reversible.

Applies to: Pointer activation.

WCAG cross-reference: sc-2-5-2.

Assessment heuristics:

• Confirm primary actions (form submit, navigation, destructive controls) fire on click/pointerup rather than pointerdown/mousedown.

• Verify that dragging off a button before release cancels the action.

• Document essential exceptions (instrument keys in a music app, hold-to-talk) and confirm they are flagged accordingly.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-5-3

9.2.5.3 Label in name

For user-interface components with labels that include visible text, the accessible name shall contain the visible text.

Applies to: Accessible names.

WCAG cross-reference: sc-2-5-3.

Assessment heuristics:

• Audit components with visible text labels and confirm the accessible name (computed via aria-label, aria-labelledby, or content) begins with or contains that visible text.

• Reject aria-label overrides that replace the visible text with a different string, since this breaks voice-input ("click Sign up").

• Validate with the browser accessibility tree inspector across a representative component sample.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-2-5-4

9.2.5.4 Motion actuation

Functionality that can be operated by device motion (shake, tilt) or user motion (waving in front of a camera) shall also be operable through standard UI controls, and the motion-actuation behaviour shall be disableable.

Applies to: Device-motion controls.

WCAG cross-reference: sc-2-5-4.

Assessment heuristics:

• Inventory motion-triggered features (shake-to-undo, tilt-to-pan, gesture-camera input) and confirm each offers a UI-based alternative.

• Verify a setting exists to disable motion actuation and that the setting persists.

• Confirm involuntary motion (tremor, transport) does not trigger destructive actions in default settings.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-1-1

9.3.1.1 Language of page

The default human language of each web page shall be programmatically determined (typically through the lang attribute on the root <html> element).

Applies to: Page language.

WCAG cross-reference: sc-3-1-1.

Assessment heuristics:

• Confirm every page sets <html lang="…"> to a valid BCP 47 tag matching the rendered language.

• Verify localisation pipelines emit the language attribute per locale rather than serving a fixed default.

• Capture the language-attribute policy in the conformance report and gate it in CI.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-1-2

9.3.1.2 Language of parts

The human language of each passage or phrase whose language differs from the page default shall be programmatically determined.

Applies to: Content language.

WCAG cross-reference: sc-3-1-2.

Assessment heuristics:

• Audit content for embedded quotations, names, and phrases in a language other than the page default and confirm each carries a lang attribute on the enclosing element.

• Verify CMS authoring tools expose a language-attribute control to editors.

• Test with a screen reader configured for the page default and confirm it switches voice when reading the tagged phrase.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-2-1

9.3.2.1 On focus

When any user-interface component receives focus, it shall not initiate a change of context (new window, focus jump, form submission, major content change).

Applies to: Input behavior.

WCAG cross-reference: sc-3-2-1.

Assessment heuristics:

• Tab through every interactive control and confirm receiving focus does not trigger navigation, submission, or a popup.

• Reject autocomplete dropdowns that move focus or submit on focus rather than on user action.

• Confirm select elements do not navigate on focus change in custom widgets.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-2-2

9.3.2.2 On input

Changing the setting of a user-interface component shall not automatically cause a change of context unless the user has been warned before using the component.

Applies to: Input changes.

WCAG cross-reference: sc-3-2-2.

Assessment heuristics:

• Inventory controls that change context on input (select-to-navigate menus, auto-submit toggles, dynamic filter forms) and confirm either the behaviour is removed or an explicit warning precedes the control.

• Provide a submit button for forms that change context, rather than firing on input change.

• Confirm the warning is announced to assistive technology before the control receives focus.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-2-3

9.3.2.3 Consistent navigation

Navigational mechanisms that are repeated on multiple pages within a set shall appear in the same relative order each time they are presented.

Applies to: Navigation pattern.

WCAG cross-reference: sc-3-2-3.

Assessment heuristics:

• Compare the global header, footer, sidebar, and breadcrumb regions across a representative sample of pages and confirm element order is consistent.

• Verify user-initiated reordering (drag-to-customise) defaults to the shared baseline and persists per user only.

• Capture the navigation pattern in the design system and gate against drift in CI.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-2-4

9.3.2.4 Consistent identification

Components that have the same functionality across pages within a set shall be identified consistently (icon, label, accessible name).

Applies to: UI consistency.

WCAG cross-reference: sc-3-2-4.

Assessment heuristics:

• Inventory recurring controls (search button, print, share, help) and confirm each uses the same icon, label, and accessible name across pages.

• Reject inconsistent labelling like "Search" on one page and "Find" on another for the same component.

• Capture the labelling baseline in the design system content guide.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-3-1

9.3.3.1 Error identification

When an input error is automatically detected, the failing item shall be identified and the error described in text.

Applies to: Form errors.

WCAG cross-reference: sc-3-3-1.

Assessment heuristics:

• Trigger validation errors on representative forms and confirm each failing field is identified by name and the error is described in text (not just colour or icon).

• Verify error messages are associated with their inputs via aria-describedby or programmatic relationship so screen readers announce them.

• Confirm summary error messages link to the offending fields.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-3-2

9.3.3.2 Labels or instructions

Labels or instructions shall be provided when content requires user input.

Applies to: Form guidance.

WCAG cross-reference: sc-3-3-2.

Assessment heuristics:

• Confirm every form field carries a persistent visible label (not placeholder text alone) and supplementary instructions for any non-obvious format requirements.

• Verify required fields are identified both visually and programmatically (aria-required, required).

• Confirm format hints (date format, password rules) are visible before the user begins typing rather than only on error.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-3-3

9.3.3.3 Error suggestion

When an input error is automatically detected and suggestions for correction are known, the suggestions shall be provided to the user unless doing so would jeopardise security or the purpose of the content.

Applies to: Error recovery.

WCAG cross-reference: sc-3-3-3.

Assessment heuristics:

• Audit validation messages and confirm each one offers a concrete correction suggestion (expected format, allowed values, closest match) where suggestions are derivable.

• Reject vague "Invalid input" messages in favour of actionable guidance.

• Document security-sensitive fields (e.g. credentials) where suggestions are intentionally withheld.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-3-3-4

9.3.3.4 Error prevention (legal, financial, data)

For pages that cause legal commitments, financial transactions, modify or delete user-controlled data, or submit test responses, submissions shall be reversible, checked for input errors with a chance to correct, or confirmed before final submission.

Applies to: Critical input.

WCAG cross-reference: sc-3-3-4.

Assessment heuristics:

• Inventory checkout, contract-signing, data-deletion, and exam-submission flows and confirm each offers reversal, validation-with-correction, or an explicit confirmation step.

• Verify the confirmation surface displays the data that will be committed in a reviewable format.

• Confirm destructive actions outside these flows (account deletion, bulk operations) follow the same pattern.

Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/

clause-9-4-1-1

9.4.1.1 Parsing

In content implemented using markup languages, elements shall have complete start and end tags, shall be nested according to specification, shall not contain duplicate attributes, and any IDs shall be unique. (EN 301 549 V3.2.1 inherits this from WCAG 2.1; WCAG 2.2 has since deprecated it, but the criterion remains in force for EN 301 549 conformance.)