success-criteria-problematic-for-closed-functionality.md

Success Criteria Problematic for Closed Functionality

There are success criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. Where ICT with closed functionality doesn’t support use of assistive technology or the platform does not have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of these success criteria. See also the Comments on Closed Functionality section.

Other success criteria would apply to systems with closed functionality either if they are partially closed or if they allow for the connection of some types of devices. As an example, Success Criterion 2.1.1 Keyboard would apply to systems that are closed to screen readers, but have a physical keyboard, a connector for standard keyboards, or allow the installation of alternate keyboards. While these criteria, as written, are not always applicable to closed functionality, most of them can inform and aid development of built-in features needed to make products with closed functionality accessible.

For non-web software on products with closed functionality, those who implement this document (WCAG2ICT) should consider the applicability of individual WCAG 2 success criteria on a criterion-by-criterion basis. Alternate accessibility provisions might be needed to cover the user needs addressed by the following success criteria:

• 1.1.1 Non-text Content — Depends upon text (or a text alternative) being in a programmatically determinable form.
• 1.2.1 Pre-recorded video — One of the options available to authors for Success Criterion 1.2.1 is providing a media alternative that is text which, in the absence of connected assistive technology, would need to be made available in different modalities.
• 1.2.3 Audio description or Media Alternative — One of the options available to authors for Success Criterion 1.2.3 is providing a media alternative that is text which, in the absence of connected assistive technology, would need to be made available in different modalities.
• 1.3.1 Info and Relationships — Requires that information be in a programmatically determinable form or in text (that is programmatically determinable).
• 1.3.2 Meaningful Sequence — Requires information (i.e, a correct reading sequence) in a programmatically determinable form. An equivalent for software with closed functionality would be to provide a meaningful reading sequence through auditory output or some other non-visual means that helps users correlate the output with the corresponding information displayed on the screen.
• 1.3.4 Orientation — Products with closed functionality that have fixed-in-place displays or other limitations that prevent modifying the physical display orientation should be considered as examples that are covered under the essential exception. See the note in the section Applying SC 1.3.4 Orientation to Non-Web Documents and Software.
• 1.3.5 Identify Input Purpose — Depends upon information in a programmatically determinable form; in the absence of programmatic capabilities, text labels need to be specific and be provided to the user in other modalities (e.g. auditory).
• 1.4.2 Audio Control — The intent of this success criterion is to avoid interference of audio with assistive products, which are not available in a system with closed functionality. If the built-in accessibility features of a closed system provide speech output, then the interference may happen and this success criterion applies. In addition, there are existing requirements in regulations (e.g., the EN 301 549 and U.S. Revised 508 Standards) that address volume control for products with closed functionality.
• 1.4.3 Contrast (Minimum) — There are cases where applying this success criterion to non-web software for products with closed functionality is problematic:
  • When the contrast of the content is determined by the hardware and not modifiable by the software author, it may not be possible to meet this success criterion.
    Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion).
  • When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement.
    Photographs (e.g., of a hardware display) are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
• 1.4.4 Resize Text — Non-web software on closed functionality products may offer more limited text rendering support than the support found in user agents for the Web. As a result, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author.
• 1.4.5 Images of Text — To enable assistive technology to modify displayed text (e.g., adjusting contrast, increasing font size), machine-readable text is needed, as opposed to mere images of text. Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology and/or lack of platform support.
• 1.4.10 Reflow — Some software on ICT with closed functionality does not support scrolling content, or zooming, or changing the size of a viewport or scrollable content area to the specified width/height (examples include, but are not limited to, software for self-service transaction machines or kiosks). Therefore, some other non-WCAG requirements would be needed for products with closed functionality to ensure that content is readable by persons with low vision without scrolling in two dimensions.
  Some ICT with closed functionality does not display large chunks of text and only has UI controls. In such cases, two-dimensional scrolling to access the text and UI controls may be considered essential, thus meeting an exception, and the success criterion would be satisfied.
• 1.4.11 Non-text Contrast — There are cases where applying this success criterion to non-web software on products with closed functionality is problematic:
  • When the contrast of the content is determined by the hardware and not modifiable by the software author, it may not be possible to meet this success criterion.
    Hardware requirements for contrast are out of scope for WCAG2ICT (and this success criterion).
  • When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement.
    Photographs are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
• 1.4.12 Text Spacing — In software with closed functionality the ability for users to modify line, paragraph, letter, or word spacing is rarely supported. Regardless, the success criterion applies as written and as noted in the Applying SC 1.4.12 Text Spacing to Non-Web Documents and Software.
• 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when the ICT does not have a built-in keyboard, and it also does not support an alternative input method (hardware or software) that provides keyboard-like access to all functionality.
  A keypad that provides full access to functionality might be considered a keyboard.
• 2.1.2 No Keyboard Trap — This criterion applies when focus can be moved using a keyboard interface. In some closed systems, tactile input like numeric keypads or other functional groups of keys may be available, but there is no mechanism for onscreen focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this success criterion would be satisfied.
• 2.1.4 Character Key Shortcuts — Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
• 2.4.1 Bypass Blocks — The WCAG2ICT interpretation of this success criterion replaces "sets of Web pages" with "sets of software programs" which are extremely rare - especially for closed functionality software. However, being able to bypass blocks of content that are repeated within software is generally considered best practice.
• 2.4.2 Page Titled — Where the software is part of a product that provides a single function, or has a menu-driven interface, the intent of this success criterion would be met without needing an explicit title.
• 2.4.4 Link Purpose (In Context) — This success criterion relies upon text and context being made available in a programmatically determinable form.
• 2.4.5 Multiple Ways — The WCAG2ICT interpretation of this success criterion replaces "set of Web pages" with "set of software programs". Such sets, particularly in the context of closed functionality software, are exceedingly rare. There are a number of notes in the section Applying SC 2.4.5 Multiple Ways to Non-Web Documents and Software that are applicable to closed functionality software.
• 2.4.7 Focus Visible — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface is designed not to need that. For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this success criterion would be satisfied.
• 2.5.2 Pointer Cancellation — As noted in the section Applying SC 2.5.2 Pointer Cancellation to Non-Web Documents and Software, examples of ‘essential’ functionality are features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).
• 2.5.3 Label in Name — Requires information in a programmatically determinable form; specifically, the programmatic name contains the text of the visual label.
• 2.5.8 Target Size (Minimum) — This success criterion uses CSS pixels for defining the target size. ICT with closed functionality may not use CSS pixels as a standard measurement, but the definition of ‘CSS pixel’ still applies as described in Applying “CSS pixel” to Non-Web Documents and Software. If the system supports a density-independent pixel measurement, it should be used in place of CSS pixels.
  If the viewing distance and pixel density of the system are unknown, approximating the reference pixel as described in Applying “CSS pixel” to Non-Web Documents and Software is not possible.
  For software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for a CSS pixel are dependent on the viewing distance or pixel density of the display.
• 3.1.1 Language of Page — Depends upon language information being in a programmatically determinable form intended to drive correct pronunciation. Where another mechanism achieves correct pronunciation for products with closed functionality, such as self-voicing, the intent of this success criterion would be met.
• 3.1.2 Language of Parts — Depends upon language information in a programmatically determinable form intended to drive correct pronunciation. Where another mechanism achieves correct pronunciation for ICT with closed functionality, such as self-voicing, the intent of this success criterion would be met.
• 3.2.3 Consistent Navigation — This success criterion is interpreted to only apply to “sets of software programs” which are very rare. See the second note in the section Applying SC 3.2.3 Consistent Navigation to Non-Web Documents and Software.
• 3.2.4 Consistent Identification — This success criterion is interpreted to only apply to “sets of software programs” which are very rare. See the second note in the section Applying SC 3.2.4 Consistent Identification to Non-Web Documents and Software.
• 3.2.6 Consistent Help — The WCAG2ICT interpretation of this success criterion replaces "sets of Web pages" with "sets of software programs" which are extremely rare - especially for closed functionality software. However, providing consistent access to help is generally considered best practice.
• 3.3.1 Error Identification — Requires error information to be provided as text, noting that the WCAG definition of text is that it be "programmatically determinable".
• 3.3.8 Accessible Authentication (Minimum) — There are situations where meeting this success criterion is problematic for products with closed functionality:
  • Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be needed, such as an identity card scanner.
  • Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may be judged to take legal precedence over Success Criterion 3.3.8 Accessible Authentication (Minimum).
• 4.1.1 Parsing
  • When WCAG 2.0 and 2.1 were written, the Intent of Success Criterion 4.1.1 was to provide consistency so that different user agents or assistive technologies would yield the same result.
  • In WCAG 2.2, Success Criterion 4.1.1 Parsing was made obsolete and WCAG 2.2 removed it as a requirement, so this success criterion is not applicable.
• 4.1.2 Name, Role, Value — Requires information in a programmatically determinable form.
• 4.1.3 Status Messages — Depends upon status messages being programmatically determinable using role or properties.
  Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.