- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 14 Aug 2000 15:56:02 -0400
- To: w3c-wai-gl@w3.org
Hello, I very much like the idea of creating a more abstract WCAG 2.0. Please consider my comments below. Part 1 requests a change. Part 2 requests an addition (in WCAG 2.0 or in a central document). Part 3 plays with the principles themselves. Part 1) I don't think it's a good idea to redefine the terms Guidelines and Checkpoints. I think doing so will create confusion and I don't understand why it's necessary. a) The checkpoint is the fundamental unit of action and conformance. b) Everything else is either organization (Guidelines) or implementation detail (Technique). c) Principles are nice, and they can help convey a model, but I don't think that they are any more than further organization. d) Please don't shift terms! (A means what B used to mean and B means what C used to mean). If you want more granularity, please just create checkpoints consisting of more than one statement: "You must do A and B and C but aren't required to do D." e) I believe that we have in the past (in both WCAG and ATAG) considered two levels of conformance: "you must do this to meet the checkpoint and by meeting all the checkpoints, you satisfy the Guideline." We dropped this because it confused readers. And I don't think it's necessary. If a Guideline is purely organizational, then you don't have to satisfy it. You only have to satisfy the checkpoints (which are prioritized). Part 2) I think it's important to convey the following (either in WCAG 2.0 or in a document central to all the guidelines): a) The WAI accessibility model assigns responsibilities to different parties for ensuring accessibility: authors, user agent developers, and users. For instance, it is the responsibility of the author to provide alternative content, the responsibility of user agent developers to ensure that it is synchronized and to allow control over style, and it is the responsibility of the user to procure assistive technology. One may also consider two other entities in assigning responsibilities: authoring tool developers and specification writers. Thus, it is the responsibility of the spec writer to ensure that a specification includes accessibility features, separates structure from style, etc. b) The requirements of the WAI Guidelines are determined by the Working Group based on (in no particular order): 1) User needs 2) Technology readily available to users and authors, including authoring software, assistive technologies, operating systems, and specifications. Cost and feasibility do factor into the requirements, though more weight is given to user requirements in general. Making some assumptions more explicit will make the document easier to write and easier to communicate to readers. For example, consider why text is so important: + Today, speech synthesis technology is readily available and fairly reliable. + Most mainstream user agents do not include speech synthesis technology + Optical character recognition and audio-to-speech transcription technology is either not reliable enough or too resource intensive or too expensive. + Text is easy for authors to create Therefore, since today it is easy for authors to create text documents that today's readily available technologies can render to eyes, ears, and fingertips, it is a requirement to provide text equivalents to non-text content. (Refer to comments from Eric Hansen on this topic [2]). Part 3) Organizing principles. While I'm at it, here's how I might break down the requirements (without indicating here which responsibilities are for authors, user agent developers, and users. WARNING: The following organization and commentary has been jotted down capriciously and is subject to emphatic retraction by the author. Comments are welcome! a) Requirements related to perception and the senses: content and user interface must be usable through sight, hearing, and touch. [Again, note that this makes technological assumptions. Perhaps interaction through brainwaves directly will some day be possible. But it's not today.] This principle includes all requirements related to the senses: colors, renderings, control of style due to sensory needs, etc. I think it would also include requirements related to space (e.g., don't require the user to move through space to activate a functionality, the requirement that content be available in serial form) and time (e.g., maintain synchronization on the one hand, and allow the user to control time scales on the other). It also involves communication through APIs between user agents since the assitive technologies are generally there to compensate for sensory limitations. b) Requirements related to meaning: ensure that the user can understand the author's intended meaning. This principle inclues all requirements related to markup (separation of style and structure), to validity of markup, consistency, writing style, simplicity, use of graphics, overviews, summaries, use of metadata, etc. c) Requirements related to usability: This principle includes requirements for navigation, control of sudden changes to content, documentation, configuration, control, repair strategies, implementation of standards, following system conventions, consistency in the user interface, user control of changes to the user interface, etc. Of course, some requirements don't fall perfectly under a particular principle, others may fall into more than one. Some reasons for this choice of groupings: 1) I suspect that sensory requirements can be generalized to device requirements. I can't prove this. <grin> 2) I think it's useful to separate meaning and sense, just as it's useful to separate structure and style. Structure is close to meaning and style is all about rendering (to the senses). It's useful when designing content (I think) to consider meaning before rendering issues, even if the two worlds collide almost immediately (and in the authoring process they are frequently performed close together if not at the same time. For instance, it's useful to provide graphics because they can convey meaning more effectively than text in many cases. But because they're graphics, they raise some other accessibility issues and text equivalents are necessary. 3) Reviewers of the UA Guidelines requested that "content" requirements and "UI" requirements be clearly identified as such. I think that identifying requirements related to using the content, and not just reading it, may be useful. Obviously, navigation bars are part of content, but some of them differ little from UA "back buttons". The usability of a page, site, or piece of software feels different to me than understanding the author's meaning. - Ian [1] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000726.html [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html -- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783
Received on Monday, 14 August 2000 15:56:08 UTC