Functional Accessibility Requirements

    5. Generic requirements

    5.1.2 General

    5.1.3 Non-visual access

    5.1.6 Operation without keyboard interface

    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.

    6. ICT with two way voice communication

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

    9. Web

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

    10. Non-web documents

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

    11. Software

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

    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.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.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.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.2 Non-Web software requirements (closed functionality)

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

    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.3.2 Accessibility services

    12. Documentation and support services

    12.2.3 Effective communication

    ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.

    13. ICT providing relay or emergency service access

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