- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 07 Sep 2000 11:49:30 -0400
- To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
At 08:29 AM 2000-09-07 -0400, Wendy A Chisholm wrote: >At the face to face meeting in March [1] we determined the need for an >Executive Summary or some sort of short (2 page?) overview of the >guidelines. At the Steering Committee meeting in July(?) it was decided >that this role was clearly ours and not EOs. I believe that William's >draft is the possible basis for this short, easy to read version. > AG:: I think there could be a problem with the concept that the Executive Summary is an Executive Summary of the Content Guidelines. None of our content-encoding strategies works unless the corresponding User Agent and Authoring practices are in place. The principles and core strategies fan out into plans that place requirements on all these three areas. So the story we have to tell is a WAI story, not so much a WCAG story, at this level. The core strategies shared across the WAI are the logical background for the more local, concrete provisions in the WCAG. This doesn't mean the WCA group can't develop of this resource, but it does affect the goals and scope addressed. [separate, more detailed topic continues below] >There seem to be at least 2 main concepts to cover in an overview: >1. separation of content and structure from presentation >2. transform gracefully and device independence > AG:: A possible way to trace the logical origins of the guidelines are as follows: 1. Most general principle: This is the Web Accessibility fusion of the Hippocratic "First, do no harm," and the ADA concept of reasonable accomodation. It reads "First, leave no gratuitous barrier between the information and its consumer." 2. This leads to a survey of variations in human performance, also known as functional impairments, that we want to prevent from turning into the dis-ability to access web-posted information. Hence, "Transform gracefully into various views, don't depend on any one device or sense." 3. As an information engineering tactic to support the range of views required above, "Separate the content that informs all views from the presentation that is view specific." Each of these is in turn, a more concrete, more specific, response to the challenge posed in the one before it. As you may be aware, I remain concerned that we not think the dividing line between content and presentation is obvious, or subject to some a_priori definition aside from the statisfaction of point 2. above. Otherwise, we will find that the web medium is growing in content that is outside our "content" format. We are already suffering mightily from the fact that this has happened in the area of behavior. Web object behavior is today predominantly expressed in a script overlay outside the "document" medium. Web object behavior involves very important _content_ that is not captured in our de_jure "content" medium. Al PS: Technical note. There is content structure and presentation structure. I have been looking at an example page -- I will post it presently -- where there are sections that contentwise are FIELDSETs and presentationwise are sub-regions in a TABLE. The fact that we don't have markup that can indicate both of these things at once is a deep W3C/PF problem. But you can't isolate 'structure' into the 'content' factor. The presentation view reflects content and structure from the deep content, true, but it elaborates the presentation with yet more content and structure. The tree structure we love in eyes-free navigation is often, at a relevant level, view-specific; and the intrinsic structure of the information is graph-shaped, not tree-shaped. [note to self: need to post re: 2 pp. Executive summary has to tell the story of the solution, not the content guidelines. This involves that user agents perform transforms based on the content model captured in the markup, and that authors create content in a process where they review the content through multiple views or presentations. Introduce "markup language is semi-formal" concept; success depends on the correlation between native content and formal content.] >Other major themes to cover? > >I would love to see "WCAG in X points" similar to the "XML in 10 (7 really) >points" [2]. >--wendy > >[1] http://www.w3.org/WAI/GL/meetings/20000320 >[2] http://www.w3.org/XML/1999/XML-in-10-points > >>Given that the guidelines are likely to be scrutinized carefully in a >>variety of contents (by software developers, implementors, regulators, >>policy analysts, etc.), I would agree with William that they must maintain >>a high standard of clarity and precision, thus avoiding any informal >>treatment of the subject. >> >>The latter could be included, perhaps, in a section which is explicitly >>identified as non-normative, or in a separate document, perhaps prepared >>by EO (as they are more in contact with non-specialist audiences than we >>are). >> >>Do we need to define our terms twice, once in an informal introduction >>(perhaps worked on jointly with EO) and again in precise definitions that >>would be designed to avoid the kind of ambiguity and misconstruction that >>can easily arise when terms and concepts are not carefully explained and >>used consistently. >> >>For example, the term "textual equivalent" was introduced into WCAG 1.0 >>(and accompanying documents), at least in part as a response to the >>inadequacies that had been identified in the existing nomenclature. >>Specifically, the term "description" had to be avoided, as it was >>inappropriate and misleading: a genuine "equivalent" to an image, for >>example, achieves the same effect and plays the same role as the graphical >>content, but often does not constitute a description of it. Emphasis is >>placed on the function and meaning to be communicated in the context of >>the document, rather than on a characterisation of the medium-specific >>presentation for which the text provides a substitute. >> >>Similar arguments apply to many of the other terms which have been >>introduced in the course of developing the guidelines. They serve to >>clarify concepts and, if used consistently, can actually facilitate >>comprehension of the text (for example by avoiding long and repetitious >>explanatory clauses in sentences). >> >>Thus, writing on my own behalf and not in my capacity as co-chair, I would >>urge that informal explanations be either avoided or provided in sections >>of the working group's deliverables that are clearly identified as >>illucidatory and non-normative. > >-- >wendy a chisholm >world wide web consortium >web accessibility initiative >madison, wi usa >tel: +1 608 663 6346 >/-- >
Received on Thursday, 7 September 2000 11:33:41 UTC