Criteria for apps (from end of 2026)

On 02 September 2026, a new version of the European standard was published: Version 4.1.1 (2026-09) EN 301549 (PDF) (external link). This version is expected to be published in the Official Journal of the European Union by late November 2026. From that point on, this new version will replace the previously applicable Version 3.2.1 (2021-03).

To support preparation, we have summarised here the criteria that must be met for apps. The applicable criteria can be found in Annex ZA of the European standard, in Table ZA.2.

A large number of the clauses are identical to the criteria of the Web Content Accessibility Guidelines (WCAG) 2.2 A and AA. This applies to the clauses:

• 9 Web: applies to web content that is attributable to an app (e.g., when the accessibility statement for an app is made available via a website)
• 10 Non-web documents: applies to non-web documents that are made available via apps
• 11 Non-web software: applies to the app itself

In these three clauses, the relevant WCAG criteria for web content, documents and non-web software (apps) are integrated.

Some WCAG criteria are excluded:

• Web:
  • 1.2.4 Captions (Live)
• Non-web documents:
  • 1.2.4 Captions (Live)
  • 2.4.1 Bypass Blocks
  • 2.5.4 Multiple Ways
• Non-web software:
  • 1.2.4 Captions (Live)
  • 2.4.1 Bypass Blocks
  • 2.5.4 Multiple Ways
  • 3.1.2 Language of Parts
  • 3.2.3 Consistent Navigation

The remaining clauses include criteria that go beyond the WCAG. Many of these apply only under certain conditions. The conditions are specified in the text of the criterion.

Note: We have adjusted the formatting from the European standard in some places in favour of digital accessibility. References have not been included.

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 donot 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).

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.

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.

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:

• a) directly by a mechanism included in or provided with the ICT; or
• b) by a personal headset that can be connected through a 3,5 mm audio jack without requiring the use of vision; or
• c) 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.

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.

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 so the new item will being to 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

• a) 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;
• b) 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;
• c) for displayed languages that cannot be selected using non-visual access;
• d) where the user explicitly selects a speech language that is different from the language of the displayed content.

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.

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.

Where ICT includes closed functionality, and any functionality of the ICT is closed to the text enlargement features of 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 CSS px.

• NOTE 1: The formula for calculating the physical x-height (in mm) from the x-height (in CSSpx) and the distance (in mm) from the eye to the font is x-height (mm) = D (mm) × CSSpx / 2 690.
• 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:

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.

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.

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.

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.

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, 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.

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

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.

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.

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.

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.

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: a) the delay before the key repeat shall be adjustable to at least 2 seconds; and b) the key repeat rate shall be adjustable down to one character per 2 seconds.

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.

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.

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.

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.

Where ICT is, or includes, authoring tool functionality, the authoring tool shall enable and guide the production of content that conforms to clauses 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.

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.

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.

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.

Where ICT is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports 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.

Where ICT is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports 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.

Where ICT is, or includes, a communication system that supports 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.

Where ICT is, or includes, a communication system that supports 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.

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 supports 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.

Where ICT is, or includes, a communication system that supports real-time bidirectional voice communication in emergency communications with PSAPs, the system shall meet all applicable 6.1 to 6.6 requirements, when performing the emergency communication.

Where ICT is, or includes, a communication system that supports 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, 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 and a PSAP in the visited country in emergency communications.

Where ICT is, or includes, a communication system that supports 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 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.

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: a) 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. b) 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: a) 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: Recommendation ITU-T G.722 [i.20], Recommendation ITU‑T G.722.2 [i.21] also called AMR-WB. IETF RFC 6716 [i.83] updated by IETF RFC 8251 [i.86] called OPUS. b) 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 ETSITS 126 114 [i.11] (= 3GPP TS 26.114). Multimedia Telephony is specified to use Recommendation ITU‑T G.722.2 [i.23], also called AMR-WB for wide band audio, and also EVS specified in ETSI TS 126 441 [i.88]. For interoperability with other systems, Recommendation ITU-T G.722 [i.20] is specified. c) 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).d) 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 wideband 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.e) Emergency communications: An interface to IP based emergency communications is specified inETSI TS 103 479 [i.48]. It makes use of Recommendation ITU-T G.722.2 [i.21] AMR-WB, IETFRFC 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, ETSITS 103 478 [i.47] is specified in ETSI TS 103 945 [i.89] to implement wide band audio by use ofOpus IETF RFC 6716 [i.83] updated by IETF RFC 8251 [i.86]. The use of these standards foraccessible and interoperable emergency communications is specified in ETSI TS 103 919 [i.56].f) 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 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 inETSI ES 204 009 [i.77].

Where ICT provides functionality that allows real-time bidirectional voice communication, and has a user interface forreal-time bidirectional voice communication,the ICT shall be able to capture, communicate and present voice communication with a frequency range of at leastdown to 250 Hz and up to at least 7 000 Hz.

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 ETSITR 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 isavailable while not disturbing the reading of earlier received text.

Where ICT provides real-time bidirectional voice communication, and supports RTT, the ICT shall allow concurrent voice and RTT.

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.

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).

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.

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.

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.

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.

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.

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 so character by character transmission is not required unless the characters are generated more slowly than 1 ms 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.

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.

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.

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.

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.

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.

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:

a) 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.

b) 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:
• a) 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.
• b) 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] (= 3GPP TS 26.114) to create the services including RTT and Total Conversation services specified in ETSI TS 122 173 [i.12] (= 3GPP TS 22.173). 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.
• c) 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.
• d) 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].
• e) 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]
• f) 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.

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.

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.

Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT: a) shall support at least QVGA resolution; b) should preferably support at least VGA resolution.

Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, the ICT: a) shall support a frame rate of at least 20 Frames Per Second (FPS); b) should preferably support a frame rate of at least 30 Frames Per Second (FPS) with or without sign language in the video stream.

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 ITU-T H-series Supplement 1 [i.65], clause 6.

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.

Where ICT provides real-time bidirectional voice communication, and includes real-time bidirectional video communication, and provides speaker identification for voice users, the ICT shall provide a means for speaker identification for real-time signing and sign language users once the start of signing has been indicated.

• 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.

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.

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:

a) 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.

b) 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.

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).

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.

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.

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.

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.

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 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.

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.

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.

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 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.1.1 Non-text content (external link).

WCAG Success Criterion 1.1.1 Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

• Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
• Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
• Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
• Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
• CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
• Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

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) (external link).

WCAG Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:

• Prerecorded Audio-only An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
• Prerecorded Video-only Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded) (external link).

• 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".

WCAG Success Criterion 1.2.2 Captions (Prerecorded) (Level A)

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

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) (external link).

• 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.

WCAG Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.2.5 Audio Description (Prerecorded) (external link).

• 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

Success Criterion 1.2.5 Audio Description (Prerecorded) (Level AA)

Audio description is provided for all prerecorded video content in synchronized media.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.1 Info and Relationships (external link).

Success Criterion 1.3.1 Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.2 Meaningful Sequence (external link).

WCAG Success Criterion 1.3.2 Meaningful Sequence (Level A)

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.3 Sensory Characteristics (external link).

WCAG Success Criterion 1.3.3 Sensory Characteristics (Level A)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

• Note: For requirements related to color, refer to Guideline 1.4 (external link).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.4 Orientation (external link).

WCAG Success Criterion 1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

• Note: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose (external link).

WCAG Success Criterion 1.3.5 Identify Input Purpose (Level AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.1 Use of Color (external link).

WCAG Success Criterion 1.4.2 Audio Control (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

• Note: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.2 Audio Control (external link).

WCAG Success Criterion 1.4.2 Audio Control (Level A)

If any audio on a web page 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: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference (external link).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum) (external link).

WCAG Success Criterion 1.4.3 Contrast (Minimum) (Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.4 Resize text (external link).

• NOTE: Best practice is for the smallest text have an x-height of at least 8 CSS px 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.

WCAG Success Criterion 1.4.4 Resize Text (Level AA)

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.5 Images of Text (external link).

WCAG Success Criterion 1.4.5 Images of Text (Level AA)

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

• Customizable: The image of text can be visually customized to the user's requirements;
• Essential: A particular presentation of text is essential to the information being conveyed.
• Note: Logotypes (text that is part of a logo or brand name) are considered essential.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.10 Reflow (external link).

WCAG Success Criterion 1.4.10 Reflow (Level AA)

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 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast (external link).

WCAG Success Criterion 1.4.11 Non-text Contrast (Level AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(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 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 1.4.12 Text spacing (external link).

WCAG Success Criterion 1.4.12 Text Spacing (Level AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

• Note 1: Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.
• Note 2: Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system.

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 (external link).

WCAG Success Criterion 1.4.13 Content on Hover or Focus (Level AA)

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 and is not modified by the author.

Notes

• Note 1: Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute [HTML].
• 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.1 Keyboard (external link).

WCAG Success Criterion 2.1.1 Keyboard (Level AA)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
• Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.2 No Keyboard Trap (external link).

WCAG Success Criterion 2.1.2 No Keyboard Trap (Level A)

If keyboard focus can be moved to a component of the page 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: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference (external link).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.1.4 Character Key Shortcuts (external link).

WCAG Success Criterion 2.1.4 Character Key Shortcuts (Level A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
• Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable (external link).

WCAG Success Criterion 2.2.1 Timing Adjustable (Level A)

For each time limit that is set by the content, 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: 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 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide (external link).

WCAG Success Criterion 2.2.2 Pause, Stop, Hide (Level A)

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.

Notes

• Note 1: For requirements related to flickering or flashing content, refer to 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 page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference (external link).
• 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.

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 (external link).

WCAG Success Criterion 2.3.1 Three Flashes or Below Threshold (Level A)

Web pages 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: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference (external link).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.1 Bypass Blocks (external link).

WCAG Success Criterion 2.4.1 Bypass Blocks

A mechanism is available to bypass blocks of content that are repeated on multiple web pages.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.2 Page Titled (external link).

WCAG Success Criterion 2.4.2 Page Titled (Level A)

Web pages have titles that describe topic or purpose.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.3 Focus Order (external link).

WCAG Success Criterion 2.4.3 Focus Order (Level A)

If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

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) (external link).

WCAG Success Criterion 2.4.4 Link Purpose (In Context) (Level A)

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.5 Multiple Ways (external link).

WCAG Success Criterion 2.4.5 Multiple Ways (Level AA)

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

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.6 Headings and Labels (external link).

WCAG Success Criterion 2.4.6 Headings and Labels (Level AA)

Headings and labels describe topic or purpose.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.4.7 Focus Visible (external link).

WCAG Success Criterion 2.4.7 Focus Visible (Level AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

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) (external link).

WCAG Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

• Note 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
• Note 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.

Where ICT is, or includes, a web page,the web page shall satisfy WCAG 2.2 Success Criterion 2.5.1 Pointer Gestures (external link).

WCAG 2.2 Success Criterion 2.5.1 Pointer Gestures (Level A)

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: This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).

Where ICT is, or includes, a web page,the web page shall satisfy WCAG 2.2 Success Criterion 2.5.2 Pointer Cancellation (external link).

WCAG Success Criterion 2.5.2 Pointer Cancellation (Level A)

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.

Notes

• Note 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.
• Note 2: This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).

Where ICT is, or includes, a web page,the web page shall satisfy WCAG 2.2 Success Criterion 2.5.3 Label in Name (external link).

WCAG Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

• Note: A best practice is to have the text of the label at the start of the name.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.4 Motion Actuation (external link).

WCAG Success Criterion 2.5.4 Motion Actuation (Level A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
• Essential: The motion is essential for the function and doing so would invalidate the activity.

Where ICT is, or includes, a web page,the web page shall satisfy WCAG 2.2 Success Criterion 2.5.7 Dragging Movements (external link).

WCAG Success Criterion 2.5.7 Dragging Movements (Level A)

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 and not modified by the author.

• Note: This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum) (external link).

WCAG Success Criterion 2.5.8 Target Size (Minimum) (Level A)

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 centered 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 on the same page 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 Control The size of the target is determined by the user agent 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.

Notes

• 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, color pickers displaying a gradient of colors, or editable areas where you position the cursor.
• 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.1.1 Language of Page (external link).

WCAG Success Criterion 3.1.1 Language of Page (Level A)

The default human language of each web page can be programmatically determined.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.1.2 Language of Parts (external link).

WCAG Success Criterion 3.1.2 Language of Parts (Level AA)

The human language of each passage or phrase in the content 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.1 On Focus (external link).

WCAG Success Criterion 3.2.1 On Focus (Level A)

When any user interface component receives focus, it does not initiate a change of context.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.2 On Input (external link).

WCAG Success Criterion 3.2.2 On Input (Level A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.3 Consistent Navigation (external link).

WCAG Success Criterion 3.2.3 Consistent Navigation (Level AA)

Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.4 Consistent Identification (external link).

WCAG Success Criterion 3.2.4 Consistent Identification (Level AA)

Components that have the same functionality within a set of web pages are identified consistently.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.2.6 Consistent Help (external link).

WCAG Success Criterion 3.2.6 Consistent Help (Level A)

If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page 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 on the page, or may be provided via a direct link to a different page containing the information.
• Note 2: For this success criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.1 Error Identification (external link).

WCAG Success Criterion 3.3.1 Error Identification (Level A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions (external link).

WCAG Success Criterion 3.3.2 Labels or Instructions (Level A)

Labels or instructions are provided when content requires user input.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.3 Error Suggestion (external link).

WCAG Success Criterion 3.3.3 Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

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) (external link).

WCAG Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

For web pages 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.7 Redundant Entry (external link).

WCAG Success Criterion 3.3.7 Redundant Entry (Level A)

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

• auto-populated, or
• available for the user to select.

Except when:

• re-entering the information is essential,
• the information is required to ensure the security of the content, or
• previously entered information is no longer valid.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum) (external link).

WCAG Success Criterion 3.3.8 Accessible Authentication (Minimum) (Level AA)

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 the website.

Notes

• 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.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value (external link).

WCAG Success Criterion 4.1.2 Name, Role, Value (Level A)

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 user agents, including assistive technologies.

• Note: This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Where ICT is, or includes, a web page, the web page shall satisfy WCAG 2.2 Success Criterion 4.1.3 Status Messages (external link).

WCAG Success Criterion 4.1.3 Status Messages (Level AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

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: 1) Conformance level 2) Full pages 3) Complete processes 4) Only Accessibility-Supported Ways of Using Technologies 5) 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 successcriteria (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 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 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 webpages in the process conform at the specified level or better. Refer to the Glossary section inWCAG 2.2 for the definition of the term "process".
• NOTE 5: Conformance requirement 4 states that only accessibility-supported ways of using technologies are reliedupon 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 for the definition of the terms "accessibility-supported", "technologies", "reliedupon".
• 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 useragent, 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 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, which waspublished as a W3C Recommendation June 2018 (updated on May 2025). Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1".

Where ICT is, or includes, a web page,the web page shall not block the user agents mode(s) of operation that present the web page according to userpreference settings, or explicitly override user preferences 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 a web browser 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.

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 (external link).

• NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance isaccurate.

WCAG Success Criterion 1.1.1 Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

• Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
• Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
• Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
• Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
• CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
• Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

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) (external link).

• NOTE: The alternative can be provided directly in the non-web document - or provided in an alternate version that satisfies the success criterion.

WCAG Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:

• Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
• Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

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) (external link).

• 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".

WCAG Success Criterion 1.2.2 Captions (Prerecorded) (Level A)

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

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) (external link).

• 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.

WCAG Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

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) (external link).

• 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.

WCAG Success Criterion 1.2.5 Audio Description (Prerecorded) (Level AA)

Audio description is provided for all prerecorded video content in synchronized media.

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 (external link).

• 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.

WCAG Success Criterion 1.3.1 Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

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 (external link).

WCAG Success Criterion 1.3.2 Meaningful Sequence (Level A)

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

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 (external link).

WCAG Success Criterion 1.3.3 Sensory Characteristics (Level A)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

• Note: For requirements related to color, refer to Guideline 1.4.

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 (external link).

• 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.

WCAG Success Criterion 1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

• Note: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

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 (external link).

• 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.

WCAG Success Criterion 1.3.5 Identify Input Purpose (Level AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

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 (external link).

WCAG Success Criterion 1.4.1 Use of Color (Level A)

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

• Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Audio control.

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 (external link), 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.

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) (external link).

WCAG Success Criterion 1.4.3 Contrast (Minimum) (Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

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 (external link).

• 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 CSS px 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.

WCAG Success Criterion 1.4.4 Resize Text (Level AA)

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

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 (external link).

WCAG Success Criterion 1.4.5 Images of Text (Level AA)

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

• Customizable: The image of text can be visually customized to the user's requirements;
• Essential: A particular presentation of text is essential to the information being conveyed.
• Note: Logotypes (text that is part of a logo or brand name) are considered essential.

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 Non-web document success criterion: Reflow.

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.

Notes

• 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.
• 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 (external link) replacing "web content" with "content" in the original WCAG 2.2 note 1 and adding notes 3, 4, and 5.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Non-text contrast.

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 color(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 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.

Notes

• 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 (external link) replacing "user agent" with "user agent or other platform software" and adding note 1.

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 (external link).

• 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.

WCAG Success Criterion 1.4.12 Text Spacing (Level AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

• Note 1: Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.
• Note 2: Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Content on hover or focus.

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.

Notes

• 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 2.1.1 Content on Hover or Focus (external link) 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".

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 (external link).

WCAG Success Criterion 2.1.1 Keyboard (Level A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
• Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

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 Non-web document success criterion: No keyboard trap.

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 (external link) 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".

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 (external link).

WCAG Success Criterion 2.1.4 Character Key Shortcuts (Level A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off A mechanism is available to turn the shortcut off;
• Remap A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
• Active only on focus The keyboard shortcut for a user interface component is only active when that component has focus.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Timing adjustable.

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.

Notes

• 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 (external link) 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.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Pause, stop, hide .

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.

Notes

• 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 (external link) 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.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Three flashes or below threshold.

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 (external link) 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".

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.

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 Non-web document success criterion: Focus order.

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 (external link) replacing "web page" with "non-web document".

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) (external link).

WCAG Success Criterion 2.4.4 Link Purpose (In Context) (Level A)

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

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 (external link).

WCAG Success Criterion 2.4.6 Headings and Labels (Level AA)

Headings and labels describe topic or purpose.

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 (external link).

WCAG 2 Success Criterion 2.4.7 Focus Visible (Level AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is 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 WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum) (external link).

WCAG Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

• Note 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
• Note 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Pointer gestures.

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 (external link) replacing "web content" with "content" in note 1 and adding note 2.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Pointer cancellation.

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.

Notes

• 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 (external link) replacing "web content" with "content" in note 2 and adding note 3.

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 (external link).

WCAG Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

• Note: A best practice is to have the text of the label at the start of the name.

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 (external link).

WCAG Success Criterion 2.5.4 Motion Actuation (Level A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported Interface The motion is used to operate functionality through an accessibility supported interface;
• Essential The motion is essential for the function and doing so would invalidate the activity.

Where ICT is, or includes, a non-web document the non-web document shall satisfy the Non-web document success criterion: Dragging movements.

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 (external link) replacing "user agent" with "user agent or other platform software", "web content" with "content" in note 1, and adding note 2.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Target size (minimum).

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.

Notes

• 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: 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) (external link) 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.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Language of non-web document.

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 (external link) replacing "web page" with "non-web document".

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Language of parts.

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 (external link) replacing "content" with "non-web document" and with the addition of notes 1 and 2 above.

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 (external link).

• 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.

WCAG Success Criterion 3.2.1 On Focus (Level A)

When any user interface component receives focus, it does not initiate a change of context.

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 (external link).

WCAG Success Criterion 3.2.1 On Focus (Level A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Where ICT is, or includes, a non-web document within a set of non-web documents, the non-web document shall satisfy the Non-web document success criterion: Consistent navigation.

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 WCAG 2 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 (external link) 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.

Where ICT is, or includes, a non-web document within a set of non-web documents, the the Non-web document shall satisfy the Non-web document success criterion: Consistent identification.

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 (external link) 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.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Consistent Help

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

Notes

• 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 (external link) 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.

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 (external link).

WCAG Success Criterion 3.3.1 Error Identification (Level A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

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 (external link).

WCAG Success Criterion 3.3.2 Labels or Instructions (Level A)

Labels or instructions are provided when content requires user input.

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 (external link).

WCAG Success Criterion 3.3.3 Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Error prevention (legal, financial, data).

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:

1. Reversible: Submissions are reversible.
2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

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 (external link).

WCAG Success Criterion 3.3.7 Redundant Entry (Level A)

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

• auto-populated, or
• available for the user to select

Except when:

• re-entering the information is essential,
• the information is required to ensure the security of the content, or
• previously entered information is no longer valid.

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Accessible authentication (minimum).

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.

Notes

• 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:
  • 1) support for password entry by password managers to reduce memory need, and
  • 2) 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) (external link) replacing "website" with "non-web document".

Where ICT is, or includes, a non-web document, the non-web document shall satisfy the Non-web document success criterion: Name, role, value.

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 (external link) 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 2.

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 (external link).

• 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.

WCAG Success Criterion 4.1.3 Status Messages (Level AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Where ICT is, or includes, a non-web document, the non-web document shall not block the user agent's mode(s) of operation that present the document according to user preference settings, or explicitly override user preferences 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-a non web document viewing software that meets clause 11.7 there is at least one mode of operation where the non web document viewing 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 be documented as platform accessibility features include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.

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 (external link).

• NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.

WCAG Success Criterion 1.1.1 Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

• Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
• Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
• Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
• Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
• CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
• Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

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) (external link).

• NOTE: The alternative can be provided directly in the non-web software - or provided in an alternate version that satisfies the success criterion.

WCAG Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:

• Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
• Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

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) (external link).

• 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".

WCAG Success Criterion 1.2.2 Captions (Prerecorded) (Level A)

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

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) (external link).

• 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.

WCAG Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

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) (external link).

• 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.

WCAG Success Criterion 1.2.5 Audio Description (Prerecorded) (Level AA)

Audio description is provided for all prerecorded video content in synchronized media.

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 (external link).

• 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).

WCAG Success Criterion 1.3.1 Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in 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.3.2 Meaningful Sequence (external link).

WCAG Success Criterion 1.3.2 Meaningful Sequence (Level A)

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

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 (external link).

WCAG Success Criterion 1.3.3 Sensory Characteristics (Level A)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

• Note: For requirements related to color, refer to Guideline 1.4.

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 (external link).

• 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.

WCAG Success Criterion 1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

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 (external link).

• 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.

WCAG Success Criterion 1.3.5 Identify Input Purpose (Level AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

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 (external link).

WCAG Success Criterion 1.4.1 Use of Color (Level A)

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

• Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Audio control.

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 (external link) 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".

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) (external link).

WCAG Success Criterion 1.4.3 Contrast (Minimum) (Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

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 Non-web software success criterion: Resize Text.

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 CSS px 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 (external link) 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.

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 (external link).

WCAG Success Criterion 1.4.5 Images of Text (Level AA)

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

• Customizable: The image of text can be visually customized to the user's requirements;
• Essential: A particular presentation of text is essential to the information being conveyed.
• Note: Logotypes (text that is part of a logo or brand name) are considered essential.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Reflow.

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 (external link) replacing "web content" with "content" and adding notes 3 to 7.

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 (external link).

• 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.

WCAG Success Criterion 1.4.11 Non-text Contrast (Level AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(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 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.

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 (external link).

• 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.

WCAG Success Criterion 1.4.12 Text Spacing (Level AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

• Note 1: Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.
• Note 2: Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system.

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, and is not modified by the author, the non-web software shall satisfy the Non-web software success criterion: Content on Hover or Focus.

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 2.1.1 Content on Hover or Focus (external link) replacing "user agent" with "user agent or other platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes".

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 (external link) in accordance with the Intent from Understanding Success Criterion 2.1.1 (external link).

• 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.

WCAG Success Criterion 2.1.1 Keyboard (Level A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
• Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

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 Non-web software success criterion: No keyboard trap.

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 (external link) 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".

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 (external link).

• 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.

WCAG Success Criterion 2.1.4 Character Key Shortcuts (Level A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
• Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Timing adjustable.

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.

Notes

• 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 (external link) replacing "the content" with "non-web software" and with the words "WCAG 2.2" added before the word "Success Criterion" in note 1 above.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Pause, stop, hide.

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.

Notes

• 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 (external link) 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.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Three flashes or below threshold.

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 (external link) 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.

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.

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 Non-web software success criterion: Focus order.

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 (external link) replacing "web page" with "non-web software".

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) (external link).

• NOTE: In non-web software, a "link" is any user interface control that behaves like a hypertext link.

WCAG Success Criterion 2.4.4 Link Purpose (In Context) (Level A)

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

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 (external link).

• 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.

WCAG Success Criterion 2.4.6 Headings and Labels (Level AA)

Headings and labels describe topic or purpose.

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 (external link).

WCAG Success Criterion 2.4.7 Focus Visible (Level AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is 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.11 Focus Not Obscured (Minimum) (external link).

WCAG Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

• Note 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
• Note 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.

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 Non-web software success criterion: Pointer gestures.

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.

Notes

• 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 (external link), 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.

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 Non-web software success criterion: Pointer cancellation.

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.

Notes

• 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 (external link) 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.

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 (external link).

WCAG Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

• Note: A best practice is to have the text of the label at the start of the name.

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 (external link).

WCAG Success Criterion 2.5.4 Motion Actuation (Level A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
• Essential: The motion is essential for the function and doing so would invalidate the activity.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Dragging Movements.

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 (external link), 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.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Target size (minimum).

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.

Notes

• 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) (external link) 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.

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 Non-web software success criterion: Language of non-web software.

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 (external link), replacing "each web page" with "non-web software" and with the addition of note 1 above.

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 (external link).

• 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.

WCAG Success Criterion 3.2.1 On Focus (Level A)

When any user interface component receives focus, it does not initiate a change of context.

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 (external link).

WCAG Success Criterion 3.2.2 On Input (Level A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

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" (external link), 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.

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 (external link).

WCAG Success Criterion 3.3.1 Error Identification (Level A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

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 (external link).

WCAG Success Criterion 3.3.2 Labels or Instructions (Level A)

Labels or instructions are provided when content requires user 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.3.3 Error Suggestion (external link).

WCAG Success Criterion 3.3.3 Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Error prevention (legal, financial, data).

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:

1. Reversible: Submissions are reversible.
2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
3. 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) (external link) replacing "web pages" with "non-web software".

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 (external link).

WCAG Success Criterion 3.3.7 Redundant Entry (Level A)

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

• auto-populated, or
• available for the user to select.

Except when:

• re-entering the information is essential,
• the information is required to ensure the security of the content, or
• previously entered information is no longer valid.

Where ICT is, or includes, non-web software that provides a user interface, the non-web software shall satisfy the Non-web software success criterion: Accessible authentication (minimum).

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.

Notes

• 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: 1) support for password entry by password managers to reduce memory need; and 2) 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) (external link) replacing "the website" with "a website, non-web document, or software" and adding notes 3 and 4.

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 Non-web software success criterion: Name, role, value.

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.

Notes

• 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 (external link) 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Where ICT is, or includes, platform software, the platform software shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.

• 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.

Where ICT is, or includes, non-web software, the software shall not disrupt those documented platform accessibility features that are defined in platform documentation 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.

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 it is essential to the function of the non-web software to not follow a user preference settings.

• 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 software, the underlying platform is usually the operating system.
• NOTE 4: 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 5: 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 6: 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.

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.

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.

Where ICT includes information about the ICT, whether provided separately or integrated within the ICT, the information shall list and explain how to use the accessibility features of the ICT and its features that facilitate compatibility with assistive technology, any accessibility provisions that are not met, as well as any available support service, including accessibility specific support service.

• NOTE 1: It is best practice to not only offer this information directly to users but also to use standardized vocabularies to provide metadata on the accessibility of the ICT, such as "Schema.org Accessibility Properties for Discoverability Vocabulary" [i.39], or "Service and discovery metadata - DVB" [i.68].
• NOTE 2: It is best practice to present ICT accessibility metadata in a manner that is understandable to users. There exists guidance in this respect, such as the "User Experience Guide for Displaying Accessibility Metadata 1.0" [i.68].
• NOTE 3: Help pages are examples of the provision of product information

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.

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) is available, 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 the 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.

Where ICT is, or includes, a relay service invocation system, the ICT shall assign unique user identifiers to primary users to be used in relayed communication with secondary users as caller identifiers in outgoing communications from the primary users, and as user identifiers used to address the primary users in incoming communications to them.

Where ICT is, or includes, a relay service invocation system, 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.

Where ICT is, or includes, a relay service invocation system, the ICT shall allow the 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.

Where ICT is, or includes, a relay service invocation system, the ICT shall allow the 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.

Where ICT is, or includes, a relay service invocation system, the ICT shall initiate and perform emergency communications on the request by the primary user with relay service invoked.

• NOTE 1: The relay service is expected to allow invocations of PSAPs in a three-party fashion and perform the relaying action in the ways specified in ETSI TS 103 919 [i.56], clauses 7.2.6 and 7.3.5.
• NOTE 2: This way of invoking relay services in emergency communications is seen as a fallback option and may optionally not provide all desired contextual information to the PSAP.

Where ICT is, or includes, a relay service, the relay service shall allow primary users with availability of the relay service to participate in speech communication with secondary users by performing modality conversion or communication support function according to the type and mode of operation of the relay service.

Where ICT is, or includes, a relay service, the relay service connection shall support all of the three media of total conversation between which the conversion is performed according to the type and mode of operation of the relay service, and passing-through media not involved in the conversion but commonly supported and enabled by the communication clients involved in the communication.

• 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.

Where ICT is, or includes, a relay service, the ICT shall support participation of primary relay service users in conferences and enable conference participation of users of the relay service.

• 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.

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.