- From: Wendy A Chisholm <wendy@w3.org>
- Date: Fri, 18 Aug 2000 17:40:38 -0400
- To: w3c-wai-gl@w3.org
Hello, Summary of this (rather long) message: I summarized the assumptions that we made in yesterday's call and the W3C Recommendation track. I claim that technology-specific checkpoints as well as a set of core checkpoints could be normative while the supporting code examples and implementation details could be informative. To support my point, I created a few core checkpoints, a few technology-specific checkpoints, and suggestions for supporting discussions. The issues and assumptions from yesterday's telcon: 1. It is preferable that people only interact with one layer of the document. We assume that in most cases, the one layer that developers will work with is the technology-specific checkpoints (commonly referred to as "layer 3" in yesterday's call). 2. It is therefore preferable that a person could claim conformance if they have followed the technology-specific checkpoints. 3. However, our assumption yesterday was that the technology-specific checkpoints might be updated frequently. And, if updated frequently they should be informative. 4. There is concern that informative technology-specific checkpoints would not carry as much weight as we like. It seems that developers need something normative to claim conformance to. 5. The issue with publishing a normative document is how long it takes to update. We might not have the flexibility we need. Therefore, I took an action item to investigate the possibilities of the W3C process [1]. A document on the W3C Recommendation track usually goes through the following steps: 1. Public Working Draft (should be updated every 3 months, can stay at this level indefinitely and usually with several non-public working drafts in between) 2. Last Call (It is suggested to last 3-4 weeks) 3. Candidate Recommendation (Criteria are set before entering this stage and must be satisfied before the document moves on. This step can be skipped if for some reason it is urgent to get to PR). 4. Proposed Recommendation (Mandatory 4 weeks minimum) 5. Sent to the directory (2 weeks) 6. Recommendation If something has been published as a Recommendation and: if only editorial clarifications or bug fixes are made, the document may be republished without going through the process. if a new requirement is added, the document has to go back through the process. However, the question is, "where in the process does it return to - last call or proposed recommendation?" It appears that last year when HTML 4.0 was updated to HTML 4.01 it did not go back to last call but went to Proposed Recommendation (on August 24, 1999 and then became a Recommendation on 24 December 1999). A revised version of CSS was published with last year, but I have not tracked down what process it went through. Since there were only editorial changes it is still CSS1 rather than CSS1.01. The minimum time per the above calendar for publishing minor updates seems to be 6 weeks. The goal of making something normative is to provide a stable document. It if changes often is it really "normative." However, how often will technology-specific documents realistically need to change? Changes to technology-specifics seem to be based on a few things: 1. browser updates 2. spec changes 3. new ideas or work arounds 4. assistive technology updates We had anticipated that the current Techniques document would be fairly dynamic, yet it hasn't really changed too much or very often (we're just now getting ready to publish a new note). Therefore, I would like to challenge the assumptions that we were making yesterday. I think that we can make technology-specific checkpoints normative (and therefore stable). I think that we can do this by separating the technology-specific checkpoints from the techniques (informative - code examples, explanations, screen shots, etc). For example, for XHTML a few technology-specific checkpoints (normative) might be: Provide an "alt" attribute for every IMG element. Provide a "longdesc" attribute for some IMG elements. Provide text equivalents or descriptions within the content of all OBJECT elements. Associate each LABEL element with its INPUT element with the "for" attribute (on the LABEL element). A core techniques document (informative) would discuss: how to write text equivalents, how to decide when to write a long description, and how to write a long description. While the HTML specific techniques (informative) would discuss: examples of "alt" on IMG, examples of "longdesc" on IMG, the many uses of OBJECT with examples of each, examples of associated LABEL and INPUT elements. The HTML/XHTML spec won't change too much from here on out. If it does, we should be well aware of the changes before they happen. They will all be on the same W3C schedule as we are! Browser updates might change the priority or preference of some items, but how much? If a new browser supports cool features but no one uses it yet, does that change what we suggest developers do? As always, the wording is really rough in these "straw" proposals, but I hope you get the general idea of what we might be able to make normative versus informative. --wendy [1] http://www.w3.org/Consortium/Process/Process-19991111/tr.html#Recs -- wendy a chisholm world wide web consortium web accessibility initiative madison, wi usa tel: +1 608 663 6346 /--
Received on Friday, 18 August 2000 17:38:18 UTC