- From: Gregg Vanderheiden <GV@trace.wisc.edu>
- Date: Fri, 11 Aug 2000 14:44:23 -0500
- To: "GL - WAI Guidelines WG (E-mail)" <w3c-wai-gl@w3.org>
Once again, every time I work on WCAG 2.0 it feels good. I think this format really moves us forward in the fundamental changes and modifications to the guidelines to make them better and simpler and more straightforward. With that introduction -- my first point is that many of our principles are way too academic. In some respects it is important to be academic in order to capture the underlying essence. On the other hand, if we can't figure out how to make them more readable, people will just bounce off of them and head in some other direction again, and create their own guidelines. We have to figure out how to make these real. I have a friend who is very good at writing in very fundamental or essential terms but it takes a second paragraph with an example before you really catch on. In the spirit of Ian's comments (about making things longer if necessary to make them understandable) , I would like to suggest that we make some of these a little longer if we need to in order to make them more discernable. More specifics on this are below. ITEM 1 WORDING IN THE INTRODUCTION Some edits in order are: 1. In the introduction we have a sentence that says, "if the checkpoint for a technology are met, then the guideline and principle would also have been satisfied". I don't think that this is true. In many cases we will not have checkpoints which completely cover the guideline. The checkpoints might partially address the topic - but not completely. If they completely cover, then it seems that checkpoints in some ways would be the fundamental statement. I suggest that we remove this item or at least put it in square brackets with three question marks after it so that we come back and check to make sure in deed this is true when we are finished. I'm afraid it won't be and would hate to see this sentence accidentally remain in the final draft if it is not. 2. There is also a phrase "and guidelines should be easiest to meet by following the checkpoints". I would probably suggest changing that to "and the checkpoints are provided to present strategies for addressing each of the checkpoints within the different technologies. 3. A final point on this introduction is that we have to be careful not to imply that someone needs to follow all of the checkpoints in order to satisfy the guideline. If the checkpoints give alternatives, we somehow should combine them and word them so that it's clear that when you do one of the two alternatives you have satisfied the issue. Again, we can talk about this more when we talk about specific checkpoints. ITEM 2 Principle 1 currently talks about all contents being presented in any medium or combination of media. When I read this I'm thinking of cd-roms versus floppy disks versus ???. In the interest of making this easier to understand I would suggest rewording. "Principle 1: Ensure that all content can be presented through any single sensory channel or a combination of sensory channels that may be required by the user (e.g. all information only through vision or only through hearing, etc.)" ITEM 3 Under Guideline 1.1 we talk about talking about a text equivalent for all non-text. I would like to somehow get in here the idea that this needs to be electronic text. Text by itself cannot be translated into any form but electronic text can. Again, since we are talking about very general principles, I would like to eliminate right off the bat anyone thinking that putting a painted image of text on the screen solves the problem. Remember that we are talking about many different formats and not just talking about html. There maybe a wide variety of technologies in the future used to representative information. The key here is that it be electronically readable. Therefore, suggest that 1.1 be changed to. "1.1 provide (an electronically readable) text equivalent for every non-text (auditory or graphical) component or multi-media presentation". ITEM 4 1.2 talks about providing an auditory description of the visual track. We just got through (in 1.1) requiring that they have a text description of the visual track. This, therefore, looks like it's one of those "until" category items. This leaves me in a dilemma. First, audio descriptions of the video track are the preferred approach to providing access. The text approach is really only preferred by individuals who are deaf/blind and can't use the audio description. Thus, saying that the preferred approach is with text and this is a secondary approach seems counter productive. Also given the rulings that are coming down around providing audio description, it appears that this should be required. On the other hand, we are talking about fundamental concepts here. If we are then 1.2 is really redundant with 1.1. Are we saying that 1 plus 2 must be provided theoretically? My final outcome on this is that we should leave 1.2 as it is as a requirement since that's really what's needed today. If, in the future, 1.2 turns out to not be needed anymore, then we can simply remove the requirement. I doubt if anybody will complain if at some point in the future a requirement is removed. ITEM 5 1.3 handles time based multi-media presentation but it drops the timed interaction component. It should probably be part of 1.3 or a separate 1.4. Since it is really the same concept and they maybe intermixed, I think it should probably be part of 1.3. The wording might be: "1.3 for any time based multi-media presentation (e.g. movie or animation) or any single media presentation which requires time synchronized action by the user (e.g. for xyz press the button now). Synchronize any equivalent alternatives (e.g. captions or auditory descriptions of the visual track) with the presentation. ITEM 6 Principle 2 is a good solid principle. However, I believe it will be indecipherable to 95% of the people that it is intended to reach. Mostly I find that the only people who already understand the concept can understand the principle. This is the exact opposite of everything that we've been trying to work toward. However, it is a very difficult one to figure out how to express in simple terms. The only thing I can think of is to add some e.g.'s into it or something to make it more decipherable. I do not have an alternate wording for this one but it definitely needs to be an open issue. ITEM 7 2.1 again, I suggest that we add some e.g.'s in here so that people have an idea for what a mark-up language is and what we mean by a data model. ITEM 8 2.2 same thing with style languages. People are going to be wondering, "Is the style sheet the same as a style language?" ITEM 9 Same thing for 2.3. It really does need an example at the end of it so that people have some idea what it means. ITEM 10 2.4 seems pretty straightforward except the e.g. is capitalized and should be lower case, I believe. ITEM 11 2.5 Hey, I don't have comments on this one except to say that this is a very good example of how an example at the end can render an abstract guideline into something that is much easier to understand. ITEM 12 Priorities. Early in the document it states that one conforms with WCAG 2 if they conform with the guidelines. However, none of the guidelines have any priority on them. We really need to do this. If was interesting to even think about whether or not the principles have a priority on them. One of the interesting things about this reorganization is that it groups things under the general concepts and the general concepts themselves kind of reflect the priorities in some ways. ITEM 13 3.2 is another example of something that is written almost entirely in jargon. "Transformal grammars", "Mark-up languages", etc. This one definitely needs to have a sentence added at the end of it that translates it to English. Alternatively, you could pepper the sentence with e.g.'s to provide examples of what each of these different terms mean so that someone has a chance of understanding them. I am worrying more and more that we are moving toward basic concepts and sinking into jargons at the same time. Please note that jargon is not a bad thing. Jargon terms are generally developed because there are not good terms already in a language to express a particular meeting. The problem is that if you don't know the jargon, then the sentences might as well be written in a foreign language. ITEM 14 4.1 again I would fill this full of e.g.'s for the same reason discussed above. In reading this I know I'm supposed to use a consistent style of presentation, but I'm not sure what a semantic distinction is or a structural distinction nor am I sure what an appropriate formatting convention means (I do, of course, but only because I've been working on the mark-up languages for so long). ITEM 15 4.3 has an e.g. at the end but it is not clear if the e.g. refers to the split into multiple resources or to a technique for overview. (Rather I should say that I can decipher it but it is not clear from the structure of the sentence). I would suggest that 1 e.g. be put to explain what the overview means and a second e.g. to explain what "split into multiple, independent resources" means. ITEM 16 4.6 I would probably add the following example to make this clear list items as "Sanitation Department, Motor Vehicle Department, Revenue Department" rather than "Department of Sanitation, Department of Motor Vehicles, Department of Revenue". ITEM 17 4.9 talks about providing an overview or summary of highly structured materials such as tables. Should we have some kind of a size on this? If you have a table that is 3X3 items, providing an overview is probably a little overkill. ITEM 18 5.4 is a big one. We should think about if that can be made a little less broad and vague. ITEM 19 6.1 I think we should add something to the end to explain transform gracefully a little better. Perhaps something like "6.1 Make sure that websites which use newer technologies transform gracefully when browsers do not support the technology or it is turned off". ITEM 20 6.2 Avoid causing content to blink or flicker. This is a very absolute statement to be in a guideline. As stated, this looks like an absolute prohibition. Although I guess it depends on what the priority level would be for it. If it were a level three then it wouldn't be an absolute prohibition. Blinking or flickering in certain ranges, of course, can be very bad. If we make it a priority 1...I don't know it just seems pretty absolute. ITEM 21 6.3 Avoid causing pages to be refreshed or updated automatically. Again, this depends on the priority level but if this is a 1 or a 2, this could be a real problem for many pages and it would be a severe ban. I would suggest that at least we add, "Unless the user can freeze the action" to the end of the sentence or something like that. ITEM 22 Checkpoint 2.2 from WCAG seems to not fit anywhere. It actually looks like it could fit into two or three places (which is probably why we can't figure out where to put it). The first half looks like it deals with sensory. The second part dealing with black and white screens appears to be device independence. On the other hand, it could also fit into principle 2 since color is a form of presentation. Perhaps that is a better home. Gregg
Received on Friday, 11 August 2000 15:43:59 UTC