EN 301 549 - Accessibility requirements for ICT products and services

Product documentation shall list and explain the ICT product's accessibility and compatibility features (12.1.1) and shall itself be provided in an accessible electronic form (12.1.2).

• Accessibility feature documentation (e.g. VPAT/EAA report)
• Accessible documentation format

• Documentation only in inaccessible PDF
• No documentation of accessibility features

Support services shall include information on the ICT product's accessibility and compatibility features (12.2.2), shall communicate effectively with users with disabilities (12.2.3), and shall provide accessible documentation (12.2.4).

• Support-channel accessibility (e.g. RTT, video relay)
• Training of support staff on accessibility features

• Support staff unaware of accessibility features

Where the standard provides no functional-feature-based requirement addressing one or more functional needs, or where alternative ways of meeting an identified need are not addressed, ICT shall be designed and provided such that it satisfies the relevant Functional Performance Statements of clause 4.2.

• Mapping of provided ICT functions to the FPS of clause 4.2 they satisfy
• Accessibility conformance assessment / VPAT-style report

• Claiming conformance with neither a clause requirement nor an FPS justification

Sets the 11 functional performance statements: usage without vision (4.2.1), with limited vision (4.2.2), without perception of colour (4.2.3), without hearing (4.2.4), with limited hearing (4.2.5), with no or limited vocal capability (4.2.6), with limited manipulation or strength (4.2.7), with limited reach (4.2.8), minimisation of photosensitive seizure triggers (4.2.9), usage with limited cognition, language or learning (4.2.10), and privacy (4.2.11).

• Evidence each ICT function supports the relevant FPS user needs
• User-needs analysis covering the 11 statements

• Ignoring one or more user-need categories

Where ICT has closed functionality (the user cannot connect or use assistive technology), it must itself provide accessibility features for users with disabilities, including for users with sight, hearing, speech, manipulation/strength, reach and cognition limitations.

• Accessibility features built into closed-functionality ICT
• User-test evidence for users with the relevant impairments

• Assuming assistive technology can be used when functionality is closed

Where the ICT has documented accessibility features, it shall be possible for a user to activate any such feature that is required by the user.

• Activation paths for built-in accessibility features

• Accessibility features that cannot be activated without sighted assistance

Where biometrics are the sole means of user identification or control of the ICT, the ICT shall also provide a biometric mode that does not rely on a single biological characteristic.

• Alternative biometric or non-biometric authentication paths

• Sole-biometric authentication with no alternative for users unable to provide that biometric

Where the ICT converts information or communication from one form/medium to another, it shall preserve any non-proprietary information that is provided to support accessibility, to the extent that this information can be contained or supported by the destination form/medium.

• Test evidence that accessibility metadata survives conversion (e.g. text alternatives, captions, language)

• Loss of alt text, captions or language metadata during format conversion

Operable parts (controls, including buttons and connectors) shall be discernible by touch and operable by users with limited manipulation, with set requirements on tactile discernibility, single-hand use, the absence of tight grasping/twisting, and the maximum operating force.

• Tactile-discernibility and force-of-operation testing of physical controls

• Controls requiring fine motor skills or both hands without alternative

Where ICT has locking or toggle controls (e.g. Caps Lock, Num Lock), the state of the control shall be visually discernible and discernible through either touch or sound.

• State-indication evidence (visual + tactile/audible) for locking/toggle controls

• Toggle state visible only on a screen indicator inaccessible to the user

Where ICT has a keyboard or keypad: key-repeat shall be adjustable or disable-able and the delay before repeat shall be adjustable (5.7); when the same key is pressed twice in succession, the second key press shall be acceptable within a configurable time window (5.8); and where operation requires simultaneous user actions, the ICT shall offer a mode that does not require simultaneous actions (5.9).

• Keyboard key-repeat configuration and double-strike timing test
• Sequential-action alternative to any simultaneous-action requirement

• Fixed key-repeat rate with no adjustment
• Simultaneous-action operation with no sequential alternative

General hardware requirements covering the principle that, where ICT hardware has user-facing functionality, it shall conform to the applicable provisions of clauses 5-8, providing accessibility either intrinsically or via assistive technology connections.

• Hardware accessibility conformance assessment

• Inaccessible hardware controls or interfaces

Where ICT hardware provides speech output for any non-user-supplied audio (e.g. announcements, voice menus), the speech output shall be discernible (with sufficient amplification and capable of private listening) and intelligible.

• Speech-output amplification/private-listening tests

• Speech output not adjustable for hard-of-hearing users

Stationary ICT (e.g. kiosks, ATMs) shall provide accessible user positions, reach ranges, clearances, operable parts and a privacy mode where personal data is entered, accommodating wheelchair users and users of small stature.

• Reach-range and clear-floor-space measurements
• Privacy-mode evidence for sensitive data entry

• Kiosks reachable only by standing users
• No private mode for PIN entry

Mechanically operable parts (8.4) shall be discernible by touch, operable with one hand without tight grasping/twisting, and within a maximum operating force; and where a speech-output mode is provided, it shall be tactilely indicated (8.5).

• Mechanical-operability conformance
• Tactile indication of speech-output mode

• Buttons requiring fine motor control with no alternative

Non-web documents shall meet the WCAG 2.1 Perceivable success criteria adapted for documents, including text alternatives, time-based media alternatives, adaptable presentation and distinguishable content.

• Document accessibility test results (PDF/UA, accessible Word/HTML docs)

• Scanned-image PDFs with no OCR/text layer

Non-web documents shall meet the WCAG 2.1 Operable success criteria adapted for documents, including keyboard accessibility, sufficient time, seizure avoidance, navigability and input modalities for interactive documents.

• Keyboard-operability tests for interactive documents
• Bookmarks/headings for navigation

• Interactive forms not keyboard-operable

Non-web documents shall meet the WCAG 2.1 Understandable success criteria adapted for documents, including language identification, predictability and input assistance with error handling.

• Document language metadata
• Form-error guidance

• Missing document language

Non-web documents shall meet the WCAG 2.1 Robust success criteria adapted for documents (compatibility with assistive technology, accessible name/role/value for interactive elements).

• Document accessibility-API/structure tests (tags, reading order)

• Untagged PDFs

Where ICT provides or supports relay services, the relay services (text relay, sign relay, lip-reading relay, captioned telephony, speech-to-speech relay) shall meet defined functional requirements ensuring interoperability and effective communication.

• Relay-service support evidence and interoperability tests

• Relay services not supported on the ICT

ICT supporting two-way voice communication shall allow users to access relay services (13.2) and shall enable access to emergency services for users with disabilities (13.3) with information at least equivalent to that for voice users.

• Documented relay-access path
• Emergency-service access for non-voice users (e.g. via RTT)

• No path to emergency services for non-voice users

Software shall meet the WCAG 2.1 Perceivable success criteria adapted for software (text alternatives, time-based media alternatives, adaptable presentation, distinguishable content).

• Software-accessibility test results against WCAG-adapted criteria
• Screen-reader compatibility testing

• Images without alt text in the software UI

Software shall meet the WCAG 2.1 Operable success criteria adapted for software (keyboard accessible, enough time, seizures and physical reactions, navigable, input modalities).

• Keyboard-only operation tests
• Focus-visible and navigation testing

• UI controls not reachable by keyboard

Software shall meet the WCAG 2.1 Understandable success criteria adapted for software (readable, predictable, input assistance).

• Software language metadata
• Error prevention and suggestions

• Unhelpful error messages

Software shall meet the WCAG 2.1 Robust success criteria adapted for software (compatible name/role/value via the platform accessibility services).

• Accessibility-API testing
• Custom-control name/role/value validation

• Custom controls with no exposed accessibility properties

Software shall be interoperable with assistive technology, providing platform accessibility services so that assistive technology can interact with closed-functionality software and access UI components, properties and events.

• Use of platform accessibility services (e.g. UI Automation, AX, AT-SPI)
• Assistive-technology testing reports

• Custom rendering bypassing platform accessibility services

Software shall preserve user control of accessibility features (11.6.1), shall not disrupt accessibility features provided by the platform (11.6.2), and shall respect platform user accessibility preferences (11.7).

• Tests confirming platform accessibility preferences are honoured
• No-disruption tests of platform accessibility services

• Software overriding system contrast/font-size preferences

Authoring tools shall support content authors in producing accessible content: capability to author content in technologies that support accessibility, support for accessible content creation, preservation of accessibility information in transformations, repair assistance and accessible templates.

• Authoring-tool accessibility-support features
• Repair-assistance and accessible-template evidence

• Authoring tool with no accessibility checking or repair

Where ICT provides two-way voice communication, it shall be capable of encoding and decoding two-way speech with the frequency bandwidth specified, to ensure intelligibility for users with hearing impairments.

• Speech-bandwidth conformance test against the specified frequency range

• Lower bandwidth degrading speech intelligibility

Where ICT provides two-way voice communication, it shall provide Real-Time Text (RTT) capability that operates in parallel with voice, supports the required character set and ordering, allows visually distinguishing of own/other-party text and runs end-to-end interoperably.

• RTT implementation evidence (parallel to voice, character set, interoperability)
• Conformance against the RTT requirements in clause 6.2.1-6.2.4

• No RTT alternative to voice
• RTT not end-to-end interoperable

Where ICT provides caller identification, the same identifying information shall be available in a non-auditory form (text or visual) so that users who do not hear can also receive caller identification.

• Visual caller-ID display alongside any audible announcement

• Caller ID audible only

Where voice-based services are provided, the ICT shall also support at least one non-voice means of communication (e.g. RTT) and shall be able to initiate, maintain and end calls using that non-voice means in parallel with voice.

• Non-voice call modality (RTT/sign relay/text) integrated with the voice service

• Voice-only service with no text or RTT alternative

Where ICT provides two-way video communication, it shall support a resolution, frame rate, latency and synchronisation that allow communication using sign language, with controls and identification suitable for users with disabilities.

• Video conformance against the resolution/frame-rate/latency requirements
• Sign-language test results

• Video too low quality for sign language to be understood

Where video-based services are provided, the ICT shall provide at least one alternative means of communication that does not require video, supporting users who do not use sign or video communication.

• Audio/text alternative to any video-based service

• Video-only service with no alternative

Where ICT displays video with synchronised audio, it shall support decoding and rendering of captions, preserving alignment and timing of captions, and provide user controls for captions.

• Caption decode/render conformance
• User-controllable caption display

• Captions present but not rendered or controllable

Where ICT displays video with synchronised audio, it shall support decoding and rendering of audio description and user selection of an audio-description track.

• Audio-description decode/track-selection conformance

• No mechanism to enable audio description

ICT displaying video with synchronised audio shall provide user controls for captions and audio description that are at least as discoverable and operable as the controls for the primary media (volume/playback).

• Equivalent-discoverability test for caption/AD controls

• Caption/AD controls hidden behind menus while volume is one tap away

Web content shall conform to the Perceivable success criteria of WCAG 2.1 Level A and Level AA, including text alternatives, time-based media alternatives, adaptable presentation and distinguishable content (contrast, resizing, audio control).

• WCAG 2.1 A/AA test results for Perceivable success criteria
• Text alternatives, captions/AD, contrast and resize testing

• Missing text alternatives
• Insufficient contrast

Web content shall conform to the Operable success criteria of WCAG 2.1 Level A and AA, including keyboard accessibility, enough time, no seizure-inducing content, navigable structure and input modalities (pointer gestures, label-in-name).

• WCAG 2.1 A/AA test results for Operable success criteria
• Keyboard-only and pointer-alternative testing

• Content reachable only with a mouse
• No skip-navigation

Web content shall conform to the Understandable success criteria of WCAG 2.1 Level A and AA, including readable language identification, predictable behaviour and input assistance with error identification and suggestions.

• WCAG 2.1 A/AA test results for Understandable success criteria
• Language attributes, error-handling and instructions testing

• No language metadata
• Unhelpful or missing form-error messages

Web content shall conform to the Robust success criteria of WCAG 2.1 Level A and AA, including compatibility (parsing, name/role/value) and status messages so that assistive technologies can present content.

• WCAG 2.1 A/AA test results for Robust success criteria
• Accessibility-API name/role/value testing

• Custom widgets without accessible name/role/value

Web content shall meet the WCAG 2.1 conformance requirements: conformance level (at least AA), full pages, complete processes, accessibility-supported ways of using technologies and non-interference.

• WCAG 2.1 conformance statement (level, scope, technologies relied upon)

• Conformance claim without addressing complete processes or non-interference