- From: <ehansen@ets.org>
- Date: Thu, 18 Nov 1999 16:53:55 -0500 (EST)
- To: w3c-wai-ua@w3.org
Issue #44. Document must give greater emphasis to the differential applicability of the guidelines to various classes of user agent, especially assistive technologies. In addition to providing a new issue, this follows up on Issue #1 (re: Abstract) and Issue #5 (re: "natively"). Readers of the UAAG document need greater clues as to the scope of the document -- especially, what kinds of user agents to which the document is most applicable, especially with regard to assistive technologies. The following revisions also attempt to clarify the relationship between user agents and assistive technologies. Old (5 Nov 1999 - Last Call): "Abstract:" "This document provides guidelines to user agent developers for making their products -- browsers, multimedia players, plugins -- accessible to people with disabilities. An accessible user agent allows users with disabilities to retrieve and view Web content or to enable access when used in conjunction with other software or hardware, called assistive technologies. These guidelines discuss the accessibility of the user agent as well as how the user agent communicates with assistive technologies such as screen readers, screen magnifiers, braille displays, and voice input software." My suggestion from Issue #1 (17 November 1999): "Abstract:" "This document provides guidelines to user agent developers for making their products -- browsers, multimedia players, and related assistive technologies -- accessible to people with disabilities. Developers must ensure: (1) that the functionalities offered by the user agent are accessible, and (2) that the user agent works well with other user agents -- especially assistive technologies -- that are necessary to access diverse Web content. For example, the developer of a graphical desktop Web browser will ensure that its functionalities are accessible by keyboard, since many people who are blind or have other disabilities require it. The developer will also use standard ways of interfacing the browser with other user agents, such as movie and audio players, and assistive technologies such as screen readers, screen magnifiers, braille displays, and voice input software. This document establishes criteria for three levels of user agent accessibility ("A", "Double-A", or "Triple-A"). User agents that are accessible can be more flexible, powerful, and usable for all users." My current (17 November 1999, 16:05 hrs) suggestion: "Abstract:" "This document provides guidelines to user agent developers for making their products -- browsers, multimedia players, plug-ins, and other input/output technologies used to access Web content -- are accessible to people with disabilities. Developers must ensure: (1) that the functionalities offered by the user agent are accessible, and (2) that the user agent works well with other user agents that provide additional functionalities that are necessary for full access to Web content. For example, the developer of a graphical desktop Web browser will ensure that its functionalities are accessible by keyboard, since many people who are blind or have other disabilities require it. The developer will also use standard ways of interfacing the browser with other user agents, such as movie and audio players, and assistive technologies such as screen readers, screen magnifiers, braille displays, and voice input software. Not every guideline or checkpoint is applicable to every kind of user agent. User agents that are accessible can be more flexible, powerful, and usable for all users." -- I suggest the following additional changes in the Priorities and Conformance sections. Old: {beginning of Old:} 1.5 Priorities Each checkpoint in this document is assigned a priority that indicates its importance for users. [Priority 1] This checkpoint must be satisfied by user agents as a native feature, otherwise one or more groups of users with disabilities will find it impossible to access information. Satisfying this checkpoint is a basic requirement for some individuals to be able to use the Web. [Priority 2] This checkpoint should be satisfied by user agents as a native feature, otherwise one or more groups of users will find it difficult to access information. Satisfying this checkpoint will remove significant barriers to accessing Web documents. [Priority 3] This checkpoint may be satisfied by user agents as a native feature to make it easier for one or more groups of users to access information. Satisfying this checkpoint will improve access to the Web for some individuals. 1.6 Conformance The terms "must", "should", and "may" (and related terms) are used in this document in accordance with RFC 2119 ([RFC2119]). User agents must satisfy natively all the applicable checkpoints for a chosen conformance level. {End of Old} Really new (18 November 1999): {beginning of New:} 1.5 Priorities Each checkpoint in this document is assigned a priority that indicates its importance for users WITH DISABILITIES. [Priority 1] This checkpoint must be satisfied by a user agent; otherwise one or more groups of users with disabilities will find it impossible to access information. Satisfying this checkpoint is a basic Web access {or "accessibility"} requirement. [Priority 2] This checkpoint should be satisfied by a user agent; otherwise one or more groups of users with disabilities will find it difficult to access information. Satisfying this checkpoint will remove significant Web access {or "accessibility"} barriers. [Priority 3] This checkpoint may be satisfied by a user agent; otherwise one or more groups with disabilities will find it somewhat difficult to access information. Satisfying this checkpoint will improve Web access {or "accessibility"}. {Note. The foregoing priority levels are unchanged from yesterday.} Note. The terms "must", "should", and "may" (and related terms) are used in this document in accordance with RFC 2119 ([RFC2119]). 1.6 Applicability {This section is mostly new.} User agents must satisfy all the _applicable checkpoints_ {extend link to include "checkpoints"} for a chosen conformance level. {NOTE. I DELETED THE WORD "NATIVELY". REMEMBER, IT IS NOT NEEDED BECAUSE IT IS ALREADY PART OF THE DEFINITION OF "APPLICABLE CHECKPOINT."} Not every checkpoint or guideline is applicable to every user agent. Generally, a user agent must adhere to checkpoints that ensure accessibility of functionalities that it offers to users, but is generally not required to address checkpoints that address the accessibility of functionalities that it does not provide. This means that for user agents such as graphical Web browsers which are general-purpose user agents for accessing the virtually all Web content, a greater portion of the checkpoints will be applicable. On the other hand, applications or utilities with a much narrower range of functionality will tend to have a smaller set of applicable checkpoints. Many of the user agents that are also classified as "assistive technologies" (which are specifically designed for people with disabilities), often have a narrow range of functionality and hence may a smaller set of applicable checkpoints. See the definition of "Applicable checkpoint" in the appendix ("Terms and Definitions") for greater detail." {Note. If necessary, this section could bring in more material from "Terms and Definitions -- Applicable checkpoint" if necessary.} 1.6 Conformance Developers of user agents may claim any of three levels of conformance to this document. {Note that I have newly inserted the word "applicable" into the definition of each of the conformance levels.} Conformance Level "A": all applicable Priority 1 checkpoints are satisfied Conformance Level "Double-A": all applicable Priority 1 and 2 checkpoints are satisfied Conformance Level "Triple-A": all applicable Priority 1, 2, and 3 checkpoints are satisfied Note. Conformance levels are spelled out in text ("Double-A" instead of "AA") so they may be understood when rendered as speech. Claims of conformance to this document must use one of the following two forms. [etc., etc.] {End of New} Issue #45. Some attention needs to be given to additional situations in which the UA document is not applicable. I wonder if there are some unexpected implications of the guidelines. For example, "Web authoring tools" could be considered "user agents". Do the UA guidelines place any additional burden upon developers of Web authoring tools? I have some small concern here about whether the applicability rules are robust enough to avoid unnecessary burdens on developers of assistive technologies. Will the UA guidelines require the developers of pwWebSpeak, a non-graphical [at least the last time I looked] self-voicing Web browser be required to provide a lot more capabilities for presenting graphical material. Probably not, but it might be good to ask people who develop different kinds of assistive technologies (screen readers, special access devices, etc.) how well they stack up against the UA document and whether they see the UA guidelines as an unnecessary burden. Will developers of utilities for individuals who are deaf-blind be required to interface to multimedia-capable user agents? Will manufacturers of new handheld Web appliances, especially some that may be built for individuals with disabilities, be required to provide capabilities that are burdensome? Will wheelchair will classified as a user agent if it allows a person to sit in front of a computer. Are there any checkpoints applicable to wheelchairs? These are concerns that may be unfounded. Once you try to have the document cover every possible case or exception, you may start down a slippery slope that you might not climb out of. Yet if we have concerns, then perhaps would should do as the U.S Congress does: When it passes a law, it often exempts itself (the House and Senate) from compliance to the law <grin>. Seriously, if developers of assistive technologies have serious concerns about this, then perhaps somewhere there needs to be statement like the following. "Note. Certain exceptions to the requirements of this document may be granted to user agents that are specifically targeted at users with disabilities, especially very low-incidence disabilities." Another possible exception might be certain educational applications (which obscure and hide information for instructional and testing purposes). Probably not necessary to cite as an exception. Perhaps these concerns are unfounded. Opinions are welcomed. ---- ============================= Eric G. Hansen, Ph.D. Development Scientist Educational Testing Service ETS 12-R Rosedale Road Princeton, NJ 08541 (W) 609-734-5615 (Fax) 609-734-1090 E-mail: ehansen@ets.org
Received on Thursday, 18 November 1999 16:58:43 UTC