Web and Software: Interaction and operating system

Interaction and operating system

The following Section 508 provisions are grouped together for discussion purposes and address keyboard interaction and support for accessibility features of an operating system or platform. The TEITAC Web and Software subcommittee is reviewing these for issues, gaps, and keeping in mind the themes.

Discussion of these provisions should take place on the mailing list. Be sure to include an appropriate subject line that begins with "Group A". Rewording proposals may be made by editing this page:

21 (a)

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.

Summary of discussion on 21(a)

• 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.
• This is missing from Web requirements in 1194.22
  • WCAG 2.0: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task requires analog, time-dependent input. (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
• Both ISO and WCAG 2.0 set a higher bar for keyboard operability than 508 requiring that free-form drawing be keyboard accessible.
  • Do we want 508 to require keyboard operation of free-form drawing for users who can see but cannot use a mouse?
  • Is MouseKeys support in the OS enough to satisfy this requirement? According to Jonathan, drawing may require a combination of MouseKeys and StickyKeys which may be impossible for some users. If we go this way, we may need modifications to MouseKeys. Gregg pointed out that MouseKeys would appear to be identical to building a pixel by pixel freehand drawing capability into a tool.
  • Does allowing MouseKeys to satisfy this requirement open the door for MouseKeys to be used to claim keyboard operability of discrete user interface elements such as menus and dialog box controls?
    • MouseKeys should not be allowed for discrete operation like menu or dialog navigation or CAD like drawing (lines, rectangles, etc.)
• Alternative wording proposal: When EIT is designed to use a keyboard as a means of (insert functionality), (insert keyboard accessibility requirements here).
• Discussed at October 24, 2006 meeting

21(b)

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.

Summary of discussion on 21(b)

• 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.
• Should we define a minumum set of "accessibility features" that an operating system or platform must provide? If so, should these be "required" or "recommended"? Does this inhibit innovation? For example, there may be a better way to provide the desired function on a phone or PDA.
  • ISO has this requirement for MouseKeys: Platform software shall provide a keyboard alternative to standard pointing devices that enables keyboard (or keyboard equivalent) control of pointer movement and pointer button functions in parallel with the standard pointing devices. (Andi: There are other platform accessibility features required by the ISO standard. If we decide we want to define a minimum set, I can get them.)
  • If 508 does define accessibility features that an OS must provide, they should be described in a generic way; that is, don't require that an OS provide "MouseKeys" but instead require the function as the pointer functions can be operated via the keyboard.
  • It must be easy to add assistive technology to the system. For example, an alternative pointing device must be able to consistently control every piece of software in the same manner that a mouse works.
    • ISO addresses this with a requirement to "Accept the installation of keyboard and/or pointing device emulators" and a requirement to "Use system standard input/output".
• Do we need a provision similar to this in section 22? Web applications often remove the menu and/or tool bars of the browser. The result is that some accessibility features may be disabled like the ability to ignore colors, change font sizes, affect focus and make use of alt text.
• Discussed at October 24, 2006 meeting
• Discussed with 21(g) at November 15, 2006 meeting

21(c)

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.

Summmary of discussion on 21(c)

• 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 include changes in focus as one such event.
• Alternative proposal: A well-defined on-screen indication shall be provided for every interactive interface element as it gains input focus. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
• Suggestion to combine c and d. Consider defining minimum requirements for an accessibilitiy API. Note that ISO 9241-171 does define such a minimum set.
• Is this requirement testable?
  • Tools exist to test for this but may be unknown to non-technical people and may not be accessible
  • Lots of dicussion about testing tools and development tools which gets into the "content" discussion.
• Also provide guidance on where the focus should be placed?
• This requirement is missing for Web content (section 22). A well-defined visual focus is another essential aspect of web applications. Lack of focus tends to result in confusion as to where the focus is, extra keystrokes and missing information. Search functions, error handling and instructional text are all affected by a lack of a well-defined focus.
• Discussed at December 13, 2006 meeting

21(g)

Applications shall not override user selected contrast and color selections and other individual display attributes.

Summary of discussion on 21(g)

• The term "display attributes" is vague. Does it include fonts, font size, screen resolution, etc. Should we create a definition for it?
• This is not addressed in the ISO software standard perhaps because the ISO group thought this was a technique for addressing 21(b).
• The phrase "shall not override" is subjective. Does it mean an application shall repect the user's system settings or does it mean an application shall not change the user's settings such that the system and other applications would be impacted?
• Discussed at November 6, 2006 meeting

Proposed change to 21(g): 3 options

1. Applications shall respect/honor user selected contrast and color selections and other individual display attributes.
2. Applications shall respect/honor 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.
3. Applications shall respect user selected contrast and color selections.

Summary of discussion on proposed change to 21(g)

• Should there be an OS requirement to provide user settings for color and contrast?
• "other individual display attributes" could cover font size, screen resolution, custom attributes such as bolding, turning off effects such as fade in, etc.
• update to proposal suggested by Jim (21(g) updated 11/15
  • 21(g) 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(b) 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.
• Combine 21 b & g?
• "other products" in 21(b) is problematic. For developers, the OS is a known quantity but it's a tall order to to require that applications not interfere with any other product.
• Discussed at November 15, 2006 meeting
• Inheriting system settings - a technical discussion
• Inheriting color and contrast settings doesn't usually work for remote access environments.

21(j)

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.

Summary of discussion on 21(j)

• The ISO standard contains only recommendations, not normative requirements, for this and it is equally as vague as 508.
  • ISO: software that includes colour schemes should provide colour schemes designed for use by people who have visual impairments.
  • ISO: Software that uses colour schemes should allow users to create, save, and individualise colour schemes, including background and foreground color combinations.
• WCAG 2.0 has a provision that includes an algorithmic approach.
  • WCAG 2.0: Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
  • Does an algorithmic approach address real human performance issues, or is it purely mathematical? That is, just looking at colorblindness, are there color pairs that would fail an automated test but not interfere with anyone's real life performance?
• Discussed at November 6, 2006 meeting

Proposed change: to 21(j) 2 options

1. When a product permits a user to adjust color and contrast settings, at least one of the color selections provided shall produce a minimum luminosity contrast ratio of 5:1. Default combinations of foreground and background colours (hue and luminance) should produce a minimum luminosity contrast ratio of 3:1.
2. 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 5:1 shall be provided. Default combinations of foreground and background colours (hue and luminance) should produce a minimum luminosity contrast ratio of 3:1.

Summmary of discussion on proposed change to 21(j)

• What is the research basis for 5:1?
• 5:1 may be too strict
  • Note that the Voluntary Voting System Guidelines recommend a contrast ratio between 6:1 and 15:1.
• use the W3C definition of colour (sRGB), and then change the contrast formula to:
  • 0.33 * ((R / FS) ^ 2.2) + 0.6 * ((G / FS) ^ 2.2) + 0.06 * ((B / FS) ^ 2.2)
  • Gregg notes that WCAG 2.0 is calling this simply "contrast" and is using sRGB space and the W3C formula. Need a link to this definition.
• definition of what "permits a user to adjust" means - for example, if the hardware allows the user to adjust contrast, that should not trigger this requirement in software.
  • value chain regarding color and contrast includes the "program content" link, the "display hardware" link and the "user hardware settings" link. That is, the user gets the "right" results only if all three are within certain limits. 508 can act on this chain in 3 ways:
    1. require the "right" content, as in the color and contrast requirements in WCAG
    2. require the display hardware to render the output as closely as possible to what was intended by the designer
    3. allow the user to adjust the display, but provide "one touch" reversion to the proper default settings.
• consider defining non luminosity contrast effects such as relative stroke widths and so on
• need to be clear about where this applies. For example, "designer" elements should be excluded.
• Discussed at November 15, 2006 meeting