- From: Hansen, Eric <ehansen@ets.org>
- Date: Fri, 06 Oct 2000 18:28:20 -0400
- To: "UA List (E-mail)" <w3c-wai-ua@w3.org>, "Ian Jacobs (E-mail)" <ijacobs@w3.org>, "Jon Gunderson (E-mail)" <jongund@ux1.cso.uiuc.edu>
I suggest some changes to the Abstract. Old (29 September 2000): "Abstract" "The guidelines in this document explain to developers how to design user agents that are accessible to people with disabilities. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers, plug-ins, and other assistive technologies that provide access to Web content. Virtually all the requirements in this document apply to mainstream graphical browsers and multimedia players. Many of the requirements also apply to other user agents, such as text browsers, voice browsers, and assistive technologies. Following the principles presented in this document will help make the Web accessible to users with disabilities and will benefit all users." New 1: "Abstract" "This document provides guidelines to help developers design Web browsers that are more accessible to people with disabilities. Virtually all the requirements in this document apply to mainstream graphical desktop browsers and many of the requirements apply to browsers that have different or more limited media presentation capabilities, such as text-only browsers and audio-only browsers. A valid claim for conformance to this document is expected to be a useful, though imperfect, indicator of accessibility. The document places strong emphasis on communication with other software, including assistive technologies. Although some known accessibility capabilities (e.g., Braille support, visual object enlargement, some navigation via speech output) are outside the scope of the document, some of these capabilities can be met through assistive technologies. For many people with disabilities, a conformant Web browser supplemented with such assistive technologies is likely to provide an appropriate accessibility solution." Comment 1: Since the document does not define a clear end-state of "accessibility", it is not correct to characterize the document as telling developers "how to design user agents that are accessible". We are mainly, if not "only", telling them what direction to move in. Comment 2: I use the term "Web browser" because I think that it communicates better. If we just say that, then we don't have to confuse things with the definition of user agent. This change sure seems to make things clearer. Comment 3: I think that it is critical that the Abstract properly make clear that we recognize that there are known pieces of the accessibility puzzle that are outside the scope of the document. Comment 4: I avoided the term "built-in" accessibility features because I think that it will lead to confusion about whether one means 'built-in to the browser' or 'built-in to the subject of the claim.' New 2: "Abstract" "This document provides guidelines to help developers design Web browsers that are more accessible to people with disabilities. Virtually all the requirements in this document apply to mainstream graphical desktop browsers and many of the requirements apply to browsers that have different or more limited media presentation capabilities, such as text-only browsers and audio-only browsers. In some cases a Web browser that conforms to this document will constitute an appropriate accessibility solution. In other cases, the conforming Web browser must be supplemented by assistive technologies providing capabilities that are beyond the scope of this document." Comment 1: This one is shortened. There will be more to come soon (tonight or tomorrow) on scope and limitations. =========================== Eric G. Hansen, Ph.D. Development Scientist Educational Testing Service ETS 12-R Princeton, NJ 08541 609-734-5615 (Voice) E-mail: ehansen@ets.org (W) 609-734-5615 (Voice) FAX 609-734-1090
Received on Friday, 6 October 2000 18:28:23 UTC