---
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`](wcag-22.md) 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`](../../../../../instructions/accessibility/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.

## Clause Roll-up

| Clause    | Title                                                   | Applies to                     | WCAG cross-ref                                                   | Reference                                                |
|-----------|---------------------------------------------------------|--------------------------------|------------------------------------------------------------------|----------------------------------------------------------|
| 5.1       | Functional performance                                  | All ICT                        | n/a                                                              | [clause-group-5.md#clause-5-1](#clause-5-1)              |
| 5.2       | Activation of accessibility features                    | All ICT                        | n/a                                                              | [clause-group-5.md#clause-5-2](#clause-5-2)              |
| 5.3       | Biometrics                                              | Biometric authentication       | n/a                                                              | [clause-group-5.md#clause-5-3](#clause-5-3)              |
| 5.4       | Preservation of accessibility information               | All ICT                        | n/a                                                              | [clause-group-5.md#clause-5-4](#clause-5-4)              |
| 5.5       | Operable parts                                          | Hardware controls              | [sc-2-5-5](wcag-22.md#sc-2-5-5)                                  | [clause-group-5.md#clause-5-5](#clause-5-5)              |
| 5.6       | Locking and toggle controls                             | Hardware locks                 | n/a                                                              | [clause-group-5.md#clause-5-6](#clause-5-6)              |
| 5.7       | Key repeat                                              | Keyboard input                 | n/a                                                              | [clause-group-5.md#clause-5-7](#clause-5-7)              |
| 5.8       | Double-strike key acceptance                            | Keyboard input                 | n/a                                                              | [clause-group-5.md#clause-5-8](#clause-5-8)              |
| 5.9       | Simultaneous user actions                               | Multi-touch and chorded input  | n/a                                                              | [clause-group-5.md#clause-5-9](#clause-5-9)              |
| 5.10      | Privacy                                                 | All ICT                        | n/a                                                              | [clause-group-5.md#clause-5-10](#clause-5-10)            |
| 6.1       | Audio bandwidth for speech                              | Voice communication            | n/a                                                              | [clause-group-6.md#clause-6-1](#clause-6-1)              |
| 6.2       | Real-time text functionality                            | Voice ICT with text            | n/a                                                              | [clause-group-6.md#clause-6-2](#clause-6-2)              |
| 6.3       | Caller identification                                   | Voice communication            | n/a                                                              | [clause-group-6.md#clause-6-3](#clause-6-3)              |
| 6.4       | Alternatives to voice-based services                    | Voice services                 | n/a                                                              | [clause-group-6.md#clause-6-4](#clause-6-4)              |
| 6.5       | Video communication                                     | Video calls                    | [sc-1-2-2](wcag-22.md#sc-1-2-2), [sc-1-2-5](wcag-22.md#sc-1-2-5) | [clause-group-6.md#clause-6-5](#clause-6-5)              |
| 6.6       | Interoperability with emergency services                | Emergency voice access         | n/a                                                              | [clause-group-6.md#clause-6-6](#clause-6-6)              |
| 7.1       | Captioning playback                                     | Video playback                 | [sc-1-2-2](wcag-22.md#sc-1-2-2), [sc-1-2-4](wcag-22.md#sc-1-2-4) | [clause-group-7.md#clause-7-1](#clause-7-1)              |
| 7.2       | Audio description playback                              | Video playback                 | [sc-1-2-3](wcag-22.md#sc-1-2-3), [sc-1-2-5](wcag-22.md#sc-1-2-5) | [clause-group-7.md#clause-7-2](#clause-7-2)              |
| 7.3       | User controls for captions and audio description        | Video player UI                | [sc-1-2-2](wcag-22.md#sc-1-2-2), [sc-1-2-3](wcag-22.md#sc-1-2-3) | [clause-group-7.md#clause-7-3](#clause-7-3)              |
| 8.1       | General                                                 | All hardware                   | n/a                                                              | [clause-group-8.md#clause-8-1](#clause-8-1)              |
| 8.2       | Hardware products with speech output                    | Speech-output hardware         | n/a                                                              | [clause-group-8.md#clause-8-2](#clause-8-2)              |
| 8.3       | Stationary ICT                                          | Kiosks and stationary devices  | [sc-1-4-3](wcag-22.md#sc-1-4-3)                                  | [clause-group-8.md#clause-8-3](#clause-8-3)              |
| 8.4       | Mechanical hardware (locks and operable parts)          | Physical controls              | [sc-2-1-1](wcag-22.md#sc-2-1-1)                                  | [clause-group-8.md#clause-8-4](#clause-8-4)              |
| 8.5       | Tickets, fare cards, and keycards                       | Identification media           | n/a                                                              | [clause-group-8.md#clause-8-5](#clause-8-5)              |
| 9.1.1.1   | Non-text content                                        | Images and media               | [sc-1-1-1](wcag-22.md#sc-1-1-1)                                  | [clause-group-9.md#clause-9-1-1-1](#clause-9-1-1-1)      |
| 9.1.2.1   | Audio-only and video-only (prerecorded)                 | Prerecorded media              | [sc-1-2-1](wcag-22.md#sc-1-2-1)                                  | [clause-group-9.md#clause-9-1-2-1](#clause-9-1-2-1)      |
| 9.1.2.2   | Captions (prerecorded)                                  | Prerecorded video              | [sc-1-2-2](wcag-22.md#sc-1-2-2)                                  | [clause-group-9.md#clause-9-1-2-2](#clause-9-1-2-2)      |
| 9.1.2.3   | Audio description or media alternative (prerecorded)    | Prerecorded video              | [sc-1-2-3](wcag-22.md#sc-1-2-3)                                  | [clause-group-9.md#clause-9-1-2-3](#clause-9-1-2-3)      |
| 9.1.2.4   | Captions (live)                                         | Live video                     | [sc-1-2-4](wcag-22.md#sc-1-2-4)                                  | [clause-group-9.md#clause-9-1-2-4](#clause-9-1-2-4)      |
| 9.1.2.5   | Audio description (prerecorded)                         | Prerecorded video              | [sc-1-2-5](wcag-22.md#sc-1-2-5)                                  | [clause-group-9.md#clause-9-1-2-5](#clause-9-1-2-5)      |
| 9.1.3.1   | Info and relationships                                  | Page structure                 | [sc-1-3-1](wcag-22.md#sc-1-3-1)                                  | [clause-group-9.md#clause-9-1-3-1](#clause-9-1-3-1)      |
| 9.1.3.2   | Meaningful sequence                                     | Content order                  | [sc-1-3-2](wcag-22.md#sc-1-3-2)                                  | [clause-group-9.md#clause-9-1-3-2](#clause-9-1-3-2)      |
| 9.1.3.3   | Sensory characteristics                                 | Instructions                   | [sc-1-3-3](wcag-22.md#sc-1-3-3)                                  | [clause-group-9.md#clause-9-1-3-3](#clause-9-1-3-3)      |
| 9.1.3.4   | Orientation                                             | Responsive pages               | [sc-1-3-4](wcag-22.md#sc-1-3-4)                                  | [clause-group-9.md#clause-9-1-3-4](#clause-9-1-3-4)      |
| 9.1.3.5   | Identify input purpose                                  | Form fields                    | [sc-1-3-5](wcag-22.md#sc-1-3-5)                                  | [clause-group-9.md#clause-9-1-3-5](#clause-9-1-3-5)      |
| 9.1.4.1   | Use of color                                            | Visual design                  | [sc-1-4-1](wcag-22.md#sc-1-4-1)                                  | [clause-group-9.md#clause-9-1-4-1](#clause-9-1-4-1)      |
| 9.1.4.2   | Audio control                                           | Sound and media                | [sc-1-4-2](wcag-22.md#sc-1-4-2)                                  | [clause-group-9.md#clause-9-1-4-2](#clause-9-1-4-2)      |
| 9.1.4.3   | Contrast (minimum)                                      | Text and graphics              | [sc-1-4-3](wcag-22.md#sc-1-4-3)                                  | [clause-group-9.md#clause-9-1-4-3](#clause-9-1-4-3)      |
| 9.1.4.4   | Resize text                                             | Text sizing                    | [sc-1-4-4](wcag-22.md#sc-1-4-4)                                  | [clause-group-9.md#clause-9-1-4-4](#clause-9-1-4-4)      |
| 9.1.4.5   | Images of text                                          | Text presentation              | [sc-1-4-5](wcag-22.md#sc-1-4-5)                                  | [clause-group-9.md#clause-9-1-4-5](#clause-9-1-4-5)      |
| 9.1.4.10  | Reflow                                                  | Layout and scrolling           | [sc-1-4-10](wcag-22.md#sc-1-4-10)                                | [clause-group-9.md#clause-9-1-4-10](#clause-9-1-4-10)    |
| 9.1.4.11  | Non-text contrast                                       | UI components and graphics     | [sc-1-4-11](wcag-22.md#sc-1-4-11)                                | [clause-group-9.md#clause-9-1-4-11](#clause-9-1-4-11)    |
| 9.1.4.12  | Text spacing                                            | Content spacing                | [sc-1-4-12](wcag-22.md#sc-1-4-12)                                | [clause-group-9.md#clause-9-1-4-12](#clause-9-1-4-12)    |
| 9.1.4.13  | Content on hover or focus                               | Dynamic content                | [sc-1-4-13](wcag-22.md#sc-1-4-13)                                | [clause-group-9.md#clause-9-1-4-13](#clause-9-1-4-13)    |
| 9.2.1.1   | Keyboard                                                | Input methods                  | [sc-2-1-1](wcag-22.md#sc-2-1-1)                                  | [clause-group-9.md#clause-9-2-1-1](#clause-9-2-1-1)      |
| 9.2.1.2   | No keyboard trap                                        | Navigation                     | [sc-2-1-2](wcag-22.md#sc-2-1-2)                                  | [clause-group-9.md#clause-9-2-1-2](#clause-9-2-1-2)      |
| 9.2.1.4   | Character key shortcuts                                 | Keyboard bindings              | [sc-2-1-4](wcag-22.md#sc-2-1-4)                                  | [clause-group-9.md#clause-9-2-1-4](#clause-9-2-1-4)      |
| 9.2.2.1   | Timing adjustable                                       | Timed content                  | [sc-2-2-1](wcag-22.md#sc-2-2-1)                                  | [clause-group-9.md#clause-9-2-2-1](#clause-9-2-2-1)      |
| 9.2.2.2   | Pause, stop, hide                                       | Animated content               | [sc-2-2-2](wcag-22.md#sc-2-2-2)                                  | [clause-group-9.md#clause-9-2-2-2](#clause-9-2-2-2)      |
| 9.2.3.1   | Three flashes or below threshold                        | Animation safety               | [sc-2-3-1](wcag-22.md#sc-2-3-1)                                  | [clause-group-9.md#clause-9-2-3-1](#clause-9-2-3-1)      |
| 9.2.4.1   | Bypass blocks                                           | Navigation aids                | [sc-2-4-1](wcag-22.md#sc-2-4-1)                                  | [clause-group-9.md#clause-9-2-4-1](#clause-9-2-4-1)      |
| 9.2.4.2   | Page titled                                             | Page identification            | [sc-2-4-2](wcag-22.md#sc-2-4-2)                                  | [clause-group-9.md#clause-9-2-4-2](#clause-9-2-4-2)      |
| 9.2.4.3   | Focus order                                             | Keyboard navigation            | [sc-2-4-3](wcag-22.md#sc-2-4-3)                                  | [clause-group-9.md#clause-9-2-4-3](#clause-9-2-4-3)      |
| 9.2.4.4   | Link purpose (in context)                               | Link text                      | [sc-2-4-4](wcag-22.md#sc-2-4-4)                                  | [clause-group-9.md#clause-9-2-4-4](#clause-9-2-4-4)      |
| 9.2.4.5   | Multiple ways                                           | Navigation options             | [sc-2-4-5](wcag-22.md#sc-2-4-5)                                  | [clause-group-9.md#clause-9-2-4-5](#clause-9-2-4-5)      |
| 9.2.4.6   | Headings and labels                                     | Content structure              | [sc-2-4-6](wcag-22.md#sc-2-4-6)                                  | [clause-group-9.md#clause-9-2-4-6](#clause-9-2-4-6)      |
| 9.2.4.7   | Focus visible                                           | Focus indication               | [sc-2-4-7](wcag-22.md#sc-2-4-7)                                  | [clause-group-9.md#clause-9-2-4-7](#clause-9-2-4-7)      |
| 9.2.5.1   | Pointer gestures                                        | Gesture interactions           | [sc-2-5-1](wcag-22.md#sc-2-5-1)                                  | [clause-group-9.md#clause-9-2-5-1](#clause-9-2-5-1)      |
| 9.2.5.2   | Pointer cancellation                                    | Pointer activation             | [sc-2-5-2](wcag-22.md#sc-2-5-2)                                  | [clause-group-9.md#clause-9-2-5-2](#clause-9-2-5-2)      |
| 9.2.5.3   | Label in name                                           | Accessible names               | [sc-2-5-3](wcag-22.md#sc-2-5-3)                                  | [clause-group-9.md#clause-9-2-5-3](#clause-9-2-5-3)      |
| 9.2.5.4   | Motion actuation                                        | Device-motion controls         | [sc-2-5-4](wcag-22.md#sc-2-5-4)                                  | [clause-group-9.md#clause-9-2-5-4](#clause-9-2-5-4)      |
| 9.3.1.1   | Language of page                                        | Page language                  | [sc-3-1-1](wcag-22.md#sc-3-1-1)                                  | [clause-group-9.md#clause-9-3-1-1](#clause-9-3-1-1)      |
| 9.3.1.2   | Language of parts                                       | Content language               | [sc-3-1-2](wcag-22.md#sc-3-1-2)                                  | [clause-group-9.md#clause-9-3-1-2](#clause-9-3-1-2)      |
| 9.3.2.1   | On focus                                                | Input behavior                 | [sc-3-2-1](wcag-22.md#sc-3-2-1)                                  | [clause-group-9.md#clause-9-3-2-1](#clause-9-3-2-1)      |
| 9.3.2.2   | On input                                                | Input changes                  | [sc-3-2-2](wcag-22.md#sc-3-2-2)                                  | [clause-group-9.md#clause-9-3-2-2](#clause-9-3-2-2)      |
| 9.3.2.3   | Consistent navigation                                   | Navigation pattern             | [sc-3-2-3](wcag-22.md#sc-3-2-3)                                  | [clause-group-9.md#clause-9-3-2-3](#clause-9-3-2-3)      |
| 9.3.2.4   | Consistent identification                               | UI consistency                 | [sc-3-2-4](wcag-22.md#sc-3-2-4)                                  | [clause-group-9.md#clause-9-3-2-4](#clause-9-3-2-4)      |
| 9.3.3.1   | Error identification                                    | Form errors                    | [sc-3-3-1](wcag-22.md#sc-3-3-1)                                  | [clause-group-9.md#clause-9-3-3-1](#clause-9-3-3-1)      |
| 9.3.3.2   | Labels or instructions                                  | Form guidance                  | [sc-3-3-2](wcag-22.md#sc-3-3-2)                                  | [clause-group-9.md#clause-9-3-3-2](#clause-9-3-3-2)      |
| 9.3.3.3   | Error suggestion                                        | Error recovery                 | [sc-3-3-3](wcag-22.md#sc-3-3-3)                                  | [clause-group-9.md#clause-9-3-3-3](#clause-9-3-3-3)      |
| 9.3.3.4   | Error prevention (legal, financial, data)               | Critical input                 | [sc-3-3-4](wcag-22.md#sc-3-3-4)                                  | [clause-group-9.md#clause-9-3-3-4](#clause-9-3-3-4)      |
| 9.4.1.1   | Parsing                                                 | Code validity                  | [sc-4-1-1](wcag-22.md#sc-4-1-1)                                  | [clause-group-9.md#clause-9-4-1-1](#clause-9-4-1-1)      |
| 9.4.1.2   | Name, role, value                                       | Accessible components          | [sc-4-1-2](wcag-22.md#sc-4-1-2)                                  | [clause-group-9.md#clause-9-4-1-2](#clause-9-4-1-2)      |
| 9.4.1.3   | Status messages                                         | Notifications                  | [sc-4-1-3](wcag-22.md#sc-4-1-3)                                  | [clause-group-9.md#clause-9-4-1-3](#clause-9-4-1-3)      |
| 10.1.1.1  | Non-text content                                        | Images in documents            | [sc-1-1-1](wcag-22.md#sc-1-1-1)                                  | [clause-group-10.md#clause-10-1-1-1](#clause-10-1-1-1)   |
| 10.1.2.1  | Audio-only and video-only (prerecorded)                 | Prerecorded media in documents | [sc-1-2-1](wcag-22.md#sc-1-2-1)                                  | [clause-group-10.md#clause-10-1-2-1](#clause-10-1-2-1)   |
| 10.1.2.2  | Captions (prerecorded)                                  | Video in documents             | [sc-1-2-2](wcag-22.md#sc-1-2-2)                                  | [clause-group-10.md#clause-10-1-2-2](#clause-10-1-2-2)   |
| 10.1.2.3  | Audio description or media alternative                  | Video in documents             | [sc-1-2-3](wcag-22.md#sc-1-2-3)                                  | [clause-group-10.md#clause-10-1-2-3](#clause-10-1-2-3)   |
| 10.1.3.1  | Info and relationships                                  | Document structure             | [sc-1-3-1](wcag-22.md#sc-1-3-1)                                  | [clause-group-10.md#clause-10-1-3-1](#clause-10-1-3-1)   |
| 10.1.3.2  | Meaningful sequence                                     | Content order in documents     | [sc-1-3-2](wcag-22.md#sc-1-3-2)                                  | [clause-group-10.md#clause-10-1-3-2](#clause-10-1-3-2)   |
| 10.1.3.3  | Sensory characteristics                                 | Document instructions          | [sc-1-3-3](wcag-22.md#sc-1-3-3)                                  | [clause-group-10.md#clause-10-1-3-3](#clause-10-1-3-3)   |
| 10.1.4.1  | Use of color                                            | Visual design in documents     | [sc-1-4-1](wcag-22.md#sc-1-4-1)                                  | [clause-group-10.md#clause-10-1-4-1](#clause-10-1-4-1)   |
| 10.1.4.2  | Audio control                                           | Sound in documents             | [sc-1-4-2](wcag-22.md#sc-1-4-2)                                  | [clause-group-10.md#clause-10-1-4-2](#clause-10-1-4-2)   |
| 10.1.4.3  | Contrast (minimum)                                      | Text and graphics in documents | [sc-1-4-3](wcag-22.md#sc-1-4-3)                                  | [clause-group-10.md#clause-10-1-4-3](#clause-10-1-4-3)   |
| 10.2.1.1  | Keyboard                                                | Document navigation            | [sc-2-1-1](wcag-22.md#sc-2-1-1)                                  | [clause-group-10.md#clause-10-2-1-1](#clause-10-2-1-1)   |
| 10.2.1.2  | No keyboard trap                                        | Document input                 | [sc-2-1-2](wcag-22.md#sc-2-1-2)                                  | [clause-group-10.md#clause-10-2-1-2](#clause-10-2-1-2)   |
| 10.2.4.2  | Page titled                                             | Document identification        | [sc-2-4-2](wcag-22.md#sc-2-4-2)                                  | [clause-group-10.md#clause-10-2-4-2](#clause-10-2-4-2)   |
| 10.2.4.3  | Focus order                                             | Document focus                 | [sc-2-4-3](wcag-22.md#sc-2-4-3)                                  | [clause-group-10.md#clause-10-2-4-3](#clause-10-2-4-3)   |
| 10.3.1.1  | Language of document                                    | Document language              | [sc-3-1-1](wcag-22.md#sc-3-1-1)                                  | [clause-group-10.md#clause-10-3-1-1](#clause-10-3-1-1)   |
| 11.1.1.1  | Non-text content                                        | UI graphics and icons          | [sc-1-1-1](wcag-22.md#sc-1-1-1)                                  | [clause-group-11.md#clause-11-1-1-1](#clause-11-1-1-1)   |
| 11.1.3.1  | Info and relationships                                  | UI structure                   | [sc-1-3-1](wcag-22.md#sc-1-3-1)                                  | [clause-group-11.md#clause-11-1-3-1](#clause-11-1-3-1)   |
| 11.1.3.2  | Meaningful sequence                                     | UI component order             | [sc-1-3-2](wcag-22.md#sc-1-3-2)                                  | [clause-group-11.md#clause-11-1-3-2](#clause-11-1-3-2)   |
| 11.1.3.3  | Sensory characteristics                                 | UI instructions                | [sc-1-3-3](wcag-22.md#sc-1-3-3)                                  | [clause-group-11.md#clause-11-1-3-3](#clause-11-1-3-3)   |
| 11.1.4.1  | Use of color                                            | App visual design              | [sc-1-4-1](wcag-22.md#sc-1-4-1)                                  | [clause-group-11.md#clause-11-1-4-1](#clause-11-1-4-1)   |
| 11.1.4.2  | Audio control                                           | App audio output               | [sc-1-4-2](wcag-22.md#sc-1-4-2)                                  | [clause-group-11.md#clause-11-1-4-2](#clause-11-1-4-2)   |
| 11.1.4.3  | Contrast (minimum)                                      | App contrast ratio             | [sc-1-4-3](wcag-22.md#sc-1-4-3)                                  | [clause-group-11.md#clause-11-1-4-3](#clause-11-1-4-3)   |
| 11.1.4.11 | Non-text contrast                                       | App UI components              | [sc-1-4-11](wcag-22.md#sc-1-4-11)                                | [clause-group-11.md#clause-11-1-4-11](#clause-11-1-4-11) |
| 11.2.1.1  | Keyboard                                                | App keyboard access            | [sc-2-1-1](wcag-22.md#sc-2-1-1)                                  | [clause-group-11.md#clause-11-2-1-1](#clause-11-2-1-1)   |
| 11.2.1.2  | No keyboard trap                                        | App focus management           | [sc-2-1-2](wcag-22.md#sc-2-1-2)                                  | [clause-group-11.md#clause-11-2-1-2](#clause-11-2-1-2)   |
| 11.2.1.3  | Keyboard (no exception)                                 | App keyboard-only mode         | [sc-2-1-3](wcag-22.md#sc-2-1-3)                                  | [clause-group-11.md#clause-11-2-1-3](#clause-11-2-1-3)   |
| 11.2.2.1  | Timing adjustable                                       | App timed interactions         | [sc-2-2-1](wcag-22.md#sc-2-2-1)                                  | [clause-group-11.md#clause-11-2-2-1](#clause-11-2-2-1)   |
| 11.2.2.2  | Pause, stop, hide                                       | App animations                 | [sc-2-2-2](wcag-22.md#sc-2-2-2)                                  | [clause-group-11.md#clause-11-2-2-2](#clause-11-2-2-2)   |
| 11.2.4.3  | Focus order                                             | App focus sequence             | [sc-2-4-3](wcag-22.md#sc-2-4-3)                                  | [clause-group-11.md#clause-11-2-4-3](#clause-11-2-4-3)   |
| 11.2.4.6  | Headings and labels                                     | App labels                     | [sc-2-4-6](wcag-22.md#sc-2-4-6)                                  | [clause-group-11.md#clause-11-2-4-6](#clause-11-2-4-6)   |
| 11.2.4.7  | Focus visible                                           | App focus indication           | [sc-2-4-7](wcag-22.md#sc-2-4-7)                                  | [clause-group-11.md#clause-11-2-4-7](#clause-11-2-4-7)   |
| 11.3.1.1  | Language of software                                    | UI language setting            | [sc-3-1-1](wcag-22.md#sc-3-1-1)                                  | [clause-group-11.md#clause-11-3-1-1](#clause-11-3-1-1)   |
| 11.3.2.1  | On focus                                                | App predictable behavior       | [sc-3-2-1](wcag-22.md#sc-3-2-1)                                  | [clause-group-11.md#clause-11-3-2-1](#clause-11-3-2-1)   |
| 11.3.2.2  | On input                                                | App input behavior             | [sc-3-2-2](wcag-22.md#sc-3-2-2)                                  | [clause-group-11.md#clause-11-3-2-2](#clause-11-3-2-2)   |
| 11.3.2.4  | Consistent identification                               | App consistent UI patterns     | [sc-3-2-4](wcag-22.md#sc-3-2-4)                                  | [clause-group-11.md#clause-11-3-2-4](#clause-11-3-2-4)   |
| 11.3.3.1  | Error identification                                    | App error messages             | [sc-3-3-1](wcag-22.md#sc-3-3-1)                                  | [clause-group-11.md#clause-11-3-3-1](#clause-11-3-3-1)   |
| 11.3.3.2  | Labels or instructions                                  | App guidance                   | [sc-3-3-2](wcag-22.md#sc-3-3-2)                                  | [clause-group-11.md#clause-11-3-3-2](#clause-11-3-3-2)   |
| 11.4.1.2  | Name, role, value                                       | App API accessibility          | [sc-4-1-2](wcag-22.md#sc-4-1-2)                                  | [clause-group-11.md#clause-11-4-1-2](#clause-11-4-1-2)   |
| 11.4.1.3  | Status messages                                         | App state changes              | [sc-4-1-3](wcag-22.md#sc-4-1-3)                                  | [clause-group-11.md#clause-11-4-1-3](#clause-11-4-1-3)   |
| 12.1.1    | Accessibility and compatibility features                | Feature documentation          | n/a                                                              | [clause-group-12.md#clause-12-1-1](#clause-12-1-1)       |
| 12.1.2    | Accessible documentation                                | Help content                   | n/a                                                              | [clause-group-12.md#clause-12-1-2](#clause-12-1-2)       |
| 12.2.2    | Information on accessibility and compatibility features | Support information            | n/a                                                              | [clause-group-12.md#clause-12-2-2](#clause-12-2-2)       |
| 12.2.3    | Effective communication                                 | Support channels               | n/a                                                              | [clause-group-12.md#clause-12-2-3](#clause-12-2-3)       |
| 12.2.4    | Accessible documentation                                | Support materials              | n/a                                                              | [clause-group-12.md#clause-12-2-4](#clause-12-2-4)       |
| 13.1.1    | Access to relay services                                | Relay service access           | n/a                                                              | [clause-group-13.md#clause-13-1-1](#clause-13-1-1)       |
| 13.1.2    | Access to emergency services                            | Emergency service access       | n/a                                                              | [clause-group-13.md#clause-13-1-2](#clause-13-1-2)       |
| 13.2.1    | Real-time text emergency communication                  | Emergency RTT                  | n/a                                                              | [clause-group-13.md#clause-13-2-1](#clause-13-2-1)       |
| 13.2.2    | Caller location for emergency                           | Emergency location data        | n/a                                                              | [clause-group-13.md#clause-13-2-2](#clause-13-2-2)       |
| 13.2.3    | Video relay for emergency                               | Emergency video relay          | n/a                                                              | [clause-group-13.md#clause-13-2-3](#clause-13-2-3)       |

## 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`](wcag-22.md) 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 functional performance, accessibility activation, biometrics, preservation of accessibility metadata, operable parts, locking and toggle controls, key repeat and double-strike handling, simultaneous user actions, and privacy of assistive technology output. 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 Functional performance**

ICT shall provide closed functionality that lets people with the full range of disabilities (visual, hearing, speech, cognitive, manual dexterity) use the product without requiring them to attach personal assistive technology. Where assistive technology is required, the ICT shall expose information and operability through accessibility services so that AT can mediate the interaction.

**Applies to**: All ICT, especially closed systems (kiosks, fixed-function devices) that cannot accept personal AT and must satisfy accessibility through built-in alternative modes.

**WCAG cross-reference**: n/a (clause expresses outcome-oriented functional performance rather than a WCAG SC).

**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.
* For products that depend on external AT, confirm the platform accessibility API surface (UIA, AT-SPI, ATK, AXAPI) is implemented end-to-end.
* 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-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](wcag-22.md#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-5-10

**5.10 Privacy**

Accessibility features that present information audibly or otherwise differently from the default mode (such as screen-reader speech or visual captioning on a kiosk) shall offer the same degree of privacy as the default mode — for example, audio output should be available through a headphone jack so that sensitive content (PINs, balance information) is not exposed publicly.

**Applies to**: ICT that exposes private information when accessibility modes are active, 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.
* Confirm that the visual presentation of private content does not unintentionally become more exposed (large-font rendering on a public screen) when accessibility modes are enabled.
* Document the privacy preservation approach as part of the conformance report.

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 the obligation to interoperate with emergency services for users who cannot rely on voice alone. 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](wcag-22.md#sc-1-2-2), [sc-1-2-5](wcag-22.md#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 Interoperability with emergency services**

Where ICT enables real-time communication to emergency services, it shall support the modalities required for users who cannot rely on voice, including RTT (and, where the system supports real-time video, the video lane) end-to-end through the call path. The clause is concerned with the call reaching an equipped public-safety answering point with the chosen modality intact rather than being silently transcoded or dropped to voice-only.

**Applies to**: Voice and unified-communications ICT that can place calls to national or regional emergency services (for example 112 in the EU, 999, 911).

**WCAG cross-reference**: n/a (network-interoperability requirement with no WCAG equivalent).

**Assessment heuristics**:

* Place test calls to the regional emergency service using each supported modality (voice, RTT, video where offered) and confirm the call is delivered to an appropriately equipped answering point.
* Verify that the modality chosen at call setup is preserved end-to-end and that no gateway downgrades RTT or video to a less accessible form without surfacing the change to the user.
* Confirm that location and caller-identification metadata required by the local emergency framework accompanies the call across every supported modality.
* Document the supported emergency modalities, the regions in which they have been validated, and any known network conditions in which fallback occurs.

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](wcag-22.md#sc-1-2-2), [sc-1-2-4](wcag-22.md#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](wcag-22.md#sc-1-2-3), [sc-1-2-5](wcag-22.md#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](wcag-22.md#sc-1-2-2), [sc-1-2-3](wcag-22.md#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, mechanical locks and physical operable parts, and machine-readable cards used to identify or authenticate the user.

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](wcag-22.md#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](wcag-22.md#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-5

**8.5 Tickets, fare cards, and keycards**

Tickets, fare cards, keycards, and similar machine-readable identification media issued or accepted by ICT shall carry a tactile orientation feature (notch, raised edge, asymmetric shape) so users who are blind or have low vision can insert the card in the correct orientation without sighted assistance.

**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 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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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](wcag-22.md#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.)

**Applies to**: Code validity.

**WCAG cross-reference**: [sc-4-1-1](wcag-22.md#sc-4-1-1).

**Assessment heuristics**:

* Run an HTML validator across representative pages and triage parse errors that would affect assistive-technology interpretation.
* Audit for duplicate `id` attributes that break label, `aria-describedby`, and `aria-labelledby` associations.
* Confirm dynamic content updates (SPA route changes, component re-renders) preserve unique IDs and valid nesting.

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

### clause-9-4-1-2

**9.4.1.2 Name, role, value**

For all user-interface components, the name and role shall be programmatically determined; states, properties, and values that can be set by the user shall be programmatically settable; and notification of changes shall be available to assistive technology.

**Applies to**: Accessible components.

**WCAG cross-reference**: [sc-4-1-2](wcag-22.md#sc-4-1-2).

**Assessment heuristics**:

* Inspect the accessibility tree for every custom component and confirm it exposes a correct role, accessible name, and current state (expanded, selected, checked, pressed).
* Prefer native HTML elements over divs with ARIA where possible; verify ARIA widget patterns follow the ARIA Authoring Practices.
* Test components with NVDA, VoiceOver, and JAWS to confirm state changes are announced.

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

### clause-9-4-1-3

**9.4.1.3 Status messages**

Status messages (success, error, progress, in-page notifications) shall be programmatically determined through role or property so assistive technology can present them without moving focus.

**Applies to**: Notifications.

**WCAG cross-reference**: [sc-4-1-3](wcag-22.md#sc-4-1-3).

**Assessment heuristics**:

* Inventory toasts, inline confirmations, progress indicators, and validation banners and confirm each uses `role="status"`, `role="alert"`, or an appropriate `aria-live` region.
* Verify the live region is present in the DOM before the message is injected so the announcement fires reliably.
* Confirm urgency and politeness levels (`aria-live="polite"` vs `assertive`) match the message importance.

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

## Clause 10: Non-Web Documents

Clause 10 of EN 301 549 V3.2.1 adopts a curated subset of WCAG 2.1 Level A and AA success criteria and reapplies them to non-web documents (tagged PDF, DOCX, PPTX, XLSX, EPUB, ODT, and other portable formats). The reading experience for these formats is driven by document viewers and assistive technology rather than by browsers, so each sub-clause restates the WCAG requirement in terms of what a document author and a document-producing tool chain must encode into the file itself. Live web behaviours (timing, scripted state, dynamic input) are out of scope; the curated list focuses on perceivable content, operable navigation, and understandable language as expressed through document structure and metadata.

Source: ETSI / CEN / CENELEC, EN 301 549 V3.2.1, Clause 10, <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-10-1-1-1

**10.1.1.1 Non-text content**

Every non-text element in the document (images, charts, icons, decorative ornaments, scanned pages) shall carry a text alternative that conveys equivalent information or function, or shall be marked as decorative so assistive technology can skip it. Purely decorative artwork shall be tagged as an artifact; informational graphics shall expose alternative text through the document format's native mechanism (PDF `/Alt`, Office image alt-text, EPUB `alt` attribute).

**Applies to**: Images in documents.

**WCAG cross-reference**: [sc-1-1-1](wcag-22.md#sc-1-1-1).

**Assessment heuristics**:

* Enumerate every image, shape, chart, and icon in the document and confirm each one has either an alternative text string or an "artifact / decorative" tag.
* Open the file in a screen reader (NVDA + Acrobat, VoiceOver + Preview, JAWS + Word) and verify the alternative is announced when navigating to the image.
* Confirm scanned pages have been processed through OCR so the underlying text is available to assistive technology, not just the page image.

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

### clause-10-1-2-1

**10.1.2.1 Audio-only and video-only (prerecorded)**

For prerecorded audio-only content embedded in or referenced by the document, an equivalent text transcript shall be provided. For prerecorded video-only content (silent video), either a text description or an equivalent audio track shall be provided so users who cannot see the video receive the same information.

**Applies to**: Prerecorded media in documents.

**WCAG cross-reference**: [sc-1-2-1](wcag-22.md#sc-1-2-1).

**Assessment heuristics**:

* For each embedded audio file, confirm a transcript is included in the document body or linked from the same page that hosts the audio.
* For each embedded silent video, confirm a textual description or equivalent narration accompanies the video and conveys the same information.
* Verify alternatives are reachable by the document's reading order, not stranded in a separate file the screen reader cannot locate.

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

### clause-10-1-2-2

**10.1.2.2 Captions (prerecorded)**

Prerecorded video with synchronized audio that is embedded in or referenced by the document shall be accompanied by captions for all spoken dialogue and meaningful non-speech audio. Captions shall be either open (burned into the video) or available through a caption track the document viewer can render.

**Applies to**: Video in documents.

**WCAG cross-reference**: [sc-1-2-2](wcag-22.md#sc-1-2-2).

**Assessment heuristics**:

* For each video with audio, verify a synchronized caption track is bundled with the document or made available alongside it.
* Confirm captions cover dialogue, speaker identification when ambiguous, and non-speech sounds that carry meaning.
* Spot-check timing against the audio to confirm captions match speech without drift.

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

### clause-10-1-2-3

**10.1.2.3 Audio description or media alternative (prerecorded)**

Prerecorded video with synchronized audio shall be accompanied by either an audio description of the visual track during natural pauses in dialogue, or a full media alternative (a text document that describes both the audio and the visual track in sequence).

**Applies to**: Video in documents.

**WCAG cross-reference**: [sc-1-2-3](wcag-22.md#sc-1-2-3).

**Assessment heuristics**:

* For each video, confirm either an audio-described version is available or a full text alternative is provided in the document.
* Verify the text alternative includes setting, actions, on-screen text, and speaker cues sufficient for a non-sighted reader to follow the narrative.
* Confirm the alternative is linked from the same context as the video so users can locate it without separate instructions.

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

### clause-10-1-3-1

**10.1.3.1 Info and relationships**

The structure that is conveyed visually (headings, paragraphs, lists, tables, columns, sidebars, captions) shall also be encoded in the document's underlying semantics so assistive technology can present the same relationships. Use real heading styles instead of bold text, real list elements instead of bullet glyphs, and tagged tables with header rows or columns marked as such.

**Applies to**: Document structure.

**WCAG cross-reference**: [sc-1-3-1](wcag-22.md#sc-1-3-1).

**Assessment heuristics**:

* Inspect the document's tag tree (Acrobat Tags pane, Word accessibility checker, EPUB nav doc) and confirm headings, lists, and tables map to their semantic equivalents.
* Verify data tables identify header cells; complex tables additionally use scope or header-id associations so cell relationships are unambiguous.
* Confirm form fields, where present, carry programmatic labels and group associations rather than placeholder text alone.

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

### clause-10-1-3-2

**10.1.3.2 Meaningful sequence**

The reading order encoded in the document shall match the order required to understand the content. Multi-column layouts, sidebars, callouts, and floating images shall be sequenced so a linear read (screen reader, refreshable braille, reflow on small screens) presents content in the author's intended order.

**Applies to**: Content order in documents.

**WCAG cross-reference**: [sc-1-3-2](wcag-22.md#sc-1-3-2).

**Assessment heuristics**:

* Use the viewer's "read order" or "reflow" view to walk the document linearly and confirm the sequence matches the visual narrative.
* For PDFs, inspect the tag tree to confirm sidebars and pull quotes are placed at the intended position rather than interrupting body flow.
* Test with a screen reader on a multi-column page and confirm reading does not cross columns mid-sentence.

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

### clause-10-1-3-3

**10.1.3.3 Sensory characteristics**

Instructions embedded in the document shall not rely solely on sensory properties (shape, colour, size, visual location, sound) to identify referenced elements. Pair a sensory cue with a text descriptor such as the figure number, section title, or field label.

**Applies to**: Document instructions.

**WCAG cross-reference**: [sc-1-3-3](wcag-22.md#sc-1-3-3).

**Assessment heuristics**:

* Search the document for instructional phrasing ("click the green button", "see the chart on the right", "the round icon") and confirm each instance also names the element by label or section.
* Verify cross-references use figure or section identifiers rather than positional shorthand ("see above", "the box on the left").
* Confirm any audio cues are paired with a textual alert that delivers the same information.

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

### clause-10-1-4-1

**10.1.4.1 Use of color**

Colour shall not be the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Pair colour with text, iconography, patterns, or labels so the same information reaches users who cannot perceive the colour distinction.

**Applies to**: Visual design in documents.

**WCAG cross-reference**: [sc-1-4-1](wcag-22.md#sc-1-4-1).

**Assessment heuristics**:

* Review charts, status indicators, highlighted text, and legends; verify each colour distinction is paired with a label, pattern, or icon.
* Convert the document to greyscale and confirm the meaning still comes through.
* Inspect required-field markers and error highlights to confirm they carry text or an icon alongside the colour.

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

### clause-10-1-4-2

**10.1.4.2 Audio control**

When the document auto-plays audio that lasts more than three seconds, it shall provide a mechanism to pause, stop, or independently lower the audio volume without requiring the user to change system-wide settings. Documents that do not auto-play audio satisfy the clause by construction.

**Applies to**: Sound in documents.

**WCAG cross-reference**: [sc-1-4-2](wcag-22.md#sc-1-4-2).

**Assessment heuristics**:

* Open the document and confirm whether any audio starts automatically; if it does, time it against the three-second threshold.
* When auto-play exceeds three seconds, verify a pause or stop control is exposed in the document or by the viewer.
* Confirm volume control is independent of the operating system mixer (in-document slider, viewer-level volume control) so users can lower the document's audio without muting other applications.

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

### clause-10-1-4-3

**10.1.4.3 Contrast (minimum)**

Body text and images of text in the document shall meet a 4.5 to 1 contrast ratio against their background; large-scale text (18 point regular or 14 point bold and above) shall meet a 3 to 1 ratio. Logotypes and incidental text are exempt.

**Applies to**: Text and graphics in documents.

**WCAG cross-reference**: [sc-1-4-3](wcag-22.md#sc-1-4-3).

**Assessment heuristics**:

* Sample representative body and heading styles on each page background colour and measure the contrast ratio with a colour-contrast tool.
* Verify text that overlays photographs, gradients, or watermarks meets the ratio at the worst-case overlap region.
* Confirm images of text used in the document (banners, diagrams with embedded labels) also meet the ratio, or replace them with live text.

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

### clause-10-2-1-1

**10.2.1.1 Keyboard**

Any interactive functionality the document exposes (form fields, buttons, hyperlinks, navigation aids, embedded media controls) shall be operable through a keyboard interface, without requiring specific timings for individual keystrokes. Pointer-only interactions are not acceptable as the sole operating mode.

**Applies to**: Document navigation.

**WCAG cross-reference**: [sc-2-1-1](wcag-22.md#sc-2-1-1).

**Assessment heuristics**:

* Tab through the document and confirm every interactive element receives focus and can be activated with Enter, Space, or the appropriate key for the control type.
* Verify embedded media players expose keyboard-operable play, pause, and seek controls.
* Confirm form submission, signature fields, and bookmark navigation work without the mouse.

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

### clause-10-2-1-2

**10.2.1.2 No keyboard trap**

When the keyboard moves focus into any part of the document, focus shall also be able to move away from that part using the keyboard alone. If a non-standard interaction (modal, embedded media, signature pad) requires a particular key to exit, the exit method shall be discoverable.

**Applies to**: Document input.

**WCAG cross-reference**: [sc-2-1-2](wcag-22.md#sc-2-1-2).

**Assessment heuristics**:

* Tab forward and backward through every interactive region and confirm focus exits each control without requiring the mouse.
* Test embedded media, scripted forms, and signature widgets; confirm Escape, Tab, or a documented key combination releases focus.
* Verify any documented exit shortcut appears in the document's instructions or tooltip text.

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

### clause-10-2-4-2

**10.2.4.2 Page titled**

The document shall carry a title that identifies its topic or purpose. The title shall be stored in the document's metadata (PDF `/Title`, Office document properties, EPUB metadata, ODF meta:title) so viewers and assistive technology can announce it.

**Applies to**: Document identification.

**WCAG cross-reference**: [sc-2-4-2](wcag-22.md#sc-2-4-2).

**Assessment heuristics**:

* Open the document properties dialog and confirm the title field is populated with a descriptive string rather than a file name or boilerplate.
* Configure the viewer to display the document title (Acrobat: View > Page Display > Document Title) and confirm it surfaces in the window chrome.
* Verify automated export pipelines preserve the title across format conversions.

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

### clause-10-2-4-3

**10.2.4.3 Focus order**

When the document supports keyboard navigation, focus shall move through interactive elements in an order that preserves meaning and operability. The tab order shall align with the document's reading order and shall not skip past required fields or jump unexpectedly across the page.

**Applies to**: Document focus.

**WCAG cross-reference**: [sc-2-4-3](wcag-22.md#sc-2-4-3).

**Assessment heuristics**:

* Tab through a form-bearing document and confirm focus moves field-by-field in the same order a sighted user would complete the form.
* For PDFs, inspect the Tab Order setting and confirm it is set to "Use Document Structure" rather than the row or column default.
* Verify focus order remains coherent when the document is reflowed for small-screen viewers.

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

### clause-10-3-1-1

**10.3.1.1 Language of document**

The default human language of the document shall be programmatically identified in the document's metadata or root structure (PDF `/Lang`, Office language property, EPUB `xml:lang` on the root, ODF document language). Assistive technology uses this value to select the correct speech synthesiser and pronunciation rules.

**Applies to**: Document language.

**WCAG cross-reference**: [sc-3-1-1](wcag-22.md#sc-3-1-1).

**Assessment heuristics**:

* Inspect the document properties and confirm the language field is set to a valid BCP 47 tag that matches the document's primary language.
* Open the document with a screen reader configured for a different default language and confirm it switches to the document's declared language during reading.
* Verify automated authoring pipelines emit the language tag rather than relying on viewer defaults.

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

## Clause 11: Software

Clause 11 of EN 301 549 V3.2.1 carries WCAG 2.1 Level A and AA success criteria into the native software application context, covering desktop applications, mobile apps, embedded firmware UIs, and kiosk software. Where Clause 9 binds WCAG to web content, Clause 11 binds the same criteria to UI built on platform toolkits and exposes them through the operating-system accessibility APIs (UIA, AT-SPI, ATK, AXAPI, Android `AccessibilityService`, iOS `UIAccessibility`, Java Access Bridge). Each sub-clause below restates the WCAG outcome in software-UI terms; the linked WCAG cross-reference in the sibling [`wcag-22`](wcag-22.md) skill carries the full technical detail and test procedure.

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

### clause-11-1-1-1

**11.1.1.1 Non-text content**

Software shall expose a text alternative for every non-text UI element (icon button, status glyph, decorative image, chart, captcha) through the platform accessibility API so assistive technologies can read the alternative in place of the graphic. Purely decorative graphics shall be marked so AT can skip them.

**Applies to**: UI graphics and icons rendered by the application or its UI toolkit.

**WCAG cross-reference**: [sc-1-1-1](wcag-22.md#sc-1-1-1).

**Assessment heuristics**:

* Enumerate every icon, image, and graphical control and confirm each has an accessible name exposed through the platform API.
* Run a screen reader (NVDA, JAWS, VoiceOver, TalkBack, Orca) over each window and verify the announced name matches the visual purpose.
* Mark decorative-only graphics as hidden from AT so they do not clutter the accessibility tree.

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

### clause-11-1-3-1

**11.1.3.1 Info and relationships**

Software shall expose UI structure (groupings, lists, tables, headings, form fields and their labels, landmarks) through the platform accessibility API so the relationships conveyed visually are also available programmatically. Toolkit controls shall use the correct semantic roles rather than visually styled generic containers.

**Applies to**: UI structure across windows, dialogs, panes, and complex composite controls.

**WCAG cross-reference**: [sc-1-3-1](wcag-22.md#sc-1-3-1).

**Assessment heuristics**:

* Inspect the accessibility tree (Accessibility Insights, Accerciser, Xcode Accessibility Inspector, Android Layout Inspector) and confirm each visible group maps to a structural element with the correct role.
* Verify form fields are programmatically associated with their labels rather than relying on adjacency alone.
* Confirm data tables expose row and column relationships and that headings expose level information.

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

### clause-11-1-3-2

**11.1.3.2 Meaningful sequence**

The reading and navigation order presented through the accessibility tree shall match the order in which the user is expected to perceive and operate the UI. Visual reflow, RTL mirroring, and asynchronous panel insertion shall not produce an AT traversal order that contradicts the visual sequence.

**Applies to**: Order of UI components as presented to assistive technology.

**WCAG cross-reference**: [sc-1-3-2](wcag-22.md#sc-1-3-2).

**Assessment heuristics**:

* Traverse each window with screen-reader navigation commands and confirm the announced order matches the intended visual reading order.
* Tab through controls and confirm focus moves in the same order an unsupported sighted user would scan.
* Re-check after locale changes, window resizing, and dynamic panel updates.

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

### clause-11-1-3-3

**11.1.3.3 Sensory characteristics**

In-app instructions and prompts shall not rely solely on shape, size, visual location, orientation, or sound to identify the control or action being referenced. Wording shall identify targets by accessible name or position in the structural model so users without that sensory channel can still follow.

**Applies to**: In-app instructions, tutorials, error messages, and tooltips.

**WCAG cross-reference**: [sc-1-3-3](wcag-22.md#sc-1-3-3).

**Assessment heuristics**:

* Scan instructional text for phrases like "the round button", "the icon on the right", or "press the button that beeps" and replace them with accessible-name references.
* When spatial directions are unavoidable, pair them with the accessible name of the target.
* Validate that audio cues are mirrored by a visible state change.

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

### clause-11-1-4-1

**11.1.4.1 Use of color**

Color shall not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a UI state in the application's visual design. A non-color cue (icon, text, pattern, shape, position) shall accompany every color-coded distinction.

**Applies to**: Visual design of the application — status indicators, validation feedback, chart series, theme states.

**WCAG cross-reference**: [sc-1-4-1](wcag-22.md#sc-1-4-1).

**Assessment heuristics**:

* Render each screen in monochrome (or in a high-contrast simulator) and confirm all state distinctions remain perceivable.
* Pair color-coded validation errors with an icon and explicit text.
* For charts, supply patterns, markers, or labels in addition to series color.

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

### clause-11-1-4-2

**11.1.4.2 Audio control**

Where the application plays audio automatically for more than three seconds, it shall provide a mechanism to pause, stop, or independently adjust the application's audio volume separately from overall system volume. Background audio shall not block use of speech output from AT.

**Applies to**: Application audio output — alerts, ambient sound, autoplaying media.

**WCAG cross-reference**: [sc-1-4-2](wcag-22.md#sc-1-4-2).

**Assessment heuristics**:

* Inventory every auto-playing audio source and confirm an in-app control mutes or pauses it within reach of the first focusable control.
* Verify the in-app volume slider is independent of the OS master volume.
* Confirm screen-reader speech remains intelligible while application audio is active.

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

### clause-11-1-4-3

**11.1.4.3 Contrast (minimum)**

Text and images of text rendered by the application shall meet a contrast ratio of at least 4.5:1 against their background, or 3:1 for large text (18 pt regular or 14 pt bold and larger). Inactive controls, pure decoration, and incidental text are exempt.

**Applies to**: Application contrast ratio for text rendered in the UI.

**WCAG cross-reference**: [sc-1-4-3](wcag-22.md#sc-1-4-3).

**Assessment heuristics**:

* Sample foreground and background colors with an eyedropper or contrast analyzer (Colour Contrast Analyser, axe DevTools) across every theme the app ships.
* Re-test after honoring OS dark-mode or high-contrast theme settings.
* Confirm placeholder text and helper text meet the same threshold, not just the primary body text.

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

### clause-11-1-4-11

**11.1.4.11 Non-text contrast**

Visual information needed to identify UI components and their states (focus ring, selected toggle, checkbox tick, slider thumb, input border) and meaningful graphical objects (icons that convey information, chart elements) shall have a contrast ratio of at least 3:1 against adjacent colors.

**Applies to**: UI components and graphical objects rendered by the application.

**WCAG cross-reference**: [sc-1-4-11](wcag-22.md#sc-1-4-11).

**Assessment heuristics**:

* Measure the border or fill of each control state (default, hover, focused, selected, disabled) against the adjacent surface.
* Verify the focus indicator contrasts at least 3:1 with both the focused control's resting state and the surrounding background.
* For informational icons, measure the icon glyph against its background.

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

### clause-11-2-1-1

**11.2.1.1 Keyboard**

All functionality of the application 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 (for example, freehand drawing).

**Applies to**: Application keyboard access across every function exposed in the UI.

**WCAG cross-reference**: [sc-2-1-1](wcag-22.md#sc-2-1-1).

**Assessment heuristics**:

* Disconnect the pointing device and walk through every user task end to end using only the keyboard.
* Verify custom controls implement keyboard equivalents for every mouse gesture (drag, right-click, double-click, hover-reveal).
* Document and justify any path-dependent exception in the conformance report.

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

### clause-11-2-1-2

**11.2.1.2 No keyboard trap**

If keyboard focus can be moved into a component, focus shall be moveable away from that component using only the keyboard, and the user shall be advised of the exit method if it is anything other than standard arrow, tab, or escape keys.

**Applies to**: Application focus management — modal dialogs, embedded controls, custom widgets, plug-in surfaces.

**WCAG cross-reference**: [sc-2-1-2](wcag-22.md#sc-2-1-2).

**Assessment heuristics**:

* Tab into every dialog, popover, embedded WebView, OLE/embedded document, and confirm Tab and Shift+Tab move focus out.
* Verify Escape dismisses modal layers and returns focus to the originating control.
* Where exit requires a non-standard key, surface the instruction on entering the trap zone.

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

### clause-11-2-1-3

**11.2.1.3 Keyboard (no exception)**

All functionality of the application shall be operable through a keyboard interface without exception. This is the stricter AAA-aligned variant of 11.2.1.1 and removes the path-dependent carve-out, so even freehand and continuous gestures must have a keyboard-operable equivalent.

**Applies to**: Application keyboard-only mode, including continuous and path-dependent input flows.

**WCAG cross-reference**: [sc-2-1-3](wcag-22.md#sc-2-1-3).

**Assessment heuristics**:

* Identify every freehand, drag, and continuous-gesture interaction and pair each with a discrete keyboard equivalent (arrow-key nudge, numeric entry, step-through).
* Confirm continuous transforms (rotate, resize, pan) expose keyboard increments and a precise numeric input.
* Test with a switch-access device to validate the keyboard-only path is fully usable.

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

### clause-11-2-2-1

**11.2.2.1 Timing adjustable**

For every time limit the application imposes (session timeout, response window, auto-advance, countdown), the user shall be able to turn off, adjust to at least ten times the default, or extend the limit at least once with a simple action, unless the timing is essential or shorter than 20 hours.

**Applies to**: Application timed interactions — auto-logout, transaction windows, quiz timers, slide auto-advance.

**WCAG cross-reference**: [sc-2-2-1](wcag-22.md#sc-2-2-1).

**Assessment heuristics**:

* Catalog every timer and identify the user-facing control to extend, adjust, or disable it.
* Verify the warning fires at least 20 seconds before the deadline and is announced by AT.
* Confirm session extension is reachable from keyboard focus without first dismissing other UI.

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

### clause-11-2-2-2

**11.2.2.2 Pause, stop, hide**

Moving, blinking, scrolling, or auto-updating content in the application that starts automatically, lasts more than five seconds, or appears alongside other content shall be pausable, stoppable, or hidable by the user, and auto-updating content shall additionally be controllable in update frequency.

**Applies to**: Application animations and auto-updating content — splash animations, busy indicators that exceed five seconds, news tickers, live charts.

**WCAG cross-reference**: [sc-2-2-2](wcag-22.md#sc-2-2-2).

**Assessment heuristics**:

* Expose a global pause control or honor the OS reduced-motion setting (prefers-reduced-motion equivalent) for every long-running animation.
* Provide a stop or hide control on tickers, carousels, and animated status surfaces.
* Verify auto-refresh intervals can be increased or disabled by the user.

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

### clause-11-2-4-3

**11.2.4.3 Focus order**

Where the application can be navigated sequentially and the order affects meaning or operation, the focus order shall preserve meaning and operability. Dynamic content insertion (newly opened panes, just-revealed wizards) shall move focus to the expected next step rather than dropping the user back to the start of the window.

**Applies to**: Application focus sequence across windows, dialogs, and dynamic panel insertion.

**WCAG cross-reference**: [sc-2-4-3](wcag-22.md#sc-2-4-3).

**Assessment heuristics**:

* Tab through each window and confirm focus traverses controls in the order a user would expect to operate them.
* When a modal opens, confirm focus moves into the modal, and when it closes, focus returns to the invoking control.
* In wizards, confirm each step begins with focus on the first actionable control of that step.

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

### clause-11-2-4-6

**11.2.4.6 Headings and labels**

Headings and labels in the application shall describe topic or purpose. Generic strings such as "Button 1", "Input", or unlabeled toolbar buttons shall be replaced with descriptive accessible names so AT users can distinguish controls by their announced name alone.

**Applies to**: Application labels — control labels, section headings, group labels, accessible names exposed to AT.

**WCAG cross-reference**: [sc-2-4-6](wcag-22.md#sc-2-4-6).

**Assessment heuristics**:

* Run a screen reader and list every announced label; flag any non-descriptive or duplicated label for rewording.
* Confirm icon-only buttons carry a tooltip or accessible name that describes the action, not the icon.
* Verify section headings within a window describe the content that follows.

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

### clause-11-2-4-7

**11.2.4.7 Focus visible**

Any keyboard-operable UI component shall have a visible focus indicator whenever it receives keyboard focus. The indicator shall be distinguishable from the control's unfocused appearance and shall not be suppressed by custom theming.

**Applies to**: Application focus indication on every focusable control.

**WCAG cross-reference**: [sc-2-4-7](wcag-22.md#sc-2-4-7).

**Assessment heuristics**:

* Tab through every screen and confirm the currently focused control is visually distinguishable in every theme.
* Replace any CSS or toolkit override that suppresses the default focus ring with an equivalent or stronger indicator.
* Confirm focus visibility on custom controls, embedded WebViews, and surfaces that override platform rendering.

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

### clause-11-3-1-1

**11.3.1.1 Language of software**

The default human language of each application shall be programmatically determinable so AT (and especially screen readers) can select the correct pronunciation, voice, and braille table. The platform locale or accessibility-API language attribute shall reflect the language actually rendered.

**Applies to**: UI language setting reported through the accessibility API or platform locale.

**WCAG cross-reference**: [sc-3-1-1](wcag-22.md#sc-3-1-1).

**Assessment heuristics**:

* Confirm the application sets a language attribute that AT can query (platform locale, NSLocale, `setLanguage`, UIA `LocalizedControlType`).
* When the user switches in-app language, verify the AT-readable language attribute updates accordingly.
* Test with a non-default-language screen reader voice and confirm pronunciation matches the rendered content.

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

### clause-11-3-2-1

**11.3.2.1 On focus**

Receiving focus on a UI component shall not trigger a change of context (opening a new window, moving focus elsewhere, submitting a form, navigating to a different view). Focus shall be a passive event from the user's point of view.

**Applies to**: Application predictable behavior on focus events.

**WCAG cross-reference**: [sc-3-2-1](wcag-22.md#sc-3-2-1).

**Assessment heuristics**:

* Tab through every control and confirm nothing opens, closes, navigates, or submits purely on focus.
* Audit auto-focusing behaviors on dialog open and confirm they reposition focus only, without triggering side effects.
* Verify dropdown menus do not commit selection on focus alone — selection must require an explicit activation key.

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

### clause-11-3-2-2

**11.3.2.2 On input**

Changing the value or state of a UI control shall not automatically cause a change of context unless the user has been advised of the behavior before interacting. Combo-box selection, radio-button toggling, and text entry shall not auto-submit or auto-navigate without explicit warning.

**Applies to**: Application input behavior on value-change events.

**WCAG cross-reference**: [sc-3-2-2](wcag-22.md#sc-3-2-2).

**Assessment heuristics**:

* Change every control's value and confirm no context change occurs unless the user activates a separate submit affordance.
* When auto-submit is essential, surface a visible and AT-announced warning before the user interacts.
* Verify combo-boxes and listboxes only commit selection on enter or activate, not on highlight.

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

### clause-11-3-2-4

**11.3.2.4 Consistent identification**

Components that have the same functionality within the application shall be identified consistently. Save, print, search, cancel, and similar actions shall use the same label, icon, position, and accessible name across every window where they appear.

**Applies to**: Application consistent UI patterns across screens, dialogs, and panes.

**WCAG cross-reference**: [sc-3-2-4](wcag-22.md#sc-3-2-4).

**Assessment heuristics**:

* Compare the labeling and iconography of equivalent actions across every window and flag inconsistencies.
* Maintain a component or token library that enforces consistent accessible names and icons for shared actions.
* Verify keyboard shortcuts for the same action match across surfaces.

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

### clause-11-3-3-1

**11.3.3.1 Error identification**

When an input error is automatically detected in the application, the item in error shall be identified and the error shall be described to the user in text rendered both visually and through the accessibility API. Coloring the field alone or relying on iconography alone is insufficient.

**Applies to**: Application error messages on form validation, command failures, and constraint violations.

**WCAG cross-reference**: [sc-3-3-1](wcag-22.md#sc-3-3-1).

**Assessment heuristics**:

* Trigger each validation error and confirm a text message identifies both the field and the nature of the problem.
* Verify AT announces the error (via `aria-describedby` equivalent, accessible description, or live-region equivalent).
* Confirm focus or AT attention is directed to the first errored field after submission.

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

### clause-11-3-3-2

**11.3.3.2 Labels or instructions**

When the application requires user input, labels or instructions shall be provided so the user knows what data is expected, the required format, and any constraints. Placeholder-only labeling is insufficient because placeholder text disappears on focus and is unreliable through AT.

**Applies to**: Application guidance — input field labels, format hints, required-field markers, help text.

**WCAG cross-reference**: [sc-3-3-2](wcag-22.md#sc-3-3-2).

**Assessment heuristics**:

* Confirm every input has a persistent visible label programmatically associated with the field.
* Surface format constraints (date pattern, length, character set) before the user submits.
* Mark required fields with both a visible indicator and an AT-readable required state.

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

### clause-11-4-1-2

**11.4.1.2 Name, role, value**

For every UI component in the application, the name and role shall be programmatically determinable; states, properties, and values that can be set by the user shall be programmatically settable; and notification of changes to these items shall be available to assistive technology through the platform accessibility API.

**Applies to**: Application API accessibility — every focusable or interactive control, including custom-drawn widgets.

**WCAG cross-reference**: [sc-4-1-2](wcag-22.md#sc-4-1-2).

**Assessment heuristics**:

* Inspect every custom control in the accessibility tree and confirm it exposes role, name, value, and state through the platform API rather than as visual-only attributes.
* Verify state changes (expanded/collapsed, checked/unchecked, selected/unselected) fire accessibility events.
* Walk the UI with a screen reader and confirm role announcements match the rendered control type.

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

### clause-11-4-1-3

**11.4.1.3 Status messages**

Status messages that inform the user of success, progress, or other non-modal state shall be programmatically determinable through role or properties so AT can present them without requiring the user to move focus to the message.

**Applies to**: Application state changes — toast notifications, progress updates, validation summaries, save confirmations.

**WCAG cross-reference**: [sc-4-1-3](wcag-22.md#sc-4-1-3).

**Assessment heuristics**:

* Mark non-modal status surfaces with the platform's live-region or notification role so AT announces them automatically.
* Verify progress, success, and warning messages reach AT without stealing keyboard focus.
* Confirm transient toasts persist long enough to be announced and inspected, or offer a history surface.

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

## Clause 12: Documentation and Support Services

Clause 12 of EN 301 549 V3.2.1 extends accessibility obligations beyond the ICT product itself and onto the documentation that accompanies it and the support services that customers rely on when something goes wrong. Sub-clauses under 12.1 govern product documentation (what features must be described and what accessibility properties the documentation itself must satisfy), and sub-clauses under 12.2 govern the support channel (what accessibility information support agents must surface, how the support channel must accommodate users with disabilities, and what accessibility properties any documentation handed out through support must satisfy).

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

### clause-12-1-1

**12.1.1 Accessibility and compatibility features**

Product documentation shall describe the accessibility and compatibility features that the ICT exposes, including how to activate each feature, the configuration options it offers, any known limitations, and the assistive technologies the product has been tested with. The description shall be discoverable rather than buried as a footnote, so a user evaluating the product can locate the accessibility coverage without prior knowledge of the feature names.

**Applies to**: Feature documentation that ships with the product (printed manuals, in-product help, online documentation portals, release notes, conformance reports).

**WCAG cross-reference**: n/a (documentation-content requirement; not a UI behaviour rule).

**Assessment heuristics**:

* Inventory every accessibility feature the product exposes and confirm each one is documented with activation steps, configuration options, and limitations.
* Verify the documentation lists the assistive technologies the product has been validated against and the platform versions used during validation.
* Confirm the accessibility section is discoverable from the documentation entry points (table of contents, search index, on-product help launcher).
* Cross-check the documentation against the product accessibility conformance report so that no feature claimed in conformance is missing from user-facing documentation.

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

### clause-12-1-2

**12.1.2 Accessible documentation**

The product documentation itself shall meet accessibility requirements equivalent to those that apply to the product. Web-delivered help shall meet the Clause 9 web requirements, downloadable documents shall meet the Clause 10 non-web document requirements, and in-product software help shall meet the Clause 11 software requirements. Inaccessible-only delivery (for example, scanned-image PDFs or video tutorials without captions and transcripts) does not satisfy the clause.

**Applies to**: Help content in every form the product ships it (HTML help portals, downloadable PDFs, embedded software help, printed manuals with electronic counterparts, video tutorials, in-product tooltips, getting-started guides).

**WCAG cross-reference**: n/a (clause defers to Clauses 9, 10, and 11 by reference rather than naming a specific WCAG SC).

**Assessment heuristics**:

* Pick the documentation delivery medium (web, document, software) and apply the corresponding clause group's reference file as the assessment checklist.
* Confirm video tutorials carry captions, transcripts, and audio descriptions where the visual track conveys information.
* Verify downloadable PDFs are tagged, contain real text rather than scanned images, and pass a tagged-PDF accessibility check.
* Confirm in-product help is reachable by keyboard, exposed to platform accessibility APIs, and respects user-configured text size and contrast settings.

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

### clause-12-2-2

**12.2.2 Information on accessibility and compatibility features**

Support services shall be able to surface the same accessibility and compatibility feature information that Clause 12.1.1 places in product documentation. A user who contacts support shall be able to obtain a description of the available accessibility features, activation procedures, known limitations, and supported assistive technologies through the support channel rather than being redirected to documentation they may not be able to read.

**Applies to**: Support information surfaces (help-desk scripts, knowledge-base articles consumed by agents, chatbot responses, support portal landing pages, FAQ entries).

**WCAG cross-reference**: n/a (support-content requirement; not a UI behaviour rule).

**Assessment heuristics**:

* Confirm front-line support agents have a knowledge-base entry that summarises every accessibility feature with activation steps and known limitations.
* Verify the support portal lists the supported assistive technologies and links into the conformance report.
* Spot-check support transcripts to confirm accessibility questions receive substantive answers rather than redirects.
* Confirm that automated support channels (chatbots, IVR menus) recognise accessibility-related intents and route them to the correct knowledge entry or agent.

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

### clause-12-2-3

**12.2.3 Effective communication**

Support services shall accommodate the communication needs of users with disabilities so that a user can request and receive support through a channel they can actually operate. The provider shall offer alternatives to voice-only telephony — for example, real-time text, TTY, video relay or sign-language interpretation, web chat, and email — and shall accept calls placed through telecommunications relay services without dropping or restricting them.

**Applies to**: Live support channels (telephone help desks, video support, web chat, email queues, in-person support counters) and the routing logic that delivers user contacts to those channels.

**WCAG cross-reference**: n/a (service-delivery requirement; not a UI behaviour rule).

**Assessment heuristics**:

* Confirm support is reachable through at least one text-based channel (web chat, email, SMS, or RTT) in addition to voice telephony.
* Verify support phone lines accept inbound relay-service calls and that agents are trained on relay protocol.
* Confirm video support offers captioning and, where the product market includes sign-language users, a sign-language interpretation option.
* Compare response-time service levels across channels and confirm the accessible channels are not deprioritised.
* Train support agents on accessibility-aware communication (plain language, willingness to repeat or rephrase, awareness of assistive-technology constraints).

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

### clause-12-2-4

**12.2.4 Accessible documentation**

Documentation handed to users through the support channel — knowledge-base articles, troubleshooting guides, follow-up emails, attachments, recorded training sessions — shall itself meet the accessibility requirements of the medium in which it is delivered. Web-delivered support content shall meet Clause 9, downloadable attachments shall meet Clause 10, and software-embedded help shall meet Clause 11; the support channel does not get a documentation accessibility exemption that the product documentation does not also enjoy.

**Applies to**: Support-delivered materials in every form (web knowledge-base articles, PDF guides emailed to users, screenshots and diagrams attached to tickets, recorded webinars and tutorials, transcripts).

**WCAG cross-reference**: n/a (clause defers to Clauses 9, 10, and 11 by reference rather than naming a specific WCAG SC).

**Assessment heuristics**:

* Apply the relevant clause-group reference file (9, 10, or 11) to every documentation artefact the support team distributes.
* Confirm that screenshots and diagrams attached to tickets carry alt text or are accompanied by a text description.
* Verify recorded webinars carry captions and that transcripts are offered alongside on-demand recordings.
* Confirm follow-up emails are sent as accessible HTML or plain text rather than as image-only graphics, and that any attached PDFs are tagged.
* Audit the support knowledge base on a regular cadence using the same accessibility tooling applied to the main product documentation.

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

## Clause 13: ICT Providing Relay or Emergency Services

Clause 13 of EN 301 549 V3.2.1 covers ICT that provides telecommunications relay services (bridging users with different communication modes) and ICT that provides access to public emergency services. The sub-clauses bind both the relay or emergency endpoint and the originating ICT to interoperability obligations so that users who depend on text, video, or assistive communication paths reach the same services on the same terms as voice users.

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

### clause-13-1-1

**13.1.1 Access to relay services**

ICT that initiates voice communication shall provide a means by which users can reach available relay services (text relay, video relay, captioned telephony) using the same call-origination affordances as a standard voice call. The path to the relay endpoint shall not impose extra steps, separate apps, or non-accessible address books on users who depend on it.

**Applies to**: Relay service access from any ICT capable of initiating two-way voice communication, including handsets, softphones, web calling clients, and embedded calling features.

**WCAG cross-reference**: n/a (relay-service interoperability requirement rather than a web success criterion).

**Assessment heuristics**:

* Confirm the dial UI accepts the published relay service identifier (number, SIP URI, or equivalent) in the same field as a normal destination.
* Verify the relay endpoint is reachable from the contacts, recents, and speed-dial surfaces, not only from a hidden settings screen.
* Test that user-selected relay modality (TTY, VRS, IP CTS) persists as a per-contact or default preference where the platform supports it.
* Walk the relay call flow with assistive technology (screen reader, switch control) to confirm initiation, in-call indicators, and termination are all operable.

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

### clause-13-1-2

**13.1.2 Access to emergency services**

ICT that supports two-way voice communication shall let users reach the relevant public emergency service using the platform's standard call-origination path. The emergency endpoint shall be reachable without first navigating an inaccessible menu, completing identity steps that block urgent calls, or installing additional software.

**Applies to**: Emergency service access from any ICT capable of initiating two-way voice communication, including mobile handsets, VoIP clients, in-vehicle systems, and connected room or kiosk telephony.

**WCAG cross-reference**: n/a (emergency-service interoperability requirement rather than a web success criterion).

**Assessment heuristics**:

* Place test emergency calls (against a test endpoint or in a regulator-approved test environment) from each supported originating modality and confirm completion.
* Verify the emergency call path is reachable from a lock screen or restricted state where regulation permits, and that AT cues (screen reader announcements, haptics) accompany the connection state.
* Confirm that account-state restrictions (no SIM, prepaid balance, parental controls) do not block emergency dialling.
* Document how the ICT routes emergency calls when multiple SIPs, eSIMs, or carriers are configured, so dispatch routing remains predictable.

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

### clause-13-2-1

**13.2.1 Real-time text emergency communication**

ICT that provides access to emergency services shall accept and transmit real-time text (RTT) for emergency calls, so that users who cannot use voice can convey emergency information character-by-character with no perceptible delay. RTT shall interwork with the receiving public-safety answering point either directly or through a designated text relay path.

**Applies to**: Emergency RTT origination and transport in ICT that originates or carries emergency calls, including handsets, calling clients, carrier networks, and emergency-call gateways.

**WCAG cross-reference**: n/a (emergency-service interoperability requirement rather than a web success criterion).

**Assessment heuristics**:

* Confirm the ICT exposes an explicit RTT mode in the emergency call UI, not buried under accessibility submenus.
* Verify RTT and voice can run on the same emergency call where the dispatch endpoint accepts both, so callers can shift modality mid-call.
* Test interworking with the regulator-mandated text relay path when direct RTT delivery to dispatch is unavailable.
* Validate that character transmission latency, capitalisation, and special-character handling meet the regional emergency-RTT profile (for example ETSI TS 134 109 or comparable national profile).

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

### clause-13-2-2

**13.2.2 Caller location for emergency**

ICT that provides access to emergency services shall convey caller location information to the receiving emergency centre with the same accuracy and timeliness as is provided for voice callers, regardless of whether the call was initiated by voice, text, RTT, or video. Location data shall accompany the call without requiring the caller to read coordinates or address details aloud.

**Applies to**: Emergency caller location data in ICT that originates or routes emergency calls, including handsets, calling clients, network elements, and emergency-call gateways.

**WCAG cross-reference**: n/a (emergency-service interoperability requirement rather than a web success criterion).

**Assessment heuristics**:

* Confirm the location payload (cell-based, GNSS, Wi-Fi, advanced mobile location) attaches to text and video emergency calls, not only to voice.
* Verify the receiving endpoint can render the supplied location with the precision the originating ICT advertises.
* Test location delivery in low-coverage and indoor scenarios to confirm graceful fallback rather than silent failure.
* Audit privacy posture so emergency-only location release does not leak into non-emergency contexts.

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

### clause-13-2-3

**13.2.3 Video relay for emergency**

ICT that provides access to emergency services shall support video communication for emergency calls where a sign-language video relay path is available in the relevant jurisdiction, so that deaf and hard-of-hearing users who sign can place emergency calls in their first language. The ICT shall route the video emergency call to the designated relay or dispatch endpoint without imposing extra setup steps not required for voice emergency calls.

**Applies to**: Emergency video relay origination and transport in ICT that originates or carries emergency calls, including handsets, calling clients, carrier networks, and emergency-call gateways.

**WCAG cross-reference**: n/a (emergency-service interoperability requirement rather than a web success criterion).

**Assessment heuristics**:

* Confirm the emergency UI surfaces a video-relay option whenever the device camera and network bandwidth permit it.
* Verify video and audio media streams negotiate the codecs the receiving relay or dispatch endpoint accepts, with documented fallback to RTT if video fails.
* Test camera, frame rate, and lighting handling against the signed-emergency-call quality targets in the regional profile.
* Walk the flow with a signing user to confirm orientation cues, mute indicators, and in-call status are perceivable without audio.

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

