Mapping between Revised Section 508 and EN 301 549 (2014, 2018, 2019 and 2021)

E207.2 WCAG Conformance

User interface components and content of platforms and applications shall conform to Level A and Level AA Success Criteria and Conformance Requirements specified for web pages in WCAG 2.0.

EXCEPTIONS:

1. Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to E207.2.
2. Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.
3. Non-Web software shall not be required to conform to Conformance Requirement 3 Complete Processes in WCAG 2.0.

Chapters 9, 10, and 11 apply WCAG 2.0 Level A and Level AA Success Criteria to Web content (Chapter 9), Documents (Chapter 10), and Non-Web Software (Chapter 11).

EN 301 549 Video Series

4.2.1 Usage without vision

Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that does not require vision.

NOTE: Audio and tactile user interfaces may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.1 Usage without vision

Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that does not require vision.

NOTE 1: A web page or application with a well formed semantic structure can allow users without vision to identify, navigate and interact with a visual user interface.

NOTE 2: Audio and tactile user interfaces may contribute towards meeting this clause.

4.2.1 Usage without vision

Where ICT provides visual modes of operation, the ICT provides at least one mode of operation that does not require vision. This is essential for users without vision and benefits many more users in different situations.

NOTE 1: A web page or application with a well formed semantic structure can allow users without vision to identify, navigate and interact with a visual user interface.

NOTE 2: Audio and tactile user interfaces may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.1 Usage without vision

Where ICT provides visual modes of operation, the ICT provides at least one mode of operation that does not require vision. This is essential for users without vision and benefits many more users in different situations.

NOTE 1: A web page or application with a well formed semantic structure can allow users without vision to identify, navigate and interact with a visual user interface.

NOTE 2: Audio and tactile user interfaces may contribute towards meeting this clause.

4.2.2 Usage with limited vision

Where ICT provides visual modes of operation, some users will need the ICT to provide features that enable users to make better use of their limited vision.

NOTE 1: Magnification, reduction of required field of vision and control of contrast, brightness and intensity can contribute towards meeting this clause.

NOTE 2: Where significant features of the user interface are dependent on depth perception, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

NOTE 3: Users with limited vision may also benefit from non-visual access (see clause 4.2.1).

Stylistic rewording

Explanatory update

4.2.2 Usage with limited vision

Where ICT provides visual modes of operation, some users will need the ICT to provide features that enable users to make better use of their limited vision.

NOTE 1: Magnification, reduction of required field of vision and control of contrast, brightness and intensity can contribute towards meeting this clause.

NOTE 2: Where significant features of the user interface are dependent on depth perception, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

NOTE 3: Users with limited vision may also benefit from non-visual access (see clause 4.2.1).

4.2.2 Usage with limited vision

Where ICT provides visual modes of operation, the ICT provides features that enable users to make better use of their limited vision. This is essential for users with limited vision and benefits many more users in different situations.

NOTE 1: Magnification, reduction of required field of vision and control of contrast, brightness and intensity can contribute towards meeting this clause.

NOTE 2: Where significant features of the user interface are dependent on depth perception, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

NOTE 3: Users with limited vision may also benefit from non-visual access (see clause 4.2.1).

Stylistic rewording

Explanatory update

4.2.2 Usage with limited vision

Where ICT provides visual modes of operation, the ICT provides features that enable users to make better use of their limited vision. This is essential for users with limited vision and benefits many more users in different situations.

NOTE 1: Magnification, reduction of required field of vision and control of contrast, brightness and intensity can contribute towards meeting this clause.

NOTE 2: Where significant features of the user interface are dependent on depth perception, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

NOTE 3: Users with limited vision may also benefit from non-visual access (see clause 4.2.1).

302.3 Without Perception of Color

Where a visual mode of operation is provided, ICT shall provide at least one visual mode of operation that does not require user perception of color.

4.2.3 Usage without perception of colour

Where ICT provides visual modes of operation, some users will need the ICT to provide a visual mode of operation that does not require user perception of colour.

NOTE: Where significant features of the user interface are colour-coded, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.3 Usage without perception of colour

Where ICT provides visual modes of operation, some users will need the ICT to provide a visual mode of operation that does not require user perception of colour.

NOTE: Where significant features of the user interface are colour-coded, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

4.2.3 Usage without perception of colour

Where ICT provides visual modes of operation, the ICT provides a visual mode of operation that does not require user perception of colour. This is essential for users with limited colour perception and benefits many more users in different situations.

NOTE: Where significant features of the user interface are colour-coded, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.3 Usage without perception of colour

Where ICT provides visual modes of operation, the ICT provides a visual mode of operation that does not require user perception of colour. This is essential for users with limited colour perception and benefits many more users in different situations.

NOTE: Where significant features of the user interface are colour-coded, the provision of additional methods of distinguishing between the features may contribute towards meeting this clause.

4.2.4 Usage without hearing

Where ICT provides auditory modes of operation, some users need ICT to provide at least one mode of operation that does not require hearing.

NOTE: Visual and tactile user interfaces may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.4 Usage without hearing

Where ICT provides auditory modes of operation, some users need ICT to provide at least one mode of operation that does not require hearing.

NOTE: Visual and tactile user interfaces may contribute towards meeting this clause.

4.2.4 Usage without hearing

Where ICT provides auditory modes of operation, the ICT provides at least one mode of operation that does not require hearing. This is essential for users without hearing and benefits many more users in different situations.

NOTE: Visual and tactile user interfaces, including those based on sign language, may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.4 Usage without hearing

Where ICT provides auditory modes of operation, the ICT provides at least one mode of operation that does not require hearing. This is essential for users without hearing and benefits many more users in different situations.

NOTE: Visual and tactile user interfaces, including those based on sign language, may contribute towards meeting this clause.

302.5 With Limited Hearing

Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited hearing.

4.2.5 Usage with limited hearing

Where ICT provides auditory modes of operation, some users will need the ICT to provide enhanced audio features.

NOTE 1: Enhancement of the audio clarity, reduction of background noise, increased range of volume and greater volume in the higher frequency range can contribute towards meeting this clause.

NOTE 2: Users with limited hearing may also benefit from non-hearing access (see clause 4.2.4).

Stylistic rewording

Explanatory update

4.2.5 Usage with limited hearing

Where ICT provides auditory modes of operation, some users will need the ICT to provide enhanced audio features.

NOTE 1: Enhancement of the audio clarity, reduction of background noise, increased range of volume and greater volume in the higher frequency range can contribute towards meeting this clause.

NOTE 2: Users with limited hearing may also benefit from non-hearing access (see clause 4.2.4).

4.2.5 Usage with limited hearing

Where ICT provides auditory modes of operation, the ICT provides enhanced audio features. This is essential for users with limited hearing and benefits many more users in different situations.

NOTE 1: Enhancement of the audio clarity, reduction of background noise, providing a joint monaural option, adjustment of balance of both audio channels, increased range of volume and greater volume in the higher frequency range can contribute towards meeting this clause.

NOTE 2: Allowing the use of Assistive Listening Devices, such as headsets with noise cancellation (connected by cable, Bluetooth or WLAN) can contribute towards meeting this clause.

NOTE 3: Users with limited hearing may also benefit from non-hearing access (see clause 4.2.4).

Stylistic rewording

Explanatory update

Functional change

4.2.5 Usage with limited hearing

Where ICT provides auditory modes of operation, the ICT provides enhanced audio features. This is essential for users with limited hearing and benefits many more users in different situations.

NOTE 1: Enhancement of the audio clarity, reduction of background noise, providing a joint monaural option, adjustment of balance of both audio channels, increased range of volume and greater volume in the higher frequency range can contribute towards meeting this clause.

NOTE 2: Allowing the use of Assistive Listening Devices, such as headsets with noise cancellation (connected by cable, Bluetooth or WLAN) can contribute towards meeting this clause.

NOTE 3: Users with limited hearing may also benefit from non-hearing access (see clause 4.2.4).

4.2.6 Usage without vocal capability

Where ICT requires vocal input from users, some users will need the ICT to provide at least one mode of operation that does not require them to generate vocal output.

NOTE 1: This clause covers the alternatives to the use of orally-generated sounds, including speech, whistles, clicks, etc.

NOTE 2: Keyboard, pen or touch user interfaces may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.6 Usage without vocal capability

Where ICT requires vocal input from users, some users will need the ICT to provide at least one mode of operation that does not require them to generate vocal output.

NOTE 1: This clause covers the alternatives to the use of orally-generated sounds, including speech, whistles, clicks, etc.

NOTE 2: Keyboard, pen or touch user interfaces may contribute towards meeting this clause.

4.2.6 Usage with no or limited vocal capability

Where ICT requires vocal input from users, the ICT provides at least one mode of operation that does not require them to generate vocal output. This is essential users with no or limited vocal capability and benefits many more users in different situations.

NOTE 1: Vocal output includes speech and other orally generated sounds, such as whistles and clicks.

NOTE 2: Keyboard, pen or touch user interfaces may contribute towards meeting this clause.

Functional change

Stylistic rewording

Explanatory update

4.2.6 Usage with no or limited vocal capability

Where ICT requires vocal input from users, the ICT provides at least one mode of operation that does not require them to generate vocal output. This is essential users with no or limited vocal capability and benefits many more users in different situations.

NOTE 1: Vocal output includes speech and other orally generated sounds, such as whistles and clicks.

NOTE 2: Keyboard, pen or touch user interfaces may contribute towards meeting this clause.

302.7 With Limited Manipulation

Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that does not require fine motor control or simultaneous manual operations.¹

4.2.7 Usage with limited manipulation or strength

Where ICT requires manual actions, some users will need the ICT to provide features that enable users to make use of the ICT through alternative actions not requiring manipulation or hand strength.

NOTE 1: Examples of operations that users may not be able to perform include those that require fine motor control, path dependant gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.

NOTE 2: One-handed operation, sequential key entry and speech user interfaces may contribute towards meeting this clause.

NOTE 3: Some users have limited hand strength and may not be able to achieve the level of strength to perform an operation. Alternative user interface solutions that do not require hand strength may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.7 Usage with limited manipulation or strength

Where ICT requires manual actions, some users will need the ICT to provide features that enable users to make use of the ICT through alternative actions not requiring manipulation or hand strength.

NOTE 1: Examples of operations that users may not be able to perform include those that require fine motor control, path dependant gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.

NOTE 2: One-handed operation, sequential key entry and speech user interfaces may contribute towards meeting this clause.

NOTE 3: Some users have limited hand strength and may not be able to achieve the level of strength to perform an operation. Alternative user interface solutions that do not require hand strength may contribute towards meeting this clause.

4.2.7 Usage with limited manipulation or strength

Where ICT requires manual actions, the ICT provides features that enable users to make use of the ICT through alternative actions not requiring manipulation, simultaneous action or hand strength. This is essential for users with limited manipulation or strength and benefits many more users in different situations.

NOTE 1: Examples of operations that users may not be able to perform include those that require fine motor control, path dependant gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.

NOTE 2: One-handed operation, sequential key entry and speech user interfaces may contribute towards meeting this clause.

NOTE 3: Some users have limited hand strength and may not be able to achieve the level of strength to perform an operation. Alternative user interface solutions that do not require hand strength may contribute towards meeting this clause.

Stylistic rewording

Functional change

Explanatory update

4.2.7 Usage with limited manipulation or strength

Where ICT requires manual actions, the ICT provides features that enable users to make use of the ICT through alternative actions not requiring manipulation, simultaneous action or hand strength. This is essential for users with limited manipulation or strength and benefits many more users in different situations.

NOTE 1: Examples of operations that users may not be able to perform include those that require fine motor control, path dependant gestures, pinching, twisting of the wrist, tight grasping, or simultaneous manual actions.

NOTE 2: One-handed operation, sequential key entry and speech user interfaces may contribute towards meeting this clause.

NOTE 3: Some users have limited hand strength and may not be able to achieve the level of strength to perform an operation. Alternative user interface solutions that do not require hand strength may contribute towards meeting this clause.

302.8 With Limited Reach and Strength

Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that is operable with limited reach and limited strength.²

4.2.8 Usage with limited reach

Where ICT products are free-standing or installed, the operational elements will need to be within reach of all users.

NOTE: Considering the needs of wheelchair users and the range of user statures in the placing of operational elements of the user interface may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.8 Usage with limited reach

Where ICT products are free-standing or installed, the operational elements will need to be within reach of all users.

NOTE: Considering the needs of wheelchair users and the range of user statures in the placing of operational elements of the user interface may contribute towards meeting this clause.

4.2.8 Usage with limited reach

Where ICT products are free-standing or installed, all the elements required for operation will need to be within reach of all users. This is essential for users with limited reach and benefits many more users in different situations.

NOTE: Considering the needs of wheelchair users and the range of user statures in the placing of operational elements of the user interface may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.8 Usage with limited reach

Where ICT products are free-standing or installed, all the elements required for operation will need to be within reach of all users. This is essential for users with limited reach and benefits many more users in different situations.

NOTE: Considering the needs of wheelchair users and the range of user statures in the placing of operational elements of the user interface may contribute towards meeting this clause.

302.9 With Limited Language, Cognitive, and Learning Abilities

ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier.

4.2.10 Usage with limited cognition

Some users will need the ICT to provide features that make it simpler and easier to use.

NOTE 1: This clause is intended to include the needs of persons with limited cognitive, language and learning abilities.

NOTE 2: Adjustable timings, error indication and suggestion, and a logical focus order are examples of design features that may contribute towards meeting this clause.

Stylistic rewording

Explanatory update

4.2.10 Usage with limited cognition

Some users will need the ICT to provide features that make it simpler and easier to use.

NOTE 1: This clause is intended to include the needs of persons with limited cognitive, language and learning abilities.

NOTE 2: Adjustable timings, error indication and suggestion, and a logical focus order are examples of design features that may contribute towards meeting this clause.

4.2.10 Usage with limited cognition, language or learning

The ICT provides features and/or presentation that makes it simpler and easier to understand, operate and use. This is essential for users with limited cognition, language or learning, and benefits many more users in different situations.

NOTE 1: Adjustable timings, error indication and suggestion, and a logical focus order are examples of design features that may contribute towards meeting this clause.

NOTE 2: Providing an audio output of the text is an example of providing support for people with limited reading abilities.

NOTE 3: Providing spelling aid and word prediction of the text is an example of providing support for people with limited writing abilities.

NOTE 4: Interaction with content can be made easier, and less prone to errors, by presenting tasks in steps that are easy to follow.

Functional change

Stylistic rewording

Explanatory update

4.2.10 Usage with limited cognition, language or learning

The ICT provides features and/or presentation that makes it simpler and easier to understand, operate and use. This is essential for users with limited cognition, language or learning, and benefits many more users in different situations.

NOTE 1: Adjustable timings, error indication and suggestion, and a logical focus order are examples of design features that may contribute towards meeting this clause.

NOTE 2: Providing an audio output of the text is an example of providing support for people with limited reading abilities.

NOTE 3: Providing spelling aid and word prediction of the text is an example of providing support for people with limited writing abilities.

NOTE 4: Interaction with content can be made easier, and less prone to errors, by presenting tasks in steps that are easy to follow.

402.1 General

ICT with closed functionality shall be operable without requiring the user to attach or install assistive technology other than personal headsets or other audio couplers, and shall conform to 402.

5.1.2.2 Assistive technology

Where ICT has closed functionality, that closed functionality shall be operable without requiring the user to attach, connect or install assistive technology and shall conform to the generic requirements of clauses 5.1.3 to 5.1.7 as applicable. Personal headsets and induction loops shall not be classed as assistive technology for the purpose of this clause.

Stylistic rewording

Explanatory update

5.1.2.2 Assistive technology

Where ICT has closed functionality, that closed functionality shall be operable without requiring the user to attach, connect or install assistive technology and shall conform to the generic requirements of clauses 5.1.3 to 5.1.6 as applicable. Personal headsets and personal induction loops shall not be classed as assistive technology for the purpose of this clause.

5.1.2.2 Assistive technology

Where ICT has closed functionality, that closed functionality shall be operable without requiring the user to attach, connect or install assistive technology and shall conform to the generic requirements of clauses 5.1.3 to 5.1.6 as applicable. Personal headsets and personal induction loops shall not be classed as assistive technology for the purpose of this clause.

402.2 Speech-Output Enabled

ICT with a display screen shall be speech-output enabled for full and independent use by individuals with vision impairments.³

EXCEPTIONS:

1. Variable message signs conforming to 402.5 shall not be required to be speech-output enabled.
2. Speech output shall not be required where ICT display screens only provide status indicators and those indicators conform to 409.
3. Where speech output cannot be supported due to constraints in available memory or processor capability, ICT shall be permitted to conform to 409 in lieu of 402.2.
4. Audible tones shall be permitted instead of speech output where the content of user input is not displayed as entered for security purposes, including, but not limited to, asterisks representing personal identification numbers.
5. Speech output shall not be required for: the machine location; date and time of transaction; customer account number; and the machine identifier or label.
6. Speech output shall not be required for advertisements and other similar information unless they convey information that can be used for the transaction being conducted.

5.1.3.1 General

Where visual information is needed to enable the use of those functions of ICT that are closed to assistive technologies for screen reading, ICT shall provide at least one mode of operation using non-visual access to enable the use of those functions.

NOTE 1: Non-visual access may be in an audio form, including speech, or a tactile form.

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.

Stylistic rewording

Explanatory update

5.1.3.1 General

Where visual information is needed to enable the use of those functions of ICT that are closed to assistive technologies for screen reading, ICT shall provide at least one mode of operation using non-visual access to enable the use of those functions.

NOTE 1: Non-visual access may be in an audio form, including speech, or a tactile form.

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.

5.1.3.1 Audio output of visual information

Where visual information is needed to enable the use of those functions of ICT that are closed to assistive technologies for screen reading, ICT shall provide at least one mode of operation using non-visual access to enable the use of those functions.

NOTE 1: Non-visual access may be in an audio form, including speech, or a tactile form such as braille for deaf-blind users.

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.

5.1.3.1 Audio output of visual information

Where visual information is needed to enable the use of those functions of ICT that are closed to assistive technologies for screen reading, ICT shall provide at least one mode of operation using non-visual access to enable the use of those functions.

NOTE 1: Non-visual access may be in an audio form, including speech, or a tactile form such as braille for deaf-blind users.

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.

402.2.1 Information Displayed On-Screen

Speech output shall be provided for all information displayed on-screen.

5.1.3.6 Speech output for non-text content

Where ICT presents non-text content, the alternative for non-text content shall be presented to users via speech output unless the non-text content is pure decoration or is used only for visual formatting. The speech output for non-text content shall follow the guidance for "text alternative" described in WCAG 2.0 Success Criterion 1.1.1.

Stylistic rewording

Explanatory update

5.1.3.6 Speech output for non-text content

Where ICT presents non-text content, the alternative for non-text content shall be presented to users via speech output unless the non-text content is pure decoration or is used only for visual formatting. The speech output for non-text content shall follow the guidance for "text alternative" described in WCAG 2.1 Success Criterion 1.1.1.

5.1.3.6 Speech output for non-text content

Where ICT presents non-text content, the alternative for non-text content shall be presented to users via speech output unless the non-text content is pure decoration or is used only for visual formatting. The speech output for non-text content shall follow the guidance for "text alternative" described in WCAG 2.1 Success Criterion 1.1.1.

5.1.3.6 Speech output for non-text content

Where ICT presents non-text content, the alternative for non-text content shall be presented to users via speech output unless the non-text content is pure decoration or is used only for visual formatting. The speech output for non-text content shall follow the guidance for "text alternative" described in WCAG 2.1 [5] Success Criterion 1.1.1.

5.1.3.7 Speech output for video information

Where pre-recorded video content is needed to enable the use of closed functions of ICT and where speech output is provided as non-visual access to closed functionality, the speech output shall present equivalent information for the pre-recorded video content.

NOTE: This speech output can take the form of an audio description or an auditory transcript of the video content.

Stylistic rewording

Explanatory update

5.1.3.7 Speech output for video information

Where pre-recorded video content is needed to enable the use of closed functions of ICT and where speech output is provided as non-visual access to closed functionality, the speech output shall present equivalent information for the pre-recorded video content.

NOTE: This speech output can take the form of an audio description or an auditory transcript of the video content.

5.1.3.7 Speech output for video information

Where pre-recorded video content is needed to enable the use of closed functions of ICT and where speech output is provided as non-visual access to closed functionality, the speech output shall present equivalent information for the pre-recorded video content.

NOTE: This speech output can take the form of an audio description or an auditory transcript of the video content.

5.1.3.7 Speech output for video information

Where pre-recorded video content is needed to enable the use of closed functions of ICT and where speech output is provided as non-visual access to closed functionality, the speech output shall present equivalent information for the pre-recorded video content. NOTE: This speech output can take the form of an audio description or an auditory transcript of the video content.

402.2.1 Information Displayed On-Screen

Speech output shall be provided for all information displayed on-screen.⁴

5.1.3.8 Masked entry

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

Stylistic rewording

Explanatory update

5.1.3.8 Masked entry

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

5.1.3.8 Masked entry

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

5.1.3.8 Masked entry

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

402.2.2 Transactional Outputs

Where transactional outputs are provided, the speech output shall audibly provide all information necessary to verify a transaction.

5.1.3.16 Receipts, tickets, and transactional outputs

Where ICT is closed to visual access and provides receipts, tickets or other outputs as a result of a self-service transaction, speech output shall be provided which shall include all information necessary to complete or verify the transaction. In the case of ticketing machines, printed copies of itineraries and maps shall not be required to be audible.

NOTE: The speech output may be provided by any element of the total ICT system.

Stylistic rewording

Explanatory update

5.1.3.16 Receipts, tickets, and transactional outputs

Where ICT is closed to visual access and provides receipts, tickets or other outputs as a result of a self-service transaction, speech output shall be provided which shall include all information necessary to complete or verify the transaction. In the case of ticketing machines, printed copies of itineraries and maps shall not be required to be audible.

NOTE: The speech output may be provided by any element of the total ICT system.

5.1.3.16 Receipts, tickets, and transactional outputs

Where ICT is closed to visual access and provides receipts, tickets or other outputs as a result of a self-service transaction, speech output shall be provided which shall include all information necessary to complete or verify the transaction. In the case of ticketing machines, printed copies of itineraries and maps shall not be required to be audible.

NOTE: The speech output may be provided by any element of the total ICT system.

5.1.3.16 Receipts, tickets, and transactional outputs

Where ICT is closed to visual access and provides receipts, tickets or other outputs as a result of a self-service transaction, speech output shall be provided which shall include all information necessary to complete or verify the transaction. In the case of ticketing machines, printed copies of itineraries and maps shall not be required to be audible.

NOTE: The speech output may be provided by any element of the total ICT system.

5.1.3.2 Auditory output delivery including speech

Where auditory output is provided as non-visual access to closed functionality, the auditory output shall be delivered:

1. either directly by a mechanism included in or provided with the ICT;
2. or by a personal headset that can be connected through a 3,5 mm audio jack, or an industry standard connection, without requiring the use of vision.

NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, a built-in handset/headset, or other industry standard coupled peripheral.

NOTE 2: An industry standard connection could be a wireless connection.

NOTE 3: Some users may benefit from the provision of an inductive loop.

Stylistic rewording

Explanatory update

5.1.3.2 Auditory output delivery including speech

Where auditory output is provided as non-visual access to closed functionality, the auditory output shall be delivered:

1. either directly by a mechanism included in or provided with the ICT; or
2. by a personal headset that can be connected through a 3,5 mm audio jack, or an industry standard connection, without requiring the use of vision.

NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, a built-in handset/headset, or other industry standard coupled peripheral.

NOTE 2: An industry standard connection could be a wireless connection.

NOTE 3: Some users may benefit from the provision of an inductive loop.

5.1.3.2 Auditory output delivery including speech

Where auditory output is provided as non-visual access to closed functionality, the auditory output shall be delivered:

1. either directly by a mechanism included in or provided with the ICT; or
2. by a personal headset that can be connected through a 3,5 mm audio jack, or an industry standard connection, without requiring the use of vision.

NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, a built-in handset/headset, or other industry standard coupled peripheral.

NOTE 2: An industry standard connection could be a wireless connection.

NOTE 3: Some users may benefit from the provision of an inductive loop.

5.1.3.2 Auditory output delivery including speech

Where auditory output is provided as non-visual access to closed functionality, the auditory output shall be delivered:

1. either directly by a mechanism included in or provided with the ICT; or
2. by a personal headset that can be connected through a 3,5 mm audio jack, or an industry standard connection, without requiring the use of vision.

NOTE 1: Mechanisms included in or provided with ICT may be, but are not limited to, a loudspeaker, a built-in handset/headset, or other industry standard coupled peripheral.

NOTE 2: An industry standard connection could be a wireless connection.

NOTE 3: Some users may benefit from the provision of an inductive loop.

402.2.3 Speech Delivery Type and Coordination

Speech output shall be delivered through a mechanism that is readily available to all users, including, but not limited to, an industry standard connector or a telephone handset. Speech shall be recorded or digitized human, or synthesized. Speech output shall be coordinated with information displayed on the screen.

5.1.3.3 Auditory output correlation

Where auditory output is provided as non-visual access to closed functionality, and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

Stylistic rewording

Explanatory update

5.1.3.3 Auditory output correlation

Where auditory output is provided as non-visual access to closed functionality, and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

5.1.3.3 Auditory output correlation

Where auditory output is provided as non-visual access to closed functionality, and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

5.1.3.3 Auditory output correlation

Where auditory output is provided as non-visual access to closed functionality, and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

402.2.4 User Control

Speech output for any single function shall be automatically interrupted when a transaction is selected. Speech output shall be capable of being repeated and paused.

5.1.3.4 Speech output user control

Where 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: It is best practice to allow the user to pause speech output rather than just allowing them to interrupt it.

NOTE 2: It is best practice to allow the user to repeat only the most recent portion rather than requiring play to start from the beginning.

Stylistic rewording

Explanatory update

5.1.3.4 Speech output user control

Where 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: It is best practice to allow the user to pause speech output rather than just allowing them to interrupt it.

NOTE 2: It is best practice to allow the user to repeat only the most recent portion rather than requiring play to start from the beginning.

5.1.3.4 Speech output user control

Where 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: It is best practice to allow the user to pause speech output rather than just allowing them to interrupt it.

NOTE 2: It is best practice to allow the user to repeat only the most recent portion rather than requiring play to start from the beginning.

5.1.3.4 Speech output user control

Where 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: It is best practice to allow the user to pause speech output rather than just allowing them to interrupt it.

NOTE 2: It is best practice to allow the user to repeat only the most recent portion rather than requiring play to start from the beginning.

402.2.4 User Control

Speech output for any single function shall be automatically interrupted when a transaction is selected. Speech output shall be capable of being repeated and paused.

5.1.3.5 Speech output automatic interruption

Where speech output is provided as non-visual access to closed functionality, the ICT shall interrupt current speech output when a user action occurs and when new speech output begins.

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

Stylistic rewording

Explanatory update

5.1.3.5 Speech output automatic interruption

Where speech output is provided as non-visual access to closed functionality, the ICT shall interrupt current speech output when a user action occurs and when new speech output begins.

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

5.1.3.5 Speech output automatic interruption

Where speech output is provided as non-visual access to closed functionality, the ICT shall interrupt current speech output when a user action occurs and when new speech output begins.

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

5.1.3.5 Speech output automatic interruption

Where speech output is provided as non-visual access to closed functionality, the ICT shall interrupt current speech output when a user action occurs and when new speech output begins.

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

402.2.5 Braille Instructions

Where speech output is required by 402.2, braille instructions for initiating the speech mode of operation shall be provided. Braille shall be contracted and shall conform to 36 CFR part 1191, Appendix D, Section 703.3.1.

EXCEPTION: Devices for personal use shall not be required to conform to 402.2.5.

8.5 Tactile indication of speech mode

Where ICT is designed for shared use and speech output is available, a tactile indication of the means to initiate the speech mode of operation shall be provided.

NOTE: The tactile indication could include Braille instructions.

Stylistic rewording

Explanatory update

Functional change

8.5 Tactile indication of speech mode

Where ICT is designed for shared use and speech output is available, a tactile indication of the means to initiate the speech mode of operation shall be provided.

NOTE: The tactile indication could include Braille instructions.

8.5 Tactile indication of speech mode

Where ICT is designed for shared use and speech output is available, a tactile indication of the means to initiate the speech mode of operation shall be provided.

NOTE: The tactile indication could include Braille instructions.

8.5 Tactile indication of speech mode

Where ICT is designed for shared use and speech output is available, a tactile indication of the means to initiate the speech mode of operation shall be provided.

NOTE: The tactile indication could include Braille instructions.

402.3.1 Private Listening

Where ICT provides private listening, it shall provide a mode of operation for controlling the volume. Where ICT delivers output by an audio transducer typically held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided.

5.1.3.11 Private listening volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through a mechanism for private listening, ICT shall provide at least one non-visual mode of operation for controlling the volume.

Stylistic rewording

Explanatory update

5.1.3.11 Private listening volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through a mechanism for private listening, ICT shall provide at least one non-visual mode of operation for controlling the volume.

5.1.3.11 Private listening volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through a mechanism for private listening, ICT shall provide at least one non-visual mode of operation for controlling the volume.

5.1.3.11 Private listening volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through a mechanism for private listening, ICT shall provide at least one non-visual mode of operation for controlling the volume.

402.3.1 Private Listening

Where ICT provides private listening, it shall provide a mode of operation for controlling the volume. Where ICT delivers output by an audio transducer typically held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided.⁵

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear and which carries the "T" symbol specified in ETS 300 381, it shall provide a means of magnetic coupling which meets the requirements of ES 200 381-1.

NOTE: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

Stylistic rewording

Explanatory update

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear and which carries the "T" symbol specified in ETSI ETS 300 381, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1.

NOTE: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1 and shall carry the "T" symbol specified in ETSI ETS 300 381.

NOTE 1: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

NOTE 2: Magnetic coupling is also known as inductive coupling for T-coil.

Stylistic rewording

Explanatory update

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1 [2] and shall carry the "T" symbol specified in ETSI ETS 300 381 [1].

NOTE 1: ICT fulfilling the requirements of TIA-1083-A [i.24] is deemed to comply with the requirements of this clause. NOTE 2: Magnetic coupling is also known as inductive coupling for T-coil.

402.3.1 Private Listening

Where ICT provides private listening, it shall provide a mode of operation for controlling the volume. Where ICT delivers output by an audio transducer typically held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided.⁶

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

Stylistic rewording

Explanatory update

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2 [3].

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 [i.1] is deemed to comply with the requirements of this clause.

402.3.2 Non-private Listening

Where ICT provides non-private listening, incremental volume control shall be provided with output amplification up to a level of at least 65 dB. A function shall be provided to automatically reset the volume to the default level after every use.

5.1.3.12 Speaker volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through speakers on 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, 65dBA may not be sufficient.

5.1.3.12 Speaker volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through speakers on 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.

5.1.3.12 Speaker volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through speakers on 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.

5.1.3.12 Speaker volume

Where auditory output is provided as non-visual access to closed functionality and is delivered through speakers on 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.

5.1.3.13 Volume reset

Where auditory output is provided as non-visual access to closed functionality, a function that resets the volume to be at a level of 65 dBA or less after every use, shall be provided, unless the ICT is dedicated to a single user.

NOTE: A feature to disable the volume reset function may be provided in order to enable the single-user exception to be met.

Stylistic rewording

Explanatory update

5.1.3.13 Volume reset

Where auditory output is provided as non-visual access to closed functionality, a function that resets the volume to be at a level of 65 dBA or less after every use, shall be provided, unless the ICT is dedicated to a single user.

NOTE: A feature to disable the volume reset function may be provided in order to enable the single-user exception to be met.

5.1.3.13 Volume reset

Where auditory output is provided as non-visual access to closed functionality, a function that resets the volume to be at a level of 65 dBA or less after every use, shall be provided, unless the ICT is dedicated to a single user.

NOTE: A feature to disable the volume reset function may be provided in order to enable the single-user exception to be met.

5.1.3.13 Volume reset

Where auditory output is provided as non-visual access to closed functionality, a function that resets the volume to be at a level of 65 dBA or less after every use, shall be provided, unless the ICT is dedicated to a single user.

NOTE: A feature to disable the volume reset function may be provided in order to enable the single-user exception to be met.

402.4 Characters on Display Screens

At least one mode of characters displayed on the screen shall be in a sans serif font. Where ICT does not provide a screen enlargement feature, characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”. Characters shall contrast with their background with either light characters on a dark background or dark characters on a light background.⁷

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

Stylistic rewording

Explanatory update

Functional change

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE 1: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

Explanatory update

Functional change

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

5.1.4 Functionality closed to text enlargement

Where any functionality of 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 a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

The subtended angle, in degrees, may be calculated from:

Ψ = (180 x H) / (π x D)

Where:

• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units

NOTE 1: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

403.1 General Biometrics shall not be the only means for user identification or control.

EXCEPTION: Where at least two biometric options that use different biological characteristics are provided, ICT shall be permitted to use biometrics as the only means of user identification or control.

5.3 Biometrics

Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as the only means of user identification or for control of ICT.

NOTE 1: Alternative means of user identification or for control of ICT could be non-biometric or biometric.

NOTE 2: Biometric methods based on dissimilar biological characteristics increase the likelihood that individuals with disabilities possess at least one of the specified biological characteristics. Examples of dissimilar biological characteristics are fingerprints, eye retinal patterns, voice, and face.

Stylistic rewording

Explanatory update

5.3 Biometrics

Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as the only means of user identification or for control of ICT.

NOTE 1: Alternative means of user identification or for control of ICT could be non-biometric or biometric.

NOTE 2: Biometric methods based on dissimilar biological characteristics increase the likelihood that individuals with disabilities possess at least one of the specified biological characteristics. Examples of dissimilar biological characteristics are fingerprints, eye retinal patterns, voice, and face.

5.3 Biometrics

Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as the only means of user identification or for control of ICT.

NOTE 1: Alternative means of user identification or for control of ICT could be non-biometric or biometric.

NOTE 2: Biometric methods based on dissimilar biological characteristics increase the likelihood that individuals with disabilities possess at least one of the specified biological characteristics. Examples of dissimilar biological characteristics are fingerprints, eye retinal patterns, voice, and face.

5.3 Biometrics

Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as the only means of user identification or for control of ICT.

NOTE 1: Alternative means of user identification or for control of ICT could be non-biometric or biometric.

NOTE 2: Biometric methods based on dissimilar biological characteristics increase the likelihood that individuals with disabilities possess at least one of the specified biological characteristics.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

405.1 General

The same degree of privacy of input and output shall be provided to all individuals. When speech output required by 402.2 is enabled, the screen shall not blank automatically.⁹

5.1.3.9 Private access to personal data

Where auditory output is provided as non-visual access to closed functionality, and the 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: This requirement 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 2: 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.

Stylistic rewording

Explanatory update

5.1.3.9 Private access to personal data

Where auditory output is provided as non-visual access to closed functionality, and the 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: This requirement 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 2: 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.

5.1.3.9 Private access to personal data

Where auditory output is provided as non-visual access to closed functionality, and the 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: This requirement 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 2: 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.

5.1.3.9 Private access to personal data

Where auditory output is provided as non-visual access to closed functionality, and the 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: This requirement 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 2: 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.

5.1.3.8 Masked entry

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

Stylistic rewording

Explanatory update

5.1.3.8 Masked entry

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

5.1.3.8 Masked entry

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

5.1.3.8 Masked entry

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

8.1.2 Standard connections

Where an ICT provides user input or output device connection points, the ICT shall provide at least one input and/or output connection that conforms to an industry standard non-proprietary format, directly or through the use of commercially available adapters.

NOTE 1: The intent of this requirement is to ensure compatibility with assistive technologies by requiring the use of standard connections on ICT.

NOTE 2: The word connection applies to both physical and wireless connections.

NOTE 3: Current examples of industry standard non-proprietary formats are USB and Bluetooth.

Stylistic rewording

Explanatory update

8.1.2 Standard connections

Where an ICT provides user input or output device connection points, the ICT shall provide at least one input and/or output connection that conforms to an industry standard non-proprietary format, directly or through the use of commercially available adapters.

NOTE 1: The intent of this requirement is to ensure compatibility with assistive technologies by requiring the use of standard connections on ICT.

NOTE 2: The word connection applies to both physical and wireless connections.

NOTE 3: Current examples of industry standard non-proprietary formats are USB and Bluetooth.

8.1.2 Standard connections

Where an ICT provides user input or output device connection points, the ICT shall provide at least one input and/or output connection that conforms to an industry standard non-proprietary format, directly or through the use of commercially available adapters.

NOTE 1: The intent of this requirement is to ensure compatibility with assistive technologies by requiring the use of standard connections on ICT.

NOTE 2: The word connection applies to both physical and wireless connections.

NOTE 3: Current examples of industry standard non-proprietary formats are USB and Bluetooth.

8.1.2 Standard connections

Where an ICT provides user input or output device connection points, the ICT shall provide at least one input and/or output connection that conforms to an industry standard non-proprietary format, directly or through the use of commercially available adapters.

NOTE 1: The intent of this requirement is to ensure compatibility with assistive technologies by requiring the use of standard connections on ICT.

NOTE 2: The word connection applies to both physical and wireless connections.

NOTE 3: Current examples of industry standard non-proprietary formats are USB and Bluetooth.

407.3.1 Tactilely Discernible

Input controls shall be operable by touch and tactilely discernible without activation.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

Stylistic rewording

Explanatory update

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

407.3.1 Tactilely Discernible

Input controls shall be operable by touch and tactilely discernible without activation.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and that control is visually presented to the user, 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.

Stylistic rewording

Explanatory update

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and that control is visually presented to the user, 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.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and the status of that control is visually presented to the user, 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.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and the status of that control is visually presented to the user, 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.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

Stylistic rewording

Explanatory update

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

5.5.2 Operable parts discernibility

Where ICT has operable parts, it shall provide a means to discern each operable part, without requiring vision and without performing the action associated with the operable part.

NOTE: One way of meeting this requirement is by making the operable parts tactilely discernible.

407.3.3 Numeric Keys

Where provided, numeric keys shall be arranged in a 12-key ascending or descending keypad layout. The number five key shall be tactilely distinct from the other keys. Where the ICT provides an alphabetic overlay on numeric keys, the relationships between letters and digits shall conform to ITU-T Recommendation E.161 (incorporated by reference, see 702.7.1).¹²

8.4.1 Numeric keys

Where provided, physical numeric keys arranged in a rectangular keypad layout shall have the number five key tactilely distinct from the other keys of the keypad.

NOTE: Recommendation ITU-T E.161 describes the 12-key telephone keypad layout and provides further details of the form of tactile markers.

Stylistic rewording

Explanatory update

8.4.1 Numeric keys

Where provided, physical numeric keys arranged in a rectangular keypad layout shall have the number five key tactilely distinct from the other keys of the keypad.

NOTE: Recommendation ITU-T E.161 describes the 12-key telephone keypad layout and provides further details of the form of tactile markers.

8.4.1 Numeric keys

Where provided, physical numeric keys arranged in a rectangular keypad layout shall have the number five key tactilely distinct from the other keys of the keypad.

NOTE: Recommendation ITU-T E.161 describes the 12-key telephone keypad layout and provides further details of the form of tactile markers.

8.4.1 Numeric keys

Where provided, physical numeric keys arranged in a rectangular keypad layout shall have the number five key tactilely distinct from the other keys of the keypad.

NOTE: Recommendation ITU-T E.161 [i.20] describes the 12-key telephone keypad layout and provides further details of the form of tactile markers.

407.4 Key Repeat

Where a keyboard with key repeat is provided, the delay before the key repeat feature is activated shall be fixed at, or adjustable to, 2 seconds minimum.

5.7: Key repeat

Where ICT with key repeat is provided and the key repeat cannot be turned off:

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.

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

407.6 Operation

At least one mode of operation shall be operable with one hand and shall not require tight grasping, pinching, or twisting of the wrist. The force required to activate operable parts shall be 5 pounds (22.2 N) maximum.

5.5.1 Means of operation

Where ICT has operable parts that require grasping, pinching, or twisting of the wrist to operate, an accessible alternative means of operation that does not require these actions shall be provided.

Stylistic rewording

Explanatory update

5.5.1 Means of operation

Where ICT has operable parts that require grasping, pinching, or twisting of the wrist to operate, an accessible alternative means of operation that does not require these actions shall be provided.

5.5.1 Means of operation

Where ICT has operable parts that require grasping, pinching, or twisting of the wrist to operate, an accessible alternative means of operation that does not require these actions shall be provided.

5.5.1 Means of operation

Where ICT has operable parts that require grasping, pinching, or twisting of the wrist to operate, an accessible alternative means of operation that does not require these actions shall be provided.

8.4.2.1 Means of Operation of mechanical parts

Where a control requires grasping, pinching, or twisting of the wrist to operate it, an accessible alternative means of operation that does not require these actions shall be provided.

Stylistic rewording

Explanatory update

8.4.2.1 Means of operation of mechanical parts

Where a control requires grasping, pinching, or twisting of the wrist to operate it, an accessible alternative means of operation that does not require these actions shall be provided.

8.4.2.1 Means of operation of mechanical parts

Where a control requires grasping, pinching, or twisting of the wrist to operate it, an accessible alternative means of operation that does not require these actions shall be provided.

8.4.2.1 Means of operation of mechanical parts

Where a control requires grasping, pinching, or twisting of the wrist to operate it, an accessible alternative means of operation that does not require these actions shall be provided.

8.4.2.2 Force of operation of mechanical parts

Where a control requires a force greater than 22,2 N to operate it, an accessible alternative means of operation that requires a force less than 22,2 N shall be provided.

Stylistic rewording

Explanatory update

8.4.2.2 Force of operation of mechanical parts

Where a control requires a force greater than 22,2 N to operate it, an accessible alternative means of operation that requires a force less than 22,2 N shall be provided.

8.4.2.2 Force of operation of mechanical parts

Where a control requires a force greater than 22,2 N to operate it, an accessible alternative means of operation that requires a force less than 22,2 N shall be provided.

NOTE: ISO 21542:2011: Building Construction - Accessibility and Usability of the Built Environment recommends a value between 2,5 and 5 Newtons.

8.4.2.2 Force of operation of mechanical parts

Where a control requires a force greater than 22,2 N to operate it, an accessible alternative means of operation that requires a force less than 22,2 N shall be provided.

NOTE: ISO 21542:2011 [i.34]: Building Construction - Accessibility and Usability of the Built Environment recommends a value between 2,5 and 5 Newtons.

407.7 Tickets, Fare Cards, and Keycards

Where tickets, fare cards, or keycards are provided, they shall have an orientation that is tactilely discernible if orientation is important to further use of the ticket, fare card, or keycard.

8.4.3 Keys, tickets and fare cards

Where ICT provides keys, tickets or fare cards, and their orientation is important for further use, they shall have an orientation that is tactilely discernible.

NOTE: ETS 300 767 defines suitable tactile indications for plastic cards.

Stylistic rewording

Explanatory update

8.4.3 Keys, tickets and fare cards

Where ICT provides keys, tickets or fare cards, and their orientation is important for further use, they shall have an orientation that is tactilely discernible.

NOTE: ETSI ETS 300 767 defines suitable tactile indications for plastic cards.

8.4.3 Keys, tickets and fare cards

Where ICT provides keys, tickets or fare cards, and their orientation is important for further use, they shall have an orientation that is tactilely discernible.

NOTE: ETSI ETS 300 767 defines suitable tactile indications for plastic cards.

8.4.3 Keys, tickets and fare cards

Where ICT provides keys, tickets or fare cards, and their orientation is important for further use, they shall have an orientation that is tactilely discernible.

NOTE: ETSI ETS 300 767 [i.6] defines suitable tactile indications for plastic cards.

407.8.1.1 Vertical Plane for Side Reach

Where a side reach is provided, the vertical reference plane shall be 48 inches (1220 mm) long minimum.

8.3.2.2 Clear floor or ground space

Where the operating area is integral to the ICT, it should provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

Stylistic rewording

Explanatory update

8.3.2.2 Clear floor or ground space

Where the operating area is integral to the ICT, it should provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

8.3.4.2 Clear floor or ground space

Where stationary ICT has an operating area within it, it shall provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

Numbering change

Stylistic rewording

Functional change

8.3.4.2 Clear floor or ground space

Where stationary ICT has an operating area within it, it shall provide a clear floor area that has the minimum

dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

8.3.2.2 Clear floor or ground space

Where the operating area is integral to the ICT, it should provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

Stylistic rewording

Explanatory update

8.3.2.2 Clear floor or ground space

Where the operating area is integral to the ICT, it should provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

8.3.4.2 Clear floor or ground space

Where stationary ICT has an operating area within it, it shall provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

Numbering change

Stylistic rewording

Functional change

8.3.4.2 Clear floor or ground space

Where stationary ICT has an operating area within it, it shall provide a clear floor area that has the minimum dimensions of 760 mm (30 inches) by 1 220 mm (48 inches) from which to operate the ICT.

407.8.2.1 Unobstructed Side Reach

Where the operable part is located 10 inches (255 mm) or less beyond the vertical reference plane, the operable part shall be 48 inches (1220 mm) high maximum and 15 inches (380 mm) high minimum above the floor.

8.3.3.2.1 Unobstructed high side reach

Where the access space is integral to the ICT, allows a parallel approach, and the side reach is unobstructed or obstructed by an element integral to the ICT which is less than 255 mm (10 inches), all essential controls should be within a high side reach which is less than or equal to 1 220 mm (48 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.2.1 Unobstructed high side reach

Where the access space is integral to the ICT, allows a parallel approach, and the side reach is unobstructed or obstructed by an element integral to the ICT which is less than 255 mm (10 inches), all essential controls should be within a high side reach which is less than or equal to 1 220 mm (48 inches) above the floor of the access space.

8.3.3.1 Unobstructed high side reach

Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT and which is less than 255 mm (10 inches), at least one of each type of operable part shall be within a high side reach which is less than or equal to 1 220 mm (48 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.3.1 Unobstructed high side reach

Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT and which is less than 255 mm (10 inches), at least one of each type of operable part shall be within a high side reach which is less than or equal to 1 220 mm (48 inches) above the floor of the access space.

8.3.3.2.2 Unobstructed low side reach

Where the access space is integral to the ICT, allows a parallel approach, and the side reach is unobstructed or obstructed by an element integral to the ICT which is less than 255 mm (10 inches), all essential controls should be within a low side reach which is greater than or equal to 380 mm (15 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.2.2 Unobstructed low side reach

Where the access space is integral to the ICT, allows a parallel approach, and the side reach is unobstructed or obstructed by an element integral to the ICT which is less than 255 mm (10 inches), all essential controls should be within a low side reach which is greater than or equal to 380 mm (15 inches) above the floor of the access space.

8.3.3.2 Unobstructed low side reach

Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT and which is less than 255 mm (10 inches), at least one of each type of operable part shall be within a low side reach which is greater than or equal to 380 mm (15 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

Explanatory update

8.3.3.2 Unobstructed low side reach

Where the side reach is unobstructed or obstructed by an element that is an integral part of the stationary ICT and which is less than 255 mm (10 inches), at least one of each type of operable part shall be within a low side reach which is greater than or equal to 380 mm (15 inches) above the floor of the access space.

407.8.2.2 Obstructed Side Reach

Where the operable part is located more than 10 inches (255 mm), but not more than 24 inches (610 mm), beyond the vertical reference plane, the height of the operable part shall be 46 inches (1170 mm) high maximum and 15 inches (380 mm) high minimum above the floor. The operable part shall not be located more than 24 inches (610 mm) beyond the vertical reference plane.

8.3.3.2.3.1 Obstructed (<= 255 mm) side reach

Where the access space is integral to the ICT, allows a parallel approach and has an obstruction which is integral to the ICT, the height of the obstruction should be less than 865 mm (34 inches). Where the depth of the obstruction is less than or equal to 255 mm (10 inches), the high side reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.2.3.1 Obstructed (<= 255 mm) side reach

Where the access space is integral to the ICT, allows a parallel approach and has an obstruction which is integral to the ICT, the height of the obstruction should be less than 865 mm (34 inches). Where the depth of the obstruction is less than or equal to 255 mm (10 inches), the high side reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor of the access space.

8.3.3.3.1 Obstructed (<= 255 mm) side reach

Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall be less than 865 mm (34 inches). Where the depth of the obstruction is less than or equal to 255 mm (10 inches), the high side reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.3.3.1 Obstructed (≤ 255 mm) side reach

Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall be less than 865 mm (34 inches). Where the depth of the obstruction is less than or equal to 255 mm (10 inches), the high side reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor of the access space.

407.8.2.2 Obstructed Side Reach

Where the operable part is located more than 10 inches (255 mm), but not more than 24 inches (610 mm), beyond the vertical reference plane, the height of the operable part shall be 46 inches (1170 mm) high maximum and 15 inches (380 mm) high minimum above the floor. The operable part shall not be located more than 24 inches (610 mm) beyond the vertical reference plane.

8.3.3.2.3.2 Obstructed (<= 610 mm) side reach

Where the access space is integral to the ICT, allows a parallel approach and has an obstruction which is integral to the ICT, the height of the obstruction should be less than 865 mm (34 inches). Where the depth of the obstruction is greater than 255 mm (10 inches) and 610 mm (24 inches) maximum, the high side reach to all essential controls should be no higher than 1 170 mm (46 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.2.3.2 Obstructed (<= 610 mm) side reach

Where the access space is integral to the ICT, allows a parallel approach and has an obstruction which is integral to the ICT, the height of the obstruction should be less than 865 mm (34 inches). Where the depth of the obstruction is greater than 255 mm (10 inches) with a maximum depth of 610 mm (24 inches), the high side reach to all essential controls should be no higher than 1 170 mm (46 inches) above the floor of the access space.

8.3.3.3.2 Obstructed (<= 610 mm) side reach

Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall be less than 865 mm (34 inches). Where the depth of the obstruction is greater than 255 mm (10 inches) with a maximum depth of 610 mm (24 inches), the high side reach to at least one of each type of operable part shall be no higher than 1 170 mm (46 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

Explanatory update

8.3.3.3.2 Obstructed (≤ 610 mm) side reach

Where stationary ICT has an obstruction which is an integral part of the ICT, the height of the obstruction shall be less than 865 mm (34 inches). Where the depth of the obstruction is greater than 255 mm (10 inches) with a maximum depth of 610 mm (24 inches), the high side reach to at least one of each type of operable part shall be no higher than 1 170 mm (46 inches) above the floor of the access space.

407.8.3 Forward Reach

Operable parts of ICT providing a forward reach shall conform to 407.8.3.1 or 407.8.3.2. The vertical reference plane shall be centered, and intersect with, the operable part. Where a forward reach allows a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum.

8.3.3.1.1 Unobstructed high forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no higher than 1 220 mm (48 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.1 Unobstructed high forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no higher than 1 220 mm (48 inches) above the floor of the access space.

8.3.2.1 Unobstructed high forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no higher than 1 220 mm (48 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

8.3.2.1 Unobstructed high forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no higher than 1 220 mm (48 inches) above the floor of the access space.

407.8.3 Forward Reach

Operable parts of ICT providing a forward reach shall conform to 407.8.3.1 or 407.8.3.2. The vertical reference plane shall be centered, and intersect with, the operable part. Where a forward reach allows a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum.

8.3.3.1.2 Unobstructed low forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no lower than 380 mm (15 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.2 Unobstructed low forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no lower than 380 mm (15 inches) above the floor of the access space.

8.3.2.2 Unobstructed low forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no lower than 380 mm (15 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

8.3.2.2 Unobstructed low forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no lower than 380 mm (15 inches) above the floor of the access space.

407.8.3 Forward Reach

Operable parts of ICT providing a forward reach shall conform to 407.8.3.1 or 407.8.3.2. The vertical reference plane shall be centered, and intersect with, the operable part. Where a forward reach allows a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum.

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory

Functional change

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

407.8.3 Forward Reach

Operable parts of ICT providing a forward reach shall conform to 407.8.3.1 or 407.8.3.2. The vertical reference plane shall be centered, and intersect with, the operable part. Where a forward reach allows a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum.

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

8.3.3.1.1 Unobstructed high forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no higher than 1 220 mm (48 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.1.1 Unobstructed high forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no higher than 1 220 mm (48 inches) above the floor of the access space.

8.3.2.1 Unobstructed high forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no higher than 1 220 mm (48 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

8.3.2.1 Unobstructed high forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no higher than 1 220 mm (48 inches) above the floor of the access space.

8.3.3.1.2 Unobstructed low forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no lower than 380 mm (15 inches) above the floor of the access space.

Stylistic rewording

Explanatory update

8.3.3.1.2 Unobstructed low forward reach

Where the access space is integral to the ICT and the forward reach is unobstructed, the essential controls should be located no lower than 380 mm (15 inches) above the floor of the access space.

8.3.2.2 Unobstructed low forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no lower than 380 mm (15 inches) above the floor of the access space.

Numbering change

Stylistic rewording

Functional change

8.3.2.2 Unobstructed low forward reach

Where no part of the stationary ICT obstructs the forward reach, at least one of each type of operable part shall be located no lower than 380 mm (15 inches) above the floor of the access space.

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory

Functional change

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is less than 510 mm (20 inches), the forward reach to all essential controls should be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory

Functional change

8.3.2.3.2 Obstructed (< 510 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is less than 510 mm (20 inches), the forward reach to at least one of each type of operable part shall be no higher than 1 220 mm (48 inches) above the floor contact of the ICT.

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Stylistic rewording

Explanatory update

Functional change

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

Where the access space is integral to the ICT and has an obstruction which is integral to the ICT and which is greater than 510 mm (20 inches) and less than 635 mm (25 inches) maximum, the forward reach to all essential controls should be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.2.3.3 Obstructed (< 635 mm) forward reach

Where the stationary ICT has an obstruction which is an integral part of the ICT and which is not less than 510 mm (20 inches) but is less than 635 mm (25 inches) maximum, the forward reach to at least one of each type of operable part shall be no higher than 1 120 mm (44 inches) above the floor contact of the ICT.

407.8.3.2.2 Knee and Toe Space under ICT with Obstructed Forward Reach

Knee and toe space under ICT shall be 27 inches (685 mm) high minimum, 25 inches (635 mm) deep maximum, and 30 inches (760 mm) wide minimum and shall be clear of obstructions.

EXCEPTIONS:

1. Toe space shall be permitted to provide a clear height of 9 inches (230 mm) above the floor and a clear depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT.
2. At a depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT, space between 9 inches (230 MM) and 27 inches (685 mm) minimum above the floor shall be permitted to reduce at a rate of 1 inch (25 mm) in depth for every 6 inches (150 mm) in height.¹³

8.3.2.4 Knee and toe clearance width

Where the space under an obstacle that is integral to the ICT is part of access space, the clearance should be at least 760 mm (30 inches) wide.

Stylistic rewording

Explanatory update

8.3.2.4 Knee and toe clearance width

Where the space under an obstacle that is integral to the ICT is part of access space, the clearance should be at least 760 mm (30 inches) wide.

8.3.2.4 Knee and toe clearance width

Where the space under an obstacle that is an integral part of the stationary ICT is part of access space, the clearance shall be at least 760 mm (30 inches) wide.

Stylistic rewording

Functional change

8.3.2.4 Knee and toe clearance width

Where the space under an obstacle that is an integral part of the stationary ICT is part of access space, the clearance shall be at least 760 mm (30 inches) wide.

407.8.3.2.2 Knee and Toe Space under ICT with Obstructed Forward Reach Knee and toe space under ICT shall be 27 inches (685 mm) high minimum, 25 inches (635 mm) deep maximum, and 30 inches (760 mm) wide minimum and shall be clear of obstructions.

EXCEPTIONS:

1. Toe space shall be permitted to provide a clear height of 9 inches (230 mm) above the floor and a clear depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT.
2. At a depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT, space between 9 inches (230 mm) and 27 inches (685 mm) minimum above the floor shall be permitted to reduce at a rate of 1 inch (25 mm) in depth for every 6 inches (150 mm) in height.¹⁴

8.3.2.5 Toe clearance

Where an obstacle is integral to the ICT, a space under the obstacle that is less than 230 mm (9 inches) above the floor is considered toe clearance and should:

1. extend 635 mm (25 inches) maximum under the whole obstacle;
2. provide a space at least 430 mm (17 inches) deep and 230 mm above the floor under the obstacle;
3. extend no more than150 mm (6 inches) beyond any obstruction at 230 mm (9 inches) above the floor.

Stylistic rewording

Explanatory update

Functional change

8.3.2.5 Toe clearance

Where an obstacle is integral to the ICT, a space under the obstacle that is less than 230 mm (9 inches) above the floor is considered toe clearance and should:

1. extend 635 mm (25 inches) maximum under the whole obstacle;
2. provide a space at least 430 mm (17 inches) deep and 230 mm above the floor under the obstacle;
3. extend no more than 150 mm (6 inches) beyond any obstruction at 230 mm (9 inches) above the floor.

8.3.2.5 Toe clearance

Where an obstacle is an integral part of the stationary ICT, a space under the obstacle that is less than 230 mm (9 inches) above the floor is considered toe clearance and shall:

1. extend 635 mm (25 inches) maximum under the whole obstacle;
2. provide a space at least 430 mm (17 inches) deep and 230 mm (9 inches) above the floor under the obstacle;
3. extend no more than 150 mm (6 inches) beyond any obstruction at 230 mm (9 inches) above the floor.

Stylistic rewording

Functional change

Explanatory update

8.3.2.5 Toe clearance

Where an obstacle is an integral part of the stationary ICT, a space under the obstacle that is less than 230 mm (9 inches) above the floor is considered toe clearance and shall:

1. extend 635 mm (25 inches) maximum under the whole obstacle;
2. provide a space at least 430 mm (17 inches) deep and 230 mm (9 inches) above the floor under the obstacle;
3. extend no more than 150 mm (6 inches) beyond any obstruction at 230 mm (9 inches) above the floor.

407.8.3.2.2 Knee and Toe Space under ICT with Obstructed Forward Reach Knee and toe space under ICT shall be 27 inches (685 mm) high minimum, 25 inches (635 mm) deep maximum, and 30 inches (760 mm) wide minimum and shall be clear of obstructions.

EXCEPTIONS:

1. Toe space shall be permitted to provide a clear height of 9 inches (230 mm) above the floor and a clear depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT.
2. At a depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT, space between 9 inches (230 MM) and 27 inches (685 mm) minimum above the floor shall be permitted to reduce at a rate of 1 inch (25 mm) in depth for every 6 inches (150 mm) in height.¹⁵

8.3.2.6 Knee clearance

Where an obstacle is integral to the ICT, the space under the obstacle that is between 230 mm and 685 mm above the floor is considered knee clearance and should:

1. extend no more than 635 mm (25 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
2. extend at least 280 mm (11 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
3. extend at least 205 mm (8 inches) under the obstacle at a height of 685 mm (27 inches) above the floor;
4. be between 230 mm (9 inches) and 685 mm (27 inches) above the floor be permitted to be reduced in depth at a rate of 25 mm (1 inch) for each 150 mm (6 inches) in height.

Stylistic rewording

Explanatory update

Functional change

8.3.2.6 Knee clearance

Where an obstacle is integral to the ICT, the space under the obstacle that is between 230 mm and 685 mm above the floor is considered knee clearance and should:

1. extend no more than 635 mm (25 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
2. extend at least 280 mm (11 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
3. extend at least 205 mm (8 inches) under the obstacle at a height of 685 mm (27 inches) above the floor;
4. d) be permitted to be reduced in depth at a rate of 25 mm (1 inch) for each 150 mm (6 inches) in height.

8.3.2.6 Knee clearance

Where an obstacle is an integral part of the stationary ICT, the space under the obstacle that is between 230 mm (9 inches) and 685 mm (25 inches)¹⁶ above the floor is considered knee clearance and shall:

1. extend no more than 635 mm (25 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
2. extend at least 280 mm (11 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
3. extend at least 205 mm (8 inches) under the obstacle at a height of 685 mm (27 inches) above the floor;
4. d) be permitted to be reduced in depth at a rate of 25 mm (1 inch) for each 150 mm (6 inches) in height.

Stylistic rewording

Explanatory update

Functional change

8.3.2.6 Knee clearance

Where an obstacle is an integral part of the stationary ICT, the space under the obstacle that is between 230 mm (9 inches) and 685 mm (25 inches) above the floor is considered knee clearance and shall:

1. extend no more than 635 mm (25 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
2. extend at least 280 mm (11 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;
3. extend at least 205 mm (8 inches) under the obstacle at a height of 685 mm (27 inches) above the floor;
4. d) be permitted to be reduced in depth at a rate of 25 mm (1 inch) for each 150 mm (6 inches) in height.

8.3.4 Visibility

Where the operating area is integral to the ICT, and a display screen is provided, information on the screen should be legible from a point located 1 015 mm (40 inches) above the centre of the floor of the operating area (as defined in clause 8.3.2.2).

NOTE: The intent of this provision is that the information on the screen can be read by users with normal vision and appropriate language skills, when seated in a wheelchair.

Stylistic rewording

Explanatory update

8.3.4 Visibility

Where the operating area is integral to the ICT, and a display screen is provided, information on the screen should be legible from a point located 1 015 mm (40 inches) above the centre of the floor of the operating area (as defined in clause 8.3.2.2).

NOTE: The intent of this provision is that the information on the screen can be read by users with normal vision and appropriate language skills, when seated in a wheelchair.

8.3.5 Visibility

Where stationary ICT provides one or more display screens , at least one of each type of display screen shall be positioned such that the information on the screen is legible from a point located 1 015 mm (40 inches) above the centre of the floor of the operating area).

NOTE: The intent of this requirement is that the information on the screen can be read by users with normal vision and appropriate language skills, when seated in a wheelchair.

Numbering change

Stylistic rewording

Functional change

8.3.5 Visibility

Where stationary ICT provides one or more display screens, at least one of each type of display screen shall be positioned such that the information on the screen is legible from a point located 1 015 mm (40 inches) above the centre of the floor of the operating area).

NOTE: The intent of this requirement is that the information on the screen can be read by users with normal vision and appropriate language skills, when seated in a wheelchair.

409.1 General

Where provided, status indicators shall be discernible visually and by touch or sound.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and that control is visually presented to the user, 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.

Stylistic rewording

Explanatory update

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and that control is visually presented to the user, 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.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and the status of that control is visually presented to the user, 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.

5.6.1 Tactile or auditory status

Where ICT has a locking or toggle control and the status of that control is visually presented to the user, 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.

5.6.2 Visual status

Where ICT has a locking or toggle control and the control is non-visually presented to the user, 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.

Stylistic rewording

Explanatory update

5.6.2 Visual status

Where ICT has a locking or toggle control and the control is non-visually presented to the user, 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.

5.6.2 Visual status

Where ICT has a locking or toggle control and the status of the control is non-visually presented to the user, 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.

5.6.2 Visual status

Where ICT has a locking or toggle control and the status of the control is non-visually presented to the user, 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.

8.1.3 Colour

Where the ICT has hardware aspects that use colour, colour shall not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

8.1.3 Colour

Where the ICT has hardware aspects that use colour, colour shall not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

8.1.3 Colour

Where the ICT has hardware aspects that use colour, colour shall not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

8.1.3 Colour

Where the ICT has hardware aspects that use colour, colour shall not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

412.2.1 Volume Gain for Wireline Telephones

Volume gain conforming to 47 CFR 68.317 shall be provided on analog and digital wireline telephones.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

Stylistic rewording

Explanatory update

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

412.2.1 Volume Gain for Wireline Telephones

Volume gain conforming to 47 CFR 68.317 shall be provided on analog and digital wireline telephones.¹⁷

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

Stylistic rewording

Explanatory update

Functional change

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

412.2.2 Volume Gain for Non-Wireline ICT

A method for increasing volume shall be provided for non-wireline ICT.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

Stylistic rewording

Explanatory update

Functional change

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

8.2.1.1 Speech volume range

Where ICT hardware has speech output, it shall provide a means to adjust the speech output volume level over a range of at least 18 dB.

NOTE: Fixed-line handsets and headsets fulfilling the requirements of ANSI/TIA-4965 are deemed to comply with this requirement.

412.2.2 Volume Gain for Non-Wireline ICT

A method for increasing volume shall be provided for non-wireline ICT.¹⁸

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

Stylistic rewording

Explanatory update

Functional change

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

8.2.1.2 Incremental volume control

Where ICT hardware has speech output and its volume control is incremental, it shall provide at least one intermediate step of 12 dB gain above the lowest volume setting.

412.3.1 Wireless Handsets

ICT in the form of wireless handsets shall conform to ANSI/IEEE C63.19-2011 (incorporated by reference, see 702.5.1).¹⁹

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

Stylistic rewording

Explanatory update

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2.

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

8.2.2.2 Wireless communication devices

Where ICT hardware is a wireless communication device with speech output which is normally held to the ear, it shall provide a means of magnetic coupling to hearing technologies which meets the requirements of ETSI ES 200 381-2

NOTE: ICT fulfilling the requirements of ANSI/IEEE C63.19 is deemed to comply with the requirements of this clause.

412.3.2 Wireline Handsets

ICT in the form of wireline handsets, including cordless handsets, shall conform to TIA-1083-B (incorporated by reference, see 702.9.1).²⁰

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear and which carries the "T" symbol specified in ETS 300 381, it shall provide a means of magnetic coupling which meets the requirements of ES 200 381-1.

NOTE: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

Stylistic rewording

Explanatory update

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear and which carries the "T" symbol specified in ETSI ETS 300 381, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1.

NOTE: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1 and shall carry the "T" symbol specified in ETSI ETS 300 381.

NOTE 1: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause.

NOTE 2: Magnetic coupling is also known as inductive coupling for T-coil.

Stylistic rewording

Explanatory update

8.2.2.1 Fixed-line devices

Where ICT hardware is a fixed-line communication device with speech output and which is normally held to the ear, it shall provide a means of magnetic coupling which meets the requirements of ETSI ES 200 381-1 and shall carry the "T" symbol specified in ETSI ETS 300 381.

NOTE 1: ICT fulfilling the requirements of TIA-1083-A is deemed to comply with the requirements of this clause. NOTE 2: Magnetic coupling is also known as inductive coupling for T-coil.

412.4 Digital Encoding of Speech

ICT in IP-based networks shall transmit and receive speech that is digitally encoded in the manner specified by ITU-T Recommendation G.722.2 (incorporated by reference, see 702.7.2) or IETF RFC 6716 (incorporated by reference, see 702.8.1).²¹

6.1: Audio bandwidth for speech (informative recommendation)

Where ICT provides two-way voice communication, in order to provide good audio quality, that ICT should be able to encode and decode two-way voice communication with a frequency range with an upper limit of at least 7 000 Hz.

NOTE 1: For the purposes of interoperability, support of Recommendation ITU-T G.722 is widely used.

NOTE 2: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU-T G.722.2 are sometimes used so as to avoid transcoding.

Stylistic rewording

Explanatory update

Functional change

6.1 Audio bandwidth for speech

Where ICT provides two-way voice communication, in order to provide good audio quality, that ICT shall be able to encode and decode two-way voice communication with a frequency range with an upper limit of at least 7 000 Hz.

NOTE 1: For the purposes of interoperability, support of Recommendation ITU-T G.722 is widely used.

NOTE 2: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU-T G.722.2 are sometimes used so as to avoid transcoding.

6.1 Audio bandwidth for speech

Where ICT provides two-way voice communication, in order to provide good audio quality, that ICT shall be able to encode and decode two-way voice communication with a frequency range with an upper limit of at least 7 000 Hz.

NOTE 1: For the purposes of interoperability, support of Recommendation ITU-T G.722 is widely used.

NOTE 2: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU-T G.722.2 are sometimes used so as to avoid transcoding.

6.1 Audio bandwidth for speech

Where ICT provides two-way voice communication, in order to provide good audio quality, that ICT shall be able to encode and decode two-way voice communication with a frequency range with an upper limit of at least 7 000 Hz.

NOTE 1: For the purposes of interoperability, support of Recommendation ITU-T G.722 is widely used.

NOTE 2: Where codec negotiation is implemented, other standardized codecs such as Recommendation ITU-T G.722.2 are sometimes used so as to avoid transcoding.

6.3: Caller ID

Where ICT provides caller identification and similar tele-communications functions are provided, the caller identification and similar tele-communications functions shall be available in text form and in at least one other modality.

Stylistic rewording

Explanatory update

Functional change

6.3 Caller ID

Where ICT provides caller identification or similar tele-communications functions are provided, the caller identification and similar tele-communications functions shall be available in text form and in at least one other modality.

6.3 Caller ID

Where ICT provides caller identification or similar tele-communications functions, the caller identification and similar tele-communications functions shall be available in text form as well as being programmatically determinable, unless the functionality is closed.

6.3 Caller ID

Where ICT provides caller identification or similar telecommunications functions, the caller identification and similar telecommunications functions shall be available in text form as well as being programmatically determinable, unless the functionality is closed.

6.5.1 General (informative)

Clause 6.5 (Video communications) provides performance requirements that support users who communicate using sign language and lip-reading. For these users, good usability is achieved with Common Intermediate Format (CIF) resolution, a frame rate of 20 frames per second and over, with a time difference between speech audio and video that does not exceed 100 ms.

When the resolution is reduced to Quarter Common Intermediate Format (QCIF) and the frame rate drops to 12 frames per second the communication is still usable with some restrictions.

A lower resolution causes less disturbance to the perception of sign language and lip-reading than that caused by a lower frame rate.

Delay can be a problem in video communication. Overall delay values below 0,4 s are preferred, with an increase in preference down to 0,1 s. Values over 0,8 s are felt to hinder a good sign conversation. Overall delay depends on multiple factors, including e.g. network delay and video processing. For this reason a testable requirement on minimum values for overall delay cannot be produced.

Stylistic rewording

Explanatory update

Functional change

6.5.1 General (informative)

Clause 6.5 (Video communications) provides performance requirements that support users who communicate using sign language and lip-reading. For these users, good usability is achieved with Common Intermediate Format (CIF) resolution, a frame rate of 20 frames per second and over, with a time difference between speech audio and video that does not exceed 100 ms.

When the resolution is reduced to Quarter Common Intermediate Format (QCIF) and the frame rate drops to 12 frames per second the communication is still usable with some restrictions.

A lower resolution causes less disturbance to the perception of sign language and lip-reading than that caused by a lower frame rate.

Delay can be a problem in video communication. Overall delay values below 0,4 s are preferred, with an increase in preference down to 0,1 s. Values over 0,8 s are felt to hinder a good sign conversation. Overall delay depends on multiple factors, including e.g. network delay and video processing. For this reason a testable requirement on minimum values for overall delay cannot be produced.

6.5.1 General (informative)

Clause 6.5 (Video communications) provides performance requirements that support users who communicate using sign language and lip-reading. For these users, good usability is achieved with a resolution of at least Quarter Video Graphics Array (QVGA, 320 x 240), a frame rate of 20 frames per second and over, with a time difference between speech audio and video that does not exceed 100 ms.

Increasing the resolution and frame rate further improves both sign language (especially finger spelling) and lip-reading, with frame rate being more important than resolution.

Time differences between audio and video (asynchronicity) can have a great impact onlip-reading - with video that lags behind audio having greater negative effect.

End-to-end latency can be a problem in video (sign) communication. Overall delay values below 400 ms are preferred, with an increase in preference down to 100 ms. Overall delay depends on multiple factors, including e.g. network delay and video processing. For this reason a testable requirement on minimum values for overall delay cannot be produced.

NOTE: Recommendation ITU-T F.703 defines and gives requirements for Total Conversation that relate to the integration of audio, RTT and video in a single user connection.

Functional change

Explanatory update

Stylistic rewording

6.5.1 General (informative)

Clause 6.5 (Video communications) provides performance requirements that support users who communicate using sign language and lip-reading. For these users, good usability is achieved with a resolution of at least Quarter Video Graphics Array (QVGA, 320 x 240), a frame rate of 20 frames per second and over, with a time difference between speech audio and video that does not exceed 100 ms.

Increasing the resolution and frame rate further improves both sign language (especially finger spelling) and lipreading, with frame rate being more important than resolution.

Time differences between audio and video (asynchronicity) can have a great impact onlip-reading - with video that lags behind audio having greater negative effect.

End-to-end latency can be a problem in video (sign) communication. Overall delay values below 400 ms are preferred, with an increase in preference down to 100 ms. Overall delay depends on multiple factors, including e.g. network delay and video processing. For this reason a testable requirement on minimum values for overall delay cannot be produced.

NOTE: Recommendation ITU-T F.703 defines and gives requirements for Total Conversation that relate to the integration of audio, RTT and video in a single user connection.

6.5.2 Resolution

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support at least QCIF resolution;

b) should preferably support at least CIF resolution.

Stylistic rewording

Explanatory update

Functional change

6.5.2 Resolution

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support at least QCIF resolution;

b) should preferably support at least CIF resolution.

6.5.2 Resolution

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support at least QVGA resolution;

b) should preferably support at least VGA resolution.

6.5.2 Resolution

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support at least QVGA resolution;

b) should preferably support at least VGA resolution.

6.5.3 Frame rate

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support a frame rate of at least 12 frames per second (FPS);

b) should preferably support a frame rate of at least 20 frames per second (FPS) with or without sign language in the video stream.

Stylistic rewording

Explanatory update

Functional change

6.5.3 Frame rate

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:

a) shall support a frame rate of at least 12 frames per second (FPS);

b) should preferably support a frame rate of at least 20 frames per second (FPS) with or without sign language in the video stream.

6.5.3 Frame rate

Where ICT that provides two-way voice communication includes real-time video functionality, 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.

6.5.3 Frame rate

Where ICT that provides two-way voice communication includes real-time video functionality, 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.

6.5.4 Synchronization between audio and video

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT should ensure a maximum time difference of 100 ms between the speech and video presented to the user.

Stylistic rewording

Explanatory update

Functional change

6.5.4 Synchronization between audio and video

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT should ensure a maximum time difference of 100 ms between the speech and video presented to the user.

6.5.4 Synchronization between audio and video

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT shall ensure a maximum time difference of 100 ms between the speech and video presented to the user.

NOTE: Recent research shows that, if audio leads the video, the intelligibility suffers much more than the reverse.

Functional change

Explanatory update

6.5.4 Synchronization between audio and video

Where ICT that provides two-way voice communication includes real-time video functionality, the ICT shall ensure a maximum time difference of 100 ms between the speech and video presented to the user.

NOTE: Recent research shows that, if audio leads the video, the intelligibility suffers much more than the reverse.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

Stylistic rewording

Explanatory update

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

NOTE 3: Clause 7.1.1 refers to the ability of the player to display captions. Clauses 9.1.2.2, 10.1.2.2 and 11.1.2.2 refer to the provision of captions for the content (the video).

5.4: Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

Stylistic rewording

Explanatory update

Functional change

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

5.4 Preservation of accessibility information during conversion

Where ICT converts information or communication it 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.

7.1.3 Preservation of captioning

Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.

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.

Stylistic rewording

Explanatory update

Functional change

7.1.3 Preservation of captioning

Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.

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.

7.1.3 Preservation of captioning

Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.

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.

7.1.3 Preservation of captioning

Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.

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.

414.1.1 Digital Television Tuners

Digital television tuners shall provide audio description processing that conforms to ATSC A/53 Digital Television Standard, Part 5 (2014) (incorporated by reference, see 702.2.1). Digital television tuners shall provide processing of audio description when encoded as a Visually Impaired (VI) associated audio service that is provided as a complete program mix containing audio description according to the ATSC A/53 standard.²⁸

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

Stylistic rewording

Explanatory update

Functional change

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

414.1.2 Other ICT

ICT other than digital television tuners shall provide audio description processing.

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

Stylistic rewording

Explanatory update

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

7.2.3 Preservation of audio description

Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.

415.1.1 Caption Controls

Where ICT provides operable parts for volume control, ICT shall also provide operable parts for caption selection.²⁹

7.3: User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

Stylistic rewording

Explanatory update

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

415.1.2 Audio Description Controls

Where ICT provides operable parts for program selection, ICT shall also provide operable parts for the selection of audio description.³⁰

7.3: User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

Stylistic rewording

Explanatory update

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

501.1 Scope

The requirements of Chapter 5 shall apply to software where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines.

EXCEPTION: Where Web applications do not have access to platform accessibility services and do not include components that have access to platform accessibility services, they shall not be required to conform to 502 or 503 provided that they conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

Explanatory update

Stylistic rewording

11.4.1 User control of accessibility features

Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.

11.6.1 User control of accessibility features

Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.

11.6.1 User control of accessibility features

Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.

11.6.1 User control of accessibility features

Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.

11.4.2 No disruption of accessibility features

Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

Stylistic rewording

Explanatory update

11.6.2 No disruption of accessibility features

Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

11.6.2 No disruption of accessibility features

Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

11.6.2 No disruption of accessibility features

Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

502.3 Accessibility Services

Platform software and software tools that are provided by the platform developer shall provide a documented set of accessibility services that support applications running on the platform to interoperate with assistive technology and shall conform to 502.3. Applications that are also platforms hall expose the underlying platform accessibility services or implement other documented accessibility services.

11.3.2.1 Platform accessibility service support for software that provides a user interface

Platform software shall provide a set of documented platform services that enable software that provides a user interface running on the platform software to interoperate with assistive technology.

Platform software should support requirements 11.3.2.5 to 11.3.2.17 except that, where a user interface concept that corresponds to one of the clauses 11.3.2.5 to 11.3.2.17 is not supported within the software environment, these requirements are not applicable. For example, selection attributes from 11.3.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.

NOTE 2: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services provided to conform to this clause (i.e. the service for creating a new user interface element provides role, state, boundary, name and description).

NOTE 4: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties described in clauses 11.3.2.5 to 11.3.2.17 might have different names than those used within the clauses.

Stylistic rewording

Explanatory update

11.5.2.1 Platform accessibility service support for software that provides a user interface

Platform software shall provide a set of documented platform services that enable software that provides a user interface running on the platform software to interoperate with assistive technology.

Platform software should support requirements 11.5.2.5 to 11.5.2.17 except that, where a user interface concept that corresponds to one of the clauses 11.5.2.5 to 11.5.2.17 is not supported within the software environment, these requirements are not applicable. For example, selection attributes from 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.

NOTE 2: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services provided to conform to this clause (e.g. the service for creating a new user interface element provides role, state, boundary, name and description).

NOTE 4: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties described in clauses 11.5.2.5 to 11.5.2.17 might have different names than those used within the clauses.

Numbering change

Stylistic rewording

11.5.2.1 Platform accessibility service support for software that provides a user interface

Platform software shall provide a set of documented platform services that enable software that provides a user interface running on the platform software to interoperate with assistive technology.

Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.

NOTE 2: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services provided to conform to this clause (e.g. the service for creating a new user interface element provides role, state, boundary, name and description).

NOTE 4: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties described in clauses 11.5.2.5 to 11.5.2.17 might have different names than those used within the clauses.

11.5.2.1 Platform accessibility service support for software that provides a user interface

Platform software shall provide a set of documented platform services that enable software that provides a user interface running on the platform software to interoperate with assistive technology.

Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from clause 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.

NOTE 2: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services provided to conform to this clause (e.g. the service for creating a new user interface element provides role, state, boundary, name and description).

NOTE 4: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties described in clauses 11.5.2.5 to 11.5.2.17 might have different names than those used within the clauses.

502.3 Accessibility Services

Platform software and software tools that are provided by the platform developer shall provide a documented set of accessibility services that support applications running on the platform to interoperate with assistive technology and shall conform to 502.3. Applications that are also platforms hall expose the underlying platform accessibility services or implement other documented accessibility services.

11.3.2.2 Platform accessibility service support for assistive technologies

Platform software shall provide a set of documented platform accessibility services that enable assistive technology to interoperate with software that provides a user interface running on the platform software.

Platform software should support the requirements of clauses 11.3.2.5 to 11.3.2.17 except that, where a user interface concept that corresponds to one of the clauses 11.3.2.5 to 11.3.2.17 is not supported within the software environment, these requirement are not applicable. For example, selection attributes from 11.3.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.

NOTE 2: The definition of platform in 3.1 applies to software that provides services to other software, including but not limited to, operating systems, internet browsers, virtual machines.

NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 4: Typically these services belong to the same set of services that are described in clause 11.3.2.1.

NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

Stylistic rewording

Explanatory update

11.5.2.2 Platform accessibility service support for assistive technologies

Platform software shall provide a set of documented platform accessibility services that enable assistive technology to interoperate with software that provides a user interface running on the platform software.

Platform software should support the requirements of clauses 11.5.2.5 to 11.5.2.17 except that, where a user interface concept that corresponds to one of the clauses 11.5.2.5 to 11.5.2.17 is not supported within the software environment, these requirement are not applicable. For example, selection attributes from 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.

NOTE 2: 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.

NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 4: Typically these services belong to the same set of services that are described in clause 11.5.2.1.

NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

Numbering change

Stylistic rewording

11.5.2.2 Platform accessibility service support for assistive technologies

Platform software shall provide a set of documented platform accessibility services that enable assistive technology to interoperate with software that provides a user interface running on the platform software.

Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.

NOTE 2: 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.

NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 4: Typically these services belong to the same set of services that are described in clause 11.5.2.1.

NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

11.5.2.2 Platform accessibility service support for assistive technologies

Platform software shall provide a set of documented platform accessibility services that enable assistive technology to interoperate with software that provides a user interface running on the platform software.

Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from clause 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.

NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.

NOTE 2: 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.

NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.

NOTE 4: Typically these services belong to the same set of services that are described in clause 11.5.2.1.

NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.

502.3.1 Object Information

The object role, state(s), properties, boundary, name, and description shall be programmatically determinable.

11.3.2.5 Object information

Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies.

Stylistic rewording

Explanatory update

11.5.2.5 Object information

Where the software provides a user interface it 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.

11.5.2.5 Object information

Where the software provides a user interface it 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.

11.5.2.5 Object information

Where the software provides a user interface it 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.

11.3.2.16 Modifications of states and properties

When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Stylistic rewording

Explanatory update

Functional change

11.5.2.16 Modifications of states and properties

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Numbering change

Stylistic rewording

11.5.2.16 Modifications of states and properties

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.5.2.16 Modifications of states and properties

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

502.3.3 Row, Column, and Headers

If an object is in a data table, the occupied rows and columns, and any headers associated with those rows or columns, shall be programmatically determinable.

11.3.2.6 Row, column, and headers

Where the software provides a user interface it shall, by using the services as described in clause 11.3.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.

Stylistic rewording

Explanatory update

11.5.2.6 Row, column, and headers

Where the software provides a user interface it 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.

11.5.2.6 Row, column, and headers

Where the software provides a user interface it 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.

11.5.2.6 Row, column, and headers

Where the software provides a user interface it 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.

11.3.2.7 Values

Where the software provides a user interface, it shall, by using the services as described in clause 11.3.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.

Stylistic rewording

Explanatory update

11.5.2.7 Values

Where the software provides a user interface, it 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.

11.5.2.7 Values

Where the software provides a user interface, it 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.

11.5.2.7 Values

Where the software provides a user interface, it 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.

502.3.5 Modification of Values

Values that can be set by the user shall be capable of being set programmatically, including through assistive technology.

11.3.2.17 Modifications of values and text

When permitted by security requirements, software that provides a user interface shall, by using the services as described in 11.3.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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Stylistic rewording

Explanatory update

Functional change

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Numbering change

Stylistic rewording

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.3.2.8 Label relationships

Where the software provides a user interface it 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.3.2.3, so that this information is programmatically determinable by assistive technologies.

Stylistic rewording

Explanatory update

11.5.2.8 Label relationships

Where the software provides a user interface it 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.

11.5.2.8 Label relationships

Where the software provides a user interface it 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.

11.5.2.8 Label relationships

Where the software provides a user interface it 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.

11.3.2.9 Parent-child relationships

Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.

Stylistic rewording

Explanatory update

11.5.2.9 Parent-child relationships

Where the software provides a user interface it 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.

11.5.2.9 Parent-child relationships

Where the software provides a user interface it 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.

11.5.2.9 Parent-child relationships

Where the software provides a user interface it 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.

502.3.8 Text

The content of text objects, text attributes, and the boundary of text rendered to the screen, shall be programmatically determinable.

11.3.2.10 Text

Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

Stylistic rewording

Explanatory update

11.5.2.10 Text

Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

11.5.2.10 Text

Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

11.5.2.10 Text

Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

502.3.9 Modification of Text

Text that can be set by the user shall be capable of being set programmatically, including through assistive technology.

11.3.2.17 Modifications of values and text

When permitted by security requirements, software that provides a user interface shall, by using the services as described in 11.3.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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Stylistic rewording

Explanatory update

Functional change

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Numbering change

Stylistic rewording

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.5.2.17 Modifications of values and text

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

502.3.10 List of Actions

A list of all actions that can be executed on an object shall be programmatically determinable.

11.3.2.11 List of available actions

Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies.

Stylistic rewording

Explanatory update

11.5.2.11 List of available actions

Where the software provides a user interface it 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.

11.5.2.11 List of available actions

Where the software provides a user interface it 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.

11.5.2.11 List of available actions

Where the software provides a user interface it 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.

502.3.11 Actions on Objects

Applications shall allow assistive technology to programmatically execute available actions on objects.

11.3.2.12 Execution of available actions

When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow the programmatic execution of the actions exposed according to clause 11.3.2.11 by assistive technologies.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Stylistic rewording

Explanatory update

Functional change

11.5.2.12 Execution of available actions

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Numbering change

Stylistic rewording

11.5.2.12 Execution of available actions

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.5.2.12 Execution of available actions

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

502.3.12 Focus Cursor

Applications shall expose information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface components.

11.3.2.13 Tracking of focus and selection attributes

Where software provides a user interface it shall, by using the services as described in clause 11.3.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.

Stylistic rewording

Explanatory update

11.5.2.13 Tracking of focus and selection attributes

Where software provides a user interface it 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.

11.5.2.13 Tracking of focus and selection attributes

Where software provides a user interface it 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.

11.5.2.13 Tracking of focus and selection attributes

Where software provides a user interface it 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.

11.3.2.14 Modification of focus and selection attributes

When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Stylistic rewording

Explanatory update

Functional change

11.5.2.14 Modification of focus and selection attributes

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

Numbering change

Stylistic rewording

11.5.2.14 Modification of focus and selection attributes

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.5.2.14 Modification of focus and selection attributes

Where permitted by security requirements, software that provides a user interface 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.

NOTE 1: In some cases the security requirements imposed on a 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 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.

11.3.2.15 Change notification

Where software provides a user interface it shall, by using the services as described in 11.3.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.3.2.5 to 11.3.2.11 and 11.3.2.13.

Stylistic rewording

Explanatory update

11.5.2.15 Change notification

Where software provides a user interface it 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.

Numbering change

Stylistic rewording

11.5.2.15 Change notification

Where software provides a user interface it 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.

11.5.2.15 Change notification

Where software provides a user interface it 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.

502.4 Platform Accessibility Features

Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below:

1. Section 9.3.3 Enable sequential entry of multiple (chorded) keystrokes;³¹

5.9: Simultaneous user actions

Where ICT uses simultaneous user actions for its operation, such 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.

Stylistic rewording

Explanatory update

5.9 Simultaneous user actions

Where ICT uses simultaneous user actions for its operation, such 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.

5.9 Simultaneous user actions

Where ICT has a mode of operation requiring simultaneous user actions for its operation, such 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.

5.9 Simultaneous user actions

Where ICT has a mode of operation requiring simultaneous user actions for its operation, such 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.

2. Section 9.3.4 Provide adjustment of delay before key acceptance;

5.7: Key repeat

Where ICT with key repeat is provided and the key repeat cannot be turned off:

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.

Stylistic rewording

Explanatory update

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

5.7 Key repeat

Where ICT has a key repeat function that cannot be turned off:

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.

3. Section 9.3.5 Provide adjustment of same-key double-strike acceptance;³²

5.8: Double-strike key acceptance

Where a keyboard or keypad is provided, the delay after any keystroke, during which an additional key-press will not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0,5 seconds.

Stylistic rewording

Explanatory update

5.8 Double-strike key acceptance

Where ICT has a keyboard or keypad, the delay after any keystroke, during which an additional key-press will not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0,5 seconds.

5.8 Double-strike key acceptance

Where ICT has a keyboard or keypad, the delay after any keystroke, during which an additional key-press will not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0,5 seconds.

5.8 Double-strike key acceptance

Where ICT has a keyboard or keypad, the delay after any keystroke, during which an additional key-press will not be accepted if it is identical to the previous keystroke, shall be adjustable up to at least 0,5 seconds.

7. Section 10.7.1 Display any captions provided.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

Stylistic rewording

Explanatory update

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

NOTE 3: Clause 7.1.1 refers to the ability of the player to display captions. Clauses 9.1.2.2, 10.1.2.2 and 11.1.2.2 refer to the provision of captions for the content (the video).

503.2 User Preferences Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

EXCEPTION: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.

11.5 User preferences

Where software provides a user interface it shall provide sufficient modes of operation that use user preferences for platform settings for colour, contrast, font type, font size, and focus cursor except for software that is designed to be isolated from its underlying platforms.

NOTE: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

Stylistic rewording

Explanatory update

11.7 User preferences

Where software provides a user interface it shall provide sufficient modes of operation that use user preferences for platform settings for colour, contrast, font type, font size, and focus cursor except for software that is designed to be isolated from its underlying platforms.

NOTE: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

11.7 User preferences

Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

NOTE 2: For web content, the underlying platform is the user agent.

NOTE 3: This does not preclude the 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.

Stylistic rewording

Functional change

11.7 User preferences

Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

NOTE 2: For web content, the underlying platform is the user agent.

NOTE 3: This does not preclude the 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.

11.3.2.4 Assistive technology

Where the ICT is assistive technology it shall use the documented platform accessibility services.

NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.3.2.1 and 11.3.2.2.

NOTE 2: Assistive technology can also use other documented accessibility services.

Stylistic rewording

Explanatory update

11.5.2.4 Assistive technology

Where the ICT is assistive technology it shall use the documented platform accessibility services.

NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.

NOTE 2: Assistive technology can also use other documented accessibility services.

11.5.2.4 Assistive technology

Where the ICT is assistive technology it shall use the documented platform accessibility services.

NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.

NOTE 2: Assistive technology can also use other documented accessibility services.

11.5.2.4 Assistive technology

Where the ICT is assistive technology it shall use the documented platform accessibility services.

NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.

NOTE 2: Assistive technology can also use other documented accessibility services.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

Stylistic rewording

Explanatory update

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE: Captions may contain information about timing, colour and positioning. This caption data is important for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

7.1.1 Captioning playback

Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.

NOTE 1: Captions may contain information about timing, colour and positioning. This caption data is necessary for caption users. Timing is used for caption synchronization. Colour can be used for speaker identification. Position can be used to avoid obscuring important information.

NOTE 2: If a Braille device is connected, the ICT should provide an option to display captions on the Braille device.

NOTE 3: Clause 7.1.1 refers to the ability of the player to display captions. Clauses 9.1.2.2, 10.1.2.2 and 11.1.2.2 refer to the provision of captions for the content (the video).

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

Stylistic rewording

Explanatory update

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

Stylistic rewording

Explanatory update

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

7.3 User controls for captions and audio description

Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

NOTE 1: Primary media controls are the set of controls that the user most commonly uses to control media.

NOTE 2: Products that have a general hardware volume control, such as a telephone, or a laptop which can be configured to display video through software but which is not its primary purpose, would not need dedicated hardware controls for captions and descriptions; however software controls, or hardware controls mapped through software, would need to be at the same level of interaction.

NOTE 3: It is best practice for ICT to include additional controls enabling the user to select whether captions and audio description are turned on or off by default.

11.8.1 Content technology

Authoring tools shall conform to clauses 11.8.2 to 11.8.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.

11.8.1 Content technology

Authoring tools shall conform to clauses 11.8.2 to 11.8.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.

504.2 Content Creation or Editing Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.

EXCEPTION: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.

11.6.2 Accessible content creation

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) 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 caption files for multiple formats may be provided by a different tool.

Stylistic rewording

Explanatory update

11.8.2 Accessible content creation

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) 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 caption files for multiple formats may be provided by a different tool.

11.8.2 Accessible content creation

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) 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 caption files for multiple formats may be provided by a different tool.

11.8.2 Accessible content creation

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) 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 caption files for multiple formats may be provided by a different tool.

11.6.3 Preservation of accessibility information in transformations

If the authoring tool provides restructuring transformations or re-coding transformations, then 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.

Stylistic rewording

Explanatory update

11.8.3 Preservation of accessibility information in transformations

If the authoring tool provides restructuring transformations or re-coding transformations, then 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.

11.8.3 Preservation of accessibility information in transformations

If the authoring tool provides restructuring transformations or re-coding transformations, then 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.

11.8.3 Preservation of accessibility information in transformations

If the authoring tool provides restructuring transformations or re-coding transformations, then 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.

11.6.4 Repair assistance

If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web content) or 10 (Documents) as applicable, then the authoring tool shall provide repair suggestion(s).

NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.

Stylistic rewording

Explanatory update

Functional change

11.8.4 Repair assistance

If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web) or 10 (Non-web documents) as applicable, then the authoring tool shall provide repair suggestion(s).

NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.

Numbering change

Stylistic rewording

11.8.4 Repair assistance

If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web) or 10 (Non-web documents) as applicable, then the authoring tool shall provide repair suggestion(s).

NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.

11.8.4 Repair assistance

If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web) or 10 (Non-web documents) as applicable, then the authoring tool shall provide repair suggestion(s).

NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.

11.6.5 Templates

When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web content) or 10 (Documents) as applicable shall be available and identified as such.

Stylistic rewording

Explanatory update

11.8.5 Templates

When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web) or 10 (Non-web documents) as applicable shall be available and identified as such.

Numbering change

Stylistic rewording

11.8.5 Templates

When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web) or 10 (Non-web documents) as applicable shall be available and identified as such.

11.8.5 Templates

When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web) or 10 (Non-web documents) as applicable shall be available and identified as such.

12.1.1 Accessibility and compatibility features

Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

Stylistic rewording

Explanatory update

12.1.1 Accessibility and compatibility features

Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

12.1.1 Accessibility and compatibility features

Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT.

NOTE 1: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

NOTE 2: It is best practice to use WebSchemas/Accessibility 2.0 to provide meta data on the accessibility of the ICT.

NOTE 3: The accessibility statement and help pages are both examples of the provision of product information.

12.1.1 Accessibility and compatibility features

Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT.

NOTE 1: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

NOTE 2: It is best practice to use WebSchemas/Accessibility 2.0 [i.38] to provide meta data on the accessibility of the ICT.

NOTE 3: The accessibility statement and help pages are both examples of the provision of product information.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9, or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic or printed) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with cognitive impairments).

NOTE 3: Where the documentation is integral to the ICT it will be provided through the user interface which is accessible.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

Stylistic rewording

Explanatory update

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9, or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic or printed) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with cognitive impairments).

NOTE 3: Where the documentation is integral to the ICT it will be provided through the user interface which is accessible.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9; or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic, printed or audio) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with limited cognitive, language and learning abilities).

NOTE 3: Where documentation is incorporated into the ICT, the documentation falls under the requirements for accessibility in the present document.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9; or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic, printed or audio) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with limited cognitive, language and learning abilities).

NOTE 3: Where documentation is incorporated into the ICT, the documentation falls under the requirements for accessibility in the present document.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9, or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic or printed) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with cognitive impairments).

NOTE 3: Where the documentation is integral to the ICT it will be provided through the user interface which is accessible.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

Stylistic rewording

Explanatory update

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9, or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic or printed) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with cognitive impairments).

NOTE 3: Where the documentation is integral to the ICT it will be provided through the user interface which is accessible.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9; or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic, printed or audio) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with limited cognitive, language and learning abilities).

NOTE 3: Where documentation is incorporated into the ICT, the documentation falls under the requirements for accessibility in the present document.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.1.2 Accessible documentation

Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

1. a Web format that conforms to the requirements of clause 9; or
2. a non-web format that conforms to the requirements of clause 10.

NOTE 1: This does not preclude the possibility of also providing the product documentation in other formats (electronic, printed or audio) that are not accessible.

NOTE 2: It also does not preclude the possibility of providing alternate formats that meet the needs of some specific type of users (e.g. Braille documents for blind people or easy-to-read information for persons with limited cognitive, language and learning abilities).

NOTE 3: Where documentation is incorporated into the ICT, the documentation falls under the requirements for accessibility in the present document.

NOTE 4: A user agent that supports automatic media conversion would be beneficial to enhancing accessibility.

12.2.1 General (informative)

ICT support services include, but are not limited to: help desks, call centres, technical support, relay services and training services.

12.2.1 General (informative)

ICT support services include, but are not limited to: help desks, call centres, technical support, relay services and training services.

12.2.1 General (informative)

ICT support services include, but are not limited to: help desks, call centres, technical support, relay services and training services.

12.2.1 General (informative)

ICT support services include, but are not limited to: help desks, call centres, technical support, relay services and training services.

603.2 Information on Accessibility and Compatibility Features

ICT support services shall include information on the accessibility and compatibility features required by 602.2.

12.2.2 Information on accessibility and compatibility features

ICT support services shall provide information on the accessibility and compatibility features that are included in the product documentation.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

Stylistic rewording

Explanatory update

12.2.2 Information on accessibility and compatibility features

ICT support services shall provide information on the accessibility and compatibility features that are included in the product documentation.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

12.2.2 Information on accessibility and compatibility features

ICT support services shall provide information on the accessibility and compatibility features that are mentioned in the product documentation.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

12.2.2 Information on accessibility and compatibility features

ICT support services shall provide information on the accessibility and compatibility features that are mentioned in the product documentation.

NOTE: Accessibility and compatibility features include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

603.3 Accommodation of Communication Needs

Support services shall be provided directly to the user or through a referral to a point of contact. Such ICT support services shall accommodate the communication needs of individuals with disabilities.

12.2.3 Effective communication

ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.

Stylistic rewording

Explanatory update

12.2.3 Effective communication

ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.

12.2.3 Effective communication

ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.

12.2.3 Effective communication

ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.

402.3 Volume

ICT that delivers sound, including speech output required by 402.2, shall provide volume control and output amplification conforming to 402.3.

EXCEPTION: ICT conforming to 412.2 shall not be required to conform to 402.3.

407.3 Input Controls

At least one input control conforming to 407.3 shall be provided for each function.

EXCEPTION: Devices for personal use with input controls that are audibly discernable without activation and operable by touch shall not be required to conform to 407.3.

407.5 Timed Response

Where a timed response is required, the user shall be alerted visually, as well as by touch or sound, and shall be given the opportunity to indicate that more time is needed.³³

407.8.2 Side Reach

Operable parts of ICT providing a side reach shall conform to 407.8.2.1 or 407.8.2.2. The vertical reference plane shall be centered on the operable part and placed at the leading edge of the maximum protrusion of the ICT within the length of the vertical reference plane. Where a side reach requires a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum.

408.3 Flashing Where ICT emits lights in flashes, there shall be no more than three flashes in any one-second period.

EXCEPTION: Flashes that do not exceed the general flash and red flash thresholds defined in WCAG 2.0 (incorporated by reference, see 702.10.1) are not required to conform to 408.3. ³⁵

412.1 General

ICT that provides two-way voice communication shall conform to 412.

412.2 Volume Gain

ICT that provides two-way voice communication shall conform to 412.2.1 or 412.2.2.

412.8 Legacy TTY Support

ICT equipment or systems with two-way voice communication that do not themselves provide TTY functionality shall conform to 412.8.

412.8.1 TTY Connectability

ICT shall include a standard non-acoustic connection point for TTYs.

412.8.2 Voice and Hearing Carry Over

ICT shall provide a microphone capable of being turned on and off to allow the user to intermix speech with TTY use.

412.8.3 Signal Compatibility

ICT shall support all commonly used cross-manufacturer non-proprietary standard TTY signal protocols where the system interoperates with the Public Switched Telephone Network (PSTN).

412.8.4 Voice Mail and Other Messaging Systems

Where provided, voice mail, auto-attendant, interactive voice response, and caller identification systems shall be usable with a TTY.

413.1 General

Where ICT displays or processes video with synchronized audio, ICT shall provide closed caption processing technology that conforms to 413.1.1 or 413.1.2.

415.1 General Where ICT displays video with synchronized audio, ICT shall provide user controls for closed captions and audio descriptions conforming to 415.1.

EXCEPTION: Devices for personal use shall not be required to conform to 415.1 provided that captions and audio descriptions can be enabled through system-wide platform settings.

502.1 General Software shall interoperate with assistive technology and shall conform to 502.

EXCEPTION: ICT conforming to 402 shall not be required to conform to 502.

502.4 Platform Accessibility Features

Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below:

4. Section 10.6.7 Allow users to choose visual alternative for audio output;³⁷

502.4 Platform Accessibility Features

Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below:

5. Section 10.6.8 Synchronize audio equivalents for visual events;³⁸

502.4 Platform Accessibility Features

Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below:

6. Section 10.6.9 Provide speech output services;³⁹

504.2.2 PDF Export

Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1) (incorporated by reference, see 702.3.1).⁴⁰

4.2.11 Privacy

Where ICT provides features that are provided for accessibility, some users will need their privacy to be maintained when using those ICT features that are provided for accessibility. NOTE: Enabling the connection of personal headsets for private listening, not providing a spoken version of characters being masked and enabling user control of legal, financial and personal data are examples of design features that may contribute towards meeting this clause.

4.2.11 Privacy

Where ICT provides features that are provided for accessibility, some users will need their privacy to be maintained when using those ICT features that are provided for accessibility. NOTE: Enabling the connection of personal headsets for private listening, not providing a spoken version of characters being masked and enabling user control of legal, financial and personal data are examples of design features that may contribute towards meeting this clause.

4.2.11 Privacy

Where ICT provides features for accessibility, the ICT maintains the privacy of users of these features at the same level as other users.

NOTE: Enabling the connection of personal headsets for private listening, not providing a spoken version of characters being masked and enabling user control of legal, financial and personal data are examples of design features that may contribute towards meeting this clause.

4.2.11 Privacy

Where ICT provides features for accessibility, the ICT maintains the privacy of users of these features at the same level as other users.

NOTE: Enabling the connection of personal headsets for private listening, not providing a spoken version of characters being masked and enabling user control of legal, financial and personal data are examples of design features that may contribute towards meeting this clause.

4.2.9 Minimize photosensitive seizure triggers

Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that minimizes the potential for triggering photosensitive seizures.

NOTE: Limiting the area and number of flashes per second may contribute towards meeting this clause.

4.2.9 Minimize photosensitive seizure triggers

Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that minimizes the potential for triggering photosensitive seizures.

NOTE: Limiting the area and number of flashes per second may contribute towards meeting this clause.

4.2.9 Minimize photosensitive seizure triggers

Where ICT provides visual modes of operation, the ICT provides at least one mode of operation that minimizes the potential for triggering photosensitive seizures. This is essential for users with photosensitive seizure triggers.

NOTE: Limiting the area and number of flashes per second may contribute towards meeting this clause.

4.2.9 Minimize photosensitive seizure triggers

Where ICT provides visual modes of operation, the ICT provides at least one mode of operation that minimizes the potential for triggering photosensitive seizures. This is essential for users with photosensitive seizure triggers.

NOTE: Limiting the area and number of flashes per second may contribute towards meeting this clause.

5.1.2.1 Closed functionality

Where ICT has closed functionality, it shall meet the requirements set out in clauses 5.2 to 13, as applicable.

NOTE 1: ICT may close some, but not all, of its functionalities. Only the closed functionalities have to conform to the requirements of clause 5.1.

NOTE 2: The requirements within this clause replace those in clauses 5.2 to 13 that specifically state that they do not apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability for the user to adjust system accessibility settings in products with closed functionality (e.g. products that prevent access to the system settings control panel).

5.1.2.1 Closed functionality

Where ICT has closed functionality, it shall meet the requirements set out in clauses 5.2 to 13, as applicable.

NOTE 1: ICT may close some, but not all, of its functionalities. Only the closed functionalities have to conform to the requirements of clause 5.1.

NOTE 2: The requirements within this clause replace those in clauses 5.2 to 13 that specifically state that they do not apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability for the user to adjust system accessibility settings in products with closed functionality (e.g. products that prevent access to the system settings control panel).

5.1.2.1 Closed functionality

Where ICT has closed functionality, it shall meet the requirements set out in clauses 5.2 to 13, as applicable.

NOTE 1: ICT may close some, but not all, of its functionalities. Only the closed functionalities have to conform to the requirements of clause 5.1.

NOTE 2: The requirements within this clause replace those in clauses 5.2 to 13 that specifically state that they do not apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability for the user to adjust system accessibility settings in products with closed functionality (e.g. products that prevent access to the system settings control panel).

5.1.2.1 Closed functionality

Where ICT has closed functionality, it shall meet the requirements set out in clauses 5.2 to 13, as applicable.

NOTE 1: ICT may close some, but not all, of its functionalities. Only the closed functionalities have to conform to the requirements of clause 5.1.

NOTE 2: The requirements within this clause replace those in clauses 5.2 to 13 that specifically state that they do not apply to closed functionality. This may be because they relate to compatibility with assistive technology or to the ability for the user to adjust system accessibility settings in products with closed functionality (e.g. products that prevent access to the system settings control panel).

5.1.3.10 Non-interfering audio output

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

5.1.3.10 Non-interfering audio output

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

5.1.3.10 Non-interfering audio output

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

5.1.3.10 Non-interfering audio output

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

5.1.3.14 Spoken languages

Where speech output is provided as non-visual access to closed functionality, speech output shall be in the same human language as the displayed content provided, except:

1. 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;
2. where the content is generated externally and not under the control of the ICT vendor, clause 5.1.3.14 shall not be required to apply for languages not supported by the ICT's speech synthesizer;
3. for displayed languages that cannot be selected using non-visual access;
4. where the user explicitly selects a speech language that is different from the language of the displayed content.

5.1.3.14 Spoken languages

Where speech output is provided as non-visual access to closed functionality, speech output shall be in the same human language as the displayed content provided, except:

1. 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;
2. where the content is generated externally and not under the control of the ICT vendor, clause 5.1.3.14 shall not be required to apply for languages not supported by the ICT's speech synthesizer;
3. for displayed languages that cannot be selected using non-visual access;
4. where the user explicitly selects a speech language that is different from the language of the displayed content.

5.1.3.14 Spoken languages

Where speech output is provided as non-visual access to closed functionality, speech output shall be in the same human language as the displayed content provided, except:

1. 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;
2. 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;
3. for displayed languages that cannot be selected using non-visual access;
4. where the user explicitly selects a speech language that is different from the language of the displayed content.

5.1.3.14 Spoken languages

Where speech output is provided as non-visual access to closed functionality, speech output shall be in the same human language as the displayed content provided, except:

1. 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;
2. 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;
3. for displayed languages that cannot be selected using non-visual access;
4. where the user explicitly selects a speech language that is different from the language of the displayed content.

5.1.3.15 Non-visual error identification

Where speech output is provided as non-visual access to closed functionality and an input error is automatically detected, speech output shall identify and describe the item that is in error.

5.1.3.15 Non-visual error identification

Where speech output is provided as non-visual access to closed functionality and an input error is automatically detected, speech output shall identify and describe the item that is in error.

5.1.3.15 Non-visual error identification

Where speech output is provided as non-visual access to closed functionality and an input error is automatically detected, speech output shall identify and describe the item that is in error.

5.1.3.15 Non-visual error identification

Where speech output is provided as non-visual access to closed functionality and an input error is automatically detected, speech output shall identify and describe the item that is in error.

5.1.5 Visual output for auditory information

Where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the ICT shall provide visual information that is equivalent to the pre-recorded auditory output.

NOTE: This visual information can take the form of captions or text transcripts.

5.1.5 Visual output for auditory information

Where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the ICT shall provide visual information that is equivalent to the pre-recorded auditory output.

NOTE: This visual information can take the form of captions or text transcripts.

5.1.5 Visual output for auditory information

Where auditory information is needed to enable the use of closed functions of ICT, the ICT shall provide visual information that is equivalent to the auditory output.

NOTE: This visual information can take the form of captions or text transcripts.

5.1.5 Visual output for auditory information

Where auditory information is needed to enable the use of closed functions of ICT, the ICT shall provide visual information that is equivalent to the auditory output.

NOTE: This visual information can take the form of captions or text transcripts.

5.1.6.1 Closed functionality

Where ICT functionality is closed to keyboards or keyboard interfaces, all functionality shall be operable without vision as required by clause 5.1.3.

5.1.6.1 Closed functionality

Where ICT functionality is closed to keyboards or keyboard interfaces, all functionality shall be operable without vision as required by clause 5.1.3.

5.1.6.1 Closed functionality

Where ICT functionality is closed to keyboards or keyboard interfaces, all functionality shall be operable without vision as required by clause 5.1.3.

5.1.6.1 Closed functionality

Where ICT functionality is closed to keyboards or keyboard interfaces, all functionality shall be operable without vision as required by clause 5.1.3.

5.1.6.2 Input focus

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

5.1.6.2 Input focus

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

5.1.6.2 Input focus

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

5.1.6.2 Input focus

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

5.1.7 Access without speech

Where speech is needed to operate closed functions of ICT, the ICT shall provide at least one mode of operation using an alternative input mechanism that does not require speech.

5.1.7 Access without speech

Where speech is needed to operate closed functions of ICT, the ICT shall provide at least one mode of operation using an alternative input mechanism that does not require speech.

6.2.1.1 RTT communication

Where ICT supports two-way voice communication in a specified context of use, the ICT shall allow a user to communicate with another user by RTT.

NOTE 1: The RTT capability can be provided as a factory default or added later.

NOTE 2: Provision of RTT may require additional service provision, additional hardware and/or software which may be provided separately or together.

6.2.1.1 RTT communication

Where ICT supports two-way voice communication in a specified context of use, the ICT shall allow a user to communicate with another user by RTT.

NOTE 1: The RTT capability can be provided as a factory default or added later.

NOTE 2: Provision of RTT may require additional service provision, additional hardware and/or software which may be provided separately or together.

6.2.1.1 RTT communication

Where ICT is in a mode that provides a means for two-way voice communication, the ICT shall provide a means for two-way RTT communication, except where this would require design changes to add input or output hardware to the ICT.

NOTE 1: 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 2: There is no requirement to add: a hardware display, a hardware keyboard, or hardware to support the ability to connect to a display or keyboard, wired or wirelessly, if this hardware would not normally be provided.

NOTE 3: For the purposes of interoperability, support of Recommendation ITU-T T.140 is widely used.

Stylistic rewording

Functional change

Explanatory update

6.2.1.1 RTT communication

Where ICT is in a mode that provides a means for two-way voice communication, the ICT shall provide a means for two-way RTT communication, except where this would require design changes to add input or output hardware to the ICT.

NOTE 1: 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 2: There is no requirement to add: a hardware display, a hardware keyboard, or hardware to support the ability to connect to a display or keyboard, wired or wirelessly, if this hardware would not normally be provided.

NOTE 3: For the purposes of interoperability, support of Recommendation ITU-T T.140 is widely used.

6.2.1.2 Concurrent voice and text

Where ICT supports two-way voice communication in a specified context of use, and enables a user to communicate with another user by RTT, it shall provide a mechanism to select a mode of operation which allows concurrent voice and text.

NOTE: The availability of voice and RTT running concurrently can allow the RTT to replace or support voice and transfer additional information such as numbers, currency amounts and spelling of names.

6.2.1.2 Concurrent voice and text

Where ICT supports two-way voice communication in a specified context of use, and enables a user to communicate with another user by RTT, it shall provide a mechanism to select a mode of operation which allows concurrent voice and text.

NOTE: The availability of voice and RTT running concurrently can allow the RTT to replace or support voice and transfer additional information such as numbers, currency amounts and spelling of names.

6.2.1.2 Concurrent voice and text

Where ICT provides a means for two-way voice communication and for users to communicate by RTT, it shall allow concurrent voice and text through a single user connection.

NOTE 1: With many-party communication, as in a conference system, it is allowed (but not required or necessarily recommended) that RTT be handled in a single display field and that "turn-taking" be necessary to avoid confusion (in the same way that turn-taking is required for those presenting/talking with voice).

NOTE 2: With many-party communication, best practice is for hand-raising for voice users and RTT users to be handled in the same way, so that voice and RTT users are in the same queue.

NOTE 3: With a many-party conference system that has chat as one of its features - the RTT (like the voice) would typically be separate from the chat so that RTT use does not interfere with chat (i.e. people can be messaging in the chat field while the person is presenting/talking with RTT - in the same manner that people message using the chat feature while people are talking with voice). RTT users would then use RTT for presenting and use the Chat feature to message while others are presenting (via Voice or RTT).

NOTE 4: The availability of voice and RTT running concurrently (and separately from chat) can also allow the RTT field to support text captioning when someone is speaking (and it is therefore not being used for RTT since it is not the RTT user's turn to speak).

NOTE 5: Where both server-side software and local hardware and software are required to provide voice communication, where neither part can support voice communication without the other and are sold as a unit for the voice communication function, the local and server-side components are considered a single product.

Stylistic rewording

Functional change

Explanatory update

6.2.1.2 Concurrent voice and text

Where ICT provides a means for two-way voice communication and for users to communicate by RTT, it shall allow concurrent voice and text through a single user connection.

NOTE 1: With many-party communication, as in a conference system, it is allowed (but not required or necessarily recommended) that RTT be handled in a single display field and that "turn-taking" be necessary to avoid confusion (in the same way that turn-taking is required for those presenting/talking with voice).

NOTE 2: With many-party communication, best practice is for hand-raising for voice users and RTT users to be handled in the same way, so that voice and RTT users are in the same queue.

NOTE 3: With a many-party conference system that has chat as one of its features - the RTT (like the voice) would typically be separate from the chat so that RTT use does not interfere with chat (i.e. people can be messaging in the chat field while the person is presenting/talking with RTT - in the same manner that people message using the chat feature while people are talking with voice). RTT users would then use RTT for presenting and use the Chat feature to message while others are presenting (via Voice or RTT).

NOTE 4: The availability of voice and RTT running concurrently (and separately from chat) can also allow the RTT field to support text captioning when someone is speaking (and it is therefore not being used for RTT since it is not the RTT user's turn to speak).

NOTE 5: Where both server-side software and local hardware and software are required to provide voice communication, where neither part can support voice communication without the other and are sold as a unit for the voice communication function, the local and server-side components are considered a single product.

6.2.2.1 Visually distinguishable display

Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from and separated from received text.

6.2.2.1 Visually distinguishable display

Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from and separated from received text.

6.2.2.1 Visually distinguishable display

Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from, and separated from, received text.

NOTE: The ability of the user to choose between having the send and receive text be displayed in-line or separately, and with options to select, allows users to display RTT in a form that works best for them. This would allow Braille users to use a single field and take turns and have text appear in the sequential way that they may need or prefer.

6.2.2.1 Visually distinguishable display

Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from, and separated from, received text.

NOTE: The ability of the user to choose between having the send and receive text be displayed in-line or separately, and with options to select, allows users to display RTT in a form that works best for them. This would allow Braille users to use a single field and take turns and have text appear in the sequential way that they may need or prefer.

6.2.2.2 Programmatically determinable send and receive direction

Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted text shall be programmatically determinable, unless the RTT has closed functionality.

NOTE: The intent of clause 6.2.2.2 is to enable screen readers to be able to distinguish between incoming text and outgoing text when used with RTT functionality.

6.2.2.2 Programmatically determinable send and receive direction

Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted text shall be programmatically determinable, unless the RTT has closed functionality.

NOTE: The intent of this clause is to enable screen readers to be able to distinguish between incoming text and outgoing text when used with RTT functionality.

6.2.2.2 Programmatically determinable send and receive direction

Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted/received text shall be programmatically determinable, unless the RTT is implemented as closed functionality.

NOTE: This enables screen readers to distinguish between incoming text and outgoing text when used with RTT functionality.

Functional change

Stylistic rewording

6.2.2.2 Programmatically determinable send and receive direction

Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted/received text shall be programmatically determinable, unless the RTT is implemented as closed functionality.

NOTE: This enables screen readers to distinguish between incoming text and outgoing text when used with RTT functionality.

6.2.2.3 Speaker identification

Where ICT has RTT capabilities, and provides speaker identification for voice, the ICT shall provide speaker identification for RTT.

NOTE: This is necessary to enable both voice and RTT participants to know who is currently communicating, whether it be in RTT or voice.

6.2.2.3 Speaker identification

Where ICT has RTT capabilities, and provides speaker identification for voice, the ICT shall provide speaker identification for RTT.

NOTE: This is necessary to enable both voice and RTT participants to know who is currently communicating, whether it be in RTT or voice.

6.2.2.4 Visual indicator of Audio with RTT

Where ICT provides two-way voice communication, and has RTT capabilities, the ICT shall provide a real-time visual indicator of audio activity on the display.

NOTE 1: The visual indicator may be a simple character position on the display that flickers on and off to reflect audio activity, or presentation of the information in another way that can be both visible to sighted users and passed on to deaf-blind users who are using a braille display.

NOTE 2: Without this indication a person who lacks the ability to hear does not know when someone is talking.

6.2.2.4 Visual indicator of Audio with RTT

Where ICT provides two-way voice communication, and has RTT capabilities, the ICT shall provide a real-time visual indicator of audio activity on the display.

NOTE 1: The visual indicator may be a simple character position on the display that flickers on and off to reflect audio activity, or presentation of the information in another way that can be both visible to sighted users and passed on to deaf-blind users who are using a braille display.

NOTE 2: Without this indication a person who lacks the ability to hear does not know when someone is talking.

6.2.3 Interoperability

Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by 6.2.1.1) they shall support at least one of the four RTT interoperability mechanisms described below:

1. ICT interoperating over the Public Switched Telephone Network (PSTN), with other ICT that directly connects to the PSTN as described in Recommendation ITU-T V.18 or any of its annexes for text telephony signals at the PSTN interface;
2. ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using real-time text that conforms to RFC 4103;
3. ICT interoperating with other ICT using RTT that conforms with the IP Multimedia Sub-System (IMS) set of protocols specified in TS 126 114, TS 122 173 and TS 134 229;
4. ICT interoperating with other ICT using a relevant and applicable common specification for RTT exchange that is published and available. This common specification shall include a method for indicating loss or corruption of characters.

6.2.3 Interoperability

Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by clause 6.2.1.1) they shall support at least one of the four RTT interoperability mechanisms described below:

1. ICT interoperating over the Public Switched Telephone Network (PSTN), with other ICT that directly caonnects to the PSTN as described in Recommendation ITU-T V.18 or any of its annexes for text telephony signals at the PSTN interface;
2. ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using real-time text that conforms to IETF RFC 4103;
3. ICT interoperating with other ICT using RTT that conforms with the IP Multimedia Sub-System (IMS) set of protocols specified in ETSI TS 126 114, ETSI TS 122 173 and ETSI TS 134 229;
4. ICT interoperating with other ICT using a relevant and applicable common specification for RTT exchange that is published and available. This common specification shall include a method for indicating loss or corruption of characters.

Stylistic rewording

Explanatory update

6.2.3 Interoperability

Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by clause 6.2.1.1) they shall support the applicable RTT interoperability mechanisms described below:

1. ICT interoperating with other ICT directly connected to the Public Switched Telephone Network (PSTN), using Recommendation ITU-T V.18 or any of its annexes for text telephony signals at the PSTN interface;
2. ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using RTT that conforms to IETF RFC 4103. For ICT interoperating with other ICT using the IP Multimedia Sub-System (IMS) to implement VOIP, the set of protocols specified in ETSI TS 126 114, ETSI TS 122 173 and ETSI TS 134 229 describe how IETF RFC 4103 would apply;
3. ICT interoperating with other ICT using technologies other than a or b, above, using a relevant and applicable common specification for RTT exchange that is published and available for the environments in which they will be operating. This common specification shall include a method for indicating loss or corruption of characters.
4. ICT interoperating with other ICT using a standard for RTT that has been introduced for use in any of the above environments, and is supported by all of the other active ICT that support voice and RTT in that environment.

NOTE 1: In practice, new standards are introduced as an alternative codec/protocol that is supported alongside the existing common standard and used when all end-to-end components support it while technology development, combined with other reasons including societal development and cost efficiency, may make others become obsolete.

NOTE 2: Where multiple technologies are used to provide voice communication, multiple interoperability mechanisms may be needed to ensure that all users are able to use RTT.

EXAMPLE: A conferencing system that supports voice communication through an internet connection might provide RTT over an internet connection using a proprietary RTT method (option c). However, regardless of whether the RTT method is proprietary or non-proprietary, if the conferencing system also offers telephony communication it will also need to support options a or b to ensure that RTT is supported over the telephony connection.

Stylistic rewording

Explanatory update

Functional change

6.2.3 Interoperability

Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by clause 6.2.1.1) they shall support the applicable RTT interoperability mechanisms described below:

1. ICT interoperating with other ICT directly connected to the Public Switched Telephone Network (PSTN), using Recommendation ITU-T V.18 [i.23] or any of its annexes for text telephony signals at the PSTN interface;
2. ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using RTT that conforms to IETF RFC 4103 [i.13]. For ICT interoperating with other ICT using the IP Multimedia Sub-System (IMS) to implement VOIP, the set of protocols specified in ETSI TS 126 114 [i.10], ETSI TS 122 173 [i.11] and ETSI TS 134 229 [i.12] describe how IETF RFC 4103 [i.13] would apply;
3. ICT interoperating with other ICT using technologies other than a or b, above, using a relevant and applicable common specification for RTT exchange that is published and available for the environments in which they will be operating. This common specification shall include a method for indicating loss or corruption of characters;
4. ICT interoperating with other ICT using a standard for RTT that has been introduced for use in any of the above environments, and is supported by all of the other active ICT that support voice and RTT in that environment.

NOTE 1: In practice, new standards are introduced as an alternative codec/protocol that is supported alongside the existing common standard and used when all end-to-end components support it while technology development, combined with other reasons including societal development and cost efficiency, may make others become obsolete.

NOTE 2: Where multiple technologies are used to provide voice communication, multiple interoperability mechanisms may be needed to ensure that all users are able to use RTT.

EXAMPLE: A conferencing system that supports voice communication through an internet connection might provide RTT over an internet connection using a proprietary RTT method (option c). However, regardless of whether the RTT method is proprietary or non-proprietary, if the conferencing system also offers telephony communication it will also need to support options a or b to ensure that RTT is supported over the telephony connection.

6.2.4 Real-time responsiveness

Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network supporting RTT within 1 second of the input entry.

NOTE 1: Input entry is considered to have occurred when sufficient user input has occurred for the ICT to establish which character(s) to send.

NOTE 2: Input entry will differ between systems where text is entered on a word-by-word basis (e.g. speech-to-text and predictive-text based systems) and systems where each character is separately generated.

6.2.4 Real-time text responsiveness

Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network supporting RTT within 1 second of the input entry.

NOTE 1: Input entry is considered to have occurred when sufficient user input has occurred for the ICT to establish which character(s) to send.

NOTE 2: Input entry will differ between systems where text is entered on a word-by-word basis (e.g. speech-to-text and predictive-text based systems) and systems where each character is separately generated.

6.2.4 RTT responsiveness

Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network or platform 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. Delays due to platform or network performance shall not be included in the 500 ms limit.

NOTE 1: For character by character input, the "smallest reliably composed unit of text entry" would be a character.

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 this case, the smallest reliably composed unit of text entry available to the ICT would be the word (or phrase).

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 per 500 ms.

NOTE 3: A delay of 300 ms, or less, produces a better impression of flow to the user.

Stylistic rewording

Functional change

Explanatory update

6.2.4 RTT responsiveness

Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network or platform 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. Delays due to platform or network performance shall not be included in the 500 ms limit.

NOTE 1: For character by character input, the "smallest reliably composed unit of text entry" would be a character. 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 this case, the smallest reliably composed unit of text entry available to the ICT would be the word (or phrase).

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 per 500 ms.

NOTE 3: A delay of 300 ms, or less, produces a better impression of flow to the user.

6.4 Alternatives to voice-based services

Where ICT provides real-time voice-based communication and also provides voice mail, auto-attendant, or interactive voice response facilities, the ICT should 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: Solutions capable of handling audio, real-time text and video media could satisfy the above requirement.

6.4 Alternatives to voice-based services

Where ICT provides real-time voice-based communication and also provides voice mail, auto-attendant, or interactive voice response facilities, the ICT should 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: Solutions capable of handling audio, real-time text and video media could satisfy the above requirement.

6.4 Alternatives to voice-based services

Where ICT provides real-time voice-based communication and also 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.

Functional change

Explanatory update

Stylistic rewording

6.4 Alternatives to voice-based services

Where ICT provides real-time voice-based communication and also 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.

6.5.5 Visual indicator of audio with video

Where ICT provides two-way voice communication, and includes real-time video functionality, the ICT shall provide a real-time visual indicator of audio activity.

NOTE 1: The visual indicator may be a simple visual dot or LED, 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.

6.5.5 Visual indicator of audio with video

Where ICT provides two-way voice communication, and includes real-time video functionality, the ICT shall provide a real-time visual indicator of audio activity.

NOTE 1: The visual indicator may be a simple visual dot or LED, 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.

6.5.6 Speaker identification with video (sign language) communication

Where ICT provides speaker identification for voice users, it 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 calls.

NOTE 2: This mechanism might be triggered manually by a user, or automatically where this is technically achievable.

6.5.6 Speaker identification with video (sign language) communication

Where ICT provides speaker identification for voice users, it 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 calls.

NOTE 2: This mechanism might be triggered manually by a user, or automatically where this is technically achievable.

6.6 Alternatives to video-based services

Where ICT provides real-time video-based communication and also provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:

1. for audible information, without the use of hearing;
2. for spoken commands, without the use of speech;
3. for visual information, without the use of vision.

NOTE: Solutions capable of generating real-time captions or handling real-time text could satisfy the above requirement.

6.6 Alternatives to video-based services

Where ICT provides real-time video-based communication and also provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:

1. for audible information, without the use of hearing;
2. for spoken commands, without the use of speech;
3. for visual information, without the use of vision.

NOTE: Solutions capable of generating real-time captions or handling real-time text could satisfy the above requirement.

6.6 Alternatives to video-based services

Where ICT provides real-time video-based communication and also provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:

1. for audible information, without the use of hearing;
2. for spoken commands, without the use of speech;
3. for visual information, without the use of vision.

NOTE: Solutions capable of generating real-time captions or handling RTT could satisfy the above requirement.

6.6 Alternatives to video-based services

Where ICT provides real-time video-based communication and also provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:

1. for audible information, without the use of hearing;
2. for spoken commands, without the use of speech;
3. for visual information, without the use of vision.

NOTE: Solutions capable of generating real-time captions or handling RTT could satisfy the above requirement.

7.1.2 Captioning synchronization

Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions.

7.1.2 Captioning synchronization

Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions.

7.1.2 Captioning synchronization

Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions as follows:

• Captions in recorded material: within 100 ms of the time stamp of the caption
• Live captions: within 100 ms of the availability of the caption to the player.

7.1.2 Captioning synchronization

Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions as follows:

• Captions in recorded material: within 100 ms of the time stamp of the caption.

• Live captions: within 100 ms of the availability of the caption to the player.

7.1.4 Captions characteristics

Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual requirements, except where the captions 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.

7.1.4 Captions characteristics

Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual requirements, except where the captions 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.

7.1.5 Spoken subtitles

Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.

NOTE 1: Being able to manage speech output range for spoken subtitles independently from general ICT speech is preferable for most users. That is possible when the audio file with spoken subtitle is delivered in a separate audio track and mixed in the end users device.

NOTE 2: Presenting the separate audio track with spoken subtitles in synchronization with the displayed subtitles/captions improves understandability of the subtitles.

NOTE 3: Providing subtitles/captions as separate text-streams, facilitates converting the respective texts into audio.

NOTE 4: Subtitles that are bitmap images are examples where the content of the displayed captions will not be programmatically determinable.

7.1.5 Spoken subtitles

Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.

NOTE 1: Being able to manage speech output range for spoken subtitles independently from general ICT speech is preferable for most users. That is possible when the audio file with spoken subtitle is delivered in a separate audio track and mixed in the end users device. NOTE 2: Presenting the separate audio track with spoken subtitles in synchronization with the displayed subtitles/captions improves understandability of the subtitles.

NOTE 3: Providing subtitles/captions as separate text-streams, facilitates converting the respective texts into audio.

NOTE 4: Subtitles that are bitmap images are examples where the content of the displayed captions will not be programmatically determinable.

7.2.1 Audio description playback

Where ICT displays video with synchronized audio, it 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.

7.2.1 Audio description playback

Where ICT displays video with synchronized audio, it 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.

7.2.1 Audio description playback

Where ICT displays video with synchronized audio, it 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.

7.2.1 Audio description playback

Where ICT displays video with synchronized audio, it 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.

7.2.2 Audio description synchronization

Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

7.2.2 Audio description synchronization

Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

7.2.2 Audio description synchronization

Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

7.2.2 Audio description synchronization

Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.

8.3.0 General

The present document defines the dimensions for accessing stationary ICT that can be placed in a built environment, but does not define the dimensions of the built environment in general.

The scope includes stationary ICT, of which floors and circulation spaces are "an integral part" (typically kiosks and cabins), and where there are external reach ranges relevant for operating the stationary ICT.

Clauses 8.3.2 to 8.3.4 specify mandatory limits for the maximum and minimum height of operable parts and displays.

Based on dimensions shown in figure 53 of ISO 21542:2011, it is recommended that the possible height range is reduced to:

• minimum and maximum heights of operable parts: 800 mm and 1 100 mm respectively, and
• minimum and maximum heights of displays: 1 200 mm and 1 400 mm respectively.

8.3.0 General

The present document defines the dimensions for accessing stationary ICT that can be placed in a built environment, but does not define the dimensions of the built environment in general.

The scope includes stationary ICT, of which floors and circulation spaces are "an integral part" (typically kiosks and cabins), and where there are external reach ranges relevant for operating the stationary ICT.

Clauses 8.3.2 to 8.3.4 specify mandatory limits for the maximum and minimum height of operable parts and displays. Based on dimensions shown in Figure 53 of ISO 21542:2011, it is recommended that the possible height range is reduced to:

• minimum and maximum heights of operable parts: 800 mm and 1 100 mm respectively, and

• minimum and maximum heights of displays: 1 200 mm and 1 400 mm respectively.

8.3.2.1 Change in level

Where there is a change in floor level that is integral to the ICT then it should be ramped with a slope no steeper than 1:48.

Exceptions:

1. If the change in floor level is less than or equal to 6,4 mm (¼ inch) the change may be vertical.
2. If the change in floor level is less than or equal to 13 mm (½ inch) the change may have a slope not steeper than 1:2.

8.3.2.1 Change in level

Where there is a change in floor level that is integral to the ICT then it should be ramped with a slope no steeper than 1:48.

Exceptions:

1. If the change in floor level is less than or equal to 6,4 mm (¼ inch) the change may be vertical.
2. If the change in floor level is less than or equal to 13 mm (½ inch) the change may have a slope not steeper than 1:2.

8.3.4.1 Change in level

Where stationary ICT has a floor within it, then any change of floor level within it or entering it shall be ramped with a slope no steeper than 1:48.

Exceptions:

1. If the change in floor level is less than or equal to 6,4 mm (¼ inch) the change may be vertical.
2. If the change in floor level is less than or equal to 13 mm (½ inch) the change may have a slope not steeper than 1:2.

Numbering change

Stylistic rewording

Functional change

8.3.4.1 Change in level

Where stationary ICT has a floor within it, then any change of floor level within it or entering it shall be ramped with a

slope no steeper than 1:48.

Exceptions:

1. If the change in floor level is less than or equal to 6,4 mm (¼ inch) the change may be vertical as shown in Figure 8.
2. If the change in floor level is less than or equal to 13 mm (½ inch) the change may have a slope not steeper than 1:2.

8.3.2.3.1 General

Where the access space is integral to the ICT, at least one full side of the space should be unobstructed.

8.3.2.3.1 General

Where the access space is integral to the ICT, at least one full side of the space should be unobstructed.

8.3.4.3.1 General

Where stationary ICT has an access space inside it, at least one full side of the space shall be unobstructed.

Numbering change

Stylistic rewording

Functional change

8.3.4.3.1 General

Where stationary ICT has an access space inside it, at least one full side of the space shall be unobstructed.

8.3.2.3.2 Forward approach

Where the operating area is inside an alcove integral to the ICT, the alcove is deeper than 610 mm (24 inches), and where a forward approach is necessary, the dimension of the access space should be a minimum of 915 mm (36 inches) wide.

8.3.2.3.2 Forward approach

Where the operating area is inside an alcove integral to the ICT, the alcove is deeper than 610 mm (24 inches), and where a forward approach is necessary, the dimension of the access space should be a minimum of 915 mm (36 inches) wide.

8.3.4.3.2 Forward approach

Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 610 mm (24 inches), and where a forward approach is necessary, the dimension of the access space shall be a minimum of 915 mm (36 inches) wide.

Numbering change

Stylistic rewording

Functional change

8.3.4.3.2 Forward approach

Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 610 mm (24 inches), and where a forward approach is necessary, the dimension of the access space shall be a minimum of 915 mm (36 inches) wide.

8.3.2.3.3 Parallel approach

Where the operating area is inside an alcove integral to the ICT, the alcove is deeper than 380 mm (15 inches), and where a parallel approach is possible, the dimension of the access space should be a minimum of 1 525 mm (60 inches) wide.

8.3.2.3.3 Parallel approach

Where the operating area is inside an alcove integral to the ICT, the alcove is deeper than 380 mm (15 inches), and where a parallel approach is possible, the dimension of the access space should be a minimum of 1 525 mm (60 inches) wide.

8.3.4.3.3 Parallel approach

Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 380 mm (15 inches), and where a parallel approach is possible, the dimension of the access space shall be a minimum of 1 525 mm (60 inches) wide.

Numbering change

Stylistic rewording

Functional change

8.3.4.3.3 Parallel approach

Where the operating area is inside an alcove within the stationary ICT, the alcove is deeper than 380 mm (15 inches), and where a parallel approach is possible, the dimension of the access space shall be a minimum of 1 525 mm (60 inches) wide.

8.3.5 Installation instructions

Where an ICT is intended to be installed, instructions should be made available which outline a method to install the ICT in a manner that ensures that the dimensions of the integral spaces of the ICT conform to clauses 8.3.2 to 8.3.4.

8.3.5 Installation instructions

Where an ICT is intended to be installed, instructions should be made available which outline a method to install the ICT in a manner that ensures that the dimensions of the integral spaces of the ICT conform to clauses 8.3.2 to 8.3.4.

8.3.6 Installation instructions

Installation instructions shall be made available for all stationary ICT. These instructions shall give guidance on how to install the ICT in a manner that takes into account applicable requirements for accessibility of the built environment as they apply to the installation of the ICT. Where there are no such requirements the instructions should require that the dimensions of the installed ICT conform to clauses 8.3.2 to 8.3.5 of the present document.

Numbering change

Stylistic rewording

Explanatory update

Functional change

8.3.6 Installation instructions

Installation instructions shall be made available for all stationary ICT. These instructions shall give guidance on how to install the ICT in a manner that takes into account applicable requirements for accessibility of the built environment as they apply to the installation of the ICT. Where there are no such requirements the instructions should require that the dimensions of the installed ICT conform to clauses 8.3.2 to 8.3.5 of the present document.

9.1.3.4 Orientation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.4 Orientation.

9.1.3.4 Orientation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.4 Orientation.

9.1.3.4 Orientation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.4 Orientation.

9.1.3.5 Identify input purpose

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

9.1.3.5 Identify input purpose

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

9.1.3.5 Identify input purpose

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

9.1.4.10 Reflow

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.10 Reflow.

9.1.4.10 Reflow

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.10 Reflow.

9.1.4.10 Reflow

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.10 Reflow.

9.1.4.11 Non-text contrast

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

9.1.4.11 Non-text contrast

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

9.1.4.11 Non-text contrast

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

9.1.4.12 Text spacing

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

9.1.4.12 Text spacing

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

9.1.4.12 Text spacing

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

9.1.4.13 Content on hover or focus

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

9.1.4.13 Content on hover or focus

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

9.1.4.13 Content on hover or focus

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

9.2.1.4 Character key shortcuts

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

9.2.1.4 Character key shortcuts

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

9.2.1.4 Character key shortcuts

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

9.2.5.1 Pointer gestures

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures.

9.2.5.1 Pointer gestures

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures.

9.2.5.1 Pointer gestures

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures.

9.2.5.2 Pointer cancellation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation.

9.2.5.2 Pointer cancellation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation.

9.2.5.2 Pointer cancellation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation.

9.2.5.3 Label in name

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

9.2.5.3 Label in name

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

9.2.5.3 Label in name

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

9.2.5.4 Motion actuation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

9.2.5.4 Motion actuation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

9.2.5.4 Motion actuation

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

9.4.1.3 Status messages

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

9.4.1.3 Status messages

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

9.4.1.3 Status messages

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

9.5 WCAG 2.1 AAA Success Criteria

In addition to the Level AA success criteria, included in clauses 9.1 to 9.4, the Web Content Accessibility Guidelines include success criteria for Level AAA. These are listed in Table 9.1. Web authors and procurement accessibility specialists are encouraged to consider the WCAG 2.1 Level AAA success criteria that, when it is possible to apply them, may provide access beyond that required in the present document.

NOTE: The W3C states that "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content".

9.5 WCAG 2.1 AAA Success Criteria

In addition to the Level AA success criteria, included in clauses 9.1 to 9.4, the Web Content Accessibility Guidelines include success criteria for Level AAA. These are listed in Table 9.1. Web authors and procurement accessibility specialists are encouraged to consider the WCAG 2.1 Level AAA success criteria that, when it is possible to apply them, may provide access beyond that required in the present document.

NOTE: The W3C states that "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content".

10.2.7 Info and relationships

Where ICT is a non-web document, it shall satisfy the success criterion.

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

NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 1.3.1 Info and Relationships.

10.1.3.1 Info and relationships

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.

10.1.3.1 Info and relationships

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.

NOTE: Where 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.

10.1.3.1 Info and relationships

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.

NOTE: Where 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.

10.1.3.4 Orientation

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

10.1.3.4 Orientation

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

10.1.3.4 Orientation

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

10.1.3.5 Identify input purpose

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

10.1.3.5 Identify input purpose

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

10.1.3.5 Identify input purpose

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

10.1.4.10 Reflow

Where ICT is a non-web document, it shall satisfy the following success criterion.

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

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

10.1.4.10 Reflow

Where ICT is a non-web document, it shall satisfy the following success criterion.

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 % zoom. For documents which are 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 % zoom.

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

10.1.4.10 Reflow

Where ICT is a non-web document, it shall satisfy the success criterion 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 % zoom. For documents which are 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 % zoom.

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

10.1.4.11 Non-text contrast

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

10.1.4.11 Non-text contrast

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

10.1.4.11 Non-text contrast

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

10.1.4.12 Text spacing

Where ICT is a non-web document that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

10.1.4.12 Text spacing

Where ICT is a non-web document that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

10.1.4.12 Text spacing

Where ICT is a non-web document that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

10.1.4.13 Content on hover or focus

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

10.1.4.13 Content on hover or focus

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

10.1.4.13 Content on hover or focus

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus.

10.2.1.4 Character key shortcuts

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

10.2.1.4 Character key shortcuts

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

10.2.1.4 Character key shortcuts

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

10.2.20 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

10.2.4.1 Void

NOTE 1: The related web page requirement "Bypass blocks" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

NOTE 2: Although not a requirement, the ability to bypass blocks of content that are repeated within documents is generally considered best practice and addresses user needs.

10.2.4.1 Void

NOTE 1: The related web page requirement "Bypass blocks" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

NOTE 2: Although not a requirement, the ability to bypass blocks of content that are repeated within documents is generally considered best practice and addresses user needs.

10.2.24 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

10.2.4.5 Void

NOTE: The related web page requirement "Multiple ways" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.2.4.5 Void

NOTE: The related web page requirement "Multiple ways" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.2.5.1 Pointer gestures

Where ICT is a non-web document, it shall satisfy the following success criterion.

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 documents that interpret pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

10.2.5.1 Pointer gestures

Where ICT is a non-web document, it shall satisfy the following success criterion.

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 documents that interpret pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

10.2.5.1 Pointer gestures

Where ICT is a non-web document, it shall satisfy the success criterion 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 documents that interpret pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

10.2.5.2 Pointer cancellation

Where ICT is a non-web document, it shall satisfy the following success criterion.

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to a document 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

10.2.5.2 Pointer cancellation

Where ICT is a non-web document, it shall satisfy the following success criterion.

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to a document 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

10.2.5.2 Pointer cancellation

Where ICT is a non-web document, it shall satisfy the success criterion. For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to a document 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

10.2.5.3 Label in name

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

10.2.5.3 Label in name

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

10.2.5.3 Label in name

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

10.2.5.4 Motion actuation

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

10.2.5.4 Motion actuation

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

10.2.5.4 Motion actuation

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

10.2.31 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

10.3.2.3 Void

NOTE: The related web page requirement "Consistent navigation" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.3.2.3 Void

NOTE: The related web page requirement "Consistent navigation" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.2.32 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

10.3.2.4 Void

NOTE: The related web page requirement "Consistent identification" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.3.2.4 Void

NOTE: The related web page requirement "Consistent identification" does not apply to single documents, but to a specific definition of "sets of documents" that are rare.

10.4.1.3 Status messages

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

10.4.1.3 Status messages

Where ICT is a non-web document, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

10.2.39 Caption positioning

Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

10.5 Caption positioning

Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

10.5 Caption positioning

Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

10.5 Caption positioning

Where ICT is a non-web document that contains synchronized media with captions, the captions should not obscure relevant information in the synchronized media.

11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the functionality of software that provides a user interface shall meet requirement 5.1.5 (Visual output for auditory information).

11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the functionality of software that provides a user interface shall meet requirement 5.1.5 (Visual output for auditory information).

11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the functionality of software that provides a user interface shall meet requirement 5.1.5 (Visual output for auditory information).

11.1.2.1.2.2 Pre-recorded video-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.1.2.1.2.2 Pre-recorded video-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.1.2.1.2.2 Pre-recorded video-only (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.2.1.6 Audio description (pre-recorded)

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion Audio description is provided for all pre-recorded video content in synchronized media.

NOTE 1: The WCAG 2.0 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 1.2.5 Audio Description (Pre-recorded) with the addition of note 1 above.

11.1.2.5 Audio description (pre-recorded)

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.5 Audio Description (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.5 Audio description (pre-recorded)

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.5 Audio Description (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.5 Audio description (pre-recorded)

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.5 Audio Description (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.3.1 Audio description or media alternative (pre-recorded - open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.3.1 Audio description or media alternative (pre-recorded - open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.3.1 Audio description or media alternative (pre-recorded - open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).

NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' and 'descriptive narration'".

NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.

11.1.2.3.2 Audio description or media alternative (pre-recorded - closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.1.2.3.2 Audio description or media alternative (pre-recorded - closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.1.2.3.2 Audio description or media alternative (pre-recorded - closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).

11.2.1.7 Info and relationships

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the success criterion Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

NOTE 1: In 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.3 Interoperability with assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.3.1 Info and Relationships with the addition of note 1 above.

11.1.3.1.1 Info and relationships (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships. NOTE: In 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 assistive technology).

11.1.3.1.1 Info and relationships (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships. NOTE: In 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 assistive technology).

11.1.3.1.1 Info and relationships (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.

NOTE: In 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 assistive technology).

11.1.3.1.2 Info and relationships (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.1.3.1.2 Info and relationships (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.1.3.1.2 Info and relationships (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.2.1.8 Meaningful sequence

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the success criterion When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 1.3.2 Meaningful Sequence.

11.1.3.2.1 Meaningful sequence (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence.

11.1.3.2.1 Meaningful sequence (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence.

11.1.3.2.1 Meaningful sequence (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence.

11.1.3.2.2 Meaningful sequence (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.1.3.2.2 Meaningful sequence (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.1.3.2.2 Meaningful sequence (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.

NOTE 1: Many people who are legally blind 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: 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.

11.1.3.4 Orientation

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

11.1.3.4 Orientation

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

11.1.3.4 Orientation

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.

11.1.3.5 Identify input purpose

Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

11.1.3.5.1 Identify input purpose (open functionality)

Where ICT is non-web software that provides a user interface and supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

Numbering change

Functional change

11.1.3.5.1 Identify input purpose (open functionality)

Where ICT is non-web software that provides a user interface and supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.

11.1.3.5.2 Identify input purpose (closed functionality)

Where ICT is non-web software that provides a user interface and is closed to assistive technologies, in at least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each input field collecting information about the user when the input field serves a purpose identified in the WCAG 2.1 Input Purposes for User Interface Components section

11.1.3.5.2 Identify input purpose (closed functionality)

Where ICT is non-web software that provides a user interface and is closed to assistive technologies, in at least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each input field collecting information about the user when the input field serves a purpose identified in the WCAG 2.1 Input Purposes for User Interface Components section.

11.2.1.13 Resize text

Where ICT is non-web software that provides a user interface and that supports access to enlargement features of platform or assistive technology, it shall satisfy the success criterion Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

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 players, unless the content will not work with zoom.

NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200 % (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.4 Resize text with the addition of notes 1 and 2 above.

11.1.4.4.2 Resize text (closed functionality)

Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

NOTE: Because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting 11.1.4.4.2 in a closed environment may place a much heavier burden on the content author.

Numbering change

Functional change

11.1.4.4.2 Resize text (closed functionality)

Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

NOTE: Because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting the present clause in a closed environment may place a much heavier burden on the content author.

11.1.4.4.2 Resize text (closed functionality)

Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

NOTE: Because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting the present clause in a closed environment may place a much heavier burden on the content author.

11.2.1.14 Images of text

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the success criterion 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 1: Logotypes (text that is part of a logo or brand name) are considered essential.

NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.5 Images of Text.

11.1.4.5.1 Images of text

(open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.4.5 Images of Text.

Numbering change

Functional change

Explanatory change

11.1.4.5.1 Images of text (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.4.5 Images of Text.

11.1.4.5.1 Images of text (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.4.5 Images of Text.

11.1.4.5.2 Images of text (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it does not need to meet the WCAG 2.1 Success Criterion 1.4.5 Images of Text because there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2.1), given that there is no interoperability with assistive technology.

11.1.4.5.2 Images of text (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for non-text content).

11.1.4.5.2 Images of text (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for non-text content).

11.1.4.10.1 Reflow (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the following success criterion.

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 % zoom. For non-web software which are 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 % zoom.

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

11.1.4.10 Reflow

Where ICT is non-web software that provides a user interface it shall satisfy the following success criterion.

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 % zoom. For non-web software which are 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 % zoom.

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

Numbering change

Functional change

11.1.4.10 Reflow

Where ICT is non-web software that provides a user interface it shall satisfy the success criterion 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 % zoom. For non-web software which are 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 % zoom.

NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.

11.1.4.10.2 Reflow (closed functionality)

Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

11.1.4.11 Non-text contrast

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

11.1.4.11 Non-text contrast

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

11.1.4.11 Non-text contrast

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.

11.1.4.12 Text spacing

Where ICT is non-web software that provides a user interface and that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

11.1.4.12 Text spacing

Where ICT is non-web software that provides a user interface and that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

11.1.4.12 Text spacing

Where ICT is non-web software that provides a user interface and that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.

11.1.4.13 Content on hover or focus

Where ICT is a non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on hover or focus.

11.1.4.13 Content on hover or focus

Where ICT is a non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on hover or focus.

11.1.4.13 Content on hover or focus

Where ICT is a non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on hover or focus.

11.2.1.1.2 Keyboard (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.1.2 Keyboard (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.1.2 Keyboard (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.4.1 Character key shortcuts (open functionality)

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

11.2.1.4.1 Character key shortcuts (open functionality)

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

11.2.1.4.1 Character key shortcuts (open functionality)

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.

11.2.1.4.2 Character key shortcuts (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.4.2 Character key shortcuts (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.4.2 Character key shortcuts (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).

11.2.1.20 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

11.2.4.1 Void

NOTE 1: The related web page requirement "Bypass blocks" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

NOTE 2: Although not a requirement, it is generally considered best practice, and to address user needs, to be able to bypass blocks of content that are repeated within software.

11.2.4.1 Void

NOTE 1: The related web page requirement "Bypass blocks" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

NOTE 2: Although not a requirement, it is generally considered best practice, and to address user needs, to be able to bypass blocks of content that are repeated within software.

11.2.1.21 Empty clause

This clause contains no requirements. It is included to align the numbering of related sub-clauses in clauses 9.2, 10.2 and 11.2.

11.2.4.2 Void

NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

NOTE 2: Although the name of a software product could be a sufficient title if it describes the topic or purpose, software names are trademarked and trademark names cannot by law be descriptive names. It is not practical to make software names both unique and descriptive.

11.2.4.2 Void

NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

NOTE 2: Although the name of a software product could be a sufficient title if it describes the topic or purpose, software names are trademarked and trademark names cannot by law be descriptive names. It is not practical to make software names both unique and descriptive.

11.3.1.1.2 Language of software (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.14 (Spoken languages).

11.3.1.1.2 Language of software (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.14 (Spoken languages).

11.3.1.1.2 Language of software (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.14 (Spoken languages).

11.2.5.1 Pointer gestures

Where ICT is non-web software that provides a user interface, it shall satisfy the following success criterion.

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

11.2.5.1 Pointer gestures

Where ICT is non-web software that provides a user interface, it shall satisfy the following success criterion.

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

11.2.5.1 Pointer gestures

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.

11.2.5.2 Pointer cancellation

Where ICT is non-web software that provides a user interface, it shall satisfy the following success criterion.

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to non-web software 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

11.2.5.2 Pointer cancellation

Where ICT is non-web software that provides a user interface, it shall satisfy the following success criterion.

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to non-web software 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

11.2.5.2 Pointer cancellation

Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function.
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion.
• Up Reversal: The up-event reverses any outcome of the preceding down-event.
• Essential: Completing the function on the down-event is essential.

NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.

NOTE 2: This requirement applies to non-web software 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: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.

11.2.5.3 Label in name

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

11.2.5.3.1 Label in name (open functionality)

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

11.2.5.3.1 Label in name (open functionality)

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.

11.2.5.3.2 Label in name (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it should meet requirement 5.1.3.3 (Auditory output correlation).

11.2.5.3.2 Label in name (closed functionality)

Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it should meet requirement 5.1.3.3 (Auditory output correlation).

11.2.5.4 Motion actuation

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

11.2.5.4 Motion actuation

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

11.2.5.4 Motion actuation

Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.

11.4.1.3.1 Status messages (open functionality)

Where ICT is non-web software, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

11.4.1.3.1 Status messages (open functionality)

Where ICT is non-web software, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.

11.4.1.3.2 Status messages (closed functionality)

Not applicable.

11.4.1.3.2 Status messages (closed functionality)

Not applicable.

13.1.1 General (informative)

Relay services enable users of different modes of communication e.g. text, sign, speech, to interact remotely through ICT with two-way communication by providing conversion between the modes of communication, normally by a human operator.

It is best practice to meet the applicable relay service requirements of ES 202 975.

13.1.1 General (informative)

Relay services enable users of different modes of communication e.g. text, sign, speech, to interact remotely through ICT with two-way communication by providing conversion between the modes of communication, normally by a human operator.

It is best practice to meet the applicable relay service requirements of ETSI ES 202 975.

13.1.1 General (informative)

Relay services enable users of different modes of communication e.g. text, sign, speech, to interact remotely through ICT with two-way communication by providing conversion between the modes of communication, normally by a human operator.

It is best practice to meet the applicable relay service requirements of ETSI ES 202 975.

13.1.1 General (informative)

Relay services enable users of different modes of communication e.g. text, sign, speech, to interact remotely through ICT with two-way communication by providing conversion between the modes of communication, normally by a human operator.

It is best practice to meet the applicable relay service requirements of ETSI ES 202 975 [i.5].

13.1.6 Speech to speech relay services

Where ICT is intended to provide a speech to speech relay service, the speech to speech relay service shall enable speech or cognitively impaired telephone users and any other user to communicate by providing assistance between them.

13.1.6 Speech to speech relay services

Where ICT is intended to provide a speech to speech relay service, the speech to speech relay service shall enable speech or cognitively impaired telephone users and any other user to communicate by providing assistance between them.

13.1.6 Speech to speech relay services

Where ICT is intended to provide a speech to speech relay service, the speech to speech relay service shall enable telephone users who are speech impaired, have limited cognitive, language and learning abilities, as well as any other user, to communicate by providing assistance between them.

Stylistic rewording

Functional change

Explanatory update

13.1.6 Speech to speech relay services

Where ICT is intended to provide a speech to speech relay service, the speech to speech relay service shall enable telephone users who are speech impaired, have limited cognitive, language and learning abilities, as well as any other user, to communicate by providing assistance between them.

13.2 Access to relay services

Where ICT systems support two-way communication and a set of relay services for such communication is specified, access to those relay services shall not be prevented for outgoing and incoming calls.

NOTE 1: Two-way communication may include voice, real-time text, or video, singly or in combinations supported by both the relay service and the ICT system.

NOTE 2: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.

13.2 Access to relay services

Where ICT systems support two-way communication and a set of relay services for such communication is specified, access to those relay services shall not be prevented for outgoing and incoming calls.

NOTE 1: Two-way communication may include voice, real-time text, or video, singly or in combinations supported by both the relay service and the ICT system.

NOTE 2: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.

13.2 Access to relay services

Where ICT systems support two-way communication, and the system is specified for use with relay services, access to those relay services shall not be prevented for outgoing and incoming calls involving: voice, RTT, or video, either individually or in combinations supported by both the relay service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.

NOTE 2: The system may be specified as needing to work with relay services by, for example: procurers, regulators, or product specifications.

Explanatory update

Stylistic rewording

Functional change

13.2 Access to relay services

Where ICT systems support two-way communication, and the system is specified for use with relay services, access to those relay services shall not be prevented for outgoing and incoming calls involving: voice, RTT, or video, either individually or in combinations supported by both the relay service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.

NOTE 2: The system may be specified as needing to work with relay services by, for example: procurers, regulators, or product specifications.

13.3 Access to emergency services

Where ICT systems support two-way communication and a set of emergency services for such communication is specified, access to those emergency services shall not be prevented for outgoing and incoming calls.

NOTE 1: Two–way communication may include voice, real-time text, or video, singly or in combinations supported by both the emergency service and the ICT system.

NOTE 2: The purpose of this requirement is to achieve functionally equivalent communication access to the emergency service by persons with disabilities.

13.3 Access to emergency services

Where ICT systems support two-way communication and a set of emergency services for such communication is specified, access to those emergency services shall not be prevented for outgoing and incoming calls.

NOTE 1: Two-way communication may include voice, real-time text, or video, singly or in combinations supported by both the emergency service and the ICT system.

NOTE 2: The purpose of this requirement is to achieve functionally equivalent communication access to the emergency service by persons with disabilities.

13.3 Access to emergency services

Where ICT systems support two-way communication, and the system is specified for use with emergency services, access to those emergency services shall not be prevented for outgoing and incoming calls involving: voice, RTT, or video, either individually or in combinations supported by both the emergency service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access to the emergency service by persons with disabilities.

NOTE 2: The system may be specified as needing to work with emergency services by, for example: procurers, regulators, or product specifications.

Explanatory update

Stylistic rewording

Functional change

13.3 Access to emergency services

Where ICT systems support two-way communication, and the system is specified for use with emergency services, access to those emergency services shall not be prevented for outgoing and incoming calls involving: voice, RTT, or video, either individually or in combinations supported by both the emergency service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access to the emergency service by persons with disabilities.

NOTE 2: The system may be specified as needing to work with emergency services by, for example: procurers, regulators, or product specifications.