EN 301 549 Accessibility requirements for ICT products and services - 11. Software
11.0 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;
- mobile applications.
NOTE 1: User agents are examples of software that provide a user interface. They retrieve, render and facilitate end user interaction with authored content. User agents play a necessary role in the accessibility of authored content rendered in the user interface. UAAG 2.0 [i.33] provides additional advice for those who are creating user agents and want to increase functionality when rendering authored content in an accessible way.
NOTE 2: The requirements for Web content, including software that is Web content, can be found in clause 9.
NOTE 3: The requirements for documents, that may be presented by user agents, can be found in clause 10.
NOTE 4: Although the accessibility of command line interfaces is not dealt with in the present document, accessibility may be achieved by context specific requirements, some of which may be found in clauses 5 or 11.
Requirements in clauses 11.1 to 11.5 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.
Some requirements in clauses 11.1 to 11.5 have different versions for open or closed functionality. In those cases, the corresponding clause will be divided into two subclauses.
The success criteria set out in clauses 11.1 to 11.5 are intended to harmonize with the W3C Working Group Note [i.26] produced by the W3C's WCAG2ICT Task Force.
NOTE 5: Software that provides a user interface includes its own content. Some examples of content in software include: the controls and text displayed in a menu bar of a graphical user interface application, images that appear in a toolbar, prompts spoken in an auditory user interface, other user interaction controls, and other text, graphics or material that is not loaded from outside the software.
NOTE 6: "Void" clauses have been inserted in order to maintain alignment of the numbering in clauses 9, 10 and 11.
11.1 Perceivable
11.1.1 Text alternatives
11.1.1.1 Non-text content
11.1.1.1.1 Non-text content (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text Content.
NOTE: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.
11.1.1.1.2 Non-text content (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for non-text content).
11.1.2 Time-based media
11.1.2.1 Audio-only and video-only (pre-recorded)
11.1.2.1.1 Audio-only and video-only (pre-recorded - open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading and where pre-recorded auditory information is not needed to enable the use of closed functions of ICT, it shall satisfy the WCAG 2.1 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded).
NOTE: The alternative can be provided directly in the software - or provided in an alternate version that meets the success criterion.
11.1.2.1.2 Audio-only and video-only (pre-recorded - closed functionality)
11.1.2.1.2.1 Pre-recorded audio-only (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where pre-recorded auditory information is needed to enable the use of closed functions of ICT, the functionality of software that provides a user interface shall meet requirement 5.1.5 (Visual output for auditory information).
11.1.2.1.2.2 Pre-recorded video-only (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).
11.1.2.2 Captions (pre-recorded)
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.2 Captions (Prerecorded).
NOTE: The WCAG 2.1 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.1, 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".
11.1.2.3 Audio description or media alternative (pre-recorded)
11.1.2.3.1 Audio description or media alternative (pre-recorded - open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded).
NOTE 1: The WCAG 2.1 definition of "audio description" says that "audio description" is "also called 'video description' and 'descriptive narration'".
NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.
11.1.2.3.2 Audio description or media alternative (pre-recorded - closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.7 (Speech output for video information).
11.1.2.4 Captions (live)
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.4 Captions (Live).
NOTE: The WCAG 2.1 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.1, 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".
11.1.2.5 Audio description (pre-recorded)
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.2.5 Audio Description (Prerecorded).
NOTE 1: The WCAG 2.1 definition of "audio description" says that audio description is "Also called 'video description' and 'descriptive narration'".
NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.
11.1.3 Adaptable
11.1.3.1 Info and relationships
11.1.3.1.1 Info and relationships (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.1 Info and Relationships.
NOTE: In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software. (see clause 11.5 Interoperability with assistive technology).
11.1.3.1.2 Info and relationships (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.
NOTE 1: Many people who are legally blind still have visual ability, and use aspects of the visual display even if it cannot be fully comprehended. An audio alternative that is both complete and complementary includes all visual information such as focus or highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.
NOTE 2: Examples of auditory information that allows the user to correlate the audio with the information displayed on the screen include structure and relationships conveyed through presentation.
11.1.3.2 Meaningful sequence
11.1.3.2.1 Meaningful sequence (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence.
11.1.3.2.2 Meaningful sequence (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading and where information is displayed on the screen, the ICT should provide auditory information that allows the user to correlate the audio with the information displayed on the screen.
NOTE 1: Many people who are legally blind still have visual ability, and use aspects of the visual display even if it cannot be fully comprehended. An audio alternative that is both complete and complementary includes all visual information such as focus or highlighting, so that the audio can be correlated with information that is visible on the screen at any point in time.
NOTE 2: Examples of auditory information that allows the user to correlate the audio with the information displayed on the screen include structure and relationships conveyed through presentation.
11.1.3.3 Sensory characteristics
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.3 Sensory Characteristics.
11.1.3.4 Orientation
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.3.4 Orientation.
11.1.3.5 Identify input purpose
11.1.3.5.1 Identify input purpose (open functionality)
Where ICT is non-web software that provides a user interface and supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.3.5 Identify Input Purpose.
11.1.3.5.2 Identify input purpose (closed functionality)
Where ICT is non-web software that provides a user interface and is closed to assistive technologies, in at least one mode of operation the ICT shall present to the user, in an audio form, the purpose of each input field collecting information about the user when the input field serves a purpose identified in the WCAG 2.1 Input Purposes for User Interface Components section.
11.1.4 Distinguishable
11.1.4.1 Use of colour
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.4.1 Use of Color.
11.1.4.2 Audio control
Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.1.
Table 11.1: Software success criterion: Audio control
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.1 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.1.4.3 Contrast (minimum)
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 1.4.3 Contrast (Minimum).
11.1.4.4 Resize text
11.1.4.4.1 Resize text (open functionality)
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 WCAG 2.1 Success Criterion 1.4.4 Resize Text.
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.
11.1.4.4.2 Resize text (closed functionality)
Where ICT is non-web software that provides a user interface which is not able to access the enlargement features of platform or assistive technology, it shall meet requirement 5.1.4 (Functionality closed to text enlargement).
NOTE: Because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting the present clause in a closed environment may place a much heavier burden on the content author.
11.1.4.5 Images of text
11.1.4.5.1 Images of text (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 1.4.5 Images of Text.
11.1.4.5.2 Images of text (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.6 (Speech output for non-text content).
11.1.4.6 Void
11.1.4.7 Void
11.1.4.8 Void
11.1.4.9 Void
11.1.4.10 Reflow
Where ICT is non-web software that provides a user interface it shall satisfy the success criterion in Table 11.2.
Table 11.2: Software success criterion: Reflow
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels;
Except for parts of the content which require two-dimensional layout for usage or meaning.
NOTE 1: 320 CSS pixels is equivalent to a starting viewport width of 1 280 CSS pixels wide at 400 % zoom. For non-web software which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1 024 px at 400 % zoom.
NOTE 2: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes with notes 1 and 2, above.
11.1.4.11 Non-text contrast
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast.
11.1.4.12 Text spacing
Where ICT is non-web software that provides a user interface and that does not have a fixed size content layout area that is essential to the information being conveyed, it shall satisfy WCAG 2.1 Success Criterion 1.4.12 Text spacing.
11.1.4.13 Content on hover or focus
Where ICT is a non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.13 Content on hover or focus.
11.2 Operable
11.2.1 Keyboard accessible
11.2.1.1 Keyboard
11.2.1.1.1 Keyboard (open functionality)
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 WCAG 2.1 Success Criterion 2.1.1 Keyboard.
NOTE: 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.
11.2.1.1.2 Keyboard (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).
11.2.1.2 No keyboard trap
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: No keyboard trap
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, it is necessary for all content in the software (whether or not it is used to meet other success criteria) to meet this success criterion.
NOTE 2: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.1.2 No Keyboard Trap replacing "content", "page" and "Web page" with "software", removing "See Conformance Requirement 5: Non-Interference" and with the addition of note 2 above and with note 1 above re-drafted to avoid the use of the word "shall".
11.2.1.3 Void
11.2.1.4 Character key shortcuts
11.2.1.4.1 Character key shortcuts (open functionality)
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts.
11.2.1.4.2 Character key shortcuts (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to keyboards or keyboard interface, it shall meet requirement 5.1.6.1 (Operation without keyboard interface: Closed functionality).
11.2.2 Enough time
11.2.2.1 Timing adjustable
Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.4.
Table 11.4: Software 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 WCAG 2.1 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.1 Success Criterion 2.2.1 Timing Adjustable replacing "the content" with "software" and with the words "WCAG 2.1" added before the word "Success Criterion" in note 1 above.
11.2.2.2 Pause, stop, hide
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: 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.1 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.1 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.1" 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.3 Seizures and physical reactions
11.2.3.1 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.6.
Table 11.6: Software success criterion: Three flashes or below threshold
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.1 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.4 Navigable
11.2.4.1 Void
NOTE 1: The related web page requirement "Bypass blocks" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.
NOTE 2: Although not a requirement, it is generally considered best practice, and to address user needs, to be able to bypass blocks of content that are repeated within software.
11.2.4.2 Void
NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.
NOTE 2: Although the name of a software product could be a sufficient title if it describes the topic or purpose, software names are trademarked and trademark names cannot by law be descriptive names. It is not practical to make software names both unique and descriptive.
11.2.4.3 Focus order
Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.7.
Table 11.7: Software success criterion: Focus order
NOTE: This success criterion is identical to the WCAG 2.1 Success Criterion 2.4.3 Focus order replacing "Web page" with "software".
11.2.4.4 Link purpose (in context)
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.4.4 Link Purpose (In Context).
11.2.4.5 Void
NOTE: The related web page requirement for "Multiple ways" applies to "Sets" of web pages. In software, the equivalent to "sets of web pages" would be "sets of software", but these are extremely rare and an equivalent is not included in this clause on software requirements.
11.2.4.6 Headings and labels
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 2.4.6 Headings and Labels.
NOTE: 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.
11.2.4.7 Focus visible
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 2.4.7 Focus Visible.
11.2.5 Input modalities
11.2.5.1 Pointer gestures
Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.8.
Table 11.8: Software success criterion: Pointer gestures
NOTE 1: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
NOTE 2: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.1 Pointer Gestures replacing the original WCAG 2.1 note with note 1 above.
11.2.5.2 Pointer cancellation
Where ICT is non-web software that provides a user interface, it shall satisfy the success criterion in Table 11.9.
Table 11.9: Software success criterion: Pointer cancellation
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event: The down-event of the pointer is not used to execute any part of the function.
- Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion.
- Up Reversal: The up-event reverses any outcome of the preceding down-event.
- Essential: Completing the function on the down-event is essential.
NOTE 1: Functions that emulate a keyboard or numeric keypad key press are considered essential.
NOTE 2: This requirement applies to non-web software that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
NOTE 3: This success criterion is identical to the WCAG 2.1 Success Criterion 2.5.2 Pointer Cancellation replacing the original WCAG 2.1 note with notes 1 and 2 above.
11.2.5.3 Label in name
11.2.5.3.1 Label in name (open functionality)
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.3 Label in Name.
11.2.5.3.2 Label in name (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it should meet requirement 5.1.3.3 (Auditory output correlation).
11.2.5.4 Motion actuation
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 2.5.4 Motion Actuation.
11.3 Understandable
11.3.1 Readable
11.3.1.1 Language of software
11.3.1.1.1 Language of software (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the success criterion in Table 11.10.
Table 11.10: 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.1 Success Criterion 3.1.1 Language of page, replacing "each web page" with "software" and with the addition of note 1 above. |
11.3.1.1.2 Language of software (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.14 (Spoken languages).
11.3.1.2 Void
NOTE: To apply the related web page requirement for "Language of parts" to software would require the marking-up of all text in all locations within the software. This would be impossible so an equivalent is not included in this clause on software requirements.
11.3.2 Predictable
11.3.2.1 On focus
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 3.2.1 On Focus.
NOTE: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context would not be subject to this success criterion because it was not caused by a change of focus.
11.3.2.2 On input
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 3.2.2 On Input.
11.3.2.3 Void
NOTE: The related web page requirement for "Consistent navigation" applies to "Sets" of web pages. While consistency within software is desirable, "sets of software" in the same sense as "sets of web pages", are extremely rare and an equivalent is not included in this clause on software requirements.
11.3.2.4 Void
NOTE: The related web page requirement for "Consistent identification" applies to "Sets" of web pages. In software, the equivalent to "sets of web pages" would be "sets of software", but these are extremely rare and an equivalent is not included in this clause on software requirements.
11.3.3 Input assistance
11.3.3.1 Error identification
11.3.3.1.1 Error identification (open functionality)
Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy the WCAG 2.1 Success Criterion 3.3.1 Error Identification.
11.3.3.1.2 Error Identification (closed functionality)
Where ICT is non-web software that provides a user interface which is closed to assistive technologies for screen reading, it shall meet requirement 5.1.3.15 (Non-visual error identification).
11.3.3.2 Labels or instructions
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 3.3.2 Labels or Instructions.
11.3.3.3 Error suggestion
Where ICT is non-web software that provides a user interface, it shall satisfy the WCAG 2.1 Success Criterion 3.3.3 Error Suggestion.
11.3.3.4 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.11.
Table 11.11: 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.1 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) replacing "web pages" with "software". |
11.4 Robust
11.4.1 Compatible
11.4.1.1 Parsing
11.4.1.1.1 Parsing (open functionality)
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.12.
Table 11.12: 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 [requirement] 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, 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.1 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, 3 and 4 above. |
11.4.1.1.2 Parsing (closed functionality)
Not applicable.
NOTE: Where ICT is non-web software that provides a user interface which is closed to all assistive technology it does not have to meet the "Parsing" success criterion in Table 11.12 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.4.1.2 Name, role, value
11.4.1.2.1 Name, role, value (open functionality)
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.13.
Table 11.13: 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.1 Success Criterion 4.1.2 Name, Role, Value replacing the original WCAG 2.1 note with: "This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification." and the addition of note 2 above. |
11.4.1.2.2 Name, role, value (closed functionality)
Not applicable.
NOTE: Where ICT is non-web software that provides a user interface which is closed to all assistive technology it does not have to meet the "Name, role, value" success criterion in Table 11.13 because this success criterion requires information in a programmatically determinable form.
11.4.1.3 Status messages
11.4.1.3.1 Status messages (open functionality)
Where ICT is non-web software, it shall satisfy WCAG 2.1 Success Criterion 4.1.3 Status Messages.
11.4.1.3.2 Status messages (closed functionality)
Not applicable.
11.5 Interoperability with assistive technology
11.5.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.5.2 to clause 11.5.2.17.
11.5.2 Accessibility services
11.5.2.1 Platform accessibility service support for software that provides a user interface
Platform software shall provide a set of documented platform services that enable software that provides a user interface running on the platform software to interoperate with assistive technology.
Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from clause 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.
NOTE 1: These define the minimum functionality of software providing user interfaces when using platform services.
NOTE 2: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.
NOTE 3: User interface services that provide accessibility support by default are considered to be part of the services provided to conform to this clause (e.g. the service for creating a new user interface element provides role, state, boundary, name and description).
NOTE 4: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.
NOTE 5: Within specific programming environments, the technical attributes associated with the user interface properties described in clauses 11.5.2.5 to 11.5.2.17 might have different names than those used within the clauses.
11.5.2.2 Platform accessibility service support for assistive technologies
Platform software shall provide a set of documented platform accessibility services that enable assistive technology to interoperate with software that provides a user interface running on the platform software.
Where a user interface concept corresponding to one of the clauses 11.5.2.5 to 11.5.2.17 is supported within the software environment, the platform software should support that requirement. For example, selection attributes from clause 11.5.2.14 (Modification of focus and selection attributes) may not exist in environments that do not allow selection, which is most commonly associated with copy and paste.
NOTE 1: These define the minimum functionality available to assistive technologies when using platform services.
NOTE 2: The definition of platform in clause 3.1 applies to software that provides services to other software, including but not limited to, operating systems, web browsers, virtual machines.
NOTE 3: In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.
NOTE 4: Typically these services belong to the same set of services that are described in clause 11.5.2.1.
NOTE 5: To comply with this requirement the platform software can provide its own set of services or expose the services provided by its underlying platform layers, if those services conform to this requirement.
11.5.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.5.2.5 to 11.5.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.
NOTE: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.
It is best practice to develop software using toolkits that automatically implement the underlying platform accessibility services.
11.5.2.4 Assistive technology
Where the ICT is assistive technology it shall use the documented platform accessibility services.
NOTE 1: The term "documented platform accessibility services" refers to the set of services provided by the platform according to clauses 11.5.2.1 and 11.5.2.2.
NOTE 2: Assistive technology can also use other documented accessibility services.
11.5.2.5 Object information
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies.
11.5.2.6 Row, column, and headers
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the row and column of each cell in a data table, including headers of the row and column if present, programmatically determinable by assistive technologies.
11.5.2.7 Values
Where the software provides a user interface, it shall, by using the services as described in clause 11.5.2.3, make the current value of a user interface element and any minimum or maximum values of the range, if the user interface element conveys information about a range of values, programmatically determinable by assistive technologies.
11.5.2.8 Label relationships
Where the software provides a user interface it shall expose the relationship that a user interface element has as a label for another element, or of being labelled by another element, using the services as described in clause 11.5.2.3, so that this information is programmatically determinable by assistive technologies.
11.5.2.9 Parent-child relationships
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.
11.5.2.10 Text
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.
11.5.2.11 List of available actions
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies.
11.5.2.12 Execution of available actions
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow the programmatic execution of the actions exposed according to clause 11.5.2.11 by assistive technologies.
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
11.5.2.13 Tracking of focus and selection attributes
Where software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface elements programmatically determinable by assistive technologies.
11.5.2.14 Modification of focus and selection attributes
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where the user can modify these items.
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
11.5.2.15 Change notification
Where software provides a user interface it shall, by using the services as described in clause 11.5.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.5.2.5 to 11.5.2.11 and 11.5.2.13.
11.5.2.16 Modifications of states and properties
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items.
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
11.5.2.17 Modifications of values and text
Where permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.5.2.3, allow assistive technologies to modify values and text of user interface elements using the input methods of the platform, where a user can modify these items without the use of assistive technology.
NOTE 1: In some cases the security requirements imposed on a software product may forbid external software from interfering with the ICT product and so this requirement would not apply. Examples of systems under strict security requirements are systems dealing with intelligence activities, cryptologic activities related to national security, command and control of military forces.
NOTE 2: Assistive technologies may be required to maintain the same level of security as the standard input mechanisms supported by the platform.
11.6 Documented accessibility usage
11.6.1 User control of accessibility features
Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.
11.6.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.7 User preferences
Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.
NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.
NOTE 2: For web content, the underlying platform is the user agent.
NOTE 3: This does not preclude the software from having additional values for a setting as long as there is one mode where the application will follow the system settings even if more restricted.
11.8 Authoring tools
11.8.0 General (informative)
For those creating web content authoring tools, ATAG 2.0 [i.32] provides information that can be of interest to those who want to go beyond these requirements.
NOTE: This is applicable both to standalone and to web based authoring tools.
11.8.1 Content technology
Authoring tools shall conform to clauses 11.8.2 to 11.8.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.
11.8.2 Accessible content creation
Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.
NOTE: Authoring tools may rely on additional tools where conformance with specific requirements is not achievable by a single tool. For example, a video editing tool may enable the creation of video files for distribution via broadcast television and the web, but authoring of caption files for multiple formats may be provided by a different tool.
11.8.3 Preservation of accessibility information in transformations
If the authoring tool provides restructuring transformations or re-coding transformations, then accessibility information shall be preserved in the output if equivalent mechanisms exist in the content technology of the output.
NOTE 1: Restructuring transformations are transformations in which the content technology stays the same, but the structural features of the content are changed (e.g. linearizing tables, splitting a document into pages).
NOTE 2: Re-coding transformations are transformations in which the technology used to encode the content is changed.
11.8.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 (Non-Web content) as applicable, then the authoring tool shall provide repair suggestion(s).
NOTE: This does not preclude automated and semi-automated repair which is possible (and encouraged) for many types of content accessibility problems.
11.8.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 (Non-Web content) as applicable shall be available and identified as such.