What is ICT?
Information and Communications Technology (ICT) includes hardware, software, voice communication, video capabilities and digital content (including web and non-web-based information).
What is ICT accessibility and why is it important?
"ICT accessibility ensures that people with and without disabilities can access the same information, perform the same tasks, and receive the same services using information technology. It is the digital equivalent to accessibility in the physical environment —the curb cuts, ramps, railings, etc., of the digital age. While ICT accessibility can provide usability benefits to everyone who uses ICT, it is a vital necessity to many people with disabilities." - NASCIO - Accessibility in IT Procurement
About this document and Copyright Notice
This document reproduces relevant ICT accessibility requirements from the EN 301 549 V4.1.1 (2026-09) Harmonised European Standard – Accessibility requirements for ICT products and services (© used under license from European Telecommunications Standards Institute 2026. © Comité Européen de Normalisation 2026. © Comité Européen de Normalisation Électrotechnique 2026. All rights reserved.), which aligns with the Web Content Accessibility Guidelines (WCAG) 2.2 level AA by reference.
Intellectual Property Rights (IPRs) essential or potentially essential to normative deliverables may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https://ipr.etsi.org/). Please visit ETSI IPR database to search for any IPRs.
Annexes include definitions and references.
The information in this document uses the language from Clauses 5-13 and Annex B (informative): Relationship between requirements and functional performance criteria from the EN 301 549 V4.1.1 (2026-09) Harmonised European Standard – Accessibility requirements for ICT products and services.
Sources used to compile this document
- EN 301 549 V4.1.1 (2026-09) Harmonised European Standard - Accessibility requirements for ICT products and services (PDF)
- Web Content Accessibility Guidelines (WCAG) 2.2 (W3C Recommendation 12 December 2024)
- Comparison with WCAG 2.1
- ITI VPAT® EN 301 549 (EU) version
Part A – 4.2 Functional Performance Criteria
4.2.1 Usage without vision
Where ICT provides visual modes of operation, the ICT shall provide at least one mode of operation that does not require vision.
NOTE 1: This is essential for users without vision and benefits many more users in different situations.
NOTE 2: A web page or application with a well formed semantic structure can allow users without vision to identify, navigate and interact with a visual user interface.
NOTE 3: Audio and tactile user interfaces may contribute towards meeting this clause.
4.2.2 Usage with limited vision
Where ICT provides visual modes of operation, the ICT shall provide features that enable users to make better use of their limited vision.
NOTE 1: This is essential for users with limited vision and benefits many more users in different situations.
NOTE 2: Magnification, reduction of required field of vision and control of contrast, brightness and intensity (including of external lighting) can contribute towards meeting this clause.
NOTE 3: Where significant features of the user interface are dependent on depth perception, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.
NOTE 4: Best practice is for the smallest text have an x-height of at least 8 CSSpx which corresponds to an x-height of 1.2mm, at a viewing distance of 400mm, with no zooming or screen scaling. This is the smallest font size - not the recommended font size for body text which should be larger.
NOTE 5: The formula for calculating the physical x-height (in mm) from the x-height (in CSSpx) and the distance D (in mm) from the eye to the display is x-height (mm) = D (mm) × x-height (CSSpx) / 2 688.
NOTE 6: For handheld devices D should be assumed as 400 mm.
NOTE 7: Users with limited vision may also benefit from non-visual access (see clause 4.2.1).
4.2.3 Usage without perception of colour
Where ICT provides visual modes of operation, the ICT shall provide a visual mode of operation that does not require user perception of colour.
NOTE 1: This is essential for users with limited colour perception and benefits many more users in different situations.
NOTE 2: Where significant features of the user interface are colour-coded, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.
4.2.4 Usage without hearing
Where ICT provides auditory modes of operation, the ICT shall provide at least one mode of operation that does not require hearing.
NOTE 1: This is essential for users without hearing and benefits many more users in different situations.
NOTE 2: Visual and tactile user interfaces, including those based on text and sign language, may contribute towards meeting this clause.
NOTE 3: Sign language content that accompanies audiovisual content and that has a resolution and frame rate that is consistent with the requirements in clauses 6.5.2 and 6.5.3, and that is well synchronized with the spoken content may contribute to meeting this clause.
4.2.5 Usage with limited hearing
Where ICT provides auditory modes of operation, the ICT shall provide enhanced audio features.
NOTE 1: This is essential for users with limited hearing and benefits many more users in different situations.
NOTE 2: Enhancement of the audio clarity, reduction of background noise, providing a joint monaural option, adjustment of balance of both audio channels, increased range of volume and greater volume in the higher frequency range can contribute towards meeting this clause.
NOTE 3: Allowing the use of Assistive Listening Devices by providing a way to connect audio for example via headphone jacks, Bluetooth®, USB or WLAN can contribute to meeting this clause.
NOTE 4: Users with limited hearing may also benefit from non-hearing access (see clause 4.2.4).
4.2.6 Usage with no or limited vocal capability
Where ICT requires vocal input from users, the ICT shall provide at least one mode of operation that does not require them to generate vocal output.
NOTE 1: This is essential for users with no or limited vocal capability and benefits many more users in different situations.
NOTE 2: Vocal output includes speech and other orally generated sounds, such as whistles and clicks.
NOTE 3: Keyboard, pen or touch user interfaces may contribute towards meeting this clause.
4.2.7 Usage with limited manipulation or strength
Where ICT requires manual actions, the ICT shall provide features that enable users to make use of the ICT through alternative actions not requiring manipulation, simultaneous action or hand strength.
NOTE 1: This is essential for users with limited manipulation or strength and benefits many more users in different situations.
NOTE 2: Examples of operations that users may not be able to perform include those that require fine motor control, path dependant gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.
NOTE 3: One-handed operation, sequential key entry and speech user interfaces may contribute towards meeting this clause.
NOTE 4: Some users have limited hand strength and may not be able to achieve the level of strength to perform an operation. Alternative user interface solutions that do not require hand strength may contribute towards meeting this clause.
4.2.8 Usage with limited reach
Where ICT is stationary, free-standing or installed, all the elements required for operation shall be within reach of all users.
NOTE 1: This is essential for users with limited reach and benefits many more users in different situations.
NOTE 2 Considering the needs of wheelchair users and the range of user statures in the placing of operational elements of the user interface may contribute towards meeting this clause.
NOTE 3: Having a remote input capability can help satisfy this requirements.
4.2.9 Minimize photosensitive seizure triggers
Where ICT provides visual modes of operation, the ICT shall provide at least one mode of operation, that is the default mode, that minimizes the potential for triggering photosensitive seizures or optionally, for audiovisual material, a warning in advance that such triggers might be present.
NOTE 1: This is essential for users with photosensitive seizure triggers.
NOTE 2: Limiting the area and number of flashes per second may contribute towards meeting this clause.
4.2.10 Usage with limited cognition, language or learning
Where ICT provides information or requires user interaction, the ICT shall provide features and/or presentation that makes it simpler and easier to understand, operate and use.
NOTE 1: This is essential for users with limited cognition, language or learning, and benefits many more users in different situations.
NOTE 2: Adjustable audio playback speeds, timings, error indication and suggestion, and a logical focus order are examples of design features that may contribute towards meeting this clause.
NOTE 3: Providing an audio output of the text is an example of providing support for people with limited reading abilities.
NOTE 4: Providing spelling aid and word prediction of the text is an example of providing support for people with limited writing abilities.
NOTE 5: Interaction with content can be made easier, and less prone to errors, by presenting tasks in steps that are easy to follow.
NOTE 6: For a reference to requirements supporting the functional performance criteria 4.2.10, check Table B.2. in Annex B. All lines having "P" or "S" in column "LC" of Table B.2 may have an impact on usage with limited cognition, language or learning. (Note: in this document, this information is contained within each of the relevant clauses following the wording "Relationship between requirements and functional performance criteria".)
4.2.11 Privacy
Where ICT provides features for accessibility,
the ICT shall ensure that the privacy of the users of the ICT is maintained irrespective of the use of these features for accessibility.
NOTE: Enabling the connection of personal headsets for private listening, not providing a spoken version of characters being masked and enabling user control of legal, financial and personal data are examples of design features that may contribute towards meeting this clause.
Part B - Functional Accessibility Requirements
Explanation of the table
The table consists of a single column which contains the following key information:
- The clause from the EN 301 549 which applies to the ICT
- The associated "relationship to Functional Performance Criterion" as indicated in Annex B
- Table B.1: Key to the column header designations used in Table B.2
|
Column header abbreviation |
Functional performance criterion |
Clause number |
|---|---|---|
|
WV |
Usage without vision |
|
|
LV |
Usage with limited vision |
|
|
WPC |
Usage without perception of colour |
|
|
WH |
Usage without hearing |
|
|
LH |
Usage with limited hearing |
|
|
WVC |
Usage without vocal capability |
|
|
LMS |
Usage with limited manipulation or strength |
|
|
LR |
Usage with limited reach |
|
|
PST |
Minimize photosensitive seizure triggers |
|
|
LC |
Usage with limited cognition |
|
|
PR |
Privacy |
- The following abbreviations have been used to represent the relationship between the requirements in clauses 5 to 13 and the functional performance criteria:
- P = Primary relationship. The requirement supports the functional performance criterion.
- S = Secondary relationship. The requirement provides partial support for the functional performance criterion because some users may use the feature in specific situations.
Found in this section
- 5 Generic requirements
- 6 ICT supporting real-time bidirectional communication
- 7 ICT with video capabilities
- 8 Hardware
- 9 Web
- 10 Non-web documents
- 11 Non-web software
- 12 Information about products and services
- 13 ICT providing relay or emergency service access
- Annex - Tables and figures (from EN 301 549)
- Annex - References (from EN 301 549)
- Annex – Definition of terms, symbols and abbreviations (from EN 301 549)
5 Generic requirements
5.1 Closed functionality
5.1.1 Introduction (informative)
ICT has closed functionality for many reasons, including design or policy. Some of the functionality of products can be closed because the product is self-contained and users are precluded from adding peripherals or software in order to access that functionality.
ICT may have closed functionality in practice even though the ICT was not designed, developed or supplied to be closed.
Computers that do not allow end-users to adjust settings or install software are functionally closed.
5.1.2 General
5.1.2.1 Closed functionality
Where ICT includes closed functionality, the closed functionality shall meet 5.1. For the non-closed functionality the applicable requirements set out in clauses 5.2 to 13 shall be met.
NOTE 1: ICT may close some, but not all, of its functionalities. Only the closed functionalities have to meet the requirements of clause 5.1.
NOTE 2: The requirements within this clause replace those in clauses 5.2 to 13 that specifically state that they do not apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability for the user to adjust system accessibility settings in products with closed functionality (e.g. products that prevent access to the system settings control panel).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (P)
5.1.2.2 Assistive technology and closed functionality
Where ICT includes closed functionality, that closed functionality shall be operable without requiring the user to attach, connect or install assistive technology and meet the generic requirements of clauses 5.1.3 to 5.1.6 as applicable. Personal headsets and personal induction loops are not classed as assistive technology for the purpose of this clause.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC), Privacy (P)
5.1.3 Non-visual access
5.1.3.1 Auditory output of visual information
Where ICT includes closed functionality, and visual information is needed to enable the use of the closed functionality of the ICT, the closed functionality shall be provided through one or more non-visual means that includes auditory output to enable the use of those functions.
NOTE 1: Non-visual access may also include a tactile form such as braille in addition to audio. This is particularly useful for some individuals who are deaf-blind.
NOTE 2: The visual information needed to enable use of some functions may include operating instructions and orientation, transaction prompts, user input verification, error messages and non-text content.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.2 Auditory output delivery including speech
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, the auditory output shall be delivered through one of the following:
- directly by a mechanism included in or provided with the ICT; or
- by a personal headset that can be connected through a 3,5 mm audio jack without requiring the use of vision; or
- if it is a personal device (not a public-shared-use device), by a personal headset connected through any standard industry headset connection.
NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, and a built-in handset/headset.
NOTE 2: The use of a speaker for providing personal information may be subject to privacy law restrictions in certain situations.
NOTE 3: For personal use devices only, industry standard audio connections include but are not limited to audio USB standards and Bluetooth®.
NOTE 4: If auditory output is delivered by a connection for personal headphones, it is best practice, where space permits, to provide both visual and tactile information to indicate that it is possible to connect personal headphones to the ICT device. This can be done, for example, by using a tactile symbol representing headphones.
NOTE 5: Any jack (mono, stereo, or microphone enabled) is sufficient to meet this requirement since all will provide audio output and will work interchangeably with headphones/earbuds to provide audio output.
NOTE 6: In a publicly shared device industry standard audio connections including but not limited to audio USB standards and Bluetooth® may be provided in addition to a 3,5 mm audio jack.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.3 Auditory output correlation
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, and information that is under the control of the ICT is displayed on the screen, the ICT shall provide auditory information that includes all the non-decorative information displayed on the current screen.
NOTE 1: Many people who are blind and partially sighted still have visual ability, and use aspects of the visual display even if it cannot be fully comprehended. An audio alternative that is both complete and complementary includes all visual information such as focus or highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.
NOTE 2: The auditory information is intended to allow the user to perform the task(s) currently on the screen.
NOTE 3: Examples of auditory information that allows the user to correlate the audio with the information displayed on the screen include structure and relationships conveyed through presentation.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV)
Secondary: Usage with limited cognition (LC)
5.1.3.4 Speech output user control
Where ICT includes closed functionality, and speech output is provided as non-visual access to closed functionality, the speech output shall be capable of being interrupted and repeated when requested by the user, where permitted by security requirements.
NOTE 1: Moving the speaking cursor away from an item is a common technique for interrupting the speech and is particularly important when moving from one item and to a different one causing that the new item will be read immediately. Moving off and back to an item can be used to cause it to re-read.
NOTE 2: It is best practice to allow the user to pause speech output rather than just allowing them to interrupt it when the speech output is longer than 5 seconds.
NOTE 3: It is best practice to allow the user to repeat only the most recent portion rather than requiring play to start from the beginning when the speech output is longer than 5 seconds.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.5 Speech output automatic interruption
Where ICT includes closed functionality, and speech output is provided as non-visual access to closed functionality, and the speech output is generated to provide feedback on user interface choices and user actions, the ICT shall interrupt current speech output when a user action occurs and when new speech output begins.
NOTE 1: This requirement applies to the speech output provided for non-visual access as feedback for user interface choices and actions, not to any other speech being played by the device. If audio is already playing, including audio description as part of playing AV material, it is common to mute or 'duck' the audio (greatly reduce the relative volume of the audio) to allow the accessibility audio to be clearly heard.
NOTE 2: Where it is essential that the user hears the entire message, e.g. a safety instruction or warning, the ICT may need to block all user action so that speech is not interrupted.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.6 Auditory output for non-text content
Where ICT includes closed functionality that presents non-text content other than video, any alternative for non-text content shall be presented to users via auditory output, including speech, unless the non-text content is pure decoration or is used only for visual formatting.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.7 Auditory output for video information
Where ICT includes closed functionality, and pre-recorded video content is needed to enable the use of closed functionality of the ICT, an auditory equivalent shall be provided for the pre-recorded video content originating from the ICT, and, if provided from another source along with video content, it is also made available by the ICT.
NOTE 1: This speech output can take the form of an audio description or, where there is a transcript of the video, a spoken version of the transcript content.
NOTE 2: ICT is not required to create an auditory equivalent for content not originating from the ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.8 Masked entry
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, and the characters displayed are masking characters, the auditory output shall not be a spoken version of the characters entered unless the auditory output is known to be delivered only to a mechanism for private listening, or if the option exists and the user explicitly chooses to allow non private auditory output.
NOTE 1: Masking characters are usually displayed for security purposes and include, but are not limited to asterisks representing personal identification numbers.
NOTE 2: Unmasked character output might be preferred when closed functionality is used, for example, in the privacy of the user's home. A warning highlighting privacy concerns might be appropriate to ensure that the user has made an informed choice.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Privacy (PR)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.9 Private access to personal data
Where ICT includes closed functionality, and the ICT is intended for public shared use, and auditory output is provided by that ICT as non-visual access to closed functionality, and that output contains data that is considered to be private according to the applicable privacy policy, the corresponding auditory output shall only be delivered through a mechanism for private listening that can be connected without requiring the use of vision, or through any other mechanism explicitly chosen by the user.
NOTE 1: The wording of the requirement is such that it only applies to audio generated by that particular ICT for non-visual access, and not to any audio, such as audio descriptions, or any other information including private information that is passed to it from another source.
NOTE 2: The wording of this requirement means that does not apply in cases where data is not defined as being private according to the applicable privacy policy or where there is no applicable privacy policy.
NOTE 3: Non-private output might be preferred when closed functionality is used, for example, in the privacy of the user's home. A warning highlighting privacy concerns might be appropriate to ensure that the user has made an informed choice.
NOTE 4: An example of a privacy policy in Europe is the GDPR [i.82].
NOTE 5: Even if there are no privacy policies that cover the exact context in which the ICT is being used, it is best practice to not announce via a speaker a person's name, phone number, address, financial information (account numbers, amount of withdrawal) or other information that could be used to identify a person or track them later or to target them for robbery etc.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Privacy (PR)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.10 Non-interfering audio output
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, the ICT shall not automatically play, at the same time, any interfering audible output that lasts longer than three seconds.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.11 Private listening volume
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, and the auditory output is delivered through a mechanism for private listening, the ICT shall provide at least one non-visual mode of operation for controlling the volume.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.12 Speaker volume
Where ICT includes closed functionality, and auditory output is provided as non-visual access to closed functionality, and is delivered through speakers on the ICT, a non-visual incremental volume control shall be provided with output amplification up to a level of at least 65 dBA (-29 dBPaA).
NOTE: For noisy environments, 65 dBA may not be sufficient.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.13 Volume reset
Where ICT includes closed functionality, and the ICT is intended for public shared use, and auditory output is provided as non-visual access to closed functionality through a mechanism for private listening, a function that resets the volume to be at a level of 65 dBA or less after every use, shall be provided.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.14 Spoken languages
Where ICT includes closed functionality, and speech output is provided as non-visual access to closed functionality, the speech output shall be in the same human language as the displayed content provided, except:
- for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text;
- where the content is generated externally and not under the control of the ICT vendor, the present clause shall not be required to apply for languages not supported by the ICT's speech synthesizer;
- for displayed languages that cannot be selected using non-visual access;
- where the user explicitly selects a speech language that is different from the language of the displayed content.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.15 Non-visual error identification
Where ICT includes closed functionality, and speech output is provided as non-visual access to closed functionality, and an input error is automatically detected, and the error is indicated visually via text and/or other visual means, the speech output shall present equivalent error information.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.3.16 Receipts, tickets, and transactional outputs
Where ICT includes closed functionality, and provides physical receipts, tickets or other outputs as a result of a self service transaction, output that provides all information necessary to complete or verify the transaction shall be provided through one or more non-visual means that includes auditory output, except information that is printed and that is not needed to complete the transaction, such as receipts, itineraries, maps, etc.
NOTE: The speech output may be provided by any element of the total ICT system.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
5.1.4 Functionality closed to text enlargement
Where ICT includes closed functionality, and any functionality of the ICT is closed to the text enlargement features of its platform or assistive technology, the ICT shall provide a mode of operation where the text and images of text necessary for all functionality is displayed in such a way that the x-height of the text is at least 16 CSSpx.
NOTE 1: The formula for calculating the physical height (in mm) from the height (in CSSpx) and the distance D (in mm) from the eye to the display is
physical height (mm) = D (mm) × height (CSSpx) / 2 688.
The relationship between viewing distance and physical x-height for a font with an x-height of 16 CSSpx is "shown in Table 5.1".
NOTE 2: This is the smallest font size - not the recommended font size for body text which should be larger.
NOTE 3: For handheld devices D should be assumed as 400 mm.
NOTE 4 For detailed information about x-height, CSSpx, etc., see section 4.3.2 of [i.70].
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV)
5.1.5 Visual output for auditory information
Where ICT includes closed functionality, and auditory output is needed to enable the use of closed functionality of the ICT, the ICT shall provide visual information that is equivalent to the auditory information.
NOTE 1: This visual information can take the form of subtitles or text transcripts.
NOTE 2: Sign language interpretation can also be provided as best practice, but this is not sufficient to meet this requirement by itself.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
5.1.6 Operation without keyboard interface
5.1.6.1 Functionality closed to keyboards
Where ICT includes closed functionality, and the functionality is closed to keyboards or keyboard interfaces, the functionality closed to keyboards or keyboard interfaces shall be operable without vision as required by clause 5.1.3.
NOTE: A soft keyboard (an onscreen keyboard) would meet this requirement if it is operable without vision as required by clause 5.1.3.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
5.1.6.2 Input focus
Where ICT includes closed functionality, and the functionality is closed to keyboards or keyboard interfaces, and where input focus can be moved to a user interface element, it shall be possible to move the input focus away from that element using the same mechanism, in order to avoid trapping the input focus.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
5.1.7 Access without speech
Where ICT includes closed functionality, and speech is needed to operate closed functionality of the ICT, the ICT shall provide at least one mode of operation using an alternative input mechanism that does not require speech.
Relationship between requirements and functional performance criteria:
Primary: Usage without vocal capability (WVC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
5.1.8 Identify input purpose (closed functionality)
Where ICT includes closed functionality, and input field(s) collecting information about the user are needed to enable the use of the closed functionality of the ICT, and the input field(s) serve a purpose identified in the WCAG 2.2 Input Purposes for User Interface Components section [4], in at least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each of these input fields.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
5.2 Activation of accessibility features
Where ICT includes documented accessibility features, it shall be possible to activate those documented accessibility features that are required to meet a specific need without relying on a method that does not support that need.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.3 Biometrics
Where ICT uses biological characteristics, the ICT shall not rely on the use of a biological characteristic as the only means of user identification or for control of the ICT.
NOTE: Some examples of biological characteristics are fingerprints, eye retinal patterns, voice, and face.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Privacy (PR)
5.4 Preservation of accessibility information during conversion
Where ICT converts information or communication, the ICT shall preserve all documented non-proprietary information that is provided for accessibility to the extent that such information can be contained in or supported by the destination format.
NOTE 1: Any transmission that is not lossless would involve conversion and would be covered by this requirement.
NOTE 2: When transporting or displaying video, any loss of fidelity, synchronization, or quality would constitute a conversion and if the reduced fidelity, synchronization, or quality results in a loss of accessibility of, for example, the sign language portion of it, then it would constitute a violation of this requirement.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.5 Tactilely discernible operable parts
Where ICT includes functionality that requires manual operation and control, the ICT shall provide a mode of operation that allows all the functionality of the ICT that requires manual operation and control to be controlled without requiring vision using only tactilely discernible operable parts.
NOTE 1: As noted in the definition of tactilely discernible operable part, a touchscreen or touchpad that can be tactilely discerned, or a part of a touchscreen that is located adjacent to a tactilely discernible edge, corner, or tactile markings on a screen frame is a tactilely discernible operable part.
NOTE 2: Where physical buttons are arranged in small functional groups, or on-screen buttons are positioned in fixed positions adjacent to tactilely discernible boundaries (such as screen edges or surrounds), their position can be tactilely discerned.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited cognition (LC)
5.6 Locking or toggle controls
5.6.1 Tactile or auditory status
Where ICT includes a locking or toggle control, the ICT shall provide at least one mode of operation where the status of the control can be determined either through touch or sound without operating the control.
NOTE 1: Locking or toggle controls are those controls that can only have two or three states and that keep their state while being used.
NOTE 2: An example of a locking or toggle control is the "Caps Lock" key found on most keyboards. Another example is the volume button on a pay telephone, which can be set at normal, loud, or extra loud volume.
NOTE 3: For example, on some devices Power On/Off and Input Selection are physical toggle controls where the status can be felt. Tones can be used to indicate a change in different states such as a low-high tone for on and high-low tone for off. Or if speech output is enabled and the user invokes an action, feedback can be by speech at user option. However, the last two are not useful if the action is not a reversable one without consequence (e.g. power off/on that causes loss of information if done).
NOTE 4: Even though all the above examples relate to hardware toggle controls, this clause also applies to graphical controls in software.
NOTE 5: For graphical software controls in functionality that is not closed, this clause will usually be satisfied if the control conforms with the complementary WCAG success criteria 1.3.1 (Information and relationships) and 4.1.2 (Name, Role, Value), corresponding to clauses 9.1.3.1 and 9.4.1.2 (for web content), 10.1.3.1 and 10.4.1.2 (for non-web documents) and 11.1.3.1 and 11.4.1.2 (for non-web software). When state information is rendered in text or otherwise programmatically determinable it is possible to render it in an audible or tactile form.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV)
Secondary: Usage with limited cognition (LC)
5.6.2 Visual status
Where ICT includes a locking or toggle control, the ICT shall provide at least one mode of operation where the status of the control can be visually determined when the control is presented.
NOTE 1: Locking or toggle controls are those controls that can only have two or three states and that keep their state while being used.
NOTE 2: An example of a locking or toggle control is the "Caps Lock" key found on most keyboards. An example of making the status of a control determinable is a visual status indicator on a keyboard.
NOTE 3: A visual status can be a change on the screen or a flash of an LED after the user invokes an action. Where appropriate, adopting a pattern for example, a short flash for "off" and a longer or double flash for "on" can be considered as a good practice.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
5.7 Key repeat
Where ICT includes a keyboard or keypad, and a key repeat function that cannot be turned off, and that key repeat will result in the generation of multiple entries of the same alphanumeric data into input fields or into documents:
- the delay before the key repeat shall be adjustable to at least 2 seconds; and
- the key repeat rate shall be adjustable down to one character per 2 seconds.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS)
Secondary: Usage with limited reach (LR), Usage with limited cognition (LC)
5.8 Double-strike key acceptance
Where ICT includes a device-independent keyboard interface service, keyboard, or keypad, and includes a capability to adjust the time before the same key can be accepted again, the delay after any keystroke, during which the same key-press will not be accepted, shall be adjustable up to at least 0,5 seconds.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS)
Secondary: Usage with limited reach (LR), Usage with limited cognition (LC)
5.9 Simultaneous user actions
Where ICT includes a mode of operation requiring simultaneous user actions for its operation, the ICT shall provide at least one mode of operation that does not require simultaneous user actions to operate the ICT.
NOTE: Having to use both hands to open the lid of a laptop, having to press two or more keys at the same time or having to touch a surface with more than one finger are examples of simultaneous user actions.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
5.10 Authoring tools
5.10.0 General (informative)
For those creating web content authoring tools, ATAG 2.0 [i.33] provides information that can be of interest to those who want to go beyond these requirements.
NOTE: This is applicable both to standalone and to web based authoring tools.
5.10.1 Content technology
Where ICT is, or includes, authoring tool functionality, the authoring tool shall meet clauses 5.10.2 to 5.10.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.10.2 Accessible content creation
Where ICT is, or includes, authoring tool functionality, the authoring tool shall enable and guide the production of content that conforms to clause 9 (web), or clause 10 (Non web documents), or clause 11 (Non-web software) as applicable.
NOTE: Authoring tools may rely on additional tools where conformance with specific requirements is not achievable by a single tool. For example, a video editing tool may enable the creation of video files for distribution via broadcast television and the web, but authoring of subtitle files for multiple formats may be provided by a different tool.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.10.3 Preservation of accessibility information in transformations
Where ICT is, or includes, authoring tool functionality, and provides restructuring transformations or re-coding transformations, accessibility information shall be preserved in the output if equivalent mechanisms exist in the content technology of the output.
NOTE 1: Restructuring transformations are transformations in which the content technology stays the same, but the structural features of the content are changed (e.g. linearizing tables, splitting a document into pages).
NOTE 2: Re-coding transformations are transformations in which the technology used to encode the content is changed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.10.4 Repair assistance
Where ICT is, or includes, authoring tool functionality, and is capable of detecting that content does not meet a requirement of clause 9 (Web), or clause 10 (Non-web document), or clause 11 (Non-web software) as applicable, the authoring tool shall provide repair suggestion(s).
NOTE 1: Automatic detection of failure to meet some requirements may be very challenging, but there are other types of failure that can be very easy to automatically detect. It is best practice that failure detection of at least the easily detected failures should be implemented.
NOTE 2: This does not preclude automated and semi-automated repair which is possible (and encouraged with author review) for many types of content accessibility problems.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
5.10.5 Templates
Where ICT is, or includes, authoring tool functionality, and provides templates, at least one template that supports the creation of content that conforms to the requirements of clause 9 (Web) or clause 10 (Non-web document). or clause 11 (Non-web software) as applicable shall be available and identified as such.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
6 ICT supporting real-time bidirectional communication
6.0 Accessible real-time bidirectional communication operational scenarios
6.0.1 Rationale for scenarios (informative)
Clauses 6.0.2 to 6.0.5 specify a minimum set of operational scenarios in which real-time bidirectional communication typically takes place. To deliver the goal of accessible communications it is necessary to ensure that applicable accessibility requirements defined in clauses 6.1 to 6.6 are met in all applicable scenarios for the communication described by the scenarios.
Clauses 6.0.6 to 6.0.9 specify a minimum set of operational scenarios in which ICT is expected to deliver emergency communications. To ensure that emergency communications are accessible, it is necessary to ensure that ICT meets the applicable accessibility requirements defined in clauses 6.1 to 6.6 of the present document in all applicable scenarios for the emergency communications described by the scenarios.
NOTE 1: The scenarios add preconditions to each of the tests in clauses C.6.1 to C.6.6 to make sure that testing is done in a way that is both effective and practical for each of the different scenarios.
NOTE 2: For emergency communication aspects, the present document concerns the general accessibility aspects of ICT that is expected to provide access to emergency communications. The detailed aspects of how to ensure accessibility of emergency communications are covered in ETSI TS 103 919 [i.56] and are not further elaborated in the present document. These aspects include but are not limited to addressing, routing, location information provision, provision of emergency communication specific contextual information, details of invocation of relay services in emergency communications and invocation of other support services in the emergency communication.
6.0.2 Communication client
Where ICT is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that provides real-time bidirectional voice communication, the communication client shall meet all applicable 6.1 and 6.3 to 6.6 requirements, when communicating with or within the communication system, and, where the communication client is part of a terminal with text handling capabilities, all applicable 6.2 requirements.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.3 Communication system
Where ICT is, or includes, or is a part of, a communication system that provides real-time bidirectional voice communication with communication clients of the system, the system shall meet all applicable 6.1 to 6.6 requirements when communicating with communication clients.
NOTE: ICT that are component parts of a communication system can be tested by ensuring that that ICT is included in a communication system during testing.
EXAMPLE: The suitability of a home/office internet router for correctly handling RTT communication can be evaluated by ensuring that this router is part of the local ICT that is used to perform a test of RTT communication routed through the real-time bidirectional voice communication system.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.4 System connecting to another communication system
Where ICT is, or includes, a communication system that provides real-time bidirectional voice communication with one or more other communication systems that support real-time bidirectional voice communication, the system shall meet all applicable 6.1 to 6.6 requirements when communicating with the other communication systems.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.5 System with roaming visiting client
Where ICT is, or includes, a communication system that provides real-time bidirectional voice communication, and a communication client that supports real-time bidirectional voice communication with another compatible communication system, visits and connects to the communication system, the system shall meet all applicable 6.1 to 6.6 requirements when communicating with the visiting communication client.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.6 Client in emergency communications
Where ICT is required to provide, or otherwise provides, emergency communications, and is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that provides real-time bidirectional voice emergency communication, the communication client shall meet applicable 6.1 and 6.3 to 6.6 requirements, when performing the emergency communication, and, where the communication client is part of a terminal with text handling capabilities, all applicable 6.2 requirements.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.7 Emergency communications
Where ICT is, or includes, a communication system that provides real-time bidirectional voice communication in emergency communications with PSAPs, the communication system shall meet all applicable 6.1 to 6.6 requirements, when performing the emergency communication.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.8 System with roaming visiting client in an emergency
Where ICT is, or includes, a (first) communication system that provides real-time bidirectional voice communication in emergency communications with PSAPs, and a communication client that supports real-time bidirectional voice communication with another compatible communication system that provides real-time bidirectional voice communication, visits and connects to the (first) communication system, the (first) communication system shall meet all applicable 6.1 to 6.6 requirements, when communicating with the visiting communication client and a PSAP in emergency communications.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.0.9 System with client in emergency visiting another country
Where ICT is, or includes, a communication system that provides real-time bidirectional voice communication in emergency communications with PSAPs, and a communication client of the ICT that supports real-time bidirectional voice communication, visits another country than the home country, the communication system shall meet applicable 6.1 to 6.6 requirements when communicating with the communication client and a PSAP in the visited country in emergency communications.
NOTE: This scenario is intended for systems which in contrast to the systems of clause 6.0.8 of the present document do not use any roaming technology on call control level. Typical communication systems using the approach of the present clause are VoIP based systems using IP communications in the Internet or other IP networks, carried by mobile, Wi-Fi® or fixed technologies.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.1 Real-time bidirectional voice communication
6.1.1 Voice communication interoperability
Where ICT provides functionality that allows real-time bidirectional voice communication, and connects to other ICT that allows real-time bidirectional voice communication, the ICT's documentation shall contain information on the main specifications by which voice is implemented in a manner that allows the voice on the ICT to interoperate with the other ICT, providing electronic communication covering audio frequencies at least down to 100 Hz and at least up to 7 000 Hz using one of the following options:
- Any set of specifications for voice communication that would fulfil the voice communications requirements in the present document that is mutually agreed to be used between the ICT and any other ICT with which the ICT interoperates for real-time bidirectional voice communication.
- Recommendation ITU-T G.722 [i.20].
NOTE 1: Specifications for audio codec implementations that support the 100 Hz to 7 000 Hz frequency range are provided for a number of technologies. The following list provides an overview of the situation at the time of authoring the present document. It is presented here as a guide for achieving interoperability and suitable quality. It should be noted that most audio codecs can be used with varying parameter settings resulting in varying quality. They are listed here on the assumption that they are used with settings that allow them to provide sufficient quality to meet the requirements in the present clause. All audio codecs for the technologies listed are using IETF RFC 3550 RTP [i.51] for media transport:
- General VoIP and Multimedia communication: IETF, providing standards for Voice Over IP (VOIP) and Multimedia communications over IP based on the Session Initiation Protocol (SIP) IETF RFC 3261 [i.50]. In this technology, the following audio codecs capable of delivering sufficient quality are commonly used:
- IP Multimedia Sub-System (IMS): 3GPP, that provides standards for mobile communication systems, including IP Multimedia Sub-System (IMS) has standardized the Multimedia Telephony concept, for communications with voice, video and RTT using the set of protocols specified in ETSI TS 126 114 [i.11]:
- GSMA, that provides selected profiles of standards for implementing globally interoperating mobile communications services, has in GSMA PRD IR.92 [i.45] specified how to apply ETSI TS 126 114 [i.11] to implement RTT and Voice over LTE (VoLTE) and, in GSMA PRD IR.94 [i.46], Video over LTE (ViLTE) in 4G mobile systems. A similar document is published for RTT, voice and video over 5G in GSMA NG.114 [i.46]. Wide band audio is specified in these documents to use the same audio codecs as under b).
- Web technologies: For communication in web technologies, W3C® and IETF have created the WebRTC concept specified in IETF RFC 8825 [i.87] where the mandatory audio codecs with wide band audio capabilities are specified in IETF RFC 7874 [i.84] to be Opus, while Recommendation ITU T G.722 [i.20] is also recommended by IETF RFC 7875 [i.85] and is usually provided in implementations.
- Emergency communications: An interface to IP based emergency communications is specified in ETSI TS 103 479 [i.48]. It makes use of Recommendation ITU-T G.722.2 [i.21] AMR-WB, IETF RFC 6716 [i.83] updated by IETF RFC 8251 OPUS, and Recommendation ITU-T G.722 [i.20]. for wide-band audio. A corresponding standard exists for North America. For emergency apps, ETSI TS 103 478 [i.47] is specified in ETSI TS 103 945 [i.89] to implement wide band audio by use of Opus IETF RFC 6716 [i.83] updated by IETF RFC 8251 [i.86]. The use of these standards for accessible and interoperable emergency communications is specified in ETSI TS 103 919 [i.56].
- Relay services: ETSI ES 202 975 [i.6] specifies in its clause 6.1 interfaces to relay services, referring to the present document for specific technologies.
NOTE 2: Frequencies between 250 Hz and 7 000 Hz are essential for good speech perception.
NOTE 3: Frequencies between 100 Hz and 250 Hz provide extra information for person recognition.
NOTE 4: Background information and detailed guidance about accessible voice communication is available in ETSI ES 204 009 [i.77].
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
6.1.2 Audio bandwidth for capture and presentation for voice communication
Where ICT provides functionality that allows real-time bidirectional voice communication, and has a user interface for real-time bidirectional voice communication, the ICT shall be able to capture, communicate and present voice communication with a frequency range of at least down to 250 Hz and up to at least 7 000 Hz.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
6.1.3 Audio presentation in attached listening devices for voice communication (recommendation)
Where ICT provides functionality that allows real-time bidirectional voice communication, and has an interface for external presentation of voice communication, the ICT should be able to present audio with a frequency range of at least down to 100 Hz and up to at least 7 000 Hz.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
6.1.4 Synchronization of subtitles (recommendation)
Where ICT provides subtitles for real-time bidirectional voice communication, the delay of provided subtitles in relation to the speech should not exceed 2 seconds.
NOTE: The delay is measured from when a word is completely spoken until the first character of the word is presented.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
6.2 Real-Time Text (RTT)
6.2.1 RTT provision
6.2.1.1 RTT functionality
Where ICT provides functionality that allows real-time bidirectional voice communication, the ICT shall provide functionality that allows real-time bidirectional RTT communication.
NOTE 1: The above requirement implicitly requires that ICT that interoperates with other ICT for real-time bidirectional voice communication would interoperate for RTT as well.
NOTE 2: This requirement includes those products which do not have physical display or text entry capabilities but have the capability to connect to devices that do have such capabilities. It also includes intermediate ICT between the endpoints of the communication.
NOTE 3: The precondition of the present clause implies multi-party RTT support where multi-party voice is supported.
NOTE 4: Background reading about RTT and a comprehensive reference list is available in ETSI TR 103 708 [i.59]. Additional detailed guidance is provided in ETSI ES 204 009 [i.77].
NOTE 5: Many other clauses than 6.2 of the present document are valid for RTT implementation.
NOTE 6: Clause 11.5 of the present document presents considerations about use of assistive technology which are also considerations for RTT implementations. In the RTT case, best practice is that new text input can arrive anytime while the user is reading earlier received text and the user is made aware that new text is available while not disturbing the reading of earlier received text.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.1.2 Concurrent voice and RTT
Where ICT provides real-time bidirectional voice communication, and supports RTT, the ICT shall allow concurrent voice and RTT.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.1.3 Single user action
Where ICT provides real-time bidirectional voice communication, and includes RTT capabilities, the ICT shall allow single user operations to act on all requested or already established media, during requests to establish media, answering requests to establish media, modifications during the communication, and disconnections.
NOTE 1: Modification includes transfer, hold, and other changes to communications or participants.
NOTE 2: For a communication client, the single user operation may result in multiple media requests to answer or establish voice and RTT and optionally other media.
NOTE 3: A single user operation may request the establishment of a communication that involves media that are not available at both ends. In these cases, automatic retries, with a reduced number of media, may be used to complete the establishment of a session using only the media available at both ends.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.2 Display of RTT
6.2.2.1 Distinguishable display
Where ICT supports real-time bidirectional voice communication, and includes RTT presentation capabilities, displayed text that originates from different sources, as well as the text that is sent, shall be displayed with their sources indicated and differentiated.
NOTE 1: The ability of the user to choose between different layouts of the text that is sent, and the text received from the different sources, would allow users to display RTT in a form that works best for them, while still fulfilling the requirement of clause 6.2.2.
NOTE 2: Users relying on AT with small displays (e.g. deafblind users) may benefit from accessing the locally produced text and one other source side-by side to facilitate easy reading.
NOTE 3: The source indication does not require more than a unique identifier, not necessarily a real identity (e.g. Speaker 1 or Speaker 2 would be sufficient if nothing better is known).
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.2.2 Active communicator indication
Where ICT supports real-time bidirectional voice communication, and includes RTT send and receive capabilities, and provides speaker indication for voice, the ICT shall provide indication of all active communicators including those using RTT.
NOTE: This is necessary to enable all parties to know who or what is currently communicating, whether it be in RTT or voice.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.2.3 Indication of audio with RTT
Where ICT provides real-time bidirectional voice communication, and supports RTT, the ICT shall provide a real-time indicator of non-local audio activity on the display.
NOTE 1: The indicator may be a simple character position on the display that flickers on and off to reflect the varied strength of the audio activity, or presentation of the information in another way that can be both visible to sighted users and presented to deaf-blind users.
NOTE 2: Without this indication a person who lacks the ability to hear does not know when someone is talking.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.2.4 Presentation of relative time order of text
Where ICT supports real-time bidirectional voice communication, and includes RTT presentation capabilities, the ICT shall present the text from each source, including the local source, as blocks of text that are arranged in order based on the point in time that each block of text is terminated by any sentence-terminating punctuation character followed by a space, or a line separator character is entered or received, or 5 seconds passes without a new character being entered or received. Editing of text in a block causes the entire block's termination time to change to the time of the last edited character.
NOTE 1: Text blocks from the same source are presented contiguously, forming a single block, unless an intervening text block from a different source is received. For example, the phrases 'J.D. Clampett is here! But no one else is.' will appear as one continuous text presentation when no other sources are sending concurrently. If, however, another source sends text at the same time, then within a single column view, the blocks are presented in chronological order, with text blocks from different sources interleaved but kept distinct.
NOTE 2: This requirement aims to establish an approximate chronological order for displaying text from different sources, while maintaining text blocks together for readability. Precise timing between texts from different sources received concurrently is unnecessary and would reduce readability in most layouts.
NOTE 3: Presentation aspects of RTT are presented in ETSI TR 103 708 [i.59] clause 7.2.
NOTE 4: The events terminating a block of text in the present clause is the minimum set. For smooth presentation other events can be added to a product, such as end of phrase or reasons found by linguistic analysis in languages not using explicit delimiter characters.
NOTE 5: See clause 6.2.5 of the present document for additional information regarding adding and erasing of text.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.2.5 Review of RTT communication contents
Where ICT supports real-time bidirectional voice communication, and includes RTT presentation capabilities, the ICT shall provide the ability to review the whole RTT content of the communication during the communication and, if the communication is recorded, after the communication has ended.
NOTE: Best practice is to have the text view scroll with the arrival of new text, but only when the view is fully scrolled to the end of the text display.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.3 DTMF touch-tone generation during RTT operations
Where ICT is, or includes, a communication client, and provides functionality that allows real-time bidirectional voice communication, and supports the generation and transmission of touch-tone signals on voice calls, the client shall provide a method for generation and transmission of touch-tone signals for touch-tone characters (0-9,*,#,A,B,C,D) that is distinct from the method for generating RTT for those same characters, and is compatible with the standard method for sending touch-tones during voice calls.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.4 RTT responsiveness
Where ICT is, or includes, a communication client, and supports real-time bidirectional voice communication, and supports RTT, RTT input shall be transmitted to the ICT network on which the ICT runs within 500 ms of the time that the smallest reliably composed unit of text entry is available to the ICT for transmission where delays due to network performance are not included in the 500 ms limit.
NOTE 1: The "smallest reliably composed unit of text entry" varies depending on how text is being generated. When typing individual characters, the "smallest reliably composed unit of text entry" would be a character, even if it is composed by multiple keystrokes. For word prediction, it would be a word. For some voice recognition systems - the text may not exit the recognition software until an entire word (or phrase) has been spoken, in which case, the smallest reliably composed unit of text entry available to the ICT would be the word (or phrase). Also, other operations, such as copy-paste, may occasionally cause the unit of text entry to be more than one character.
NOTE 2: The 500 ms limit allows buffering of characters for this period before transmission. Character by character transmission is only required if the characters are generated at a rate of less than 1 character per 500 ms.
NOTE 3: A delay of 300 ms, or less, produces a better impression of flow to the user.
NOTE 4: If there is less than 1-second delay between when a key is pressed and when the character appears on another communication client included in the same communication, this requirement can be deemed as met because that is the user requirement behind this requirement as specified in Recommendation ITU T F.703 [i.38], and the at least 500 ms time left for the packet with the character to reach the destination is sufficient in network conditions where voice communication show satisfying performance. (see testing C.6.2.4).
NOTE 5: Synchronization of RTT with audio and video is achieved when all three media are presented within their respective latency requirements.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.5 Adding and erasing of RTT input
Where ICT supports real-time bidirectional voice communication, and includes RTT capabilities, and supports RTT user input, the RTT user interface shall provide the functionality to enter new text and to erase text entered in an ongoing communication where the erasure is done from the current end of text without being limited by any new line or other delimiter in the earlier text.
NOTE 1: Each erase-previous-character operation erases a complete delimiter or text element (whether 1 or 2 characters) so that local and remote presentation is kept synchronized.
NOTE 2: The intention of this requirement is to enable entry of text and to allow corrections, which may include just erasure or erasure and entry of replacing text.
NOTE 3: "Functionality to erase text" includes both manual erasure, enabling replacement with corrected text, as well as automatic correction mechanisms such as automatic spelling correction or corrections done by speech-to-text and other such text-generating mechanisms that might perform auto-correction.
NOTE 4: It is best practice to mark sections where the text has changed.
NOTE 5: See clause 6.2.2.4 of the present document about presentation aspects of adding and erasing text.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.6 Processing rate of RTT
Where ICT supports real-time bidirectional voice communication, and supports multiparty communication, and includes RTT capabilities, the ICT shall have the capacity to receive and process RTT at a total rate of 90 characters per second coming from a minimum of 3 simultaneous sources sending 30 characters per second each.
NOTE: The requirement may have implications depending on the role of the ICT. For example, for a communications client, it means presenting, for a router it means transferring, and for a multi-party bridge it means mixing and distributing or just distributing.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.7 Character representation
Where ICT supports real-time bidirectional voice communication, and includes RTT capabilities, the ICT shall be capable of handling at least a subset of ISO/IEC 10646 [i.53] that includes at least:
- the Latin-1 part;
- the writing direction(s) and the characters for the languages of the regions in which the ICT is intended to be used;
- any emoji characters supported by the underlying platform;
- the ISO/IEC 10646 [i.53] "replacement character" (HEX:FFFD) used for indication of unsupported and lost characters, including emojis; and
- any characters used by the presentation protocol.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.8 RTT input methods
Where ICT is, or includes, a communication client, and supports real-time bidirectional voice communication, and supports RTT, the client shall provide RTT input methods in all ways available for general text input by the ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS)
Secondary: Usage with limited reach (LR), Usage with limited cognition (LC)
6.2.9 RTT media establishment and use
Where ICT supports real-time bidirectional voice communication, and includes RTT capabilities, all of the following shall be true for the ICT regardless of any system or client settings:
- it is possible to request establishment of a communication with RTT media;
- it is possible to answer a request for a communication and get RTT media included regardless of whether it was included in the original request;
- it is possible to upgrade an existing communication by any party to include RTT media.
NOTE 1: The establishment of the RTT media could be requested and answered by a user, an automatic procedure in a user terminal, a non-human process, or a setting in a conference session.
NOTE 2: The present clause implies that ICT with RTT capabilities has the RTT functionality ready for RTT media establishment and use when voice functionality is ready for media establishment and use.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.2.10 RTT interoperability
Where ICT provides functionality that allows real-time bidirectional voice communication, and connects to other ICT that allows real-time bidirectional voice communication, the ICT's documentation shall contain information on the main specifications by which RTT is implemented in a manner that allows the RTT on the ICT to interoperate with the other ICT that the ICT interoperates with for voice, using one of the following options:
- Any set of specifications for RTT communication that would fulfil the RTT requirements in the present document that is mutually agreed to be used between the ICT and any other ICT with which the ICT interoperates for real-time bidirectional voice communication.
- Recommendation ITU-T T.140 [i.37] for functions including coding and presentation and IETF RFC 4103 [i.13] updated by IETF RFC 9071 [i.52] for other aspects of RTT communication.
NOTE 1: If there is no agreement to use some other standard, then clause 6.2.10 allows any ICT to fulfil clause 6.2.10 by implementing option b). This is the fallback option to use when no other method has been agreed on, and it might serve as a 'safe harbour' for conforming to clause 6.2.10 when no agreement can be reached.
NOTE 2: ICT that provides Emergency communications with real-time bidirectional voice is an important case of an operational scenario where communication systems are required to interoperate. See clause 13.3.
NOTE 3: A number of other factors are important to also be agreed automatically or by external means in the communication system interface for RTT interoperability to work, such as security mechanisms, addressing, NAT-traversal mechanisms, transport method for session control, etc.
NOTE 4: Specifications for RTT implementation are provided for a number of technologies. The following list provides an overview of the situation at the time of authoring the present document. It is presented here as a guide for achieving interoperability. Almost all of these specifications make use of Recommendation ITU-T T.140 [i.37] for functions including coding and presentation:
- General VoIP and Multimedia communication: IETF, providing standards for Voice Over IP (VOIP) and Multimedia communications over IP based on the Session Initiation Protocol (SIP) IETF RFC 3261 [i.50], has published IETF RFC 4103 [i.13] for session establishment and transport of RTT over RTP IETF RFC 3550 [i.51] and its update IETF RFC 9071 [i.52] for multiparty use.
- IP Multimedia Sub-System (IMS): 3GPP, providing standards for mobile communication systems, including IP Multimedia Sub-System (IMS) has standardized the Multimedia Telephony concept, for communications with voice, video and RTT using the set of protocols specified in ETSI TS 126 114 [i.11] to create the services including RTT and Total Conversation services specified in ETSI TS 122 173 [i.12]. Multimedia Telephony is specified to use IETF RFC 4103 [i.13] updated by IETF RFC 9071 [i.52] for session establishment and transport of RTT over RTP or the RTT based on WebRTC Data Channel Technologies. Details of the use of these variants can be found in ETSI TR 126 982 [i.43].
It should be noted that 3GPP and GSMA use the following varying terms for RTT: GTT, Global Text Telephony, GTT-IP, RTT, real time text, and text. - GSMA, providing selected profiles of standards for implementing globally interoperating mobile communication services has in GSMA PRD IR.92 [i.44] specified how to apply ETSI TS 126 114 [i.11] to implement RTT and Voice over LTE (VoLTE) and in GSMA PRD IR.94 [i.45] Video over LTE (ViLTE) in 4G mobile systems. A similar document is published for RTT, voice and video over 5G in GSMA NG.114 [i.46]. RTT is specified in these documents in clause B.2 to use ETSI TS 126 114 [i.11] for session establishment and transport of RTT.
- Web technologies: For communication in web technologies, W3C and IETF have created the WebRTC concept where the Reliable WebRTC Data channel concept IETF RFC 8831 [i.57] in its section 3.2 use case U-C 5 is recommended to be used for RTT. The use of WebRTC Data Channels in web pages and apps is specified in W3C WebRTC: Real-Time Communication in Browsers [i.58].
- Emergency communications: An interface to IP based emergency communications is specified in ETSI TS 103 479 [i.48], making use of IETF RFC 4103 [i.13] updated by IETF RFC 9071 [i.52] for RTT. A corresponding standard exists for North America. For emergency apps, ETSI TS 103 478 [i.47] is specified to implement RTT as specified in ETSI TS 103 871 [i.49]. The use of these standards for accessible and interoperable emergency communications including the use of RTT is specified in ETSI TS 103 919 [i.56]
- Relay services: ETSI ES 202 975 [i.6] specifies in its Annexes A and B interfaces to relay services, referring to the present document for specific technologies.
NOTE 5: Analogue Text telephony is a legacy text communication concept providing functionality to some degree similar to RTT in circuit-switched fixed and mobile technologies. There are 6 variants for fixed lines, collected in Recommendation ITU-T V.18 [i.22], and one for circuit-switched 2G and 3G mobile technologies specified in ETSI TS 126 226 [i.55]. Interworking between these technologies and RTT can be achieved to some degree but with severe functional limitations such as no support for multiparty text communication, need for gateways for character conversion and buffering the much faster RTT text input to accommodate the slower rate of analog technologies, clashes due to lack of bi-directional support, and no possibility to use voice while text is transmitted. The differences can also cause confusion to users unaware of the differences. Details about the limitations can be found in the references in the present note and in IETF RFC 5194 [i.62], section 6.2.5. Considering these limitations, Analogue Text telephony does not provide a working (additional) sensory channel.
NOTE 6: For applying option b) it can be emphasized that the fallback method for multiparty mixing and presentation of RTT in multi-party unaware clients specified in IETF RFC 9071 [i.52], sections 2.2 and 4.2 does not provide a satisfactory user experience and is discouraged from regular use.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.3 Caller ID
Where ICT provides caller identification or other identification functions, the caller identification and other identification functions shall be available in text form as well as being programmatically determinable, for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV)
Secondary: Usage with limited cognition (LC)
6.4 Alternatives to voice-based services
Where ICT provides voice mail, auto-attendant, or interactive voice response facilities, the ICT shall offer users a means to access the information and carry out the tasks provided by the ICT without the use of hearing or speech.
NOTE 1: Tasks that involve both operating the interface and perceiving the information would require that both the interface and information be accessible without use of speech or hearing.
NOTE 2: Solutions capable of handling audio, RTT and video media could satisfy the above requirement.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
6.5 Video communication
6.5.1 General (informative)
Clause 6.5 (Video communication) provides performance requirements that support users who communicate using sign language and lip-reading. For these users, good usability is achieved with a resolution of at least Quarter Video Graphics Array (QVGA, 320 × 240), a frame rate of 20 frames per second and over, with a time difference between speech audio and video that does not exceed 100 ms.
Increasing the resolution and frame rate further improves both sign language (especially finger spelling) and lipreading, with frame rate being more important than resolution.
Time differences between audio and video (asynchronicity) can have a great impact on lip-reading - with video that lags behind audio having greater negative effect.
End-to-end latency can be a problem in video (sign) communication. Overall delay values below 400 ms are preferred, with an increase in preference down to 100 ms. Overall delay depends on multiple factors, including e.g. network delay and video processing. For this reason a testable requirement on minimum values for overall delay cannot be produced.
NOTE 1: Recommendation ITU T F.703 [i.38] defines and gives requirements for Total Conversation that relate to the integration of audio, RTT and video in a combined real-time bidirectional communication.
NOTE 2: The delays are specified in Recommendation ITU-T P.1305 [i.61].
NOTE 3: For the purposes of interoperability and sufficient quality, support of Recommendation ITU T H.264 [i.74] at least version 10 and at least constrained baseline level 3 is widely used for this purpose.
NOTE 4: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU‑T H.265 [i.75] and IETF RFC 6386 VP8 [i.76] are commonly used with proper settings are suitable so as to avoid transcoding.
NOTE 5: Background reading and detailed guidance about accessible video communication is provided in ETSI ES 204 009 [i.77].
6.5.2 Resolution
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT:
- shall support at least QVGA resolution;
- should preferably support at least VGA resolution.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage without vocal capability (WVC), Usage with limited cognition (LC)
6.5.3 Frame rate
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT:
- shall support a frame rate of at least 20 Frames Per Second (FPS);
- should preferably support a frame rate of at least 30 Frames Per Second (FPS) with or without sign language in the video stream.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage without vocal capability (WVC), Usage with limited cognition (LC)
6.5.4 Synchronization between audio and video
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT shall ensure that voice is received by the user not earlier than 100 ms before and not later than 100 ms after the corresponding video is presented to the user.
NOTE: Verification material and methods are described in Recommendation ITU-T H.Sup1 [i.65], clause 6.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage without vocal capability (WVC), Usage with limited cognition (LC)
6.5.5 Indicator of audio with video
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT shall provide a real-time indicator of audio activity.
NOTE 1: The indicator may be a simple visual dot, or other type of on/off indicator, that flickers to reflect audio activity.
NOTE 2: Without this indication a person who lacks the ability to hear does not know when someone is talking.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage without vocal capability (WVC), Usage with limited cognition (LC)
6.5.6 Indication of all active communication participants
Where ICT provides real-time bidirectional voice communication, includes real-time bidirectional video communication, and provides speaker indication for voice users, the ICT shall provide indication of all active communicators including those signing.
NOTE 1: The speaker ID can be in the same location as for voice users for multiparty communication sessions.
NOTE 2: This mechanism might be triggered manually by a user, or automatically where this is technically achievable.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage without vocal capability (WVC), Usage with limited cognition (LC)
6.6 Alternatives to video-based services (recommendation)
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, and provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:
- for audible information, without the use of hearing;
- for spoken commands, without the use of speech;
- for visual information, without the use of vision.
NOTE: Solutions capable of generating real-time subtitles or handling RTT could satisfy the above requirement.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC),
Secondary: Usage with limited cognition (LC)
6.7 Total conversation
6.7.1 Total conversation provision
Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video functionality, the ICT shall provide total conversation by also including RTT capability that conforms to the requirements of clause 6.2, voice that conforms to clause 6.1, and video that conforms to clause 6.5, conforming also to clauses 6.3 and 6.4.
NOTE: ETSI ES 204 009 [i.77] provides background information and detailed guidance on many aspects of total conversation, its media components, interoperability and use, including synchronization and multiparty aspects.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
6.7.2 Total conversation interoperability
Where ICT provides functionality that allows real-time bidirectional voice communication, and includes real-time bidirectional video functionality, and connects to other ICT that allows real-time bidirectional voice communication, including real-time bidirectional video functionality, the ICT's documentation shall contain information on the main specifications by which video is implemented in a manner that allows the video on the ICT to interoperate with other ICT that the ICT interoperates with for voice and video, using one of the following options:
- Any set of specifications for video communication that would fulfil the total conversation requirements in the present document that is mutually agreed to be used between the ICT and any other ICT with which the ICT interoperates for real-time bidirectional voice and video communication.
- Recommendation ITU-T H.264 [i.74] at least version 10 and at least constrained baseline level 3 for functions including coding and presentation, and/or, where codec negotiation is implemented, Recommendation ITU-T H.265 [i.75] and IETF RFC 6386 VP8 [i.76] to avoid transcoding.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
7 ICT with video capabilities
7.1 Subtitle processing technology
7.1.1 Subtitle playback
Where ICT displays video with synchronized audio, the ICT shall have a mode of operation to display the available subtitles. Where closed subtitles are provided as part of the content, the ICT shall allow the user to choose to display the subtitles.
NOTE 1: Subtitles may contain information about timing, colour and positioning. This subtitle data is necessary for subtitle users. Timing is used for subtitle synchronization. Colour can be used to convey additional information such as speaker identification, emotion or tone, or that the text represents music lyrics vs. dialog. Position can be used to avoid obscuring important information.
NOTE 2: If an assistive technology (such as a braille display, or large caption display) is connected to an ICT using a standard connection, identification, and data communication protocol for that type of device, it is best practice for the ICT to provide an option to display subtitles on the braille device.
NOTE 3: Clause 7.1.1 refers to the ability of the player to display subtitles. Clauses 9.1.2.2, 10.1.2.2 and 11.1.2.2 refer to the provision of subtitles for the content (the video).
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
7.1.2 Subtitle synchronization
Where ICT displays video with synchronized audio, and displays subtitles, the ICT shall display subtitles within 100 ms of the timecode value attached to the subtitle.
NOTE 1: If subtitles without timecodes are to be displayed, the best practice is to display the subtitles as soon as they are received.
NOTE 2: It is good practice to display a subtitle within 20 ms of the respective timecode.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
7.1.3 Preservation of subtitles
Where ICT transmits, converts, or records video with synchronized audio, the ICT shall preserve subtitle data such that the subtitles can be displayed in a manner consistent with clause 7.1.1, including any data relating to presentational aspects such as screen position, text and background colours, text style and text fonts.
NOTE: Additional presentational aspects of the text such as screen position, text colours, text style and text fonts may convey meaning, based on regional conventions. Altering these presentational aspects could change the meaning and should be avoided wherever possible.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
7.1.4 Subtitle characteristics
Where ICT displays video with synchronized audio, and has control over the presentation of its subtitles, the ICT shall provide a way for the user to adapt the displayed characteristics of subtitles to their individual requirements, except where the subtitles are displayed as unmodifiable characters.
NOTE 1: Defining the background and foreground colour of subtitles, font type, size, opacity of the background box of subtitles, and the contour or border of the fonts can contribute to meeting this requirement.
NOTE 2: Subtitles that are bitmap images are examples of unmodifiable characters.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
7.1.5 Spoken subtitles
Where ICT displays video with synchronized audio, the ICT shall have a mode of operation to enable output of the available spoken subtitles.
NOTE 1: Spoken subtitles are sometimes provided to accompany interlingual subtitles, so that users who are blind and partially sighted or cannot read can understand dialogue that is being spoken in a language different to their own. They are also sometimes provided to offer an understandable version of indistinct or otherwise unintelligible speech.
NOTE 2: This requirement does not mean that players generate spoken subtitles from available subtitles, but only that they play spoken subtitle audio if it is available.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
7.2 Audio description technology
7.2.1 Audio description playback
Where ICT displays video with synchronized audio, the ICT shall provide a mechanism to select and play available audio description to the default audio channel.
Where video technologies do not have explicit and separate mechanisms for audio description, an ICT is deemed to satisfy this requirement if the ICT enables the user to select and play one of several audio tracks.
NOTE 1: In such cases, the video content can include the audio description as one of the available audio tracks.
NOTE 2: Audio descriptions in digital media sometimes include information to allow descriptions that are longer than the gaps between dialogue. Support in digital media players for this "extended audio description" feature is useful, especially for digital media that is viewed personally.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
7.2.2 Audio description synchronization
Where ICT displays video with synchronized audio, and has a mechanism to play audio description, the ICT shall preserve the synchronization between the audio/visual content and the corresponding audio description.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
7.2.3 Preservation of audio description
Where ICT transmits, converts, or records video with synchronized audio, the ICT shall preserve audio description data such that the audio description can be played in a manner consistent with clauses 7.2.1 and 7.2.2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
7.3 User control of audiovisual accessibility features
Where ICT primarily displays video with synchronized audio, and has control over the activation of subtitles, audio description, and spoken subtitles, the ICT shall provide at least one mode of operation that allows the activation and deactivation of the user's choice of either subtitles, audio description, or spoken subtitles with a single user operation that is at the same level as the volume control and that meets the other accessibility requirements of the present document.
NOTE 1: Media player software would meet the precondition of this requirement because its primary purpose is to play audiovisual materials, but a preview feature in a file utility that shows quick views of the contents of files as they are selected, (including playing a video file in a window or pane without controls) would not, because its primary function is file management, and the primary function of the preview function is to allow files to be identified by peeking into them, not to view audiovisual content.
NOTE 2: It is best practice to allow other accessibility features related to audiovisual content to also be chosen with a single user operation.
NOTE 3: It is best practice for ICT to include mechanisms to enable the user to select whether subtitles, or audio description, or spoken subtitles are turned on or off each time the ICT is used.
NOTE 4: There could be separate methods for activating and deactivating these functions.
NOTE 5: The ability to use spoken commands is best practice to include because it makes it possible to have all accessibility functions available instantly, but since all speech control also requires a non-speech alternative (clause 5.1.7) it cannot be the only method for meeting clause 7.3.
NOTE 6: If the ICT is or includes a platform, on which other ICT can be implemented, it is not responsible to ensure that such other ICT meet the present clause. But it is responsible to meet clause 11.5.2.1 Platform interoperability with assistive technologies, which should result in API methods that the other ICT could use to meet the present clause.
EXAMPLE: One solution would be to have a single button at the volume control level, bring up a list of subtitles, audio description, spoken subtitles and (potentially) other accessibility features if it was held down for more than 2 seconds. The user could activate any accessibility feature from that menu - as well as chose an accessibility feature that would be turned on and off with a single short press of the same button that was used to bring up the menu with a long press. (If this was standardized across manufacturers it would facilitate dissemination of information about this feature and provide cross-manufacturer consistency). It is best practice to have a dedicated button for doing the above (providing single button to both chose and then later activate the single chosen function with a simple press), but a button that exists in a current design, like the mute button, could be repurposed for this where a remote has only a few buttons and a dedicated button cannot be provided.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
8 Hardware
8.1 General
The "generic requirements" of clause 5 also apply to ICT that is hardware.
8.2 Hardware products with speech output
8.2.1 Speech volume
8.2.1.1 Speech volume gain
Where ICT is, or includes, hardware, and has speech output, and is a device that is typically held to the ear, the ICT shall provide a means to adjust the speech output volume level to achieve at least 18 dB of conversational gain.
NOTE 1: ANSI/TIA-4965 [i.2] (for fixed-line handsets) and ANSI/TIA-5050 [i.3] (for mobile wireless handsets) require the option to enhance the SPL by at least 18 dB over the SPL level of speech for a conversation at a distance of 1 m which is 70 dB for monaural listening.
NOTE 2: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 [i.2] and mobile wireless handsets fulfilling the requirements of ANSI/TIA-5050 [i.3] are deemed to comply with this requirement.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
8.2.1.2 Incremental volume control
Where ICT is, or includes, hardware, and has speech output, and is a device that is typically held to the ear, and its volume control is incremental, the ICT shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
8.2.2 Magnetic coupling
8.2.2.1 Fixed-line devices and handsets
Where ICT is, or includes, hardware, and has speech output, and is a fixed-line communication device or wired handset that is typically held to the ear, the ICT shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-1 [2] and shall be marked as being compatible with magnetic coupling if the ICT is designed for public use.
NOTE 1: ICT fulfilling the magnetic coupling, interference, and labelling requirements of TIA-1083-B [i.23] is deemed to comply with the requirements of this clause.
NOTE 2: Magnetic coupling is also known as inductive coupling for T-coil.
NOTE 3: Kiosks and other Information Transaction Machines (ITMs) sometimes have wired handsets that are held to the ear.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
8.2.2.2 Wireless communication devices
Where ICT is, or includes, hardware, and has speech output, and is a wireless communication device that is typically held to the ear, the ICT shall provide a means of magnetic coupling and reduced interference to hearing technologies which meets the requirements of ETSI ES 200 381-2 [3].
NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 [i.1] is deemed to comply with the requirements of this clause.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH)
8.3 Stationary ICT
8.3.1 General (informative)
The present document defines the requirements for the design of stationary ICT that can be placed in a built environment, but does not define the dimensions of the built environment. The current clause contains only those accessibility requirements that are caused by functional and design requirements of the ICT.
The scope includes stationary ICT and includes ICT installed in closed spaces (typically kiosks and cabins).
NOTE 1: For stationary ICT that stands on the ground, the base of the ICT is considered to be part of the stationary ICT.
Access space and manoeuvring space needed to access the stationary ICT (whether inside or outside of a closed space) are out of the scope of this clause 8.3. Advice and requirements related to the size and design of access spaces can be found in [i.35], [i.64] and [i.63].
For certain stationary ICT it may not be possible to meet the requirements in some clauses due to functional or design requirements which restrict the possible design of stationary ICT. The present document contains therefore two sets of requirements for ICT with no functional or design restrictions (8.3.3.1, 8.3.5.1, 8.3.7.1, 8.3.9.2, 8.3.10.2, or 8.3.11.1,) (called "Set 1") and for ICT with functional or design restrictions (8.3.3.2, 8.3.5.2, 8.3.7.2, 8.3.9.3, 8.3.10.3, or 8.3.11.2) (called "Set 2").
Stationary ICT which is unable to meet the requirements in Set 1 is expected to meet the requirements in Set 2.
NOTE 2: Stationary ICT which meets the requirements in Set 1 also meets the requirements in Set 2.
If in a specified location several stationary ICT devices with identical functionality and purpose are installed, it may be possible to apply the requirements of this clause 8.3 to only a limited number of these stationary ICT devices. This exception and how it may be handled is out of scope of this clause 8.3.
NOTE 3: In the context of this exception, ICT that does not meet the requirements of Set 1, and which is installed based on this exception, is expected to meet the requirements in Set 2.
8.3.2 Display screen location
Where ICT is stationary ICT, display screens which are part of the ICT shall be placed in a way that no part of the display extends below 800 mm above the floor of the access space.
NOTE: For ICT that is mounted on a wall or installed on a table, the required minimum height can be achieved by mounting the ICT at the appropriate height above the floor or the access space or by selecting a matching table height.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.3 Presentation of information necessary for the operation of stationary ICT
8.3.3.1 Presentation of information necessary for the operation of stationary ICT (no design restrictions)
Where ICT is stationary ICT and there are no functional or design requirements which do not allow to present necessary information below 1 600 mm above the floor space, information necessary to operate the stationary ICT shall be placed not higher than 1 600 mm above the floor of the access space.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.3.2 Presentation of information necessary for the operation of stationary ICT (with design restrictions)
Where ICT is stationary ICT and there are functional or design requirements which do not allow to present necessary information below 1 600 mm above the floor space
information necessary to operate the stationary ICT shall be placed not higher than 2 000 mm above the floor of the access space.
NOTE: Examples for stationary ICT for which it may not be possible to display all necessary information below 1 600 mm above the floor level include, but are not limited to large refrigerators or other devices which need large door openings.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.4 Legibility of display screens (informative)
Where a display screen has closed functionality regarding text enlargement, clause 5.1.4 applies.
Where a display screen is a touch screen, the requirements in clauses 8.3.5 and 8.3.6 apply.
NOTE: The legibility of information on display screens is dependent on different parameters such as font size, colour contrast, environment lighting, glare, parallax, privacy screen features etc.
8.3.5 Control location (vertical)
8.3.5.1 Control location (vertical, no design restrictions)
Where ICT is stationary ICT and there are no functional or design requirements which do not allow to duplicate operable parts or locate them above 800 mm and below 1 100 mm, at least one of each type of operable part shall be located in an elevation between 800 mm (minimum) and 1 100 mm (maximum) above the floor of the floor space.
NOTE 1: Keeping the minimum height of operable parts to 800 mm is intended to give better access for standing users and for wheelchair users with impaired upper body control.
NOTE 2: If the controls for ICT that is mounted on a wall or installed on a table, the required minimum height can be achieved by mounting the ICT at the appropriate height above the floor or the access space or by selecting a matching table height .
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.5.2 Control location (vertical, with design restrictions)
Where ICT is stationary ICT and there are functional or design requirements which do not allow duplication of operable parts or locate them above 800 mm and below 1 100 mm, the minimum height of operable parts which cannot be duplicated shall be 380 mm, and the maximum height of operable parts which cannot be duplicated shall be 1 220 mm, and access to operable parts which cannot be copied shall not be hindered by obstructions.
NOTE: Examples for stationary ICT for which it may not be possible to keep copies of all operable parts within the vertical control location limits required in clause 8.3.5.1 include, but are not limited to coin sorting machines, Automated Teller Machines (ATMs), payment and ticketing terminals, food and drink dispensing machines, or supermarket checkout terminals.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.6 Control location (horizontal)
Where ICT is stationary ICT, at least one of each type of operable part shall be located in an area that has a maximum horizontal extent of 900 mm.
NOTE 1: Keeping the maximum extent of the space available for controls limited ensures that users do not need to relocate to get access to all controls.
NOTE 2: The maximum horizontal extent is based on estimates provided in [i.69].
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.7 Reach depth
8.3.7.1 Reach depth (no design restrictions)
Where ICT is stationary ICT, and there are no functional or design requirements which do not allow duplication of operable parts or locating them in an area that has a maximum distance of 300 mm from the edge of the ICT, at least one of each type of operable part shall be located in an area that has a maximum distance of 300 mm from the edge of the ICT which has the shortest distance to the user.
NOTE 1: The reach depth may also effect the maximum depth of obstructions if the position of operable parts is recessed from the edge of the stationary ICT.
NOTE 2: If the position of operable parts is recessed from the edge of the stationary ICT by x mm (x < 300 mm) then the maximum depth of an obstruction is reduced by the same x mm.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.7.2 Reach depth (with design restrictions)
Where ICT is stationary ICT, and there are functional or design requirements which do not allow duplication of operable parts or locating them in an area that has a maximum distance of 300 mm from the edge of the ICT, at least one of each type of operable part shall be located in an area that has a maximum distance of 510 mm (for forward reach) and 610 mm (for side reach) from the edge of the ICT which has the shortest distance to the user.
NOTE 1: The reach depth also effects the maximum depth of obstructions if the position of operable parts is recessed from the edge of the stationary ICT.
NOTE 2: If the position of operable parts is recessed from the edge of the stationary ICT by x mm then the maximum depth of an obstruction is reduced by the same x mm.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.8 Forward or side reach (informative)
Stationary ICT may be designed to enable users of wheeled mobility devices to access the stationary ICT for forward reach or for side reach.
NOTE: The assessment of the type of reach necessary depends on the following aspects:
- For simple interactions (e.g. pushing a button, pulling a ticket), side reach is sufficient.
- For more comprehensive interactions (e.g. reading comprehensive information on a screen, entering non sensitive information on an input device), forward reach is preferred.
- For interactions where privacy is essential and/or physical effort is required, forward approach is the best solution where other design constraints permit.
- For ICT devices which require the use of both hands for control and input, forward reach is necessary.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.9 Forward reach
8.3.9.1 Unobstructed forward reach (informative)
For unobstructed forward reach clauses 8.3.5 and 8.3.6 define the correct positioning of controls.
8.3.9.2 Obstructed forward reach (no design constraints)
Where ICT is stationary ICT, and has an obstruction that is an integral part of the ICT (this is called obstructed forward reach), and there are no functional or design constraints which require an obstruction deeper than 300 mm, the ICT shall be designed so that:
- the height of the obstruction shall not exceed 800 mm;
- the maximum depth of the obstruction shall not exceed 300 mm.
NOTE: The maximum depth of the obstruction will be further reduced by clause 8.3.7.1 if the controls are recessed from the edge of the ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.9.3 Obstructed forward reach (with design constraints)
Where ICT is stationary ICT, and has an obstruction that is an integral part of the ICT (this is called obstructed forward reach), and there are functional or design constraints which require an obstruction deeper than 300 mm
the ICT shall be designed so that:
- the height of the obstruction shall not exceed 800 mm
- the maximum depth of the obstruction shall not exceed 510 mm
NOTE: The maximum depth of the obstruction will be further reduced by clause 8.3.7.2 if the controls are recessed from the edge of the ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.10 Side reach
8.3.10.1 Unobstructed side reach (informative)
For unobstructed side reach clauses 8.3.5 and 8.3.6 define the correct positioning of controls.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.10.2 Obstructed side reach (no design constraints)
Where ICT is stationary ICT, and has an obstruction that is an integral part of the ICT (this is called obstructed side reach), and there are no functional or design constraints which require an obstruction deeper than 300 mm, the ICT shall be designed so that:
- the height of the obstruction shall not exceed 800 mm;
- the maximum depth of the obstruction shall not exceed 300 mm.
NOTE 1: The maximum depth of the obstruction will be further reduced by clause 8.3.7.1 if the controls are recessed from the edge of the ICT.
NOTE 2: See Figure 8.1 and Table 8.1 for details on obstructed side reach.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.10.3 Obstructed side reach (with design constraints)
Where ICT is stationary ICT, and has an obstruction that is an integral part of the ICT (this is called obstructed side reach), and there are functional or design constraints which require an obstruction deeper than 300 mm, the ICT shall be designed so that:
- the height of the obstruction shall not exceed 865 mm;
- the maximum depth of the obstruction shall not exceed 610 mm.
NOTE 1: The maximum depth of the obstruction will be further reduced by clause 8.3.7.2 if the controls are recessed from the edge of the ICT.
NOTE 2: Examples for stationary ICT for which it may be not possible to keep the depth of an obstruction below 300 mm include, but are not limited to, supermarket checkout terminals or stationary copier or scanner devices.
This is shown in Figure 8.1: Obstructed side reach (see Table 8.1 for explanations)
8.3.11 Free space underneath stationary ICT with or without an obstruction
8.3.11.1 Free space underneath stationary ICT with or without an obstruction (no design constraints)
Where ICT is stationary ICT and there are no functional or design constraints which prevent the provision of a free space underneath the ICT or restrict the size of that free space, the stationary ICT shall provide an open space (knee and toe clearance) with the dimensions listed in Table 8.2, column "Values for stationary ICT which complies with clause 8.3.11.1" (see Figure 8.2).
This is shown in Figure 8.2: Knee and toe clearance underneath an obstruction (see Table 8.2 for explanations)
8.3.11.2 Free space underneath stationary ICT with or without an obstruction (with design constraints)
Where ICT is stationary ICT and there are no functional or design constraints which prevent the provision of a free space underneath the ICT, but there are functional or design requirements restricting the size of an open space below the ICT, the stationary ICT shall provide an open space (knee and toe clearance) with the dimensions listed in Table 8.2, column "Values for stationary ICT which complies with clause 8.3.11.2". (see Figure 8.2).
NOTE: Functional or design constraints which may make it impossible to provide free space under stationary ICT include, but are not limited to:
- Security requirements (e.g. for ATMs).
- Vandalism protection.
- Need to have operable parts below the limits set in clause 8.3.5.1.
- Positioning stationary ICT freestanding (with a base which is part of the stationary ICT) and related stability requirements.
- There may be legal requirements or national standards which restrict the design of stationary ICT to exclude the provision of free space underneath such stationary ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.3.12 Floor characteristics (informative)
All floor characteristics including floor level changes, clear floor requirements, and the dimensions of necessary manoeuvring spaces are not caused by functional or design requirements of the stationary ICT and are therefore not in scope of this clause.
Advice and requirements related to the floor characteristics can be found in ISO 21542 [i.35] and [i.63].
There should be no change in floor level inside a kiosk, cabin or other closed space in which stationary ICT is installed.
8.3.13 Approach (informative)
The dimensions of the space required in front of stationary ICT for approaching the stationary ICT are not derived from functional or design requirements of the stationary ICT and are therefore not in scope of this clause.
Advice and requirements related to access and manoeuvring spaces can be found in [i.35] and [i.63].
8.3.14 Installation instructions
Where ICT is stationary ICT, installation instructions shall be made available, that give guidance on how to install the ICT in compliance with the applicable requirements of clause 8.3 of the present document and take into account applicable requirements for accessibility of the built environment as they apply to the installation of the ICT.
NOTE: EN 17210 [i.64] is the European standard that defines applicable requirements for accessibility of the built environment in Europe. Other applicable requirements may be found in ISO 21542 [i.35].
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
8.4 Operable parts
8.4.1 Numeric keys
Where ICT is, or includes, hardware, and has physical numeric keys arranged in a rectangular keypad layout, the number five key shall be tactilely distinct from the other keys of the keypad.
NOTE: Recommendation ITU T E.161 [i.19] describes the 12-key telephone keypad layout and provides further details of the form of tactile markers.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV)
8.4.2 Operation of operable parts
8.4.2.1 Means of operation
Where ICT is, or includes, hardware, and has operable parts that require grasping, pinching, or twisting of the wrist to operate, the ICT shall provide at least one mode of operation that does not require these actions.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS)
Secondary: Usage with limited reach (LR)
8.4.2.2 Force of operation of operable parts
Where ICT is, or includes, hardware, and has a control that requires a force greater than 22,2 N to operate it, the ICT shall provide a means of operation that does not requires a force greater than 22,2 N.
NOTE: ISO 21542:2021 [i.35] recommends a value between 2,5 and 5 N.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS)
Secondary: Usage with limited reach (LR)
8.4.3 Keys, tickets and cards
Where ICT is, or includes, hardware, and has keys, tickets or cards, and the orientation of the keys, tickets or cards is important for further use, the keys, tickets or cards shall each have an orientation that is tactilely discernible.
NOTE: ETSI ETS 300 767 [i.7] defines suitable tactile indications for plastic cards.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
8.5 Tactile indication of speech mode
Where ICT is, or includes, hardware, and the ICT is intended for public shared use, and speech output is available, a tactile indication of the means to initiate the speech mode of operation shall be provided.
NOTE: The tactile indication could include braille instructions.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
8.6 Standard connections
Where ICT is, or includes, hardware, and provides input or output device connection points, the ICT shall provide at least one input and/or output connection that conforms to an industry standard non-proprietary format, directly or through the use of commercially available adapters.
NOTE 1: The intent of this requirement is to ensure compatibility with assistive technologies by requiring the use of standard connections on ICT.
NOTE 2: The word connection applies to both physical and wireless connections.
NOTE 3: Current examples of industry standard non-proprietary connections are USB, Bluetooth®.
NOTE 4: For cables that have the same connector for two functions (data + charging and charging only), it is helpful for charging only to be marked in a manner detectable without vision or colour vision.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
8.7 Colour on hardware
Where ICT is, or includes, hardware, and colour is used on the hardware to convey information, colour shall not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Relationship between requirements and functional performance criteria:
Primary: Usage without perception of colour (WPC)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
8.8 Contrast on hardware
Where ICT is, or includes, hardware, non-digitally displayed characters or symbols required for use, or hardware operable parts without labels on them that are not tactilely discernible, shall contrast visually from their background as either light on a dark background or dark on a light background.
NOTE 1: Logos are not considered required for use.
NOTE 2: A common approach is to use a Michelson contrast formula with a contrast of at least 0,7 for the display of information consisting of characters and pictorial symbols and a contrast of at least 0,4 for the identification of operating elements without characters and pictograms.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC)
Secondary: Usage with limited cognition (LC)
9 Web
9.0 General (informative)
Requirements in clause 9 apply to web pages including:
- Conformance with W3C® Web Content Accessibility Guidelines (WCAG 2.0) [i.41] Level AA is equivalent to conforming with clauses 9.1.1, 9.1.2, 9.1.3.1 to 9.1.3.3, 9.1.4.1 to 9.1.4.5, 9.2.1.1, 9.2.1.2, 9.2.2, 9.2.3, 9.2.4 except 9.2.4.11, 9.3 except 9.3.2.6, 9.3.3.7 and 9.3.3.8, 9.4.1.2 and the conformance requirements of clause 9.6 of the present document.
- Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.1) [i.42] Level AA is equivalent to conforming with all of clauses 9.1 to 9.4 except 9.2.4.11, 9.2.5.7, 9.2.5.8, 9.3.2.6, 9.3.3.7, 9.3.3.8 and with the conformance requirements of clause 9.6 of the present document.
- Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.2) [4] Level AA is equivalent to conforming with all of clauses 9.1 to 9.4 and the conformance requirements of clause 9.6 of the present document.
- Requirements for non-web documents and non-web software are given in clauses 10 and 11 respectively.
NOTE 1: When evaluating websites they are evaluated as individual web pages. Web applications, including mobile web applications, are covered under the definition of web page which is quite broad and covers all web content types.
NOTE 2: WCAG 2.0 is identical to ISO/IEC 40500:2012 [i.41].
WCAG 2.2 is identical to ISO/IEC 40500:2025 [4].
NOTE 3: When parts of non-web software, such as mobile apps, are implemented with web views, these web views are embedded in the app and thus do not meet the definition of a web page. The clause 11 "Non-web software" requirements are the appropriate requirements to be applied to these web views. There are no circumstances in which clause 9 requirements and the corresponding clause 11 requirements are both applicable. Where there is any doubt, clause 11 requirements have precedence.
The requirements in clauses 9.1 to 9.4 are written using the concept of satisfying success criteria (defined in clause 3.1). A web page satisfies a WCAG success criterion when the success criterion does not evaluate to false when applied to the web page. This implies that if the success criterion puts conditions on a specific feature and that specific feature does not occur in the web page, then the web page satisfies the success criterion.
EXAMPLE: For example, a web page that does not contain pre-recorded audio content in synchronized media will automatically satisfy WCAG success criterion 1.2.2 (captions - pre-recorded) and, in consequence, will also meet clause 9.1.2.2.
In addition to Level AA success criteria, the Web Content Accessibility Guidelines also include success criteria for Level AAA. These are listed in clause 9.5 of the present document. Web authors and procurement accessibility specialists are encouraged to consider whether any of the WCAG Level AAA success criteria offer suggestions that may be applicable and relevant to their project, as well as potentially beneficial to some users.
NOTE 4: The W3C states that "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content".
NOTE 5: "Void" clauses have been inserted in order to maintain alignment with the numbering of WCAG 2.2 [4] Level A and Level AA Success Criteria.
9.1 Perceivable
9.1.1 Text alternatives
9.1.1.1 Non-text content
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.1.2 Time-based media
9.1.2.1 Audio-only and video-only (pre-recorded)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
9.1.2.2 Subtitles (pre-recorded)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
9.1.2.3 Audio description or media alternative (pre-recorded)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).
NOTE 1: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio video media.
NOTE 2: This clause corresponds to a WCAG success criterion at level A. Another clause (clause 9.1.2.5) addresses the same user need, but is based on a WCAG success criterion at the higher AA level of accessibility. ICT that meets the higher level of accessibility required by clause 9.1.2.5 automatically meets this clause. Because of this, there is no need to test this clause if the ICT under test has passed a test for clause 9.1.2.5. But if it has failed 9.1.2.5, testing and meeting this clause is still meaningful, as it is better to pass this clause at level A, than to fail both.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.2.4 Subtitles (live)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.4 Captions (Live).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
9.1.2.5 Audio description (pre-recorded)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.5 Audio Description (Prerecorded).
NOTE: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio-video media.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.3 Adaptable
9.1.3.1 Info and relationships
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.1 Info and Relationships.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.1.3.2 Meaningful sequence
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.2 Meaningful Sequence.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.3.3 Sensory characteristics
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.3 Sensory Characteristics.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
9.1.3.4 Orientation
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.4 Orientation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR),
Secondary: Usage with limited cognition (LC)
9.1.3.5 Identify input purpose
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.1.4 Distinguishable
9.1.4.1 Use of colour
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.1 Use of Color.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC),
Secondary: Usage with limited cognition (LC)
9.1.4.2 Audio control
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.2 Audio Control.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited hearing (LH), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV)
9.1.4.3 Contrast (minimum)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH), Usage with limited cognition (LC)
9.1.4.4 Resize text
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.4 Resize text.
NOTE: Best practice is for the smallest text have an x-height of at least 8 CSSpx which corresponds to an x-height of 1,2 mm, at a viewing distance of 400 mm, with no zooming or screen scaling. This is the smallest font size - not the recommended font size for body text which should be larger.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited hearing (LH), Usage with limited cognition (LC)
9.1.4.5 Images of text
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.5 Images of Text.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
9.1.4.6 Void
9.1.4.7 Void
9.1.4.8 Void
9.1.4.9 Void
9.1.4.10 Reflow
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.10 Reflow.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.4.11 Non-text contrast
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.4.12 Text spacing
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.12 Text spacing.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
9.1.4.13 Content on hover or focus
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.13 Content on Hover or Focus.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS). Usage with limited cognition (LC)
9.2 Operable
9.2.1 Keyboard accessible
9.2.1.1 Keyboard
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.1 Keyboard.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.2.1.2 No keyboard trap
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.2 No Keyboard Trap.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.2.1.3 Void
9.2.1.4 Character key shortcuts
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.4 Character Key Shortcuts.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
9.2.2 Enough time
9.2.2.1 Timing adjustable
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.2.2 Pause, stop, hide
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.2.3 Seizures and physical reactions
9.2.3.1 Three flashes or below threshold
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.3.1 Three Flashes or Below Threshold.
Relationship between requirements and functional performance criteria:
Primary: Minimize photosensitive seizure triggers (PST)
9.2.4 Navigable
9.2.4.1 Bypass blocks
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.1 Bypass Blocks.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.2 Page titled
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.2 Page Titled.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.3 Focus order
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.3 Focus Order.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.4 Link purpose (in context)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.4 Link Purpose (In Context).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.5 Multiple ways
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.5 Multiple Ways.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.6 Headings and labels
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.6 Headings and Labels.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH)
9.2.4.7 Focus visible
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.7 Focus Visible.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.4.8 Void
9.2.4.9 Void
9.2.4.10 Void
9.2.4.11 Focus not obscured (minimum)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.5 Input modalities
9.2.5.1 Pointer gestures
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.1 Pointer Gestures.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.5.2 Pointer cancellation
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.2 Pointer Cancellation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.2.5.3 Label in name
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.3 Label in Name.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
9.2.5.4 Motion actuation
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.4 Motion Actuation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
9.2.5.5 Void
9.2.5.6 Void
9.2.5.7 Dragging movements
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.7 Dragging Movements.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
9.2.5.8 Target size (minimum)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
9.3 Understandable
9.3.1 Readable
9.3.1.1 Language of page
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.1.1 Language of Page.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.1.2 Language of parts
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.1.2 Language of Parts.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.2 Predictable
9.3.2.1 On focus
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.1 On Focus.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.3.2.2 On input
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.2 On Input.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.3.2.3 Consistent navigation
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.3 Consistent Navigation.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.2.4 Consistent identification
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.4 Consistent Identification.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.2.5 Void
9.3.2.6 Consistent help
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.6 Consistent Help.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.3 Input assistance
9.3.3.1 Error identification
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.1 Error Identification.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
9.3.3.2 Labels or instructions
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
9.3.3.3 Error suggestion
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.3 Error Suggestion.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
9.3.3.4 Error prevention (legal, financial, data)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
9.3.3.5 Void
9.3.3.6 Void
9.3.3.7 Redundant entry
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.7 Redundant Entry.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV)
9.3.3.8 Accessible authentication (minimum)
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
9.4 Robust
9.4.1 Compatible
9.4.1.1 Void
NOTE: Earlier versions of the present document referenced the 4.1.1 Parsing success criterion from WCAG 2.0 [i.41] and WCAG 2.1 [i.42]. In WCAG 2.2 [4], this criterion has been removed, because the accessibility problems it was intended to prevent "either no longer exist or are addressed by other criteria".
9.4.1.2 Name, role, value
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
9.4.1.3 Status messages
Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 4.1.3 Status Messages.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
9.5 WCAG 2.2 AAA Success Criteria (informative)
In addition to the Level AA success criteria, included in clauses 9.1 to 9.4, the Web Content Accessibility Guidelines include success criteria for Level AAA. These are listed in Table 9.1. Web authors and procurement accessibility specialists are encouraged to consider the WCAG 2.2 Level AAA success criteria that, when it is possible to apply them, may provide access beyond that required in the present document.
NOTE 1: The W3C states that "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content".
NOTE 2: As clause 9.5 is not normative but informative, it does not describe in detail every Success Criterion in the scope of this clause.
This is shown in Table 9.1: WCAG 2.2 Level AAA Success Criteria
9.6 WCAG conformance requirements
Where ICT is, or includes, a web page, the web page shall satisfy all the following five WCAG 2.2 conformance requirements at Level AA [4]:
- Conformance level
- Full pages
- Complete processes
- Only Accessibility-Supported Ways of Using Technologies
- Non-interference
NOTE 1: Clause 9.6 is a direct copy of the WCAG Conformance Requirements, to ensure that web pages conforming to EN 301 549 also conform to WCAG. It is important to note that the WCAG 2.2 [4] success criteria (requirements in clauses 9.1 to 9.4 of the present document) and the conformance requirements were designed to work together, such that the language of the success criteria is based on the nature of the conformance requirements. Thus, the conformance conditions stated in clause 9.6 are to be applied when checking conformance of all requirements in clauses 9.1 to 9.4.
NOTE 2: A web page that meets all of requirements 9.1 to 9.4, or where a Level AA conforming alternate version is provided, will meet conformance requirement 1. Refer to the Glossary section in WCAG 2.2 [4] for the definition of the term "conforming alternate version".
NOTE 3: Conformance requirement 2 states that conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded. Refer to the Glossary section in WCAG 2.2 [4] for the definition of the term "conformance".
NOTE 4: Conformance requirement 3 states that when a web page is one of a series of web pages presenting a process (i.e. a sequence of steps that need to be completed in order to accomplish an activity), all web pages in the process conform at the specified level or better. Refer to the Glossary section in WCAG 2.2 [4] for the definition of the term "process".
NOTE 5: Conformance requirement 4 states that only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria, and any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. Refer to the Glossary section in WCAG 2.2 [4] for the definition of the terms "accessibility-supported", "technologies", "relied upon".
NOTE 6: Conformance requirement 5 states that if technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the web page as a whole has to continue to meet the conformance requirements when any technology that is not relied upon is turned on, off, or is not supported in a user agent, and all content on the page, including content that is not otherwise relied upon to meet conformance, meets clauses 9.1.4.2, 9.2.1.2, 9.2.2.2 and 9.2.3.1. Refer to the Glossary section in WCAG 2.2 [4] for the definition of the terms "accessibility-supported", "technologies", "relied upon".
NOTE 7: According to W3C: "WCAG 2.2 extends Web Content Accessibility Guidelines 2.1 [i.42], which was published as a W3C Recommendation June 2018 (updated in May 2025). Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 [i.41] and WCAG 2.1" [i.42].
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
Secondary: Usage without vocal capability (WVC)
9.7 User preferences for web pages
Where ICT is, or includes, a web page, the web page shall not block the user agent's mode(s) of operation that present the web page according to user preference settings, or explicitly override user preference settings for documented platform accessibility features in these modes of operation, unless this is essential to the information or function of the web page.
NOTE 1: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.
NOTE 2: In web browser software that meets clause 11.7 there is at least one mode of operation where the web browser will enforce user preference settings.
NOTE 3: For web pages, the underlying platform is the user agent.
NOTE 4: This does not preclude the web page from specifying other values, but it does limit the use of specifications that explicitly override user settings (e.g. "forced-color-adjust" property in CSS) to cases where this is essential.
NOTE 5: Features that might be documented as platform accessibility features include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
Secondary: Usage without vocal capability (WVC)
10 Non-web documents
10.0 General (informative)
Requirements in clause 10 apply to:
- documents that are not web pages;
- documents that are not embedded in web pages; and
- documents that are provided with web pages but are neither embedded nor rendered together with the web page from which they are provided (i.e. the present clause applies to downloadable documents).
Clause 9 provides requirements for documents that are in web pages or that are embedded in web pages and that are used in the rendering or that are intended to be rendered together with the web page in which they are embedded.
NOTE 1: Some examples of non-web documents are letters, spreadsheets, emails, books, pictures, presentations, and movies that have an associated user agent such as a document reader, editor or media player.
NOTE 2: A single non-web document may be composed of multiple files such as the video content and closed caption text. This fact is not usually apparent to the end-user consuming the document/content.
NOTE 3: Non-web documents require a user agent in order for the content to be presented to users. The requirements for user agents can be found in clause 11.
NOTE 4: The requirements for content that is part of non-web software, can be found in clause 11.
NOTE 5: The success criteria set out in clause 10 are intended to harmonize with the W3C® Group Note [i.25] produced by the W3C®'s WCAG2ICT Task Force.
NOTE 6: Where the meaning of WCAG glossary terms when applied to non-web documents is unclear, reference to the Glossary Items with Specific Guidance, in the W3C® Group Note [i.25], can help to clarify how they are to be understood.
NOTE 7: "Void" clauses have been inserted in order to maintain alignment of the numbering in clauses 9, 10 and 11.
NOTE 8: Requirements in clause 10 also apply to non-web documents that are protected using mechanisms such as digital signatures, encryption, password protection, and watermarks when they are presented to the user.
NOTE 9: It is best practice to provide meta data on the accessibility of the non-web document within or separate to the document using the "Schema.org Accessibility Properties for Discoverability Vocabulary" [i.39].
NOTE 10: A non-web document satisfies a WCAG success criterion when the success criterion does not evaluate to false when applied to the non-web document. This implies that if the success criterion puts conditions on a specific feature and that specific feature does not occur in the non-web document, then the non web document satisfies the success criterion.
EXAMPLE: For example, a non-web document that does not contain pre-recorded audio content in synchronized media will automatically satisfy WCAG success criterion 1.2.2 (captions - pre recorded) and, in consequence, will also meet clause 10.1.2.2.
NOTE 11: ISO 14289-1:2014 [i.71] and ISO 14289-2:2024 [i.72] are the technical standards for accessible PDFs and would be useful in meeting EN 301 549.
10.1 Perceivable
10.1.1 Text alternatives
10.1.1.1 Non-text content
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content.
NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.1.2 Time-based media
10.1.2.1 Audio-only and video-only (pre-recorded)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded).
NOTE: The alternative can be provided directly in the non-web document - or provided in an alternate version that satisfies the success criterion.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
10.1.2.2 Subtitles (pre-recorded)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
10.1.2.3 Audio description or media alternative (pre-recorded)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).
NOTE 1: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio video media.
NOTE 2: This clause corresponds to a WCAG success criterion at level A. Another clause (clause 10.1.2.5) addresses the same user need, but is based on a WCAG success criterion at the higher AA level of accessibility. ICT that satisfies the higher level of accessibility required by clause 10.1.2.5 automatically meets this clause. Because of this, there is no need to test this clause if the ICT under test has passed a test for clause 10.1.2.5. But if it has failed 10.1.2.5, testing and meeting this clause is still meaningful, as it is better to pass this clause at level A, than to fail both.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.2.4 Subtitles (live)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.2.4 Captions (Live).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
10.1.2.5 Audio description (pre-recorded)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.2.5 Audio Description (Prerecorded).
NOTE: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio video media.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.3 Adaptable
10.1.3.1 Info and relationships
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.1 Info and Relationships.
NOTE: Where non-web documents contain non-standard structure types (roles), it is best practice to map them to a standard structure type as a fall-back solution for the reader.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.1.3.2 Meaningful sequence
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.2 Meaningful Sequence.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.3.3 Sensory characteristics
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.3 Sensory Characteristics.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
10.1.3.4 Orientation
Where ICT is, or includes, a non-web document, and the non-web document is displayed on hardware that is designed to be reoriented in typical use, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.4 Orientation.
EXAMPLE: A non-web document that is only used on hardware that supports a single display orientation, or is only displayed on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
10.1.3.5 Identify input purpose
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose.
NOTE 1: Non-web document technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion.
NOTE 2: For non-web documents that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2.2 section Input Purposes for User Interface Components are supported by the technology used.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV) Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.1.4 Distinguishable
10.1.4.1 Use of colour
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.1 Use of Color.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC)
Secondary: Usage with limited cognition (LC)
10.1.4.2 Audio control
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.1.
Table 10.1: Non-web document success criterion: Audio control
If any audio in the non-web document plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web document, it would be necessary for all content in the non-web document (whether or not it is used to meet other success criteria) to satisfy this success criterion.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.2 Audio Control, replacing "on a web page" with "in the non-web document", "any content" with "any part of a non-web document", "whole page" with "whole document", "on the web page" with "in the non-web document", removing "See Conformance Requirement 5: Non Interference" and adding note 1.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited hearing (LH)
Secondary: Usage with limited vision (LV)
10.1.4.3 Contrast (minimum)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.4.4 Resize text
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.4 Resize text.
NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such viewers or editors, unless the content will not work with that zoom feature.
NOTE 2: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
NOTE 3: Best practice is for the smallest text have an x-height of at least 8 CSSpx which corresponds to an x-height of 1,2 mm, at a viewing distance of 400 mm, with no zooming or screen scaling. This is the smallest font size - not the recommended font size for body text which should be larger.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.4.5 Images of text
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.5 Images of Text.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
10.1.4.6 Void
10.1.4.7 Void
10.1.4.8 Void
10.1.4.9 Void
10.1.4.10 Reflow
Where ICT is, or includes, a non-web document, and where underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels or more for vertical scrolling content and a height equivalent to 256 CSS pixels or more for horizontal scrolling content, the non-web document shall satisfy the success criterion in Table 10.2.
Table 10.2: Non-web document success criterion: Reflow
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels.
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1 280 CSS pixels wide at 400 percent zoom. For content which is designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1 024 pixels at 400 percent zoom.
NOTE 2: Examples of content that requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two dimensional scrolling for such parts of the content.
NOTE 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying "CSS pixel" to Non-web documents and Non-web software in [i.25].
NOTE 4: If a non-web document type and its available user agents do not support reflow, it may not be possible for a document of that type to meet this success criterion.
NOTE 5: This success criterion is limited to those cases where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content. However, even below this threshold, reflow is still encouraged as this capability is important to people with low vision.
NOTE 6: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.10 Reflow replacing "web content" with "content" in the original WCAG 2.2 note 1 and adding notes 3, 4 and 5.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.4.11 Non-text contrast
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.3.
Table 10.3: Non-web document success criterion: Non-text contrast
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent colour(s):
- User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent or other platform software and not modified by the author;
- Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
NOTE 1: An example of appearance modification by the author is content that sets the visual style of a control, such as a colour or border, to differ from the default style for the user agent or platform.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast replacing "user agent" with "user agent or other platform software" and adding note 1.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.4.12 Text spacing
Where ICT is, or includes, a non-web document, that is implemented using markup languages that allow users to modify text spacing properties, the non-web document shall satisfy WCAG 2.2 Success Criterion 1.4.12 Text spacing.
NOTE: There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, an eBook technology may have an available user agent that allows users to override document text styles. This success criterion does not mean that non-web documents need to implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the success criterion requires that content respond appropriately to it.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
10.1.4.13 Content on hover or focus
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.4.
Table 10.4: Non-web document success criterion: Content on hover or focus
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent or other platform software and is not modified by the author.
NOTE 1: Examples of additional content controlled by the user agent or other platform software include tooltips created through use of user interface object attributes.
NOTE 2: Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.
NOTE 3: This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links or other user interface controls that behave like a link used to skip to another part of the non-web document) do not present additional content they are not covered by this criterion.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.13 Content on Hover or Focus replacing "user agent" with "user agent or other platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes", "links" with "links or other user interface controls that behave like a link", and "a page" with "the non-web document".
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited cognition (LC)
10.2 Operable
10.2.1 Keyboard accessible
10.2.1.1 Keyboard
Where ICT is, or includes, a non-web document, and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy the WCAG 2.2 Success Criterion 2.1.1 Keyboard.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.2.1.2 No keyboard trap
Where ICT is, or includes, a non-web document, and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy the success criterion in Table 10.5.
Table 10.5: Non-web document success criterion: No keyboard trap
If keyboard focus can be moved to a component of the non-web document using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web document, it would be necessary for all content in the non-web document (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 2.1.2 No Keyboard Trap replacing "page" with "non-web document, "on the web page" with "in the non-web document", removing "See Conformance Requirement 5: Non-Interference", adding note 2, and adjusting note 1 to avoid the use of the normative term "must".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.2.1.3 Void
10.2.1.4 Character key shortcuts
Where ICT is, or includes, a non-web document, and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy WCAG 2.2 Success Criterion 2.1.4 Character Key Shortcuts.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
10.2.2 Enough time
10.2.2.1 Timing adjustable
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.6.
Table 10.6: Non-web document success criterion: Timing adjustable
For each time limit that is set by the non-web document, at least one of the following is true:
- Turn off: The user is allowed to turn off the time limit before encountering it; or
- Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.
NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.2 Success Criterion 3.2.1 On Focus, which puts limits on changes of content or context as a result of user action.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "non-web document" and with the words "WCAG 2.2" added before the words "Success Criterion" and "3.2.1 On Focus" after the words "Success Criterion" in note 1 above.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.2.2 Pause, stop, hide
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.7.
Table 10.7: Non-web document success criterion: Pause, stop, hide
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.2 Guideline 2.3.
NOTE 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web document, it would be necessary for all content in the non-web document (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
NOTE 5: While the success criterion uses the term "information", the WCAG 2.2 Intent from Understanding Success Criterion 2.2.2 makes it clear that this is to be applied to all content. Any content, even if just decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.
NOTE 6: This success criterion is identical to the WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" with "non-web document" and "on the web page" with "in the non-web document", removing "See Conformance Requirement 5: Non-Interference" in note 2 of the success criterion, with the words "WCAG 2.2" added before the word "Guideline" in note 1, adjusting note 2 to avoid the use of the normative text "must", and adding note 5.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.2.3 Seizures and physical reactions
10.2.3.1 Three flashes or below threshold
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.8.
Table 10.8: Non-web document success criterion: Three flashes or below threshold
Non-web documents do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web document, it would be necessary for all content in the non-web document (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing "web pages" with "non-web documents", "page" with "non-web document", "on the web page" with "in the non-web document", removing "See Conformance Requirement 5: Non Interference", and adjusting note 1 to avoid the use of the normative term "must".
Relationship between requirements and functional performance criteria:
Primary: Minimize photosensitive seizure triggers (PST)
10.2.4 Navigable
10.2.4.1 Void
NOTE 1: WCAG 2.2 Success Criterion 2.4.1 "Bypass blocks" does not apply to single non-web documents, but to a specific definition of "sets of non-web documents" that are rare.
NOTE 2: Although not a requirement, the ability to bypass blocks of content that are repeated within non-web documents is generally considered best practice and addresses user needs.
10.2.4.2 Non-web document titled
Where ICT is, or includes, a non-web document implemented in a format that supports a programmatically determinable "Title" attribute that is editable using common authoring tools for that document format, the non-web document shall have a title that describes the name, topic, or purpose.
NOTE: The "Title" attribute is specified as "editable through that document format's common authoring tools" so that authors can view and edit the Title without requiring specialized or external metadata utilities. "Common authoring tools" are the most readily available tools used for editing a particular document type.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.4.3 Focus order
Where ICT is, or includes, a non-web document, and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy the success criterion in Table 10.9.
Table 10.9: Non-web document success criterion: Focus order
If a non-web document can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
NOTE: This success criterion is identical to the WCAG 2.2 Success Criterion 2.4.3 Focus Order replacing "web page" with "non-web document".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.4.4 Link purpose (in context)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 2.4.4 Link Purpose (In Context).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.4.5 Multiple ways (Void)
NOTE: WCAG 2.2 Success Criterion 2.4.5 "Multiple Ways" does not apply to single non-web documents, but to a specific definition of "sets of non-web documents" that are rare.
10.2.4.6 Headings and labels
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 2.4.6 Headings and Labels.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH)
10.2.4.7 Focus visible
Where ICT is, or includes, a non-web document and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy the WCAG 2.2 Success Criterion 2.4.7 Focus Visible.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.4.8 Void
10.2.4.9 Void
10.2.4.10 Void
10.2.4.11 Focus not obscured (minimum)
Where ICT is, or includes, a non-web document, and the document provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web document shall satisfy WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.5 Input modalities
10.2.5.1 Pointer gestures
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.10.
Table 10.10: Non-web document success criterion: Pointer gestures
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
NOTE 1: This requirement applies to content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
NOTE 2: Multipoint and path-based gestures are less common in non-web documents. An example where a non web document author could add such gestures is an interactive prototype document created in a software design tool.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.1 Pointer Gestures replacing "web content" with "content" in note 1 and adding note 2.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.5.2 Pointer cancellation
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.11.
Table 10.11: Non-web document success criterion: Pointer cancellation
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event: The down-event of the pointer is not used to execute any part of the function;
- Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
- Up Reversal: The up-event reverses any outcome of the preceding down-event;
- Essential: Completing the function on the down-event is essential.
NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.
NOTE 2: This requirement applies to content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
NOTE 3: Content that interprets pointer actions and controls which events are used for executing functionality is less common in non-web documents. An example where a non-web document author could add such functionality is an interactive prototype document created in a software design tool.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.2 Pointer Cancellation replacing "web content" with "content" in note 2 and adding note 3.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.2.5.3 Label in name
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 2.5.3 Label in Name.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
10.2.5.4 Motion actuation
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 2.5.4 Motion Actuation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
10.2.5.5 Void
10.2.5.6 Void
10.2.5.7 Dragging movements
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.12.
Table 10.12: Non-web document success criterion: Dragging movements
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent or other platform software and not modified by the author.
NOTE 1: This requirement applies to content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
NOTE 2: Dragging movements for operation are less common in non-web documents. An example where a non web document author could add dragging functionality is an interactive prototype document created in a software design tool.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.7 Dragging Movements replacing "user agent" with "user agent or other platform software", "web content" with "content" in note 1, and adding note 2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
10.2.5.8 Target size (minimum)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.13.
Table 10.13: Non-web document success criterion: Target size (minimum)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centred on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control in the same non-web document that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User agent or other platform software control: The size of the target is determined by the user agent or other platform software and is not modified by the author;
- Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
NOTE 1: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, colour pickers displaying a gradient of colours, or editable areas where the cursor is positioned.
NOTE 2: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.
NOTE 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying "CSS pixel" to Non-web documents and Non-web software in [i.25].
NOTE 4: Some document formats are designed for viewing at a wide range of zoom levels provided by the user agent. However, the commonly available user agents for these formats may lack a consistent base zoom level from which to evaluate this criterion. For such documents, evaluate target sizes at a zoom level that aligns with the intended usage of the content.
NOTE 5: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum) replacing "user agent" with "user agent or other platform software", replacing "on the same page" with "in the same non-web document", and adding notes 3 and 4.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
10.3 Understandable
10.3.1 Readable
10.3.1.1 Language of non-web document
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.14.
Table 10.14: Non-web document success criterion: Language of non-web document
The default human language of each non-web document can be programmatically determined.
NOTE: This success criterion is identical to the WCAG 2.2 Success Criterion 3.1.1 Language of Page. replacing "web page" with "non-web document".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.3.1.2 Language of parts
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.15.
Table 10.15: Non-web document success criterion: Language of parts
The human language of each passage or phrase in the non-web document can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.
NOTE 1: Examples of programmatic identification include language metadata or markup. There are some non web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document, and it would not be possible to satisfy this success criterion with those technologies.
NOTE 2: Inheritance is one common method. For example where the primary language of a non-web document is programmatically determinable, it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 3.1.2 Language of Parts replacing "content" with "non-web document" and with the addition of notes 1 and 2 above.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.3.2 Predictable
10.3.2.1 On focus
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 3.2.1 On Focus.
NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.3.2.2 On input
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 3.2.2 On Input.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.3.2.3 Consistent navigation
Where ICT is, or includes, a non-web document within a set of non-web documents, the non-web document shall satisfy the success criterion in Table 10.16.
Table 10.16: Non-web document success criterion: Consistent navigation
Navigational mechanisms that are repeated in multiple non-web documents within a set of non-web documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.
NOTE 1: See set of non-web documents to determine when a group of documents is considered a set for this success criterion.
NOTE 2: Although not required by this success criterion, ensuring that navigation elements have consistent order when repeated within non-web documents directly addresses user needs identified in the Intent section for this success criterion, and is generally considered best practice.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 3.2.3 Consistent Navigation replacing "on multiple pages" with "in multiple non-web documents" and "set of web pages" with "set of non-web documents" and adding notes 1 and 2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), ), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.3.2.4 Consistent identification
Where ICT is, or includes, a non-web document within a set of non-web documents, the non-web document shall satisfy the success criterion in Table 10.17.
Table 10.17: Non-web document success criterion: Consistent identification
Components that have the same functionality within a set of non-web documents are identified consistently.
NOTE 1: See set of non-web documents to determine when a group of documents is considered a set for this success criterion.
NOTE 2: Although not required by this success criterion, ensuring that component identification be consistent when they occur more than once within non-web documents directly addresses user needs identified in the Intent section for this success criterion, and is generally considered best practice.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 3.2.4 Consistent Identification replacing "on multiple pages" with "in multiple non-web documents" and "set of web pages" with "set of non-web documents" and adding notes 1 and 2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.3.2.5 Void
10.3.2.6 Consistent help
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.18.
Table 10.18: Non-web document success criterion: Consistent Help
If a non-web document contains any of the following help mechanisms, and those mechanisms are repeated in multiple non-web documents within a set of non-web documents, they occur in the same order relative to other content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
NOTE 1: Help mechanisms may be provided directly in the non-web document, or may be provided via a direct link to a different non-web document, software, or web page containing the information.
NOTE 2: For this success criterion, "the same order relative to other content" can be thought of as how the content is ordered when the non-web document content is serialized. The visual position of a help mechanism is likely to be consistent across non-web documents for the same content layout variation (e.g. CSS break point). The user can initiate a change, such as changing the non-web document's zoom or orientation, which may trigger a different content layout variation. This criterion is concerned with relative order across non-web documents displayed in the same content layout variation (e.g. same zoom level and orientation).
NOTE 3: See the set of documents definition to determine when a group of documents is considered a set for this success criterion.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 3.2.6 Consistent Help replacing "web page(s)" and "page(s)" with "non-web document(s)", "set of web pages" with "set of non-web documents", "page content" with "content", "on the page" with "in the non-web document", "page is serialized" with "non-web document content is serialized", "different page" with "different non-web document, software, or web page", and "page variation" with "content layout variation", and adding note 3.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
10.3.3 Input assistance
10.3.3.1 Error identification
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 3.3.1 Error Identification.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
10.3.3.2 Labels or instructions
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
10.3.3.3 Error suggestion
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the WCAG 2.2 Success Criterion 3.3.3 Error Suggestion.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
10.3.3.4 Error prevention (legal, financial, data)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.19.
Table 10.19: Non-web document success criterion: Error prevention (legal, financial, data)
For non-web documents that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
NOTE: This success criterion is identical to the WCAG 2.2 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) replacing "web pages" with "non-web documents".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC), Privacy (PR)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
10.3.3.5 Void
10.3.3.6 Void
10.3.3.7 Redundant entry
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 3.3.7 Redundant Entry.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV)
10.3.3.8 Accessible authentication (minimum)
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.20.
Table 10.20: Non-web document success criterion: Accessible authentication (minimum)
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative: Another authentication method that does not rely on a cognitive function test.
- Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition: The cognitive function test is to recognize objects.
- Personal Content: The cognitive function test is to identify non-text content the user provided to a non web document.
NOTE 1: "Object recognition" and "Personal content" may be represented by images, video, or audio.
NOTE 2: Examples of mechanisms that satisfy this criterion include:
- support for password entry by password managers to reduce memory need, and
- copy and paste to reduce the cognitive burden of re-typing.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 3.3.8 Accessible authentication (minimum) replacing "website" with "non-web document".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
10.4 Robust
10.4.1 Compatible
10.4.1.1 Void
NOTE: Earlier versions of the present document referenced the 4.1.1 Parsing success criterion from WCAG 2.0 [i.41] and WCAG 2.1 [i.42]. In WCAG 2.2 [4], this criterion has been removed, because the accessibility problems it was intended to prevent "either no longer exist or are addressed by other criteria".
10.4.1.2 Name, role, value
Where ICT is, or includes, a non-web document, the non-web document shall satisfy the success criterion in Table 10.21.
Table 10.21: Non-web document success criterion: Name, role, value
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies and accessibility features of underlying software.
NOTE 1: For non-web document formats that support interoperability with assistive technology, standard user interface components often satisfy this success criterion when used according to the general design and accessibility guidance for the document format.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value replacing "user agents, including assistive technologies" with "assistive technologies and accessibility features of underlying software", removing the original WCAG 2.2 note because it is only applicable to software, and adding note 1.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
10.4.1.3 Status messages
Where ICT is, or includes, a non-web document, the non-web document shall satisfy WCAG 2.2 Success Criterion 4.1.3 Status Messages.
NOTE: For non-web document where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or other platform software.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
10.5 Subtitle positioning (recommendation)
Where ICT is, or includes, a non-web document, and contains synchronized media with subtitles, the subtitles should not obscure relevant information in the synchronized media.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
10.6 Audio description timing (recommendation)
Where ICT is, or includes, a non-web document, and the non-web document contains synchronized media with audio description, the audio description should not interfere with relevant audio information in the synchronized media.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV)
10.7 User preferences for non-web documents
Where ICT is, or includes, a non-web document, the non-web document shall not block the user agents mode(s) of operation that present the web page according to user preference settings, or explicitly override user preference settings for documented platform accessibility features in these modes of operation, unless this is essential to the information or function of the non-web document.
NOTE 1: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.
NOTE 2: In non-web document viewing software that meets clause 11.7 there is at least one mode of operation where the non-web software will enforce user preference settings.
NOTE 3: For non-web documents, the underlying platform is the user agent.
NOTE 4: This does not preclude the non-web document from specifying other values, but it does limit the use of instructions that explicitly override user settings (in a mode of operation that is meant to meet clause 11.7) to cases where this is essential.
NOTE 5: Features that might documented as platform accessibility features include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
11 Non-web software
11.0 General (informative)
This clause includes requirements for the following types of non-web software as scoped by the preconditions for each requirement:
- platform software;
- non-web software that provides a user interface including content that is in the software;
- non-web software that operates as assistive technology;
- mobile applications.
NOTE 1: User agents are examples of software that provide a user interface. They retrieve, render and facilitate end user interaction with authored content. User agents play a necessary role in the accessibility of authored content rendered in the user interface. W3C® Group None UAAG 2.0 [i.34] provides additional advice for those who are creating user agents and want to increase functionality when rendering authored content in an accessible way.
NOTE 2: The requirements for web content, including software that is web content, can be found in clause 9.
NOTE 3: When parts of non-web software, such as mobile apps, are implemented with web views, such a view is embedded in the app and thus does not meet the definition of web page. The clause 11 "Non-web software" requirements are the appropriate requirements to be applied to these web views. There are no circumstances in which clause 9 requirements and the corresponding clause 11 requirements are both applicable. Where there is any doubt, clause 11 requirements have precedence.
NOTE 4: The requirements for non-web documents, that may be presented by user agents, can be found in clause 10.
NOTE 5: Although the accessibility of command line interfaces is not dealt with in the present document, accessibility may be achieved by context specific requirements, some of which may be found in clauses 5 or 11.
NOTE 6: A non-web software satisfies a WCAG success criterion when the success criterion does not evaluate to false when applied to the non-web software. This implies that if the success criterion puts conditions on a specific feature and that specific feature does not occur in the non-web software, then the non-web software satisfies the success criterion.
EXAMPLE: For example, a non-web software that does not contain pre-recorded audio content in synchronized media will automatically satisfy WCAG success criterion 1.2.2 (captions - pre-recorded) and, in consequence, will also meet clause 11.1.2.2.
Requirements in clauses 11.1 to 11.5 apply to non-web software:
- that is not a web page;
- not embedded in web pages nor used in the rendering or functioning of the page.
Clause 9 provides requirements for software that is in web pages or that is embedded in web pages and that is used in the rendering or that is intended to be rendered together with the web page in which it is embedded.
Some requirements in clauses 11.1 to 11.5 have a pre-condition that indicates that they do not apply to closed functionality, so these requirements only apply to the open functionality of the ICT.
Requirements that do not have a closed functionality pre-condition apply to both the open and closed functionality of the ICT. The requirements under clause 5.1 apply to the closed functionality of the ICT.
For non-web software that has functionality that is closed and other functionality that is not closed, the requirements in clauses 11.1 to 11.5 will still need to be met for the functionality that is not closed.
The success criteria set out in clauses 11.1 to 11.5 are intended to harmonize with the W3C® Working Group Note [i.25] produced by the W3C's WCAG2ICT Task Force.
NOTE 7: Where the meaning of WCAG glossary terms when applied to non-web software is unclear, reference to the Glossary Items with Specific Guidance, in the W3C® Working Group Note [i.25] , can help to clarify how they are to be understood.
NOTE 8: Non-web software that provides a user interface includes its own content. Some examples of content in non-web software include: the controls and text displayed in a menu bar of a graphical user interface application, images that appear in a toolbar, prompts spoken in an auditory user interface, other user interaction controls, and other text, graphics or material that is not loaded from outside the software.
NOTE 9: "Void" clauses have been inserted in order to maintain alignment of the numbering in clauses 9, 10 and 11.
11.1 Perceivable
11.1.1 Text alternatives
11.1.1.1 Non-text content
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content.
NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.1.2 Time-based media
11.1.2.1 Audio-only and video-only (pre-recorded)
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded).
NOTE: The alternative can be provided directly in the non-web software - or provided in an alternate version that satisfies the success criterion.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
11.1.2.2 Subtitles (pre-recorded)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
11.1.2.3 Audio description or media alternative (pre-recorded)
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).
NOTE 1: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio video media.
NOTE 2: This clause corresponds to a WCAG success criterion at level A. Another clause (clause 11.1.2.5) addresses the same user need, but is based on a WCAG success criterion at the higher AA level of accessibility. ICT that satisfies the higher level of accessibility required by clause 11.1.2.5 automatically satisfies this clause. Because of this, there is no need to test this clause if the ICT under test has passed a test for clause 11.1.2.5. But if it has failed clause 11.1.2.5, testing and meeting this clause is still meaningful, as it is better to pass this clause at level A, than to fail both.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.2.4 Subtitles (live)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.2.4 Captions (Live).
NOTE: The WCAG 2.2 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2, to satisfy this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
11.1.2.5 Audio description (pre-recorded)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.2.5 Audio Description (Prerecorded).
NOTE: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") add descriptive information of important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio video media.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.3 Adaptable
11.1.3.1 Info and relationships
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.3.1 Info and Relationships.
NOTE: In non-web software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software. (see clause 11.5 Interoperability with keyboards and assistive technology).
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.1.3.2 Meaningful sequence
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.3.2 Meaningful Sequence.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV)
Secondary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.3.3 Sensory characteristics
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.3.3 Sensory Characteristics.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
Secondary: Usage with limited cognition (LC)
11.1.3.4 Orientation
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software is displayed on hardware that is designed to be reoriented in typical use, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.3.4 Orientation.
NOTE: Non-web software that is only used on hardware that supports a single display orientation, or where it is an application that is run only on hardware that is physically fixed in one orientation (e.g. a digital building directory) is excluded by the precondition and therefore does not need to provide support for orientation changes.
EXAMPLES: Software that is excluded by the precondition:
- The software on a typical handheld calculator (one that typically would only be used in one orientation).
- Software that runs on wristwatches (where the software typically only runs in one orientation) (sleep mode being non-typical).
- Building directory software written to ONLY be used on tablet devices bolted to the wall, all in the same orientation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
11.1.3.5 Identify input purpose
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, and where the technology used supports attributes to identify the meaning of form input data, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose.
NOTE 1: Non-web software technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion.
NOTE 2: For non-web software that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2.2 section Input Purposes for User Interface Components that are supported by the technology used.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.1.4 Distinguishable
11.1.4.1 Use of colour
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.4.1 Use of Color.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC)
Secondary: Usage with limited cognition (LC)
11.1.4.2 Audio control
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.1.
Table 11.1: Non-web software success criterion: Audio control
1.4.2 Audio Control: If any audio in the non-web software plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web software, it would be necessary for all content in the non-web software (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.2 Audio Control replacing "on a web page" with "in the non-web software", "whole page" with "whole non-web software", "on the web page" with "in the non-web software", removing "See Conformance Requirement 5: Non Interference" and adjusting note 1 to avoid the use of the normative term "must".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited hearing (LH), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV)
11.1.4.3 Contrast (minimum)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.4.4 Resize text
Where ICT is, or includes, non-web software that provides a user interface, and is not closed to enlargement, the non-web software shall satisfy the success criterion in Table 11.2.
Table 11.2: Non-web software success criterion: Resize Text
1.4.4 Resize Text: Except for captions and images of text, text can be resized without loss of content or functionality and without assistive technology either up to 200 percent or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform.
NOTE 1: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
NOTE 2: The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200 percent without needing to use assistive technologies. This means that the non-web software provides some means for enlarging the text 200 percent (zoom or otherwise) without loss of content or functionality, or that the non-web software works with the platform features to satisfy this success criterion.
NOTE 3: For non-web software, sometimes the platform provides text scaling to 200 percent for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200 percent, but other text does increase to 200 percent). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform, without losing text size semantics, content or functionality, to satisfy this success criterion.
NOTE 4: Best practice is for the smallest text have an x-height of at least 8 CSSpx which corresponds to an x height of 1,2 mm, at a viewing distance of 400mm, with no zooming or screen scaling. This is the smallest font size - not the recommended font size for body text which should be larger.
NOTE 5: This requirement is based on WCAG 2.2 Success Criterion 1.4.4 Resize Text but has been modified to make it more relevant for non-web software where resizing capabilities may be partly limited in the platform software functionality.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.4.5 Images of text
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 1.4.5 Images of Text.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
11.1.4.6 Void
11.1.4.7 Void
11.1.4.8 Void
11.1.4.9 Void
11.1.4.10 Reflow
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.3.
Table 11.3: Non-web software success criterion: Reflow
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1 280 CSS pixels wide at 400 percent zoom. For content which is designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1 024 px at 400 percent zoom.
NOTE 2: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two dimensional scrolling for such parts of the content.
NOTE 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying "CSS pixel" to Non-web documents and Non-web software.
NOTE 4: The intent section refers to the ability for content to reflow (for vertical scrolling content at a width equivalent to 320 CSS pixels, or for horizontal scrolling content at a height equivalent to 256 CSS pixels) when user agent zooming is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window, dialog, or other resizable content area, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features that meet this success criterion.
NOTE 5: Non-web software will have more frequent cases where two-dimensional layout is relied upon for usage or meaning than what occurs on the Web. For example:
- When the non-web software has a complex user interface with toolbars that need to be visible while manipulating content, as explained in the Intent from Understanding 1.4.10 Reflow.
NOTE 6: As written, this success criterion can only be met by non-web documents or non-web software where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.
When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.
When users modify zoom, scaling, and/or display resolution at the platform software level (e.g. Operating System), it impacts the size of all applications and the platform software itself. This can result in improved readability in some applications but unwanted consequences in others.
NOTE 7: Some non-web software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported. Such software would satisfy this success criterion as long as there is no loss of information or functionality in the drafting view.
NOTE 8: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.10 Reflow replacing "web content" with "content" and adding notes 3 to 7.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.4.11 Non-text contrast
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast.
NOTE: An example of appearance modification by the author is content that sets the visual style of a control, such as a colour or border, to differ from the default style for the user agent or platform.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.4.12 Text spacing
Where ICT is, or includes, non-web software that provides a user interface, that is implemented using markup languages that allow users to modify text spacing properties, the non-web software shall satisfy WCAG 2.2 Success Criterion 1.4.12 Text spacing.
NOTE 1: "Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g. in Electron applications or mobile software web views), XAML, XML (e.g. in mobile software application layouts), and XUL.
NOTE 2: There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, a software application may provide a "user style sheet" facility to modify the appearance of the software's own user interface. This success criterion does not mean that non-web software needs to implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the success criterion requires that content respond appropriately to it.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited cognition (LC)
11.1.4.13 Content on hover or focus
Where ICT is, or includes, non-web software that provides a user interface, and any visual presentation of the additional content caused by a hover or focus is not controlled by the user agent or platform software, or that visual presentation is modified by the non-web software, the non-web software shall satisfy the success criterion in Table 11.4.
Table 11.4: Non-web software success criterion: Content on Hover or Focus
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent or other platform software and is not modified by the author.
NOTE 1: Examples of additional content controlled by the user agent or other platform software include tooltips created through the use of user interface object attributes.
NOTE 2: Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.
NOTE 3: This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 1.4.13 Content on Hover or Focus replacing "user agent" with "user agent or other platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes".
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited cognition (LC)
11.2 Operable
11.2.1 Keyboard accessible
11.2.1.1 Keyboard
Where ICT is, or includes, non-web software that can be run on a software platform that provides a device-independent keyboard interface service, the non-web software shall satisfy the WCAG 2.2 Success Criterion 2.1.1 Keyboard in accordance with the Intent from Understanding Success Criterion 2.1.1.
NOTE 1: Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides software with keystrokes from any keyboard or keyboard substitute. When the non-web software supports such a device-independent service of the platform software, and the non-web software functionality is made fully operable through the service, then this success criterion would be satisfied.
NOTE 2: A "device-independent keyboard interface service" refers to the platform service that provides keystrokes to any software running on the platform.
NOTE 3: Inclusion of an on-screen keyboard can be done as well but does not satisfy this requirement since it does not allow for the use of keyboard alternatives whereas support of input from the device-independent keyboard interface service does.
NOTE 4: This success criterion does not imply that non-web software always needs to directly support a keyboard or "keyboard interface" if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies.
NOTE 5: The success criterion also does not imply that software always needs to provide its own virtual keyboard. But if it does, then the non-web software still needs to support keyboard input from any keyboard interface provided by platform software.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.2.1.2 No keyboard trap
Where ICT is, or includes, non-web software that provides a user interface, and that provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web software shall satisfy the success criterion in Table 11.5.
Table 11.5: Non-web software success criterion: No keyboard trap
If keyboard focus can be moved to a component of the non-web software using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web software, it would be necessary for all content in the non-web software (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
NOTE 3: This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this success criterion would be satisfied.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 2.1.2 No Keyboard Trap replacing "page" with "non-web software" and "on the web page" with "in the non-web software", removing "See Conformance Requirement 5: Non-Interference", adding notes 2 and 3, and adjusting note 1 to avoid the use of the normative term "must".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.2.1.3 Void
11.2.1.4 Character key shortcuts
Where ICT is, or includes, non-web software that provides a user interface, and that provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web software shall satisfy WCAG 2.2 Success Criterion 2.1.4 Character Key Shortcuts.
NOTE: A long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
11.2.2 Enough time
11.2.2.1 Timing adjustable
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.6.
Table 11.6: Non-web software success criterion: Timing adjustable
For each time limit that is set by the non-web software, at least one of the following is true:
- Turn off: The user is allowed to turn off the time limit before encountering it; or
- Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.
NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.2 Success Criterion 3.2.1 On Focus, which puts limits on changes of content or context as a result of user action.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "non-web software" and with the words "WCAG 2.2" added before the word "Success Criterion" in note 1 above.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.2.2 Pause, stop, hide
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.7.
Table 11.7: Non-web software success criterion: Pause, stop, hide
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.2 Guideline 2.3.
NOTE 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web software, it would be necessary for all content in the non-web software (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 3: Content that is updated periodically by software is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
NOTE 5: While the success criterion uses the term "information", the WCAG 2.2 Intent from Understanding Success Criterion 2.2.2 makes it clear that this is to be applied to all content. Any content, even if just decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.
NOTE 6: This success criterion is identical to the WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "on the web page" with "in the non-web software", removing "See Conformance Requirement 5: Non-Interference" in note 2 of the success criterion, with the words "WCAG 2.2" added before the word "Guideline" in note 1, adjusting note 2 to avoid the use of the normative term "must" and adding note 5.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.2.3 Seizures and physical reactions
11.2.3.1 Three flashes or below threshold
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.8.
Table 11.8: Non-web software success criterion: Three flashes or below threshold
Non-web software does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole non-web software, it would be necessary for all content in the non-web software (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: This requirement applies to flashing of content on a screen and flashing of any other type caused by the ICT.
NOTE 3: This requirement applies to those visual elements produced by the ICT itself. Content from an external source that is presented through the ICT, is the responsibility of the source. The requirement does not require the ICT to examine or modify such externally supplied content in any way.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing "web pages do" with "non-web software does", "page" with "non-web software", and "on the web page" with "in the non-web software", removing "See Conformance Requirement 5: Non-Interference", adjusting note 1 to avoid the use of the normative term "must", and adding notes 2 and 3.
Relationship between requirements and functional performance criteria:
Primary: Minimize photosensitive seizure triggers (PST)
11.2.4 Navigable
11.2.4.1 Bypass blocks (Void)
Void.
NOTE 1: WCAG 2.2 Success Criterion 2.4.1 "Bypass blocks" does not apply to single non-web software programs, but to a specific definition of "sets of non-web software programs" that are extremely rare.
NOTE 2: Although not a requirement, it is generally considered best practice, and to address user needs, to be able to bypass blocks of content that are repeated within non-web software.
11.2.4.2 Non-web software titled
Where ICT is, or includes, non-web software that provides a user interface, implemented on a platform that supports "Title" attributes for windows or screens, the non-web software shall provide titles that describe the name, topic or purpose of each window or screen.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.4.3 Focus order
Where ICT is, or includes, non-web software that provides a user interface, and that provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web software shall satisfy the success criterion in Table 11.9.
Table 11.9: Non-web software success criterion: Focus order
If non-web software can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
NOTE: This success criterion is identical to the WCAG 2.2 Success Criterion 2.4.3 Focus Order replacing "web page" with "non-web software".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.4.4 Link purpose (in context)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy WCAG 2.2 Success Criterion 2.4.4 Link Purpose (In Context).
NOTE: In non-web software, a "link" is any user interface control that behaves like a hypertext link.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.4.5 Multiple ways (Void)
NOTE: WCAG 2.2 Success Criterion 2.4.5 "Multiple ways" applies to "Sets" of web pages. In non-web software, the equivalent to "sets of web pages" would be "sets of non-web software", but these are extremely rare and an equivalent is not included in this clause on non-web software requirements.
11.2.4.6 Headings and labels
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 2.4.6 Headings and Labels.
NOTE: In non-web software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH)
11.2.4.7 Focus visible
Where ICT is, or includes, non-web software that provides a user interface, and that provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 2.4.7 Focus Visible.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.4.8 Void
11.2.4.9 Void
11.2.4.10 Void
11.2.4.11 Focus not obscured (minimum)
Where ICT is, or includes, non-web software that provides a user interface, and that provides a keyboard or accepts input from a keyboard or keyboard interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 2.4.11 Focus not obscured (minimum).
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.5 Input modalities
11.2.5.1 Pointer gestures
Where ICT is, or includes, non-web software that provides a user interface, and that provides a pointing mechanism or accepts input from pointing devices, the non-web software shall satisfy the success criterion in Table 11.10.
Table 11.10: Non-web software success criterion: Pointer gestures
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the underlying platform software or assistive technology).
NOTE 2: This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.1 Pointer Gestures, replacing "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software" in note 1, and adding note 2.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.5.2 Pointer cancellation
Where ICT is, or includes, non-web software that provides a user interface, and that provides a pointing mechanism or accepts input from pointing devices, the non-web software shall satisfy the success criterion in Table 11.11.
Table 11.11: Non-web software success criterion: Pointer cancellation
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event: The down-event of the pointer is not used to execute any part of the function.
- Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion.
- Up Reversal: The up-event reverses any outcome of the preceding down-event.
- Essential: Completing the function on the down-event is essential.
NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.
EXAMPLE: Examples of essential functionality for non-web software are features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).
NOTE 2: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the underlying platform software or assistive technology).
NOTE 3: This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.2 Pointer Cancellation replacing "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software" in note 2 and adding note 3.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.2.5.3 Label in name
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy WCAG 2.2 Success Criterion 2.5.3 Label in Name.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
11.2.5.4 Motion actuation
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy WCAG 2.2 Success Criterion 2.5.4 Motion Actuation.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
11.2.5.5 Void
11.2.5.6 Void
11.2.5.7 Dragging movements
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.12.
Table 11.12: Non-web software success criterion: Dragging Movements
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent or other platform software and not modified by the author.
NOTE 1: This requirement applies to software applications that interpret pointer actions (i.e. this does not apply to actions that are required to operate the underlying platform software or assistive technology).
NOTE 2: This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.7 Dragging Movements, replacing "user agent" with "user agent or other platform software" in the success criterion, "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software" in note 1, and adding note 2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
11.2.5.8 Target size (minimum)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.13.
Table 11.13: Non-web software success criterion: Target size (minimum)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centred on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control in the same non-web software that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User agent or other platform software control: The size of the target is determined by the user agent or other platform software and is not modified by the author;
- Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
NOTE 1: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, colour pickers displaying a gradient of colours, or editable areas where the cursor is positioned.
NOTE 2: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.
NOTE 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying "CSS pixel" to Non-web documents and Non-web software.
NOTE 4: This success criterion is identical to the WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum) replacing "user agent" with "user agent or other platform software", "on the same page" with "in the same non-web software", and adding note 3.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
Secondary: Usage with limited cognition (LC)
11.3 Understandable
11.3.1 Readable
11.3.1.1 Language of non-web software
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the success criterion in Table 11.14.
Table 11.14: Non-web software success criterion: Language of non-web software
The default human language of non-web software can be programmatically determined.
NOTE 1: Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would satisfy this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the non-web software would also satisfy this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to satisfy this success criterion in that locale / language.
NOTE 2: This success criterion is identical to the WCAG 2.2 Success Criterion 3.1.1 Language of Page, replacing "each web page" with "non-web software" and with the addition of note 1 above.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited cognition (LC)
Secondary: Usage with limited vision (LV), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.3.1.2 Language of parts (Void)
NOTE: To apply WCAG 2.2 Success Criterion 3.1.2 "Language of parts" to non-web software would require the marking-up of all text in all locations within the non-web software. This would be impossible so an equivalent is not included in this clause on non-web software requirements.
11.3.2 Predictable
11.3.2.1 On focus
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 3.2.1 On Focus.
NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.3.2.2 On input
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 3.2.2 On Input.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.3.2.3 Consistent navigation (Void)
NOTE: WCAG 2.2 Success Criterion 3.2.3 "Consistent navigation" applies to "Sets" of web pages. While consistency within non-web software is desirable, "sets of non-web software" in the same sense as "sets of web pages", are extremely rare and an equivalent is not included in this clause on non-web software requirements.
11.3.2.4 Consistent identification
Where ICT is, or includes, non-web software that provides a user interface, components that have the same functionality within the non-web software program shall be identified consistently, except where not doing so is essential to the function of the non-web software.
NOTE 1: Consistent does not mean identical, but that the characteristics of the identifiers (such as text and look) are as similar as practical to reflect the fact that they identify the same functionality.
NOTE 2: This requirement is based on WCAG 2.2 3.2.4 "Consistent identification", but replacing the scope from a "set of web pages" to "a non-web software program", in order to make it more relevant for non-web software.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited cognition (LC)
Secondary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.3.2.5 Void
11.3.2.6 Consistent help (Void)
NOTE: WCAG 2.2 Success Criterion 3.2.6 for "Consistent help" applies to "Sets" of web pages. While consistency within non-web software is desirable, "sets of non-web software" in the same sense as "sets of web pages", are extremely rare and an equivalent is not included in this clause on non-web software requirements.
11.3.3 Input assistance
11.3.3.1 Error identification
Where ICT is, or includes, non-web software that provides a user interface, and the non-web software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the WCAG 2.2 Success Criterion 3.3.1 Error Identification.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
11.3.3.2 Labels or instructions
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
11.3.3.3 Error suggestion
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the WCAG 2.2 Success Criterion 3.3.3 Error Suggestion.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage with limited cognition (LC)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST)
11.3.3.4 Error prevention (legal, financial, data)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.15.
Table 11.15: Non-web software success criterion: Error prevention (legal, financial, data)
For non-web software that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
NOTE: This success criterion is identical to the WCAG 2.2 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) replacing "web pages" with "non-web software".
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
Secondary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR)
11.3.3.5 Void
11.3.3.6 Void
11.3.3.7 Redundant entry
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy WCAG 2.2 Success Criterion 3.3.7 Redundant Entry.
Relationship between requirements and functional performance criteria:
Primary: Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without vision (WV), Usage with limited vision (LV)
11.3.3.8 Accessible authentication (minimum)
Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the success criterion in Table 11.16.
Table 11.16: Non-web software success criterion: Accessible authentication (minimum)
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative: Another authentication method that does not rely on a cognitive function test.
- Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition: The cognitive function test is to recognize objects.
- Personal Content: The cognitive function test is to identify non-text content the user provided to a website, non-web document, or software.
NOTE 1: "Object recognition" and "Personal content" may be represented by images, video, or audio.
NOTE 2: Examples of mechanisms that satisfy this criterion include:
- support for password entry by password managers to reduce memory need; and
- copy and paste to reduce the cognitive burden of re-typing.
NOTE 3: Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software's author.
NOTE 4: There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to meet this success criterion.
NOTE 5: To achieve the same level of privacy for people with disabilities when entering pins or passwords, what is read aloud should be the same as what is shown. If the screen shows dots then what is read should be "dot, dot, dot". If the user chooses to show their password then it can be shown and read, which delivers equal privacy.
NOTE 6: This success criterion is identical to the WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum) replacing "the website" with "a website, non-web document, or software" and adding notes 3 and 4.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
11.4 Robust
11.4.1 Compatible
11.4.1.1 Void
NOTE: Earlier versions of the present document referenced the 4.1.1 Parsing success criterion from WCAG 2.0 [i.41] and WCAG 2.1 [i.42]. In WCAG 2.2 [4], this criterion has been removed, because the accessibility problems it was intended to prevent "either no longer exist or are addressed by other criteria".
11.4.1.2 Name, role, value
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall satisfy the success criterion in Table 11.17.
Table 11.17: Non-web software success criterion: Name, role, value
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies and accessibility features of underlying software.
NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already satisfy this success criterion when used according to specification.
NOTE 2: For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services of platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardized ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and/or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).
NOTE 3: This success criterion is identical to the WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value replacing "user agents, including assistive technologies" with "assistive technologies and accessibility features of underlying software", and replacing the original WCAG 2.2 note with: "This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already satisfy this success criterion when used according to specification.", and adding note 2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH)
11.4.1.3 Status messages
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and the functionality that is not closed supports status message notifications, status messages from the functionality that is not closed can be programmatically determined so that they can be presented to the user by assistive technologies without receiving focus.
NOTE 1: This clause is aligned with the Intent from Understanding Success Criterion 4.1.3. The WCAG success criterion is restricted to content implemented using markup languages, but the WCAG2ICT Task Force has concluded that even "where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or platform software".
NOTE 2: The term "status messages" is defined in WCAG 2.2.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5 Interoperability with keyboards and assistive technology
11.5.1 Closed functionality (informative)
Some requirements in clauses 11.1 to 11.5 have a pre-condition that indicates that they do not apply to closed functionality, so these requirements only apply to the open functionality of the ICT.
Requirements that do not have a closed functionality pre-condition apply to both the open and closed functionality of the ICT. The requirements under clause 5.1 apply to the closed functionality of the ICT.
For non-web software that has functionality that is closed and other functionality that is not closed, the requirements in clause 11.1 to 11.5 will still need to be met for the functionality that is not closed.
11.5.2 Accessibility services
11.5.2.1 Platform interoperability with assistive technologies
Where ICT is, or includes, platform software, the platform software shall provide a set of documented platform accessibility services that cover any user interface concept corresponding to clauses 11.5.2.5 to 11.5.2.17 supported within the platform software.
NOTE 1: Depending on the platform, the documented platform accessibility services addressed in this clause may be referred to by different names, such as accessibility services or accessibility API.
NOTE 2: Some platforms include services for user interface development that provide accessibility support by default (e.g. the service for creating a new user interface element provides role, state, boundary, name and description). These services are considered to be part of the services provided to meet this clause.
NOTE 3: To comply with this requirement, platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services meet this requirement.
NOTE 4: The definition of platform in clause 3.1 applies to software that provides services to other software, including but not limited to, operating systems, web browsers, virtual machines.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Privacy (PR)
11.5.2.2 Void
NOTE: This clause from previous versions of EN 301 549 has been merged in with clause 11.5.2.1.
11.5.2.3 Use of accessibility services (recommendation)
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed should use the applicable documented platform accessibility services listed in clause 11.5.2.1. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.5.2.5 to 11.5.2.17, then the functionality that is not closed should use other documented platform services to interoperate with assistive technology.
NOTE: It is best practice to develop software using toolkits that automatically implement the underlying platform accessibility services.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC)
Secondary: Privacy (PR)
11.5.2.4 Assistive technology
Where ICT is, or includes, non-web software that is assistive technology, the assistive technology shall use the documented platform accessibility services corresponding to clauses 11.5.2.5 to 11.5.2.17.
NOTE: Assistive technology can also use other documented accessibility services.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
11.5.2.5 Object information
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
Secondary: Privacy (PR)
11.5.2.6 Row, column, and headers
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make the row and column of each cell in a data table, including headers of the row and column if present, programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.7 Values
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements that can have values, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make the current value of a user interface element and any minimum or maximum values of the range, if the user interface element conveys information about a range of values, programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.8 Label relationships
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements that are labels of other user interface elements, the functionality that is not closed shall expose the relationship that a user interface element has as a label for another element, or of being labelled by another element, using the services as described in clause 11.5.2.3, so that this information is programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.9 Parent-child relationships
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements that are parents of other user interface elements in a hierarchical structure, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.10 Text
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and renders text to a screen, the software shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes used or available for user generated content, and the boundary of text programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE 1: See clause 5 for requirements on functionality that is closed.
NOTE 2: Depending on the software, the attributes of text may include but are not limited to different visual features, such as size and colour, and style aspects such as boldness and underlining.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.11 List of available actions
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.12 Execution of available actions
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements that have actions that can be executed by the user, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, allow the programmatic execution of the actions exposed according to clause 11.5.2.11 by assistive technologies where permitted by security requirements for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE 1: See clause 5 for requirements on functionality that is closed.
NOTE 2: In some cases the security requirements imposed on a non-web software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 3: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.13 Tracking of focus and selection attributes
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, make information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface elements programmatically determinable by assistive technologies for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.14 Modification of focus and selection attributes
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements that can receive focus or that enable text editing, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where the user can modify these items where permitted by security requirements for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE 1: See clause 5 for requirements on functionality that is closed.
NOTE 2: In some cases the security requirements imposed on a non-web software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 3: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.15 Change notification
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.5.2.5 to 11.5.2.11 and 11.5.2.13, for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE: See clause 5 for requirements on functionality that is closed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.16 Modifications of states and properties
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements whose state or properties can be modified by a user without the use of assistive technology, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items where permitted by security requirements for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE 1: See clause 5 for requirements on functionality that is closed.
NOTE 2: In some cases the security requirements imposed on a non-web software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 3: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.5.2.17 Modifications of values and text
Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and there are user interface elements whose values or text can be modified by a user without the use of assistive technology, the functionality that is not closed shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to modify values and text of user interface elements using the input methods of the platform, where a user can modify these items without the use of assistive technology where permitted by security requirements for all functionality that is not closed to programmatic access of information by assistive technologies.
NOTE 1: See clause 5 for requirements on functionality that is closed.
NOTE 2: In some cases the security requirements imposed on a non-web software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 3: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Usage with limited cognition (LC)
11.6 Documented accessibility features
11.6.1 User control of accessibility features
Where ICT is, or includes, platform software, the platform software shall provide sufficient modes of operation for user control over documented platform accessibility features.
NOTE: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
11.6.2 No disruption of accessibility features
Where ICT is, or includes, non-web software, the non-web software shall not disrupt documented platform accessibility features except when requested to do so by the user during the operation of the software.
NOTE: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
11.7 User preferences
Where ICT is, or includes, non-web software that provides a user interface, and is not designed to be isolated from its platform, that user interface shall follow the values of the user preference settings for documented platform accessibility features unless this is essential to the function of the non-web software to not follow a user preference setting.
NOTE 1: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.
NOTE 2: Non-web software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.
NOTE 3: For non-web documents, the underlying platform is the user agent.
NOTE 3: When ICT is a user agent (such as a web browser or non-web document viewing software), this clause implies that at least one mode of operation is offered that enforces a rendering of the content that follows the values of the user preferences.
NOTE 4: This does not preclude the non-web software from having additional values for a setting as long as there is one mode where the application will follow the system settings even if more restricted.
NOTE 5: Features that might be documented as accessibility features for a platform include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
12 Information about products and services
12.1 Accessible information about products
Where ICT is, or includes, information about a product, made available in a digital form, the presentation of the information shall conform to the requirements of clause 9 if it is available in a web format, clause 10 if it is available as a non-web document, and clause 11 if it is available as part of non-web software.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
12.2 Accessible information about services
Where ICT is, or includes, information about a service, made available in a digital form, the presentation of the information shall conform to the requirements of clause 9 if it is available in a web format, clause 10 if it is available as a non-web document, and clause 11 if it is available as part of non-web software.
NOTE: The term service in the precondition of this requirement includes support services.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
12.3 Accessibility and compatibility features
Where ICT has documentation about the use of the ICT on the ICT or there is an official webpage that provides documentation about the use of the ICT, this documentation about the use of the ICT on the ICT shall include directly or via a link to a web page that, directly or via further links, provides information on the accessibility features of the ICT, how to use the features, and how to get support for accessibility features.
NOTE 1: One mechanism for doing this is to provide a simple URL phrase in the footer of on any documentation, for example "Accessibility info at www.vendor.com/accessibility".
NOTE 2: The term "official web page" means any page provided by the vendor of the ICT and is used to distinguish a webpage from the vendor of the ICT from any other pages that might exist from 3rd parties about the ICT. The precondition for the existence of at least one web page from the vendor of the ICT is to prevent a product vendor who does not have any website from having to create a website just to meet this requirement.
NOTE 3: "On the ICT" is referring to documentation that is either physically on the ICT itself or that is made available through the use of the ICT.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
12.4 Electronic program guides
Where ICT is an Electronic Programme Guide (EPG), the EPG shall provide information on the availability of subtitles, audio description, spoken subtitles, and sign language interpretation of the media.
NOTE: Best practice is to include information about all accessibility features as they are developed and standard formats for including information are developed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
12.5 Electronic program guide display
Where ICT displays an Electronic Programme Guide (EPG) presenting media item(s), and information about the availability of subtitles, audio description, spoken subtitles, or sign language interpretation for the media item(s), the ICT shall provide a mode of operation in which the availability of subtitles, audio description, spoken subtitles, sign language can be determined without activating the media item(s).
NOTE 1: The information about which accessibility features are available is needed when users are assessing which programs will be accessible to them. They will need this information to be available to them when they are viewing or scrolling through the EPG.
NOTE 2: Best practice is to display information about all accessibility features as they are developed.
Relationship between requirements and functional performance criteria:
Primary: Usage without vision (WV), Usage with limited vision (LV), Usage without perception of colour (WPC), Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC), Usage with limited manipulation or strength (LMS), Usage with limited reach (LR), Minimize photosensitive seizure triggers (PST), Usage with limited cognition (LC), Privacy (PR)
13 ICT providing relay or emergency service access
13.1 Relay services requirements
13.1.1 General (informative)
Relay services enable users with speech or hearing disabilities to communicate with other users of services providing real-time bidirectional voice. The relay services convert communication modalities, allowing each user to communicate in their preferred way, using human assistance or automated translation or hybrids between these forms. Relay services also support users with cognitive and memory disabilities.
Users who use relay services because of a disability are here called "primary users", while others involved are called "secondary users".
If a primary user needs to communicate using media not supported by the secondary user's system, the primary user makes use of a system that offers that media. For instance, a sign language user communicating with a voice-only user might connect via a relay service handling sign language in video.
Even if it is unusual in practice, relay services can be interconnected to facilitate communication between primary users who cannot directly communicate. For example, a hard of hearing person using a text relay service can communicate with a deaf sign language user via a video relay service by connecting their respective services by voice.
Clause 13.1.2 of the present document addresses invocation and connection, while clause 13.1.3 of the present document addresses the media transmission and modality conversion, also including media transmission and relay service use in some special contexts.
The types of possible relay services include, but are not limited to the following types, which are more completely described in ETSI ES 202 975 [i.6]:
- Text relay services which provide conversion between real-time text and voice. Text relay services can be divided in the following three subtypes regarding their mediation directions:
- Bidirectional text relay service, which converts between speech and real-time text in both directions with the primary user both reading and sending text.
- Text relay service with voice through. which convert speech towards the primary user to text and let speech through from the primary user.
- Text relay service with hearing through, which convert text from the primary user to speech, and let speech through to the primary user.
- Captioned telephony services which convert speech to real-time text towards the primary user while letting voice through in both directions.
- Video relay services which convert between sign language in video to and from primary users and spoken language from and to secondary users.
- Speech-to-speech relay services which convert between unclear speech from the primary user to clear speech to the secondary users, also letting speech through in both directions.
- Lipspeaking relay services which convert from speech in a voice channel to lipspeaking in a video channel towards the primary user and let voice through in the both directions.
- Cognitive support services which provide support for memory and other cognitive functions in the voice channel in the direction towards the primary user and let voice through in both directions.
For detailed guidelines on how to develop and implement relay service, it is best practice to meet the applicable relay service requirements of ETSI ES 202 975 [i.6].
Relay service access is also essential in emergency communication cases. These aspects are elaborated in ETSI EN 202 919 [i.56].
The general accessibility requirements contained in the clauses 13.1.2 and 13.1.3 of the present document are based on the functional architecture and invocation of relay services described in ETSI ES 202 975 [i.6].
13.1.2 Relay service access
13.1.2.1 General remarks on access to relay services (informative)
To ensure that the primary users of the relay service have equivalent access to electronic communication, they need to have free choice of communicating with or without the support of relay services. For instance, primary users with hearing impairments who use an ICT communication system that includes alternatives to voice communication such as RTT or total conversation, and where these media are also used by the secondary users, should, if desired, be able to contact the secondary users using a common communication channel, without involvement of the relay services.
Clause 13.1.2 of the present document provides requirements for providing the access to relay services for the primary users that ensures their equivalent access to the communication services.
13.1.2.2 Use of the primary user destination address in relayed communications
Where ICT is intended to support relay service inclusion in communication, and is, or includes, relay service invocation functions, the relay service invocation functions shall use destination addresses given to the primary users by their communication systems.
NOTE: For more details see clause 6.3 in ETSI ES 202 975 [i.6].
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.2.3 Conveying of caller identifier in relayed communications for primary relay users
Where ICT is intended to support relay service inclusion in communication, and is, or includes, relay service invocation functions, the ICT shall convey the caller identifiers of primary users of relay services in their communication establishments to secondary users, unless the calling user equipment is set to anonymous communication mode.
NOTE: For more details see clause 6.3 in ES 202 975 [i.6].
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.2.4 Relay service invocation decision in outgoing communications
Where ICT is intended to support relay service inclusion in communication, and is, or includes, relay service invocation functions, the ICT shall provide features that enable the primary user to decide by user action at the moment of initiating an outgoing communication if a relay service will be invoked in the communication or not.
NOTE: It is also good practice to provide automatic decision support and settings to tune the decision support to user needs.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.2.5 Relay service invocation decision in incoming communications
Where ICT is intended to support relay service inclusion in communication, and is, or includes, relay service invocation functions, the ICT shall provide features that enable the primary user to decide by user action at the moment of receiving an incoming communication if a relay service will be invoked in the communication or not.
NOTE: It is also good practice to provide automatic decision support and settings to tune the decision support to user needs.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.2.6 Relay service support requested by the primary user for emergency communications
Where ICT is intended to support relay service inclusion in communication, and is, or includes, a relay service invocation function, the ICT shall initiate and perform emergency communications on the request by the primary user and invoke relay service.
NOTE: The relay service functions are expected to allow invocations of PSAPs in a three-party fashion and perform the relaying action in the ways specified in ETSI ES 202 975 [i.6], clauses 6.5.1.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.3 Relay service requirements
13.1.3.1 Relaying action in real-time bidirectional voice communication
Where ICT is, or includes, a relay service, the relay service shall allow primary users to participate in speech communication with secondary users by performing modality conversion or communication support functions according to the type and mode of operation of the relay service.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.3.2 Media handling in relay service communication
Where ICT is intended to support relay service inclusion in communication, and is, or includes, relay functions, the relay service invocation functions shall allow passing-through media not involved in the conversation but enabled by the communication clients of the primary and secondary users.
NOTE: Best practice is to allow the user to specify if they want the media being converted to also be passed on to the other user in addition to the conversion of its modality.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.3.3 Relay service support in ICT based conferences
Where ICT is, or includes, a relay service, the ICT shall support participation of primary users in conferences.
NOTE 1: The extra modality conversions required by each user may be conveyed via the conference system or directly between the relay service and the user of the relay service.
NOTE 2: In order for the relay service to have the best information to successfully convey the conference voice communications the relay service should not only be able to hear the voice channel of the conference but also view all contents of the conference.
NOTE 3: Access to conferences is commonly provided via web or app interface.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.1.3.4 Relay service support during emergency communications initiated by the PSAP
Where ICT is, or includes, a relay service, the relay service shall accept invocations by emergency communication PSAPs.
NOTE: The relay service is expected to allow invocations by PSAPs in a three-party fashion and perform the relaying action in the ways specified in ETSI TS 103 919 [i.56], clauses 9 and 10.
Relationship between requirements and functional performance criteria:
Primary: Usage without hearing (WH), Usage with limited hearing (LH), Usage without vocal capability (WVC)
Secondary: Usage with limited cognition (LC)
13.2 Void
NOTE: The previous topic "Access to relay services" is now addressed throughout clause 13.1 of the present document.
13.3 Access to emergency services (informative)
The present document addresses the accessibility of emergency communication by means of the emergency communication-specific scenarios of clauses 6.0.6 to 6.0.9 and by specific references to emergency communication in some of the clause C.6 conformance tests of the accessibility requirements.
List
The following selections were made when creating this document:
- No provisions have been removed.
Annex - Tables and figures (from EN 301 549)
Table 5.1
|
Viewing distance (mm) |
x-height (mm) for 16CSSpx |
|---|---|
|
400 |
2,38 |
|
500 |
2,98 |
|
700 |
4,17 |
|
1 000 |
5,95 |
|
2 000 |
11,90 |
|
3 000 |
17,86 |
|
5 000 |
29,76 |
|
10 000 |
59,52 |
Figure 8.1: Obstructed side reach (see Table 8.1 for explanations)
Table 8.1: Values for the size of obstructions for side reach
|
Description |
Values for stationary ICT which complies with clause 8.3.10.2 |
Values for stationary ICT which complies with clause 8.3.10.3 |
|---|---|---|
|
(a) Obstruction depth |
Maximum 300 mm |
Maximum 610 mm |
|
(b) High reach |
Maximum 1 100 mm |
Maximum 1 220 mm for depth (a) up to 255 mm Maximum 1 170 mm for depth (a) of up to 610mm |
|
(c) Obstruction height |
Maximum 800 mm |
Maximum 865 mm |
NOTE: The values listed in the column "Values for stationary ICT which complies with clause 8.3.10.3" are compliant with the ADA-based requirements [i.78].
Figure 8.2: Knee and toe clearance underneath an obstruction (see Table 8.2 for explanations)
Table 8.2: Values for obstructions and knee and toe space below obstructions
|
Description |
Values for stationary ICT which complies with clause 8.3.11.1 |
Values for stationary ICT which complies with clause 8.3.11.2 |
|---|---|---|
|
(a) Width of the clear space |
900 mm, but max. the width of the stationary ICT |
760 mm, but max. the width of the ICT |
|
(b) Height of the free space below an obstruction |
Min 700 mm |
Min. 685 mm |
|
(c) Depth of the knee space at the height of the free space (b) |
Min 280 mm but not larger than depth of the stationary ICT including the depth of any obstruction |
Min 205 mm but not larger than depth of the stationary ICT including the depth of any obstruction |
|
(d) Depth of the knee space at the minimum height of the toe space. |
Min. 350 but not larger than the depth of the ICT including the depth of any obstruction |
Min. 280 but not larger than the depth of the ICT including the depth of any obstruction |
|
(e) Depth of the toe space at the Height of the toe space (f). |
Minimum 450 mm, but not larger than the depth of the ICT including the depth of any obstruction |
Minimum 430 mm, but not larger that the depth of the ICT including the depth of any obstruction |
|
(f) Height of the toe space |
Minimum 350 mm |
Minimum 230 mm |
|
(g) Height of the obstruction |
Maximum 800 mm |
Maximum 865 mm |
NOTE 1: The depth of the free spaces is always measured from the largest extent of an obstruction.
NOTE 2: The depth reduction of the knee clearance (from (c) to (d) in Table 8.2 and Figure 8.2) should be avoided if possible, leading to a minimal depth of the knee clearance (c) with the value of (d) underneath an obstruction.
NOTE 3: Stationary ICT that can be used with side reach and forward reach may not need free space underneath an obstruction.
NOTE 4: The values listed in the column "Values for stationary ICT which complies with clause 8.3.11.2" are compliant with the ADA-based requirements [i.78].
Table 9.1: WCAG 2.2 Level AAA Success Criteria
Annex - References (from EN 301 549)
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.
The following referenced documents are necessary for the application of the present document.
- [1] Void.
- [2] ETSI ES 200 381-1 (V1.2.1) (October 2012): "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids; Part 1: Fixed-line speech terminals".
- [3] ETSI ES 200 381-2 (V1.1.1) (October 2012): "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids; Part 2: Cellular speech terminals".
- [4] W3C® Recommendation (12 December 2024)/ISO/IEC 40500:2025: "Web Content Accessibility Guidelines (WCAG) 2.2".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or non specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding, but are not required for conformance to the present document.
- [i.1] ANSI/IEEE C63.19 (2019): "American National Standard Methods of Measurement of Compatibility between Wireless Communication Devices and Hearing Aids".
- [i.2] ANSI/TIA-4965: "Telecommunications telephone terminal equipment receive volume control requirements for digital and analogue wireline handset terminals".
- [i.3] ANSI/TIA-5050: "Telecommunications Communications Products Receive Volume Control Requirements for Wireless (Mobile) Devices".
- [i.4] European Commission M 376 - EN: "Standardisation Mandate to CEN, CENELEC and ETSI in support of European accessibility requirements for public procurement of products and services in the ICT domain".
- [i.5] ETSI EG 201 013: "Human Factors (HF); Definitions, abbreviations and symbols".
- [i.6] ETSI ES 202 975: "Human Factors (HF); Requirements for relay services".
- [i.7] ETSI ETS 300 767: "Human Factors (HF); Telephone Prepayment Cards; Tactile Identifier".
- [i.8] Void.
- [i.9] Void.
- [i.10] Void.
- [i.11] ETSI TS 126 114: "Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (3GPP TS 26.114)".
- [i.12] ETSI TS 122 173: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1 (3GPP TS 22.173)".
- [i.13] IETF RFC 4103 (2005): "RTP Payload for Text Conversation".
- [i.14] ISO/IEC 17007:2009: "Conformity assessment — Guidance for drafting normative documents suitable for use for conformity assessment".
- [i.15] ISO 9241-11:2018: "Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts".
- [i.16] ISO 9241-110:2020: "Ergonomics of human-system interaction — Part 110: Interaction principles".
- [i.17] ISO 9241-171:2008: "Ergonomics of human-system interaction — Part 171: Guidance on software accessibility".
- [i.18] ISO/IEC 13066-1:2011: "Information technology — Interoperability with assistive technology (AT) — Part 1: Requirements and recommendations for interoperability".
- [i.19] Recommendation ITU-T E.161 (2001): "Arrangement of digits, letters and symbols on telephones and other devices that can be used for gaining access to a telephone network".
- [i.20] Recommendation ITU-T G.722 (1988): "7 kHz audio-coding within 64 kbit/s".
- [i.21] Recommendation ITU-T G.722.2 (2003): "Wideband coding of speech at around 16 kbit/s using Adaptive Multi-Rate Wideband (AMR-WB)".
- [i.22] Recommendation ITU-T V.18 (2000): "Operational and interworking requirements for DCEs operating in the text telephone mode".
- [i.23] TIA-1083-B (2015): "Telecommunications Communications Product; Handset Magnetic Measurement Procedures and Performance Requirements".
- [i.24] Void.
- [i.25] W3C® Group Note (21 August 2025): "Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)".
- [i.26] C(2017)2585 - Standardisation request M/554: "Commission Implementing Decision of 27.4.2017 on a standardisation request to the European standardisation organisations in support of Directive (EU) 2016/2102 of the European Parliament and of the Council on the accessibility of the websites and mobile applications of public sector bodies".
- [i.27] Directive (EU) 2016/2102 of the European Parliament and of the Council of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies.
- [i.28] C(2022)6456 - Standardisation request M/587: " Commission Implementing Decision of 14.9.2022 on a standardisation request to the European standardisation organisations as regards the accessibility requirements of products and services in support of Directive (EU) 2019/882 of the European Parliament and of the Council".
- [i.29] Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services.
- [i.30] EN 301 549 (V3.2.1) (March 2021): "Accessibility requirements for ICT products and services" (jointly produced by ETSI/CEN/CENELEC).
- [i.31] Void.
- [i.32] ISO/IEC TS 20071-25:2017: "Information technology — User interface component accessibility — Part 25: Guidance on the audio presentation of text in videos, including captions, subtitles and other on-screen text".
- [i.33] W3C® Recommendation (24 September 2015): "Authoring Tool Accessibility Guidelines (ATAG) 2.0".
- [i.34] W3C® Working Group Note (15 December 2015): "User Agent Accessibility Guidelines (UAAG) 2.0".
- [i.35] ISO 21542:2021: "Building construction — Accessibility and usability of the built environment".
- [i.36] Void.
- [i.37] Recommendation ITU-T T.140 (1998): "Protocol for multimedia application text conversation".
- [i.38] Recommendation ITU-T F.703 (2000): "Multimedia conversational services".
- [i.39] Final Community Group Report (26 March 2026): "Schema.org Accessibility Properties for Discoverability Vocabulary".
- [i.40] Directive 2014/24/EU of the European Parliament and of the Council of 26 February 2014 on public procurement and repealing Directive 2004/18/EC.
- [i.41] W3C® Recommendation (11 December 2008)/ISO/IEC 40500:2012: "Web Content Accessibility Guidelines (WCAG) 2.0".
- [i.42] W3C® Recommendation (5 June 2018): "Web Content Accessibility Guidelines (WCAG) 2.1".
- [i.43] ETSI TR 126 982: "5G; Implementation guidelines for Multiparty RTT (3GPP TR 26.982)".
- [i.44] GSMA PRD IR.92: "IMS Profile for Voice and SMS".
- [i.45] GSMA PRD IR.94 "IMS Profile for Conversational Video Service".
- [i.46] GSMA NG.114: "IMS Profile for Voice, Video and Messaging over 5GS".
- [i.47] ETSI TS 103 478: "Emergency Communications (EMTEL); Pan-European Mobile Emergency Application".
- [i.48] ETSI TS 103 479: "Emergency Communications (EMTEL); Core elements for network independent access to emergency services".
- [i.49] ETSI TS 103 871: "Emergency Communications (EMTEL); PEMEA Real-Time Text Extension".
- [i.50] IETF RFC 3261: "SIP: Session Initiation Protocol", J. Rosenberg et al., 2005.
- [i.51] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications", H. Schulzrinne et al., 2003.
- [i.52] IETF RFC 9071 (2021): "RTP-Mixer Formatting of Multiparty Real-Time Text".
- [i.53] ISO/IEC 10646:2020: "Information technology — Universal coded character set (UCS)".
- [i.54] ISO/IEC 17549-1:2022: "Information technology — User interface requirements and recommendations on menu navigation: Part 1: Framework".
- [i.55] ETSI TS 126 226: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Cellular text telephone modem; General description (3GPP TS 26.226)".
- [i.56] ETSI TS 103 919: "Emergency Communications (EMTEL); Accessibility and Interoperability of Emergency Communications
- [i.57] IETF RFC 8831: "WebRTC Data Channels".
- [i.58] W3C® Recommendation (8 October 2024): "WebRTC: Real-Time Communication in Browsers".
- [i.59] ETSI TR 103 708: "Human Factors (HF); Real-Time Text (RTT) in Multiparty Conference Calling".
- [i.60] ISO/IEC 23859:2023: "Information technology — User interfaces — Requirements and recommendations on making written text easy to read and understand".
- [i.61] Recommendation ITU-T P.1305 (2016): "Effect of delays on telemeeting quality".
- [i.62] IETF RFC 5194 (2008): "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)".
- [i.63] Center for Inclusive Design and Environmental Access (2010): "Anthropometry of Wheeled Mobility Project - Final Report".
- [i.64] CEN/CENELEC EN 17210: "Accessibility and usability of the built environment - Functional requirements".
- [i.65] Recommendation ITUT H.Sup1 (1999): "Application profile - Sign language and lip-reading real-time conversation using low bit rate video communication".
- [i.66] ETSI TR 104 060: "Human Factors (HF); Guidance on how to apply the EN 301 549 to digital television products".
- [i.67] Void.
- [i.68] Void.
- [i.69] ISO/TR 22411:2021: "Ergonomics data for use in the application of ISO/IEC Guide 71:2014".
- [i.70] W3C® Recommendation (7 June 2011): "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", 2011 / 2016 / 2021.
- [i.71] ISO 14289-1:2014: Document management applications — Electronic document file format enhancement for accessibility: Part 1: Use of ISO 32000-1 (PDF/UA-1).
- [i.72] ISO 14289-2:2024: Document management applications — Electronic document file format enhancement for accessibility: Part 2: Use of ISO 32000-2 (PDF/UA-2).
- [i.73] ISO/IEC TS 20071-23:2018: "Information technology — User interface component accessibility — Part 23: Visual presentation of audio information (including captions and subtitles)".
- [i.74] Recommendation ITU T H.264: "Advanced video coding for generic audiovisual services".
- [i.75] Recommendation ITU T H.265: "High efficiency video coding".
- [i.76] IETF RFC 6386 (2011): "VP8 Data Format and Decoding Guide".
- [i.77] ETSI ES 204 009: "Human Factors (HF); Requirements for interoperable total conversation services".
- [i.78] ADA Accessibility Standards: "Americans with Disabilities Act – Accessibility Standards", 2010.
- [i.79] ISO/IEC 18012-1:2004: "Information technology — Home Electronic System — Guidelines for product interoperability Part 1: Introduction".
- [i.80] ETSI ETS 300 381 (Edition 1) (December 1994): "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids".
- [i.81] Directive (EU) 2018/1972 of the European Parliament and of the Council of 11 December 2018 establishing the European Electronic Communications Code (Recast) (Text with EEA relevance).
- [i.82] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance).
- [i.83] IETF RFC 6716: "Definition of the Opus Audio Codec", 2012.
- [i.84] IETF RFC 7874: "WebRTC Audio Codec and Processing Requirements", 2016.
- [i.85] IETF RFC 7875: "Additional WebRTC Audio Codecs for Interoperability", 2016.
- [i.86] IETF RFC 8251: "Updates to the Opus Audio Codec", 2017.
- [i.87] IETF RFC 8825: "Overview: Real-Time Protocols for Browser-Based Applications", 2021.
- [i.88] ETSI TS 126 441: "Universal Mobile Telecommunications System (UMTS); LTE; 5G; Codec for Enhanced Voice Services (EVS); General overview (3GPP TS 26.441)".
- [i.89] ETSI TS 103 495: "Emergency Communications (EMTEL); PEMEA Audio Video Extension".
Annex – Definition of terms, symbols and abbreviations (from EN 301 549)
3.1 Terms
For the purposes of the present document, the terms given in ETSI EG 201 013 [i.5] and the following apply:
- access space
- space intended to be occupied by the person, including their Assistive Technology, while they are using the product
- accessibility
- extent to which products, systems, services, environments and facilities can be used by people from a population with the widest range of user needs, characteristics and capabilities, to achieve identified goals in identified contexts of use (from ISO 9241-11:2018 [i.15])
NOTE 1: Context of use includes direct use or use supported by assistive technologies.
NOTE 2: The context in which the ICT is used may affect its overall accessibility. This context could include other products and services with which the ICT may interact.
- accessibility inspection tool for platforms
- software-based tool that can be used by developers or third party accessibility evaluators to check the use of the documented platform accessibility services
NOTE 1: For a given platform, the accessibility inspection tool can be:
- Platform-provided tool for accessibility inspection.
- Platform-provided assistive technologies, if 1 is not available or is not useful to test a given requirement.
- Generally-available assistive technologies for the platform, if neither 1 nor 2 are available.
NOTE 2: Platform tools are resources provided to software developers by the organization producing the platform. Some platform tools may include the function of inspecting the accessibility of ICTs developed for that platform. Some platform tools may be available to developers but not to 3rd party accessibility evaluators.
NOTE 3: Platform-provided assistive technologies are assistive technologies that are part of the platform. In the context of the present document, operating systems are popular examples of platforms.
NOTE 4: Examples of assistive technologies (either platform or non-platform) that can be used as inspection tools are, but are not limited to, a screen reader and a voice control system.
- applicable (accessibility) requirement
- requirement, whose preconditions are true for an ICT
- applicable scenario
- scenario, whose preconditions are true for an ICT
- applicable test
- test, whose preconditions are true for an ICT
- Application Programming Interface (API)
- collection of invocation methods and associated parameters used by one piece of software to request actions from another piece of software (from ISO/IEC 18012-1:2004 [i.79])
- Assistive Listening Devices (ALDs)
- devices that help separate the sounds, particularly speech, that a person wants to hear from background noise by bringing sound directly into the ear
NOTE: These are often found in meetings and public venues such as plays, concerts and places of worship. They can also be used at home with televisions and other products with auditory output.
- Assistive Technology (AT)
- any item, piece of equipment, service or product system including software that is used to increase, maintain, substitute or improve functional capabilities of persons with disabilities or for, alleviation and compensation of impairments, activity limitations or participation restrictions
NOTE 1: Assistive technology is an umbrella term that is broader than assistive products.
NOTE 2: Assistive technology can include assistive services, and professional services needed for assessment, recommendation and provision. Some examples of "assistive services" would be: all of the relay services, text to speech services, OCR services that change images of text to text, AI's that shift the language level of a document.
NOTE 3: Where ICT does not support directly connected assistive technology, but which can be operated by a system connected over a network or other remote connection, such a separate system (with any included assistive technology) can also be considered assistive technology.
- audio description
- narration added to the soundtrack to describe important visual details of synchronized audio-visual content, which cannot be understood from the main soundtrack alone
NOTE 1: This is also variously described using terms such as "video description" or variants such as "descriptive narration" and "described video".
NOTE 2: Audio description helps blind persons, persons with low vision, and persons who need assistance with understanding important facial expressions and other visual content to perceive and understand the visual content of audio-visual media.
NOTE 3: Audio description can provide information about actions, characters, scene changes, on-screen text, and other visual content.
NOTE 4: The audio description is generally inserted in the gaps in the main audio narrative. It typically uses a different voice, tone, or speed to separate it from the main audio.
- software that can be used to create or modify content
NOTE 1: An authoring tool may be used by a single user or multiple users working collaboratively.
NOTE 2: An authoring tool may be a single stand-alone application or be comprised of collections of applications.
NOTE 3: An authoring tool may produce content that is intended for further modification or for use by end-users.
NOTE 4: Authoring tool software can be web-based or non-web-based application(s) such as Content Management Systems, social media, word processors and courseware tools.
- caller identifier (caller ID)
- information presented to the recipient of an incoming request for a communication session (such as a phone call, video call, or messaging) that uniquely specifies the identity of the originating party
- captioned telephony
- service which converts speech to real-time text towards the primary user while letting voice through in both directions
NOTE 1: When provided for VoIP, it is called IP Captioned Telephony Service or IPCTS in the US.
NOTE 2: A conversation may have more than one primary user.
- closed functionality
- functionality that is limited by characteristics that prevent a user from attaching, installing or using assistive technology
- closed subtitles
- subtitle visually presented only in response to user preference (after ISO/IEC TS 20071-23 [i.73])
- communication client
- terminating software that transmits and receives communications
NOTE 1: A communication client can be limited to work with only one communication system that is provided by one specific system provider.
NOTE 2: The ICT that is, or includes, the communication client is responsible for ensuring that the content of the communication is communicated to and from the user of the communication client.
- communication system
- ICT that enables real-time bidirectional voice communications to flow between communication clients
NOTE 1: A communication system can contain several component parts that may not be separately identifiable from outside the system. Some communication systems might simply be an "interpersonal communication service" as defined in point 5 of Article 2 of Directive (EU) 2018/1972 [i.81].
NOTE 2: Some communication systems are separate from their communication clients while in others the communication clients form an integral part of a proprietary communication system.
- communicator
- : natural person, or software imitating a natural person, using a communication client to communicate
NOTE: Software that imitates a natural person can also be an effective way to test whether the requirements in the present document are met.
- compatible communication system
- communication system that uses the same communication standards as another communication system
- content
- information and sensory experience to be communicated to the user by means of software, including code or mark-up that defines the content's structure, presentation, and interactions (after WCAG2ICT [i.25])
NOTE 1: Content occurs in three places: web pages, non-web documents and non-web software. When content occurs in a web page or a non-web document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in software, a separate user agent is not needed in order to communicate the content's information and sensory experience to the user - the software itself performs that function.
NOTE 2: For non-web software, content also includes the user interface.
- context of use
- combination of users, goals and tasks, resources, and environment (from ISO 9241-11:2018 [i.15])
NOTE: The "environment" in a context of use includes the technical, physical, social, cultural and organizational environments.
- control (when used as a noun in the form of a "user interface control")
- user interface element that is operated by a user in order to interact with a product
NOTE 1: Examples of things controls are used for include, but are not limited to, input of information, direct actions, adjustments or commands for the product to act on, store, or pass along.
NOTE 2: Controls may be physical, or virtual (buttons on a screen, or gestures in the air, or biological measurements, etc.).
- conversational gain
- increase, measured in decibels [dB], of the speech level delivered to a user's ear above a reference level of 70 dB SPL
- discoverability metadata
- information about a digital resource (e.g. a PDF document, a video document, an audio document, etc.) that supports users and systems to find, identify, and evaluate that resource
- document (non-web document)
- logically distinct assembly of content (such as a file, set of files, or streamed media) that functions as a single entity rather than a collection, that is not part of software and that does not include its own user agent (after WCAG2ICT [i.25])
NOTE 1: A document always requires a user agent to present its content to the user.
NOTE 2: Letters, e-mail messages, spreadsheets, books, pictures, presentations, and movies are examples of documents.
NOTE 3: Software configuration and storage files such as databases and virus definitions, as well as computer instruction files such as source code, batch/script files, and firmware, are examples of files that function as part of software and thus are not examples of documents. If and where software retrieves "information and sensory experience to be communicated to the user" from such files, it is just another part of the content that occurs in software and is covered by WCAG2ICT like any other parts of the software. Where such files contain one or more embedded documents, the embedded documents remain documents under this definition.
NOTE 4: A collection of files zipped together into an archive, stored within a single virtual hard drive file, or stored in a single encrypted file system file, do not constitute a single document when so collected together. The software that archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the individually collected files in that collection because that software is not providing a fully functioning presentation of that content.
NOTE 5: Anything that can present its own content without involving a user agent, such as a self-playing book, is not a document but is software.
NOTE 6: A single document may be composed of multiple files such as the video content and closed caption text. This fact is not usually apparent to the end-user consuming the document/content.
NOTE 7: An assembly of files that represented the video, audio, subtitles and timing files for a movie is an example of a document.
NOTE 8: A binder file used to bind together the various exhibits for a legal case would not be a document.
NOTE 9: Documents may contain sub-documents.
- documented accessibility feature
- feature of an ICT offered to end-users that can enhance accessibility and is documented
- documented platform accessibility feature
- feature of a platform offered to end users that can enhance accessibility and is documented
- documented platform accessibility service
- subset of the platform's Application Programming Interface (API) that supports interoperability between a user interface running on the platform software and assistive technology
NOTE 1: They allow application developers to create software that is compatible with assistive technologies.
NOTE 2: These services are also often used by non-accessibility software and testing software.
- documented platform service
- service provided by the platform that is documented by the platform author for public use by accessibility applications and utilities created by third parties
NOTE: Platform services provide documented methods that allow software to add or integrate functionality provided by the platform rather than having to attach themselves in an ad-hoc fashion which is hard for both parties to support.
- Electronic Program Guide (EPG)
- means of presenting available content to the consumer, allowing selection of desired content
- embedded
- directly included in the content that is downloaded to the user agent and its extension, and is intended to be used in rendering the web page
NOTE: Something that is downloaded using a mechanism on the web page but is not used in rendering the page is not "embedded" in the page.
- height in CSSpx
- height as measured in CSS pixels
NOTE 1: CSS pixels are not a unit of length but a measure of angle of view. A CSS pixel (CSSpx) is based on the reference pixel, which is defined by a visual angle. The angle of view for a reference pixel is defined as 2*arctan (1 / (28 × 192)). (The angle which is created by looking at a real pixel with the size 1/96th of an inch at 28 inches viewing distance (the reference viewing distance). The height in CSSpx is transposed into a physical measure of height by multiplying the viewing distance with 1 / (28 × 96)) which is equivalent to 1 / 2 688.
The formula for calculating the physical height (in mm) from the height (in CSSpx) and the distance D (in mm) from the eye to the display is therefore physical height (mm) = D (mm) × height (CSSpx) / 2 688.NOTE 2: See https://www.w3.org/TR/CSS2/syndata.html#length-units for an explanation of absolute length calculations.
- Information and Communication Technology (ICT)
- technology, interconnected system or subsystem used for the creation, conversion, processing, transmission, gathering, or presentation of information or commands from users
NOTE 1: Examples of ICT include but are not limited to web pages, non-web and hybrid documents, electronic content, hardware, communication products, computers and ancillary equipment, software including mobile applications, information kiosks and transaction machines, audiovisual technologies, videos, intelligent user agents, information services.
NOTE 2: Anything with a digital user interface would fall within this definition although most but not all requirements relate to ICT that accepts information or commands from a user in addition to transmitting and/or presenting information.
- ICT network
- technology and resources supporting the connection and operation of interconnected ICT
- interlingual subtitles
- subtitles that translate the original audio information into a different language
NOTE: Interlingual subtitles provide a translation of the audio content into a different language, which is visually displayed to enable the understanding of the content by persons who do not understand, or have difficulties understanding, the language of the original audio content.
- keyboard interface
- interface used by software to obtain keystroke input
NOTE 1: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
EXAMPLE: A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.
NOTE 2: Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
- lipspeaking
- a specialized communication service where a trained hearing person (a lipspeaker) silently or quietly repeats a speaker's words, reproducing the rhythm, flow, and facial expressions to make speech easy for deaf or hard-of-hearing people to follow
- manual operation and control
- using physical human actions to perform an operation or to exert control
NOTE: Examples of manual operation and control include, but are not limited to:
- pushing a physical button in a way that causes button travel;
- making a gesture on a touchscreen;
- grasping or pinching a physical tactile operable part in a way that will allow that tactile operable part to be physically moved or rotated in some direction;
- inserting or retrieving cards, coins, tickets, etc. into or from slots in the ICT are also examples of manual operation and control.
- mechanism for private listening
- auditory output designed so that only the current user can receive the sound
NOTE: Personal headsets, directional speakers and audio hoods are examples of mechanisms for private listening.
- media
- different specific forms of presenting information to the user
NOTE: Examples of media include, but are not limited to, text, video, audio, graphics, animations, etc.
- media establishment
- process of agreeing between ICT about resources and characteristics of media to be used in a communication session, so that media then can be communicated and used
- set of selectable options (after ISO 17549-1:2022 [i.54])
- multimedia
- combinations of static and/or dynamic media presented simultaneously
NOTE: Examples of multimedia include combinations of text and video, or audio and animation, etc.
- non-text content
- content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language (after WCAG 2.2 [4])
NOTE: An image, graphic, audio clip, or other feature that conveys meaning through either a picture or sound. Examples include: buttons, check boxes, input fields, pictures, animations, and audio/video that is embedded or streamed.
- non-web document
- document that is not a web page, not embedded in web pages nor used in the rendering or functioning of the page
- non-web software
- software that is not a web page, not embedded in web pages nor used in the rendering or functioning of the page
- open functionality
- functionality that supports access by assistive technology
NOTE: This is the opposite of closed functionality.
- open subtitles
- subtitle visually presented regardless of user preference (after ISO/IEC TS 20071-23 [i.73])
NOTE: Open subtitles cannot be turned off or moved because they are embedded in the video content.
- operable part
- hardware element that operates the ICT when touched or manipulated
NOTE 1: The areas of a touch screen that need to be touched for operation are operable parts.
NOTE 2: When used as a surface for non-location specific gestures, the entire touch area is considered a single operable part whose location as a whole need only be discerned.
NOTE 3: Not all operable parts are required to meet the requirements of the present document, only enough to allow full operation in one mode of operation unless otherwise stated.
NOTE 4: Under the conformance requirement in clause 14.2, not all operable parts will be expected to meet all the requirements that apply to operable parts in all contexts.
NOTE 5: Operable parts may also include slots for input of cards, coins and bills as well as slots to receive printed tickets, paper receipts and change (coins).
- physical height
- actual height (of a pixel or other item) in units of linear measure such as mm or inch
NOTE: See the notes below height in CSSPx for more information about physical height and height in CSSpx.
- platform software (platform)
- collection of software components that runs on an underlying software or hardware layer, and that provides a set of software services to other software components that allows those applications to be isolated from the underlying software or hardware layer (after ISO/IEC 13066-1 [i.18])
NOTE: A particular software component might play the role of a platform in some situations and a client in others.
- primary user (of relay service)
- person who is using relay services because of a disability
NOTE: See secondary user.
- programmatically determinable
- able to be read by software from developer-supplied data in a way that other software, including assistive technologies, can extract and present this information to users in different modalities
NOTE: WCAG 2.2 uses "determined" where this definition uses "able to be read" (to avoid ambiguity with the word "determined").
- Real-Time Text (RTT)
- : form of text conversation in point to point situations or in multipoint conferencing where the text being entered is sent in such a way that the communication is perceived by the user as being continuous on a character-by-character basis
NOTE 1: Users will perceive communication as continuous if the delay between text being created by the sender and received by the recipient is less than 1 s. However, the actual delay will be dependent on the communications network.
NOTE 2: The creation of text will differ between systems where text is entered on a word-by-word basis (e.g. speech‑to‑text and predictive-text based systems) and systems where each character is separately generated (e.g. typing on a physical keyboard).
NOTE 3: Although RTT may often be "perceived by the user" as being sent character-by-character, none of the RTT standards require this to be the case. They assume accumulation of characters before sending and only require that no character is held for more than 500 ms after it is created before the accumulated text is sent. An accumulation time of 300 ms or less is recommended.
NOTE 4: It is already common for autonomous ICT to be at one end of continuous bidirectional voice communication. The RTT requirements in the present document ensure that there will be RTT communication wherever there is real-time bidirectional voice communication, even when there is an autonomous ICT at one end.
- relay service
- electronic communication service which enables real-time bidirectional communication between remote end-users of different modes of communication
NOTE: This is typically achieved by providing conversion between different modes of communication such as text, sign, and speech, or by providing the needed cognitive support for end-users during the communication, by a human operator or automatic means.
- relay service invocation functions
- set of functions related to decisions, communication establishments and media interconnections between users and a relay service
- satisfies a success criterion
- success criterion does not evaluate to "false" when applied to the ICT (after WCAG 2.2 [4])
- secondary user (of relay service)
- communication user other than a primary user, participating in a communication session facilitated by a relay service that is invoked based on the primary user's preferences and actions
NOTE 1: See primary user.
NOTE 2: A secondary user may initiate or answer a communication in which a relay service is invoked by primary user's preferences or actions.
NOTE 3: A secondary user may also be another primary user participating in a communication via another relayed communication.
- set of non-web documents
- collection of non-web documents that share a common purpose; are created by the same author, group or organization; are published together; and all refer to each other by name or link (after WCAG2ICT [i.25])
NOTE 1: Republishing or bundling previously published documents as a collection does not constitute a set of documents.
NOTE 2: If a set is broken apart, the individual parts are no longer part of a set, and would be evaluated as any other individual document is evaluated.
- single user operation
- operation performed by a user and recognized by the ICT as a discrete and complete operation
NOTE: A double-click is not a single user operation.
- speech output
- speech received during voice communication, or spoken information originating from ICT
- spoken subtitles
- subtitles that are voiced over the audiovisual content (after ISO/IEC TS 20071-25 [i.32])
- stationary ICT
- ICT that stands directly or indirectly on the floor, or is mounted on, fully integrated into, or installed through a wall or other immovable structure, and is not intended to be moved by its user
NOTE 1: Typically, stationary ICT rests on the ground or a plinth (such as an information kiosk) or is installed in a wall (such as control panels for lifts, lighting or air-conditioning) or through a wall (such as a machine that dispenses cash or performs other banking services) or attached to a pole (such as passenger information systems) or permanently mounted on a desk (such as check-in systems).
NOTE 2: A manufacturer cannot control the third party installation of a stationary ICT but can provide installation guidance to meet requirements for reach ranges, lighting or privacy.
NOTE 3: Mounted on the wall means: the stationary ICT is protruding:
- Integrated in a wall means: the surface of the stationary ICT is nearly flush with the wall. It may be slightly recessed or protrude due to an installation frame.
- Installed through a wall means: The main components of the ICT are installed behind a wall and only the panel of the stationary ICT is integrated in the wall. Stationary ICT integrated in or installed through a wall are often protected by a security shutter.
- Sound Pressure Level (SPL)
- logarithmic measure, expressed in decibels (dB), of the effective sound pressure of a sound relative to a reference value
- subtitles
- written text that is offered in the audiovisual content, which aims to account for (i) either the spoken words of the content, or (ii) the spoken words of the content in combination with other elements of a soundtrack
NOTE 1: When subtitles are used as an accommodation for deaf or hard of hearing users, they are also known as captions or as subtitles for the deaf and hard of hearing and also include additional information on other elements of the soundtrack needed to understand the audiovisual content.
NOTE 2: Outside North America, the term Subtitles is often used synonymously with Closed Captions. The term "Hardsubs" is sometimes used in place of Open Captions.
NOTE 3: Subtitles can appear anywhere on the display, and where possible are positioned to avoid overlapping content that needs to be visible (such as a "news ticker"), or where the background content would make the subtitles difficult to read.
NOTE 4: Subtitles may be open subtitles or closed subtitles.
- tactilely discernible operable part
- operable part that can be located via the sense of touch without activating it
NOTE 1: Physical properties of the tactilely discernible operable part, or its surroundings, that enable operable part to be tactilely discerned include, but are not limited to:
- some portion of the operable part being above or below the surface that surrounds it;
- the operable part having a raised feature that differentiates it from its surroundings;
- a detectable gap that surrounds the tactile part;
- having a different surface texture to surrounding surfaces;
- a part of a touchscreen being located adjacent to a tactilely discernible edge, corner, tactile markings on a screen frame;
- a touchscreen or touchpad that is tactilely discernible that is used as a whole as a gesture surface for non-location-specific gestures.
NOTE 2: The part of a touchscreen where an on-screen control is located is a tactilely discernible operable part if it is located adjacent to a tactilely discernible edge, corner, or tactile marking on a screen frame.
- terminal
- combination of hardware and/or software with which the end user directly interacts and that provides the user interface
NOTE 1: The hardware may consist of more than one device working together e.g. a mobile device and a computer.
NOTE 2: For some systems, the software that provides the user interface may reside on more than one device such as a telephone and a server.
NOTE 3: The software in a communications terminal is often called "communication client".
- text handling capabilities
- means to accept text input from and present text to a user
NOTE: This would typically be the presence of, or ability to connect, an alphanumeric keyboard and display or device which can act as an alphanumeric keyboard and display.
- total conversation
- bidirectional symmetric real time transfer of motion video, real-time text and voice between users in two or more locations
- Uniform Resource Identifier (URI)
- compact string of characters for identifying an abstract or physical resource
NOTE 1: Examples of ICT resources that can be identified by URIs are communications addresses, web pages, digital books, servers, etc.
NOTE 2: A Uniform Resource Locator (URL) is a type of URI. One example of a URL is "https://www.w3.org". When entered in the address bar of a browser, it will render the home web page of the World Wide Web Consortium.
- user agent
- software that retrieves and presents content for users (after WCAG 2.2 [4])
NOTE 1: Software that only displays the content contained within it is treated as software and not considered to be a user agent.
NOTE 2: An example of software that is not a user agent is a calculator application that does not retrieve the calculations from outside the software to present it to a user. In this case, the calculator software is not a user agent, it is simply software with a user interface.
NOTE 3: Software that only shows a preview of content such as a thumbnail or other non-fully functioning presentation is not providing user agent functionality.
- user interface
- all components of an interactive system (software or hardware) that provide information and/or controls for the user to accomplish specific tasks with the interactive system (from ISO 9241-110 [i.16])
- user interface element
- entity of the user interface that is presented to the user by the software (after ISO 9241 171 [i.17])
NOTE 1: This term is also known as "user interface component".
NOTE 2: User-interface elements can be interactive or not.
- visiting communication client
- communication client that is registered to work with a communication system that is different from the one it is currently connected to
- web content
- content that belongs to a web page, and that is used in the rendering or that is intended to be used in the rendering of the web page
NOTE: Web content is the text, visual or audio content that is made available online and encountered by users as part of the online usage and experience on websites. It may include text, images, sounds and audio, online videos, among other items placed within web pages.
- web page
- non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent (after WCAG 2.2 [4])
- x-height
- height of the lower-case character "x" of a font in mm (for a given distance) or CSSpx
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
- ADA
- Americans with Disabilities Act
- AI
- Artificial Intelligence
- ALD
- Assistive Listening Device
- AMR-WB
- Adaptive Multi-Rate WideBand
- ANSI
- American National Standards Institute
- API
- Application Programming Interface
- AT
- Assistive Technology
- ATAG
- Authoring Tool Accessibility Guidelines (of W3C®)
- ATM
- Automated Teller Machine
- AV
- AudioVisual
- CEN
- Comité Européen de Normalisation
- CPS
- Characters Per Second
- CSS
- Cascading Style Sheets
- DTMF
- Dual Tone Multi-Frequency
- EAA
- European Accessibility Act (Directive (EU) 2019/882 [i.29])
- EFTA
- European Free Trade Area
- EPG
- Electronic Program Guide
- EU
- European Union
- EVS
- (Codec for) Enhanced Voice Services
- FPS
- Frames Per Second
- GDPR
- General Data Privacy Regulation
- GTT
- Global Text Telephony
- GTT-IP
- Global Text Telephony over IP
- HEX
- HEXadecimal
- HTML
- HyperText Markup Language
- HTTP
- HyperText Transfer Protocol
- ICT
- Information and Communication Technology
- ID
- IDentity
- IETF
- Internet Engineering Task Force
- IMS
- IP Multimedia System
- IP
- Internet Protocol
- ISO
- International Organization for Standardization
- ITU-T
- International Telecommunication Union - Telecommunication standardization sector
- LED
- Light Emitting Device
- LTE
- Long-Term Evolution
- NAT
- Network Address Translation
- OCR
- Optical Character Recognition
- PDA
- Personal Digital Assistant
- PSAP
- Public Safety Answering Point
- QVGA
- Quarter Video Graphics Array
- RFC
- Request For Comment
- RTP
- Real-Time Protocol
- RTT
- Real-Time Text
- SIP
- Session Initiation Protocol
- SPL
- Sound Pressure Level
- TIA
- Telecommunications Industry Association
- UAAG
- User Agent Accessibility Guidelines (of W3C)
- U-C
- Use Case
- URI
- Uniform Resource Identifier
- URL
- Uniform Resource Locator
- USB
- Universal Serial Bus
- VGA
- Video Graphics Array
- ViLTE
- Video over LTE
- VoIP
- Voice over Internet Protocol
- VOIP
- Voice Over IP
- VoLTE
- Voice over LTE
- W3C
- World Wide Web Consortium
- WAI
- Web Accessibility Initiative
- WCAG
- Web Content Accessibility Guidelines (of W3C)
- WLAN
- Wireless Local Access Network
- XAML
- eXtensible Application Markup Language
- XML
- eXtensible Markup Language
- XUL
- XML User interface Language
Page details
- Date modified: