Web and Software: software provisions
*** Proposed Report to TEITAC for February 6 - 8, 2007 meeting, subject to subcommittee approval
Contents |
21(a)
Current wording: When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
- "discerned textually" wording is unclear but so far we have not come up with a proposal for better wording.
- 508 requires discrete drawing (shapes, lines, CAD-like drawing) to be keyboard operable but not require that free-form drawing. ISO does require free-form drawing to be keyboard operable. While some have argued that this is not a need for blind users, it is a need for sighted keyboard-only users.
- ISO: Unless the task requires time-dependent analogue input, software shall provide users with the option to carry out all tasks using only non-time dependent (or keyboard equivalent) input.
- We don't know how to do free-form drawing using only the keyboard other than the function you get today with MouseKeys. Is it reasonable to require software applications to duplicate this function when there is no additional benefit to the user?
- Concern that if we say MouseKeys is sufficient to meet this requirement for free-form drawing, it opens up a loophole for people to claim conformance using MouseKeys for discrete keyboard operations such as menu and dialog box navigation or certain discrete drawing operations (line, rectangle drawing, etc.)
- Alternative wording proposal: When EIT is designed to use a keyboard as a means of (insert functionality), (insert keyboard accessibility requirements here).
- The only input functions that can't be done from the keyboard are those that are analog AND time-dependent such as painting with a spray can.
Current status:
- Some think current wording is fine
- Some think we need to improve the wording of "textually discernible" but not raise the bar in 508 to include free-form drawing.
- Some think we should harmonize with ISO and require that free-form drawing be keyboard operable. Within this group, there are some who still do not like the specific ISO wording.
21(b)
Current wording: Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
- No consensus on adopting the ISO wording and at least one person prefers the current Section 508 wording:
- ISO: Software shall not disable or interfere with the accessibility features of the operating system and software that provide services for use by other software or any other applications. The ISO spec also includes a provision for accessibility shortcut key assignments, specifically five consecutive clicks of the shift key and holding the shift key down for 8 seconds. It also notes that platform software may reserve additional shortcut keys.
- Concern that the requirement to not "disrupt or disable activated features of other products" is a very high bar to meet. Applications can reasonably be expected to avoid disrupting or disabling features of the operating system because they know it's there and what its features are. But it is unreasonable to expect apps not to disrupt or disable features of any other products.
- For example, ATs use undocumented methods to provide access. But we can't require IT vendors to not interfere with what is not documented.
- There was also an alternative proposal put forward for 21(b) during the discussion of 21(g).
- Proposal: Applications shall not disrupt or disable activated features of other products (including Operating Systems) that are identified as accessibility features, where those features are developed and documented according to industry standards.
- Concern that the proposal leaves out the possibility of an operating system vendor making APIs that are not "industry standard" available to product developers.
- Conclusion: Subcommittee recommends no change to 21(b)
21(c)
Current wording: A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
- ISO: "Software shall provide a focus cursor that visually indicates which user interface element currently has the keyboard input focus, as well as the focus location within that element when one exists." and "Software shall provide assistive technology with notification of events relevant to user interactions". The examples for the second ISO provision includes changes in focus as one such event.
- Like ISO wording but concern that it does not include an explicit requirement that the focus be programmatically exposed although some think that the provision requiring notification of events such as focus change implies that the focus is programmatically exposed. Should recommend ISO wording but add a requirement that the focus has to be programmatically exposed.
- This requirement is easily tested although the tools may not be well-known to non-technical people.
- Subcommittee recommends modifying 21(c) to: Software shall provide a focus cursor that visually indicates which user interface element currently has the keyboard input focus, as well as the focus location within that element when one exists. The focus cursor shall be programmatically exposed so that assistive technology can track focus and focus changes.
- Note that this may have to be reconsidered as part of the API requirements proposal.
21(d)
Current wording: Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
- On hold pending conclusion of discussion on the API requirements proposal.
21(e)
Current wording: When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
- There are no equivalent requirements, only some related recommendations, in the ISO standard.
- Testability issue: Considerable subjective judgement required to determine if meaning assigned to icons used in multiple places is consistent.
- Consistent use of icons is good for usability, but need clear accessibility rationale for this if it is to remain in the 508 standard. ATIA reports that 21(e) is needed for AT interoperability if applications don't properly expose object information as required by 21(d). Perhaps this can be covered in sufficient techniques for the object information requirement if this approach is adopted.
21(f)
Current wording: Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
- On hold pending conclusion of discussion on the API requirements proposal.
21(g)
Current wording: Applications shall not override user selected contrast and color selections and other individual display attributes.
- ISO has no provision that maps directly to this one, probably because it is considered to be covered by the ISO equivalent to 21(b).
- Issues with:
- "other individual display attributes" - subject to interpretation as to what this requires
- "shall not override" can be interpreted to mean very different things
- Subcommittee recommends modifying 21(g) to: Applications shall utilize user selected contrast and color selections and other individual display attributes when the availability of those selections are developed and documented according to industry standards.
21(h)
Current wording: When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
- Progress indicators implemented using controls that expose information to AT are not animations and should not be subject to this requirement.
- Informational animations that are accessible should not be required to provide an alternative non-animated version but may need to provide a mechanism for pausing and restarting.
- For informational animations that are not accessible, a static alternative can be provided using "equivalent facilitation".
- Decorative animations need a mechanism for stopping them. If the mechanism reloads the page without the decorative animation, that should be sufficient.
- Proposal currently under discussion in the subcommittee: When an informational animation is displayed that will last for more than three seconds, software shall give the user a means to pause and restart the animation. When a decorative animation is displayed that will last for more than three seconds, software shall give the user a means to stop the animation.
21(i)
Current wording: Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
- WCAG 2.0 wording is still evolving so it's probably too early to harmonize.
- Conclusion: The subcommittee recommends no change at this time to 21(i).
21(j)
Current wording: When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
- Although the ISO standard does have some recommendations with regard to contrast, there is no requirement that addresses it.
- Issues:
- As currently worded, this provision is weak and unfailable. If an app doesn't permit the user to adjust color and contrast settings, it passes. If it does permit the user to adjust them, the requirement to provide "a variety of color selections capable of producing a range of contrast levels" is so subjective that they all pass.
- "permits a user to adjust" wording is problematic because it may be interpreted to mean that if the hardware allows the user to adjust the contrast, then the software is required to provide the "variety of color selections capable of producing a range of contrast levels". (We never developed a recommendation to address this issue.)
- Also there is no requirement for a minimum default contrast ratio.
- Need to be clear about where this applies. For example, designer elements such as product logos should be excluded.
- Contrast "perception" is affected by non-luminosity factors such as character stroke width
- There is a chain of components which are required to deliver a given contrast ratio. 1) The source encoding, 2) The platform software and hardware to run it on and 3) The viewing environment. All of these have to be set up properly for the user to perceive 'sufficient contrast'. We have to decide which parts of this delivery chain 508 wants to address; but there are problems with all of them.
- Subcommittee recommends modifying 21(j) to: When a product permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of n:1 shall be provided. Default combinations of foreground and background colours (hue and luminance) should produce a minimum luminosity contrast ratio of n:1. (n:1 to be determined later based on research or harmonization with WCAG 2.0)
- Note that there are fringe cases where this may not be testable. For example, with dynamic content, the contrast ratio will depend on what the content is rendered on.
21(k)
Current wording: Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
- WCAG 2.0 introduced the idea of a minimum size. This is good because only flashing areas that are larger than a defined size are an issue. For example, a blinking text caret is not large enough to trigger a seizure even if it is flashing within the 2 to 55 Hz range.
- Proposal currently under discussion: When software has flashing or blinking elements that occupy more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when viewed at 1024 x 768 pixels, the flashing or blinking elements shall not have a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
- Further discussion of harmonizing this with WCAG 2.0 is on hold until WCAG 2.0 wording is more mature.
21(l)
Current wording: When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
- On hold pending conclusion of discussion on the API requirements proposal.
