Functional Accessibility Requirements

    5. Generic requirements

    5.1: Closed functionality

    5.1.1 Introduction (informative)

    ICT has closed functionality for many reasons, including design or policy. Some of the functionality of products can be closed because the product is self-contained and users are precluded from adding peripherals or software in order to access that functionality.

    ICT may have closed functionality in practice even though the ICT was not designed, developed or supplied to be closed.

    Computers that do not allow end-users to adjust settings or install software are functionally closed.

    5.1.2 General

    5.1.2.1 Closed functionality

    Where ICT has closed functionality, it shall meet the requirements set out in clauses 5.2 to 13, as applicable.

    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.

    5.1.3 Non-visual access

    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.

    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:

    a) either directly by a mechanism included in or provided with the ICT;

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

    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.

    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.

    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.

    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 [4] 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.

    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.

    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.

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

    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.

    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:

    a) for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text;

    b) where the content is generated externally and not under the control of the ICT vendor, clause 5.1.3.14 shall not be required to apply for languages not supported by the ICT's speech synthesizer;

    c) for displayed languages that cannot be selected using non-visual access;

    d) where the user explicitly selects a speech language that is different from the language of the displayed content.

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

    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 60 x H) / (π x D)

    Where:

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

    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.

    5.1.6 Operation without keyboard interface

    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.2: Activation of accessibility features

    Where ICT has documented accessibility features, it shall be possible to activate those documented accessibility features that are required to meet a specific need without relying on a method that does not support that need.

    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.

    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.5: Operable parts

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

    5.6: Locking or toggle controls

    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.

    5.6.2 Visual status

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

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

    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.

    6. ICT with two way voice communication

    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.

    6.2: Real-Time Text (RTT) functionality

    6.2.1 RTT provision

    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.

    6.2.1.2 Concurrent voice and text

    Where the ICT, or set of ICT, provided to a user, supports two-way voice communication and enables a user to communicate with another user by RTT, it shall provide a mechanism to select a mode of operation allowing concurrent voice and text.

    6.2.2 Display of Real-time 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.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.

    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:

    a) 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 [i.23] or any of its annexes for text telephony signals at the PSTN interface;

    b) ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using real-time text that conforms to RFC 4103 [i.13];

    c) ICT interoperating with other ICT using RTT that conforms with the IP Multimedia Sub-System (IMS) set of protocols specified in TS 126 114 [i.10], TS 122 173 [i.11] and TS 134 229 [i.12];

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

    6.3: Caller ID

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

    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.

    6.5: Video communication

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

    a) for audible information, without the use of hearing;

    b) for spoken commands, without the use of speech;

    c) for visual information, without the use of vision.

    7. ICT with video capabilities

    7.1: Caption processing technology

    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.

    7.1.2 Captioning synchronisation

    Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions.

    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.2: Audio description technology

    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.

    7.2.2 Audio description synchronisation

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

    8. Hardware

    8.1: General

    8.1.1 Generic requirements

    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.

    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.2: Hardware products with speech output

    8.2.1 Speech volume gain

    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.

    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.2 Magnetic coupling

    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 [1], it shall provide a means of magnetic coupling which meets the requirements of ES 200 381-1 [2].

    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 [3].

    8.3: Physical access to ICT

    8.3.1 General (informative)

    Clauses 8.3.2 to 8.3.4 describe recommendations on those dimensions that are integral to the ICT (e.g. integral shelves, or integral cabins that may restrict access to the operable parts of the ICT).

    When ICT is installed, the dimensions of the surrounding space combined with the dimensions of the ICT might affect the physical access to the ICT. Accessible physical access of the ICT would be achieved if the installation instructions referred to in clause 8.3.5 are followed.

    It may not be possible to apply all recommendations of clause 8.3 to all aspects of maintenance, repair, or occasional monitoring of equipment in all circumstances. Nevertheless, it is best practice to apply the recommendations in clause 8.3, where feasible and safe to do so.

    8.3.2 Clear floor or ground space

    8.3.2.1 Change in level

    Where there is a change in floor level that is integral to the ICT then it shall be ramped with a slope no steeper than 1:48.

    Exceptions:

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

    A diagram illustrating the content of the text 8.3.2.1 a)
    Figure 1: Vertical change in level

    b) 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 as shown in Figure 2.

    A diagram illustrating the content of the text 8.3.2.1 b)
    Figure 2: Bevelled change in level

    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. This is shown in Figure 3.

    A diagram illustrating the content of the text 8.3.2.2
    Figure 3: Clear floor or ground space

    8.3.2.3 Approach

    8.3.2.3.1 General

    Where the access space is integral to the ICT, 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. This is shown in Figure 4.

    A diagram illustrating the content of the text 8.3.2.3.2
    Figure 4: Manoeuvring Clearance in an Alcove, Forward Approach

    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. This is shown in Figure 5.

    A diagram illustrating the content of the text 8.3.2.3.3
    Figure 5: Manoeuvring Clearance in an Alcove, Parallel Approach

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

    a) extend 635 mm (25 inches) maximum under the whole obstacle;

    b) provide a space at least 430 mm (17 inches) deep and 230 mm above the floor under the obstacle;

    c) extend no more than 150 mm (6 inches) beyond any obstruction at 230 mm (9 inches) above the floor.

    This is shown in Figure 6.

    A diagram illustrating the content of the text 8.3.2.5
    Figure 6: Toe clearance

    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:

    a) extend no more than 635 mm (25 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;

    b) extend at least 280 mm (11 inches) under the obstacle at a height of 230 mm (9 inches) above the floor;

    c) extend at least 205 mm (8 inches) under the obstacle at a height of 685 mm (27 inches) above the floor;

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

    This is shown in Figure 7.

    A diagram illustrating the content of the text 8.3.2.6
    Figure 7: Knee clearance

    8.3.3 Reach range for ICT

    8.3.3.1 Forward reach

    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. This is shown in Figure 8.

    A diagram illustrating the content of the text 8.3.3.1.2
    Figure 8: Unobstructed forward reach

    8.3.3.1.2 Unobstructed low forward reach

    When the access space is integral to the ICT and the forward reach is unobstructed, the essential controls shall be located no lower than 380 mm (15 inches) above the floor of the access space. This is shown in Figure 8.

    A diagram illustrating the content of the text 8.3.3.1.2
    Figure 8: Unobstructed forward reach

    8.3.3.1.3 Obstructed reach

    8.3.3.1.3.1 Clear floor space

    Where the access space is integral to the ICT and has an obstruction which is integral to the ICT which hinders the access to any essential controls, the ICT should provide a clear floor space which extends beneath the obstructing element for a distance not less than the required reach depth over the obstruction.

    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. This is shown in Figure 9 (a).

    A diagram illustrating the content of the text 8.3.3.1.3.2. and 8.3.3.1.3.3
    Figure 9: Obstructed high reach

    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. This is shown in Figure 9 (b).

    A diagram illustrating the content of the text 8.3.3.1.3.2. and 8.3.3.1.3.3
    Figure 9: Obstructed high reach

    8.3.3.2 Side reach

    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. This is shown in Figure 10.

    A diagram illustrating the content of the text 8.3.3.2.2
    Figure 10: Unobstructed side reach

    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. This is shown in Figure 10.

    A diagram illustrating the content of the text 8.3.3.2.2
    Figure 10: Unobstructed side reach

    8.3.3.2.3 Obstructed side reach

    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. This is shown in Figure 11 (a).

    A diagram illustrating the content of the text 8.3.3.2.3.1 and 8.3.3.2.3.2
    Figure 11: Obstructed high side reach

    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. This is shown in Figure 11 (b).

    A diagram illustrating the content of the text 8.3.3.2.3.1 and 8.3.3.2.3.2
    Figure 11: Obstructed high side reach

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

    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.4: Mechanically operable parts

    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.

    8.4.2 Operation of mechanical parts

    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.

    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.

    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.

    9. Web

    9.1: General (informative)

    Requirements in clause 9 apply to web pages (as defined in clause 3.1) including:

    • documents that are web pages;
    • documents that are embedded in web pages and that are used in the rendering or that are intended to be rendered together with the web page in which they are embedded;
    • software that is a web page;
    • software that is embedded in web pages and that is used in the rendering or that is intended to be rendered together with the web page in which it is embedded.

    Requirements for other documents and software are provided in clauses 10 and 11 respectively.

    9.2: Web content requirements

    9.2.1 Non-text content

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.1.1 Non-text content.

    WCAG 2.0 Success Criterion 1.1.1 Non-text content

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

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

    9.2.2 Audio-only and video-only (pre-recorded)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.1 Audio-only and Video-only (Pre-recorded).

    WCAG 2.0 success criterion: Audio-only and video-only (pre-recorded)

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

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

    9.2.3 Captions (pre-recorded)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.2 Captions (Pre-recorded).

    WCAG 2.0 success criterion: Captions (pre-recorded)

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

    9.2.4 Audio description or media alternative (pre-recorded)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.3 Audio Description or Media Alternative (Pre-recorded).

    WCAG 2.0 success criterion: Audio description or media alternative (pre-recorded)

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

    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.

    9.2.5 Captions (live)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.4 Captions (Live).

    WCAG 2.0 success criterion: Captions (live)

    Captions are provided for all live audio content in synchronized media.

    9.2.6 Audio description (pre-recorded)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.5 Audio Description (Pre-recorded).

    WCAG 2.0 success criterion: Audio description (pre-recorded)

    Audio description is provided for all pre-recorded video content in synchronized media.

    9.2.7 Info and relationships

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.1 Info and Relationships.

    WCAG 2.0 success criterion: Info and relationships

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

    9.2.8 Meaningful sequence

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.2 Meaningful Sequence.

    WCAG 2.0 success criterion: Meaningful sequence

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

    9.2.9 Sensory characteristics

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.3 Sensory Characteristics.

    WCAG 2.0 success criterion: Sensory characteristics

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

    NOTE: For requirements related to colour, refer to WCAG 2.0 Guideline 1.4.

    9.2.10 Use of colour

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.1 Use of Color.

    WCAG 2.0 success criterion: Use of colour

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

    NOTE: This success criterion addresses colour perception specifically. Other forms of perception are covered in WCAG 2.0 Guideline 1.3 including programmatic access to colour and other visual presentation coding.

    9.2.11 Audio control

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.2 Audio Control.

    WCAG 2.0 success criterion: Audio control

    If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

    NOTE: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) shall meet this success criterion. See Conformance Requirement 5: Non-Interference.

    9.2.12 Contrast (minimum)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum).

    WCAG 2.0 success criterion: Contrast (Minimum)

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

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

    9.2.13 Resize text

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.4 Resize text.

    WCAG 2.0 success criterion: Resize text

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

    9.2.14 Images of text

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.5 Images of Text.

    WCAG 2.0 success criterion: Images of text

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

    • Customizable: The image of text can be visually customized to the user's requirements.
    • Essential: A particular presentation of text is essential to the information being conveyed.

    NOTE: Logotypes (text that is part of a logo or brand name) are considered essential.

    9.2.15 Keyboard

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.1 Keyboard.

    WCAG 2.0 success criterion: Keyboard

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

    NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

    NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

    9.2.16 No keyboard trap

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.2 No Keyboard Trap.

    WCAG 2.0 success criterion: No Keyboard Trap

    If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

    NOTE: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole document, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion.

    9.2.17 Timing adjustable

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.1 Timing Adjustable.

    WCAG 2.0 success criterion: Timing Adjustable

    For each time limit that is set by the content, at least one of the following is true:

    • Turn off: The user is allowed to turn off the time limit before encountering it; or
    • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
    • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
    • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
    • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
    • 20 Hour Exception: The time limit is longer than 20 hours.

    NOTE: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.0 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

    9.2.18 Pause, stop, hide

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.2 Pause, Stop, Hide.

    WCAG 2.0 success criterion: Pause, Stop, Hide

    For moving, blinking, scrolling, or auto-updating information, all of the following are true:

    • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
    • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

    NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.0 Guideline 2.3.

    NOTE 2: This success criteria is applicable to all content (whether or not there is an alternate accessible version of the content) since any content that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version).

    NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

    NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

    9.2.19 Three flashes or below threshold

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.3.1 Three Flashes or Below Threshold.

    WCAG 2.0 success criterion: Three Flashes or Below Threshold

    Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

    NOTE: This success criterion is applicable to all content on the Web page (whether or not there is an alternate accessible version of the content) since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version).

    9.2.20 Bypass blocks

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.1 Bypass Blocks.

    WCAG 2.0 success criterion: Bypass Blocks

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

    9.2.21 Page titled

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.2 Page Titled.

    WCAG 2.0 success criterion: Page Titled

    Web pages have titles that describe topic or purpose.

    9.2.22 Focus Order

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.3 Focus Order.

    WCAG 2.0 success criterion: Focus Order

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

    9.2.23 Link purpose (in context)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.4 Link Purpose (In Context).

    WCAG 2.0 success criterion: Link Purpose (In Context)

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

    9.2.24 Multiple ways

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.5 Multiple Ways.

    WCAG 2.0 Success criterion: Multiple Ways

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

    9.2.25 Headings and labels

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.6 Headings and Labels.

    WCAG 2.0 Success Criterion: Headings and Labels

    Headings and labels describe topic or purpose.

    9.2.26 Focus visible

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.7 Focus Visible.

    WCAG 2.0 Success Criterion: Focus Visible

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

    9.2.27 Language of page

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.1 Language of Page.

    WCAG 2.0 Success Criterion: Language of Page

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

    9.2.28 Language of parts

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.2 Language of Parts.

    WCAG 2.0 Success Criterion: Language of Parts

    The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

    9.2.29 On focus

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.1 On Focus.

    WCAG 2.0 Success Criterion: On Focus

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

    9.2.30 On input

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.2 On Input.

    WCAG 2.0 Success Criterion: On Input

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

    9.2.31 Consistent navigation

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.3 Consistent Navigation.

    WCAG 2.0 Success Criterion: Consistent Navigation

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

    9.2.32 Consistent identification

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.4 Consistent Identification.

    WCAG 2.0 Success Criterion: Consistent Identification

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

    9.2.33 Error identification

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.1 Error Identification.

    WCAG 2.0 Success Criterion: Error Identification

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

    9.2.34 Labels or instructions

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.2 Labels or Instructions.

    WCAG 2.0 Success Criterion: Labels or Instructions

    Labels or instructions are provided when content requires user input.

    9.2.35 Error suggestion

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.3 Error Suggestion.

    WCAG 2.0 Success Criterion: Error Suggestion

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

    9.2.36 Error prevention (legal, financial, data)

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data).

    WCAG 2.0 Success Criterion: Error prevention (Legal, Financial, Data)

    For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

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

    9.2.37 Parsing

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.1 Parsing.

    WCAG 2.0 Success Criterion: Parsing

    In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features

    NOTE: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

    9.2.38 Name, role, value

    Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.2 Name, Role, Value.

    WCAG 2.0 Success Criterion: Name, Role, Value

    For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined states, properties, and values that can be set by the user can be programmatically set and notification of changes to these items is available to user agents, including assistive technologies

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

    9.3: WCAG 2.0 conformance requirements

    Where ICT is a web page, it shall satisfy all the following five WCAG 2.0 conformance requirements at Level AA.

    1. Conformance level
    2. Full pages
    3. Complete processes
    4. Only Accessibility-Supported Ways of Using Technologies
    5. Non-interference

    10. Non-web documents

    10.1: General (informative)

    Requirements in clause 10 apply to documents:

    • that are not web pages;
    • that are not embedded in web pages;
    • that are embedded in web pages and that are not used in the rendering and that are not intended to be rendered together with the web page in which they are embedded.

    Clause 9 provides requirements for documents that are in web pages or that are embedded in web pages and that are used in the rendering or that are intended to be rendered together with the web page in which they are embedded.

    10.2: Document success criteria

    Note: The success criteria set out in this clause are intended to harmonize with the Working Group Note [i.26] produced by the W3C's WCAG2 ICT Task Force.

    10.2.1 Non-text content

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.1.

    Table 10.1: Document success criterion: Non-text content

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

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

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

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.1.1 Non-text content with the words

    10.2.2 Audio-only and video-only (pre-recorded)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.2.

    Table 10.2: Document success criterion: Audio-only and video-only (pre-recorded)

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

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

    NOTE 1: The alternative can be provided directly in the document - or provided in an alternate version that meets the success criterion.

    NOTE 2: This success criterion is identical to the WCAG 2.0

    10.2.3 Captions (pre-recorded)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.3.

    Table 10.3: Document success criterion: Captions (pre-recorded)

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

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

    NOTE 1: The alternative can be provided directly in the document - or provided in an alternate version that meets the success criterion.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.2.1 Audio-only and Video-only (Pre-recorded) with the addition of note 1 above.

    10.2.4 Audio description or media alternative (pre-recorded)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.4.

    Table 10.4: Document success criterion: Audio description or media alternative (pre-recorded)

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

    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.3 Audio Description or Media Alternative (Pre-recorded) with the addition of notes 1 and 2 above.

    10.2.5 Captions (live)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.5.

    Table 10.5: Document success criterion: Captions (live)

    Captions are provided for all live audio content in synchronized media.

    NOTE 1: The WCAG 2.0 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.0, to meet this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.2.4 Captions (Live) with the addition of note 1 above.

    10.2.6 Audio description (pre-recorded)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.6.

    Table 10.6: Document success criterion: Audio description (pre-recorded)

    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) (Level AA) with the addition of note 1 above.

    10.2.7 Info and relationships

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.7.

    Table 10.7: Document success criterion: Info and relationships

    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.2.8 Meaningful sequence

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.8.

    Table 10.8: Document success criterion: Meaningful sequence

    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.

    10.2.9 Sensory characteristics

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.9.

    Table 10.9: Document success criterion: Sensory characteristics

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

    NOTE 1: For requirements related to colour, refer to WCAG 2.0 Guideline 1.4 [4].

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.3.3 Sensory Characteristics with the words "WCAG 2.0" added before the word "Guideline" in note 1 above.

    10.2.10 Use of colour

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.10.

    Table 10.10: Document success criterion: Use of colour

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

    NOTE 1: This success criterion addresses colour perception specifically. Other forms of perception are covered in WCAG 2.0 Guideline 1.3 [4] including programmatic access to colour and other visual presentation coding.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.1 Use of Color with the words "WCAG 2.0" added before the word "Guideline" in note 1 above.

    10.2.11 Audio control

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.11.

    Table 10.11: Document success criterion: Audio control

    If any audio in a document plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

    NOTE 1: Since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole document, all content in the document (whether or not it is used to meet other success criteria) shall meet this success criterion.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.2 Audio Control replacing "on a Web page" with "in a document", "any content" with "any part of a document", "whole page" with "whole document", "on the Web page" with "in the document", removing "See Conformance Requirement 5: Non-Interference" and adding note 1.

    10.2.12 Contrast (minimum)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.12.

    Table 10.12: Document success criterion: Contrast (minimum)

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

    • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.
    • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
    • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum).

    10.2.13 Resize text

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.13.

    Table 10.13: Document success criterion: Resize text

    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.

    10.2.14 Images of text

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.14.

    Table 10.14: Document success criterion: Images of text

    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.

    10.2.15 Keyboard

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.15.

    Table 10.15: Document success criterion: Keyboard

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

    NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

    NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 2.1.1 Keyboard.

    10.2.16 No keyboard trap

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.16.

    Table 10.16: Document success criterion: No keyboard trap

    If keyboard focus can be moved to a component of the document using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

    NOTE 1: Since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole document, all content in the document (whether or not it is used to meet other success criteria) must meet this success criterion.

    NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 2.1.2 No Keyboard Trap replacing "page" and "Web page" with "document", removing "See Conformance Requirement 5: Non-Interference" and with the addition of note 1 above.

    10.2.17 Timing adjustable

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.17.

    Table 10.17: Document success criterion: Timing adjustable

    For each time limit that is set by the document, at least one of the following is true:

    • Turn off: The user is allowed to turn off the time limit before encountering it; or
    • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
    • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
    • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
    • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
    • 20 Hour Exception: The time limit is longer than 20 hours.

    NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.0 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "documents" and with the words "WCAG 2.0" added before the word "Success Criterion" in note 1 above.

    10.2.18 Pause, stop, hide

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.18.

    Table 10.18: Document success criterion: Pause, stop, hide

    For moving, blinking, scrolling, or auto-updating information, all of the following are true:

    • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
    • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

    NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.0 Guideline 2.3.

    NOTE 2: This success criteria is applicable to all content in the document (whether or not there is an alternate accessible version of the document) since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole document (including a link to the alternate version).

    NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

    NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

    NOTE 5: This is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.

    NOTE 6: This success criterion is identical to the WCAG 2.0 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "Web page" with "document", removing "See Conformance Requirement 5: Non-Interference" in note 2 of the success criterion, with the words "WCAG 2.0" added before the word "Guideline" in note 1 above and with note 2 above re-drafted to avoid the use of the word "must".

    10.2.19 Three flashes or below threshold

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.19.

    Table 10.19: Document success criterion: Three flashes or below threshold

    Documents do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

    NOTE 1: This success criterion is applicable to all content in the document (whether or not there is an alternate accessible version of the document) since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole document (including a link to the alternate version).

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing "Web pages" with "documents", "the whole page" with "the whole document", "the Web page" with "the document" and removing "See Conformance Requirement 5: Non-Interference" and with note 2 above re-drafted to avoid the use of the word "must".

    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.21 Document titled

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.21.

    Table 10.21: Document success criterion: Document titled

    Documents have titles that describe topic or purpose.

    NOTE 1: The name of a document (e.g. document, media file) is a sufficient title if it describes the topic or purpose.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.2 Page Titled replacing "Web pages" with "documents", "Page" with "Document" and with the addition of note 1 above.

    10.2.22 Focus order

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.22.

    Table 10.22: Document success criterion: Focus order

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

    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.3 Focus Order replacing "Web page" with "document".

    10.2.23 Link purpose (in context)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.23.

    Table 10.23: Document success criterion: Link purpose (in context)

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

    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.4 Link Purpose (In Context).

    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.25 Headings and labels

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.25.

    Table 10.25: Document success criterion: Headings and labels

    Headings and labels describe topic or purpose.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.6 Headings and Labels.

    10.2.26 Focus visible

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.26.

    Table 10.26: Document success criterion: Focus visible

    Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.7 Focus Visible.

    10.2.27 Language of page

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.27.

    Table 10.27: Document success criterion: Language of page

    The default human language of each document can be programmatically determined.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.1.1 Language of Page replacing "web page" with "document".

    10.2.28 Language of parts

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.28.

    Table 10.28: Document success criterion: Language of parts

    The human language of each passage or phrase in the document can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

    NOTE 1: There are some document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document, and it would not be possible to meet this success criterion with those technologies.

    NOTE 2: Inheritance is one common method. For example a document provides the language that it is using and it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated.

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 3.1.2 Language of Parts replacing "content" with "document" and with the addition of note 1.

    10.2.29 On focus

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.29.

    Table 10.29: Document success criterion: On focus

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

    NOTE 1: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 3.2.1 On Focus with the addition of note 1.

    10.2.30 On input

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.30.

    Table 10.30: Document success criterion: On input

    Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.2.2 On Input.

    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.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.2.33 Error identification

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.33.

    Table 10.33: Document success criterion: Error identification

    If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.1 Error Identification.

    10.2.34 Labels or instructions

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.34.

    Table 10.34: Document success criterion: Labels or instructions

    Labels or instructions are provided when content requires user input.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.2 Labels or Instructions.

    10.2.35 Error suggestion

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.35.

    Table 10.35: Document success criterion: Error suggestion

    If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.3 Error Suggestion.

    10.2.36 Error prevention (legal, financial, data)

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.36.

    Table 10.36: Document success criterion: Error prevention (legal, financial, data)

    For documents that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

    1. Reversible: Submissions are reversible.
    2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
    3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) replacing "web pages" with "documents".

    10.2.37 Parsing

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.37.

    Table 10.37: Document success criterion: Parsing

    For documents that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

    NOTE 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

    NOTE 2: Markup is not always available to assistive technology or to user selectable user agents such as browsers. In such cases, conformance to this provision would have no impact on accessibility as it can for web content where it is exposed.

    NOTE 3: Examples of markup that is separately exposed and available to assistive technologies and to user agents include but are not limited to: documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely in two ways: (a) by assistive technologies which may directly open the document, (b) by assistive technologies using DOM APIs of user agents for these document formats.

    NOTE 4: This success criterion is identical to the WCAG 2.0 Success Criterion 4.1.1 Parsing replacing "In content implemented using markup languages" with "For documents that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent" with the addition of notes 2 and 3 above.

    10.2.38 Name, role, value

    Where ICT is a non-web document, it shall satisfy the success criterion in Table 10.38.

    Table 10.38: Document success criterion: Name, role, value

    For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

    NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.

    NOTE 2: For document formats that support interoperability with assistive technology, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 4.1.2 Name, Role, Value replacing the original WCAG 2.0 note with: "This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification." and with the addition of note 2 above.

    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.2.40 Audio description timing

    Where ICT is a non-web document that contains synchronized media with audio description, the audio description should not interfere with relevant audio information in the synchronized media.

    11. Software

    11.1: General (informative)

    This clause provides requirements for:

    • platform software;
    • software that provides a user interface including content that is in the software;
    • authoring tools;
    • software that operates as assistive technology.

    11.2: Non-Web software success criteria

    Requirements in clause 11.2 apply to software:

    • that is not a web page;
    • not embedded in web pages nor used in the rendering or functioning of the page.

    Clause 9 provides requirements for software that is in web pages or that is embedded in web pages and that is used in the rendering or that is intended to be rendered together with the web page in which it is embedded.

    Clause 11.2.1 contains the software requirements for the functionality of software that provides a user interface and that is not closed functionality.

    Clause 11.2.2 contains the software requirements for the closed functionality of software that provides a user interface.

    The success criteria set out in clause 11.2 are intended to harmonize with the W3C Working Group Note [i.26] produced by the W3C's WCAG2ICT Task Force (http://www.w3.org/WAI/GL/WCAG2ICT-TF/).

    11.2.1 Non-Web software success criteria (excluding closed functionality)

    11.2.1.1 Non-text content (screen reading supported)

    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 in Table 11.1.

    Table 11.1: Software success criterion: Non-text content

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

    • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to WCAG 2.0 Guideline 4.1 [4] for additional requirements for controls and content that accepts user input.)
    • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to WCAG 2.0 Guideline 1.2 [4] for additional requirements for media.)
    • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
    • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
    • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
    • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
    NOTE 1: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.
    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.1.1 Non-text content with the words "WCAG 2.0" added before each occurrence of the word "guideline" and with the addition of note 1 above.

    11.2.1.2 Audio-only and video-only (pre-recorded)

    Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading and where pre-recorded auditory information is not needed to enable the use of closed functions of ICT, it shall satisfy the success criterion in Table 11.2.

    Table 11.2: Software success criterion: Audio-only and video-only (pre-recorded)

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

    • Pre-recorded Audio-only: An alternative for time-based media is provided that presents equivalent information for pre-recorded audio-only content.
    • Pre-recorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for pre-recorded video-only content.
    NOTE 1: The alternative can be provided directly in the software - or provided in an alternate version that meets the success criterion.
    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.2.1 Audio-only and Video-only (Pre-recorded) with the addition of note 1 above.

    11.2.1.3 Captions (pre-recorded)

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.3.

    Table 11.3: Software success criterion: Captions (pre-recorded)

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

    NOTE 1: The WCAG 2.0 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.0, to meet this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".

    NOTE 2: This success criterion is identic.

    11.2.1.4 Audio description or media alternative (pre-recorded)

    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 in Table 11.4.

    Table 11.4: Software success criterion: Audio description or media alternative (pre-recorded)

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

    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.3 Audio Description or Media Alternative (Pre-recorded) with the addition of notes 1 and 2 above.

    11.2.1.5 Captions (live)

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.5.

    Table 11.5: Software success criterion: Captions (live)

    Captions are provided for all live audio content in synchronized media.

    NOTE 1: The WCAG 2.0 definition of "captions" notes that "in some countries, captions are called subtitles". They are also sometimes referred to as "subtitles for the hearing impaired". Per the definition in WCAG 2.0, to meet this success criterion, whether called captions or subtitles, they would have to provide "synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content" where non-speech information includes "sound effects, music, laughter, speaker identification and location".

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.2.4 Captions (Live) with the addition of note 1 above.

    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 in Table 11.6.

    Table 11.6: Software success criterion: Audio description (pre-recorded)

    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.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 in Table 11.7.

    Table 11.7: Software success criterion: Info and relationships

    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.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 in Table 11.8.

    Table 11.8: Software success criterion: Document success criterion: Meaningful sequence

    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.2.1.9 Sensory characteristics

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.9.

    Table 11.9: Software success criterion: Software success criterion: Sensory characteristics

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

    NOTE 1: For requirements related to colour, refer to WCAG 2.0 Guideline 1.4 [4].

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.3.3 Sensory Characteristics with the words "WCAG 2.0" added before the word "Guideline" in note 1 above.

    11.2.1.10 Use of colour

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.10.

    Table 11.10: Software success criterion: Software success criterion: Use of colour

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

    NOTE 1: This success criterion addresses colour perception specifically. Other forms of perception are covered in WCAG 2.0 Guideline 1.3 [4] including programmatic access to colour and other visual presentation coding.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.1 Use of Color with the words "WCAG 2.0" added before the word "Guideline" in note 1 above.

    11.2.1.11 Audio control

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.11.

    Table 11.11: Software success criterion: Document success criterion: Audio control

    If any audio in a software plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

    NOTE 1: Since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software, all content in the software (whether or not it is used to meet other success criteria) shall meet this success criterion.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.2 Audio Control replacing "on a Web page" with "in a software", "any content" with "any part of a software", "whole page" with "whole software", "on the Web page" with "in the software", removing "See Conformance Requirement 5: Non-Interference" and adding note 1.

    11.2.1.12 Contrast (minimum)

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.12.

    Table 11.12: Software success criterion: Document success criterion: Contrast (minimum)

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

    • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.
    • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
    • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum).

    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 in Table 11.13.

    Table 11.13: Software success criterion: Document success criterion: Resize text

    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.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 in Table 11.14.

    Table 11.14: Software success criterion: Document success criterion: Images of text

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

    Where ICT is non-web software that provides a user interface and that supports access to keyboards or a keyboard interface, it shall satisfy the success criterion in Table 11.15.

    Table 11.15: Software success criterion: Document success criterion: Keyboard

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

    NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

    NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

    NOTE 3: This does not imply that software is required to directly support a keyboard or "keyboard interface". Nor does it imply that software is required to provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

    NOTE 4: This success criterion is identical to the WCAG 2.0 Success Criterion 2.1.1 Keyboard with the addition of note 3 above.

    11.2.1.16 No keyboard trap

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.16.

    Table 11.16: Software success criterion: Document success criterion: No keyboard trap

    If keyboard focus can be moved to a component of the software using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

    NOTE 1: Since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole document, all content in the document (whether or not it is used to meet other success criteria) shall meet this success criterion.

    NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 2.1.2 No Keyboard Trap replacing "page" and "Web page" with "document", removing "See Conformance Requirement 5: Non-Interference" and with the addition of note 1 above.

    11.2.1.17 Timing adjustable

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.17.

    Table 11.17: Software success criterion: Document success criterion: Timing adjustable

    For each time limit that is set by the software, at least one of the following is true:

    • Turn off: The user is allowed to turn off the time limit before encountering it; or
    • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
    • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
    • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
    • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
    • 20 Hour Exception: The time limit is longer than 20 hours.

    NOTE 1: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with clause 11.2.1.29 (On focus), which puts limits on changes of content or context as a result of user action.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "software" and with the words "WCAG 2.0" added before the word "Success Criterion" in note 1 above.

    11.2.1.18 Pause, stop, hide

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.18.

    Table 11.18: Software success criterion: Document success criterion: Pause, stop, hide

    For moving, blinking, scrolling, or auto-updating information, all of the following are true:

    • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
    • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

    NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.0 Guideline 2.3.

    NOTE 2: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible mode of operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software (including a user interface element that enables the user to activate the alternate accessible mode of operation).

    NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

    NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

    NOTE 5: This is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.

    NOTE 6: This success criterion is identical to the WCAG 2.0 Success Criterion 2.2.2 Pause, Stop, Hide replacing "page" and "Web page" with "software", removing "See Conformance Requirement 5: Non-Interference" in note 2 of the success criterion, with the words "WCAG 2.0" added before the word "Guideline" in note 1 above, with note 2 above re-drafted to avoid the use of the word "must" and with the addition of note 5 above.

    11.2.1.19 Three flashes or below threshold

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.19.

    Table 11.19: Software success criterion: Three flashes or below threshold

    Software does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

    NOTE 1: This success criteria is applicable to all content in the software (whether or not there is an alternate accessible mode of operation of the software) since any part of a software that does not meet this success criterion can interfere with a user's ability to use the whole software (including a user interface element that enables the user to activate the alternate accessible mode of operation).

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.3.1 Three Flashes or Below Threshold replacing "Web pages" with "software", "the whole page" with "the whole software", "the Web page" with "the software" and removing "See Conformance Requirement 5: Non-Interference" and with note 1 above re-drafted to avoid the use of the word "must".

    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.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.1.22 Focus order

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.22.

    Table 11.22: Software success criterion: Focus order

    If software can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.3 Focus order replacing "Web page" with "software".

    11.2.1.23 Link purpose (in context)

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.23.

    Table 11.23: Software success criterion: Link purpose (in context)

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

    NOTE 1: In software, a "link" is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.4 Link purpose (in context), replacing both "web page" and "page" with "software" and with the addition of note 1 above.

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

    11.2.1.25 Headings and labels

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.25.

    Table 11.25: Software success criterion: Headings and labels

    Headings and labels describe topic or purpose.

    NOTE 1: In software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.6 Headings and labels with the addition of note 1 above.

    11.2.1.26 Focus visible

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.26.

    Table 11.26: Software success criterion: Focus visible

    Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 2.4.7 Focus visible.

    11.2.1.27 Language of software

    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 in Table 11.27.

    Table 11.27: Software success criterion: Language of software

    The default human language of software can be programmatically determined.

    NOTE 1: Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 3.1.1 Language of page, replacing "each web page" with "software" and with the addition of note 1 above.

    11.2.1.28 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.1.29 On focus

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.29.

    Table 11.29: Software success criterion: On focus

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

    NOTE 1: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.

    NOTE 2: This success criterion is identical to the WCAG 2.0 Success Criterion 3.2.1 On focus, with the addition of note 1 above.

    11.2.1.30 On input

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.30.

    Table 11.30: Software success criterion: On input

    Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.2.2 On input.

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

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

    11.2.1.33 Error identification

    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 in Table 11.33.

    Table 11.33: Software success criterion: Error identification

    If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.1 Error identification.

    11.2.1.34 Labels or instructions

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.34.

    Table 11.34: Software success criterion: Labels or instructions

    Labels or instructions are provided when content requires user input.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.2 Labels or instructions.

    11.2.1.35 Error suggestion

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.35.

    Table 11.35: Software success criterion: Error suggestion

    If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.3 Error suggestion.

    11.2.1.36 Error prevention (legal, financial, data)

    Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.36.

    Table 11.36: Software success criterion: Error prevention (legal, financial, data)

    For software that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

    1. Reversible: Submissions are reversible.
    2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
    3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
    NOTE: This success criterion is identical to the WCAG 2.0 Success Criterion 3.3.4 Error prevention (legal, financial, data) replacing "web pages" with "software".

    11.2.1.37 Parsing

    Where ICT is non-web software that provides a user interface and that supports access to any assistive technologies, it shall satisfy the success criterion in Table 11.37.

    Table 11.37: Software success criterion: Parsing

    For software that uses markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

    NOTE 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

    NOTE 2: Markup is not always available to assistive technology or to user selectable user agents such as browsers. In such cases, conformance to this provision would have no impact on accessibility as it can for web content where it is exposed.

    NOTE 3: Examples of markup that is separately exposed and available to assistive technologies and to user agents include but are not limited to: documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely in two ways: (a) by assistive technologies which may directly open the document, (b) by assistive technologies using DOM APIs of user agents for these document formats.

    NOTE 4: Examples of markup used internally for persistence of the software user interface that are never exposed to assistive technology include but are not limited to: XUL, GladeXML, and FXML. In these examples assistive technology only interacts with the user interface of generated software.

    NOTE 5: This success criterion is identical to the WCAG 2.0 Success Criterion 4.1.1 Parsing replacing "In content implemented using markup languages" with "For software that uses markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent" with the addition of notes 2 and 3 above.

    11.2.1.38 Name, role, value

    Where ICT is non-web software that provides a user interface and that supports access to any assistive technologies, it shall satisfy the success criterion in Table 11.38.

    Table 11.38: Software success criterion: Name, role, value

    For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

    NOTE 1: This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.

    NOTE 2: For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardised ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).

    NOTE 3: This success criterion is identical to the WCAG 2.0 Success Criterion 4.1.2 Name, Role, Value replacing the original WCAG 2.0 note with: "This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification." and the addition of note 2 above.

    11.2.2 Non-Web software requirements (closed functionality)

    11.2.2.1 Non-text content

    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.2.2.2 Audio-only and video-only (pre-recorded)

    11.2.2.2.1 Pre-recorded audio-only

    Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and 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.2.2.2.2 Pre-recorded video-only

    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.2.3 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.2.4 Audio description or media alternative (pre-recorded)

    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.2.5 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.2.6 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.2.7 Info and relationships

    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.

    11.2.2.8 Meaningful sequence

    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.

    11.2.2.9 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.2.10 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.2.11 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.2.12 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.2.13 Resize text

    Where ICT is non-web software that provides a user interface which is not able to access to enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).

    11.2.2.14 Images of text

    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 "Images of text" success criterion in Table 11.14 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.0), given that there is no interoperability with assistive technology.

    11.2.2.15 Keyboard

    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.2.16 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.2.17 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.2.18 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.2.19 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.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.

    11.2.2.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.2.22 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.2.23 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.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.

    11.2.2.25 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.2.26 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.2.27 Language of software

    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.2.28 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.2.29 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.2.30 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.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.

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

    11.2.2.33 Error Identification

    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.15 (Non-visual error identification).

    11.2.2.34 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.2.35 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.2.36 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.2.37 Parsing

    Where ICT is non-web software that provides a user interface which is closed to all assistive technology it shall not have to meet the "Parsing" success criterion in Table 11.37 because the intent of this success criterion is to provide consistency so that different user agents or assistive technologies will yield the same result.

    11.2.2.38 Name, role, value

    Where ICT is non-web software that provides a user interface which is closed to all assistive technology it shall not have to meet the "Name, role, value" success criterion in Table 11.38 because this success criterion requires information in a programmatically determinable form.

    11.3: Interoperability with assistive technology

    11.3.1 Closed functionality

    Where the closed functionality of software conforms to clause 5.1 (Closed functionality) it shall not be required to conform with clause 11.3.2 to clause 11.3.17.

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

    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.

    11.3.2.3 Use of accessibility services

    Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.

    11.3.2.4 Assistive technology

    Where the ICT is assistive technology it shall use the documented platform accessibility services.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    11.4: Documented accessibility usage

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

    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.

    11.6: Authoring tools

    11.6.1 Content technology

    Authoring tools shall conform to clauses 11.6.2 to 11.6.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.

    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.

    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.

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

    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.

    12. Documentation and support services

    12.1: Product documentation

    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.

    12.1.2 Accessible documentation

    Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:

    a) a Web format that conforms to clause 9, or

    b) a non-web format that conforms to clause 10.

    12.2: Support services

    12.2.1 General (informative)

    ICT support services include, but are not limited to: help desks, call centres, technical support, and training services.

    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.

    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.4 Accessible documentation

    Documentation provided by support services shall be made available in at least one of the following electronic formats:

    a) a Web format that conforms to clause 9, or

    b) a non-web format that conforms to clause 10.

    13. ICT providing relay or emergency service access

    13.1: Relay services requirements

    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 [i.5].

    13.1.2 Text relay services

    Where ICT is intended to provide a text relay service, the text relay service shall enable text users and speech users to interact by providing conversion between the two modes of communication.

    13.1.3 Sign relay services

    Where ICT is intended to provide a sign relay service, the sign relay service shall enable sign language users and speech users to interact by providing conversion between the two modes of communication.

    13.1.4 Lip-reading relay services

    Where ICT is intended to provide a lip-reading relay service, the lip-reading service shall enable lip-readers and voice telephone users to interact by providing conversion between the two modes of communication.

    13.1.5 Captioned telephony services

    Where ICT is intended to provide a captioned telephony service, the captioned telephony service shall assist a deaf or hard of hearing user in a spoken dialogue by providing text captions translating the incoming part of the conversation.

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

    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.

Filter the requirements

Functional statements

Accessibility Requirements


Download the full standard as PDF