Functional Accessibility Requirements

    5. Generic requirements

    5.1.2 General

    5.1.3 Non-visual access

    5.1.6 Operation without keyboard interface

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

    8. Hardware

    8.1.1 Generic requirements

    8.2.1 Speech volume gain

    8.2.2 Magnetic coupling

    8.3.2 Clear floor or ground space

    8.3.2.3 Approach

    8.3.3 Reach range for ICT

    8.3.3.1 Forward reach

    8.3.3.1.3 Obstructed reach

    8.3.3.2 Side reach

    8.3.3.2.3 Obstructed side reach

    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.

    9. Web

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

    10. Non-web documents

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

    11. Software

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

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

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

    12. Documentation and support services

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

Filter the requirements

Functional statements

Accessibility Requirements


Download the full standard as PDF