Web and Software: Programmatic exposure of information

Programmatic exposure of information

The following Section 508 provisions are grouped together for discussion purposes and address exposing information programmatically so that assistive technologies can get to it. 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 C". Rewording proposals may be made by editing this page:

21(c) Software - Focus

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.

Peter: Note that "well-defined on-screen indication" in 22(c) makes  this also about a visual
representation of focus, in addition to programmatic exposure.

• Discussed as part of Group A

21(d) & 21(f) Software - Object information and text

Current wording: 21(d) 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.

Current wording: 21(f) 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.

Summary of discussion on 21(d) and 21(f)

• Grouped these two together because text is viewed by some as a special case of 21(d).
• ISO: 8.6.4 Software shall provide assistive technology with information about individual user interface elements, using methods compatible with 8.6.3, except elements that only serve as an integral portion of a larger element, taking no input and conveying no information of their own.
  • NOTE 1 User interface element information includes, but is not limited to: general states (such as existence, selection, focus, and position), attributes (such as size, colour, role and name), values (such as the text in a static or editable text field), states specific to particular classes of user interface elements (such as On/Off, depressed/released),and relationships between user interface elements (such as when one user interface element contains, names, describes, or affects another). This applies to on screen user interface elements and UI status values such as toggle keys.
  • NOTE 2 User interface element information is typically available to users by inspection or interaction. Users with certain disabilities may not be able to see or otherwise detect this information without using assistive technologies.
• The enumeration of user interface information in NOTE 1 above for ISO provision 8.6.4 does not go far enough. Perhaps the right answer is that the OS should at least define one API that covers all of the necessary information (list to be enumerated - building on the ISO list cited above), while allowing apps & AT to use other APIs that also work, and further, allowing apps & AT to use any other technique that accomplishes the same end-user goal. The important thing about that last bit is that it explicitly allows apps & AT which are working well together today under the existing 508 rules to remain OK even as we formalize and increase API-based requirements going forward.
• In addition to 8.6.4 above, ISO also has the following additional provisions related to AT interoperability:
  • 8.6.2 Enable communication between software and assistive technology. Platform software shall provide a set of services that enable assistive technologies to interact with other software sufficient to enable compliance with guidelines 8.6.5, 8.6.6, 8.6.7, 8.6.8, and 8.6.9
  • 8.6.3 Use standard accessibility services. Software that provides user interface elements shall use the accessibility services provided by the system to cooperate with assistive technologies. If it is not possible to comply with 8.6.5, 8.6.6, 8.6.7, 8.6.8 and 8.6.9, using these means, the software shall use other services that are supported, and publicly documented, and implemented by assistive technology.
  • 8.6.5 Allow assistive technology to change focus and selection. Software shall allow assistive technology to modify focus and selection attributes of user interface elements, using methods as specified in 8.6.3.
  • 8.6.6 Provide user interface element descriptions. Where tasks require access to the visual or audible content of user interface elements beyond what the role and name attributes provide software shall provide descriptions of those objects, that are meaningful to the user and available to assistive technology through a standard programmatic interface (as described in 8.6.3), whether those descriptions are presented or not.
  • 8.6.7 Make event notification available to assistive technologies. Software shall provide assistive technology with notification of events relevant to user interactions, using methods described in 8.6.3.
  • 8.6.8 Allow assistive technology to access resources. If mechanism(s) exist, software should provide assistive technology with access to shared system resources. (This one is not a normative requirement though meaning it is recommended, but not required, for conformance.)
  • 8.6.9 Use system-standard input/output. Software shall use standard input and output methods provided by the software platform, or, if this is not possible, make equivalent information available through means described in 8.6.3.
• Discussed at the November 29, 2006 meeting

21(l) & 22(n) Electronic Forms

Current wording: 21(l) 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.

Current wording: 22(n) When electronic forms are designed to be completed on-line, 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.

Summary of discussion on 21(l) and 22(n)

• Neither ISO now WCAG 2.0 have any provisions specific to forms. Just like any other software or Web content, forms must comply with all of the applicable provisions in the standard.
• Historical summary provided by Bruce Bailey. This may have been included to cover online PDF forms which were not accessible at the time of the final rulemaking.
• For software, 21(d) (object information) covers form elements but perhaps we need to add something that covers the cueing information. Note 1 in ISO provision 8.6.4 actually covers this: "relationships between user interface elements (such as when one user interface element contains, names, describes, or affects another)."
• For Web, there is nothing else currently in Section 508 that covers form controls. The HTML form controls themselves are accessible but 22(n) is needed to ensure that the labels are programmatically associated with the form controls. Maybe we need something similar to 21(d) which includes the part about directions and cues. Note that WCAG 2.0 does contain two such provisions that cover forms:
  • "4.1.2 For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can be programmatically determined and programmatically set, and notification of changes to these items is available to user agents, including assistive technologies." (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/)
  • "1.3.1. Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies." (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/)
• Feeling that this is so important, that it needs to be specified explicitly rather than being covered by a general provision like 1.3.1.
  • Proposal for re-write of 22(n): For any interactive object, prompting information that is visually evident can be programmatically determined.
• Discussed at the November 29, 2006 meeting

22(l) & 22(m) Web - Scripts, applets, and plug-ins

Current wording: 22(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Current wording:22(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

Summary of discussion on 22(l) and 22(m)

• WCAG 2.0 does not contain a special provision for scripts, applets, or plug-ins because it is technology neutral. If a technology such as JavaScript, Flash, or Java is in the "baseline", the function or content implemented using that technology must meet all applicable WCAG 2.0 provisions. For example, the function must be keyboard operable, any interactive controls implemented using scripts must expose role, state, and properties programmatically, any flickering content implemented using scripts must not violate the flash thresholds, etc. If the technology is not in the baseline, then a conforming alternative must be provided using only the baseline technologies.
• One issue is traversal of keyboard focus into and out of content that is script-generated [22(l)] and that uses applets or plug-ins [22(m)].
• Another issue is respecting the desktop color & contrast settings (e.g. a large-print theme) – the browser has a role to play in conveying that info to the script-generated content & to applets and plugins.
• Discussed at the November 29, 2006 meeting
• Harmonization issues will ensue if Section 508 continues with the current model of a requirement in the Web section that points back to the software requirements while WCAG 2.0 is self-contained with regard to scripts, applets, and plug-ins.
  • Mapping of 1194.21 to WCAG 2.0 to determine if WCAG 2.0 will cover all of the current 508 software requirements.

Summary of mailing list discussion on the mapping

• Most everything in 1194.21 is covered in the current WCAG 2.0. See Andi's post on February 19, 2007.
• Concern over removing 22(l) scripts because the requirement to provide functional text that can be read by AT is working well. But it won't be enough for the new ARIA applications which will also need WCAG success criteria 4.1.2 (role, states, values, and properties).
• Need a clear definition of "scripts", "applets", and "plug-ins".
• The "functional text" requirement is not good enough for the new W3C ARIA standard. For that you need WCAG 4.1.2. What if we kept the current 508 script provision requiring funcitonal text and added in the WCAG 4.1.2

provision?

• Additional clarity is needed on whether plugin-based apps are to be evaluated in 21 or 22.
• 1193.2 (c ) is not just a Flash issue. This can come up any time that custom controls are created in javascript also. Flash provides a well-defined focus, but sometimes developers go off the path to create new types of controls and then they need to attend to this.
• There may actually be two issues that need to be addressed:
  1. The underlying agent that renders the content and
  2. The specific content, applet, plug-in, etc. that is displayed.
• "plug-in" applications need definition as there are several structures that can be possible that "might" be a "plug-in". See Allen’s poston February 21,2007.