- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 9 Aug 2001 13:28:53 -0500
- To: "GLWAI Guidelines WG \(GL - WAI Guidelines WG\)" <w3c-wai-gl@w3.org>
- Cc: "Wendy Chisholm \(wendy\)" <wendy@w3.org>, <jasonw@ariel.ucs.unimelb.edu.au>
Here is what I have so far on the Criteria and Examples Review Have gotten up to checkpoint 2.7 Items needed action are marked with three asterisks *** Gregg 1) Normative *** At the last telecon we decided to label the Normative and Non-normative sections specifically in each checkpoint. We decided that describing the normative and non-normative sections in the introduction was not sufficient. I don’t see that in the current draft. *** We also decided to use some type of outlining to break the two types of content apart. A box or background color around the non-normative information to go along with the text cues. ------------------------------------------- Check Point 1.1 Provide a text equivalent for all non-text content. -------------------------------------------- - SUCCESS CRITERIA - the success criteria in the draft ARE necessary and sufficient to meet the stated 1.1 checkpoint. So OK as is. There will be some controversy however over the fact that this checkpoint requires a full text script (all dialog and all visuals in a text document) for every piece of video on a site. If this is a priority 1 checkpoint, which it always has been, this will be a required item for all movies in addition to captions and audio descriptions. ---- - DEFINITION - *** There is a bug in the last line of the definition. The MAY needs to be changed to CAN. - CAN be easily converted to braille or speech, or displayed in a larger font or different colors. It is not a permission but a requirement that it can be easily converted. ----- The following sentence is in the definitions section. "Depending on the purpose and content of the non-text content, a short label may be appropriate, or a more thorough explanation may be required." *** It seems like guidance, not a definition. Also seems to contradict the success criteria. It should be removed or added to the success criteria. ----- EXAMPLES -- good examples. All are examples of sufficient solutions that would satisfy the success criteria. ------------------------------------------ Checkpoint 1.2 Synchronize media equivalents with time-dependent presentations. -------------------------------------------- This checkpoint is currently broken as written The checkpoint asks for Equivalents to be Synchronized -- but it does not require that any be provided other than what is required in 1.1. "Synchronize media equivalents with time-dependent presentations." The first CRITERIA however requires audio equivalents be provided. It doesn’t say anything about synchronization. *** A FIX -- Change the checkpoint to read "PROVIDE AND sychronize media equivalents with time-dependent presentations" OR "PROVIDE sychronized media equivalents with time-dependent presentations" IF THE CHANGE IS MADE THEN Then the success criteria WOULD PASS the test for Necessary and Sufficient to meet the new checkpoint. And audio description would be required. >>There will be controversy however around the following points. 1) This requires that all live broadcasts be captioned and described either in real time or after-the-fact. Some may object to the 'after-the-fact" part but more likely the requirement for all live material to be described will be a problem. Since this guidelines also covers audio description and captioning of professional videos and movies, it is likely to have a high priority (P1?) . thus the requirement that all live broadcasts be captioned and described would be a stiff mountain. *** Suggestion: - that the fourth criteria which gives an exception to the first criteria be placed either just below the first or indented underneath it. DEFINITIONS *** Suggest adding "FOR THE OTHER MEDIA TRACK' at the end of: "Multimedia presentations include both audio and video tracks. During the time that one of the tracks does not present any significant information, there is opportunity to include a synchronized equivalent FOR THE OTHER MEDIA TRACK." Otherwise it doesn’t quite make sense. EXAMPLES ARE GOOD All examples are sufficient examples in that they satisfy all the criteria for that checkpoint ------------------------------------------- Checkpoint 1.3 Use markup or a data model to provide the logical structure of content. -------------------------------------------- SUCCESS CRITERIA This is a tough one. But what we have looks good. The criteria appear to be both necessary and sufficient. I say we call these as GOOD unless someone can think of how you could do these two and not have satisfied the checkpoint. My only problem in saying BINGO right out, is that this is checkpoint covers a lot of ground. Lets say it is good for this draft and see if we find any exceptions as we do technology specific points. BENEFITS *** The word MAY should be replaced with the word CAN. It is their ability that is provided, not permission. ------------------------------------------- Checkpoint 1.4 Identify the primary natural language of text and text equivalents and all changes in natural language -------------------------------------------- SUCCESS CRITERIA *** These look good except that the words "SHOULD" and 'WILL BE" should be remove and replaces with ARE. Also it should be made into bullets or numbered list like the other success criteria. So it reads 1. Changes in language ARE identified at the level the changes occur. 2. If there is never a change throughout a whole site, then identification can occur at the highest level (usually at a page or document level). 3. If changes occur at the word or phrase level, then changes ARE identified at the word or phrase level using the markup appropriate to the markup language in use. QUESTION: Why mention no change throughout whole site -- and then say highest level is the page? Could it be the site? Wording is a bit ambiguous but workable as is. BENEFITS *** Suggest adding "WHICH CAN MAKE THE PHRASE UNINTELLIGIBLE" to the end of When they are not identified, the speech synthesizer will use the default accent and pronunciation dictionary WHICH CAN MAKE THE PHRASE UNINTELLIGIBLE EXAMPLE - is good and sufficient ------------------------------------------- Checkpoint 1.5 Separate content and structure from presentation -------------------------------------------- CRITERIA The second criteria is basically a restatement of the checkpoint with an exception. "To the extent that the technology allows (see checkpoint solutions) the markup or data model representing the structure of the content, must be logically separated from the presentation, either in separate data structures or in a style sheet" It is clearly necessary -- but with the exception. So it is in fact LESS than the checkpoint and not sufficient If the "where technology allows' is intended to be part of the criterion, then it should be in the checkpoint. The checkpoint should NOT be more severe than the criteria for success. *** We need to remove the exception from the criteria or add it to the checkpoint. The FIRST criteria is "There must be sufficient markup or a sufficient data model to ensure that a logical, linear reading order can be derived from the content." This seems to be MORE than the checkpoint. Separating content and structure from presentation does NOT imply a linear presentation. I can show you many structures that cannot be presented logically in a linear order. Hmmmm Do we mean "Text" content? *** I do not recommend a change on this one at this time. We should just log it into an issues list to discuss later. it may not be a direct criterion of the checkpoint -- but we should capture the idea somewhere. EXAMPLES examples are good and sufficient ------------------------------------------- Checkpoint 2.1 Provide multiple site navigation mechanisms. -------------------------------------------- SUCCESS CRITERIA The criteria for 2.1 read as follows 1- One or more navigation mechanisms are provided which cover all or selected portions of the content comprising a web site. 2- Search functions report errors and may attempt to correct mistakes in user input. (refer to checkpoint 2.7) 3- The site navigation mechanisms are clearly distinguished from the main content and can be easily located. These criteria are neither necessary or sufficient as written. In this case they fail both tests - the first one is basically a restatement of the checkpoint except that it says that only part of a site needs to have multiple navigation mechanisms so it is not sufficient (or the checkpoint needs to be changed to say full or partial site navigation. - the second criteria is a technique but is not required so cannot be a criteria. It should be moved to techniques. (it is not an example because it does not meet the criteria) - the third criteria is ok. - but the set is not ok unless the qualification is removed from the first (or added to the guideline) in this case, the criteria are almost identicle to the checkpoint. *** Suggest that we remove #2. that # 1 be changed to remove the partial site as good enough, unless we want to add partial to the checkpoint. EXAMPLES There are no examples. ------------------------------------------- Checkpoint 2.2 Provide consistent and predictable responses to user actions. -------------------------------------------- SUCCESS CRITERIA These all seem to be good advice. And it seems to be a good collection. Good coverage. Can't think of anything missing -- but we should examine that after TR. I wonder though about requiring them for a whole site. What if a site has documents or sections by different authors. Or sections for advanced physicists and sections for children. Do they have to have the same type of interface? If someone creates special versions of info for people with cognitive disabilities, do they then have to use those interfaces approaches throughout their site to comply with this guideline? Because we use "SIMILAR" and not "SAME" we leave a fair amount of room for different versions for different cognitive levels. *** If we changed "SITE" to " SITE, SECTIONS OR PAGES MEANT TO BE USED TOGETHER" then I think these could meet the SUCCESS CRITERIA tests. We should come back to these later though and make sure that we have everything we want here. (e.g. will meeting ONLY these be sufficient. ) But the look good to me. *** Oh, one more point. How do we handle joke sites or mystery games etc. it may be appropriate to sometimes break rules on purpose. How do you demonstrate bad design on a site and still have the site comply? We should have add an exception statement for situations where the goal is specifically to have controls that do not act like one would think they should. How about if we add one more criteria that reads " - if controls are purposefully made to behave in unexpected or irregular fashion for a specific purpose (demonstration, humor, mystery, etc) then this is so stated on the pages or intro to the pages." EXAMPLES I presume these are not examples but simply notes that we should add examples. If they are examples of places where we should do this, I would move that text up to the BENEFITS section. Otherwise I suggest we change the EXAMPLES text so that they are examples of conformance. ------------------------------------------- Checkpoint 2.3 Give users control of mechanisms that cause extreme changes in context. -------------------------------------------- SUCCESS CRITERIA Seem to be both necessary an sufficient except that the criteria are to give control or to warn and the guideline is that you must give control. *** To use these criteria we would need to modify the checkpoint to say Warn or give users control of mechanisms that cause extreme changes in context. OR Give users control of mechanisms that cause extreme changes in context - or warn them in advance of triggering changes. One could argue that warning someone of something was giving them control but that argument could be applied in many places resulting in inaccessible interfaces that people are just warned of. **** also suggest we add the phrase "OR SO THEY CAN BE PREPARED FOR THE CHANGE' to the end of: "....or identify extreme changes in context before they occur so the user may determine if they wish to proceed OR SO THEY CAN BE PREPARED FOR THE CHANGE. ------------------------------------------- Checkpoint 2.4 Either give the user control over how long they can interact with content that requires a timed response or give them as much time as possible. -------------------------------------------- SUCCESS CRITERIA The criteria require that the user have control but the Checkpoint does not The criteria are therefore more strict than the checkpoint They therefore fail the necessary Test. Other than that they are well written and appear sufficient. **** We need to either add the exception to the criteria or remove it from the checkpoint. We should also define what the maximum possible means -- or at least what is reasonable. EXAMPLES Are good and sufficient ------------------------------------------- Checkpoint 2.5 Use device-independent event handlers. -------------------------------------------- SUCCESS CRITERIA This looks like it has two different sets of Success Criteria. It doesn’t but it looks that way. ***We need to format it so that it is clear if you have to do all three parts, or 1 and 2 OR 3, Or what. Otherwise looks good. EXAMPLE The Example is good and sufficient ------------------------------------------- Checkpoint 2.6 Avoid causing the screen to flicker. -------------------------------------------- SUCCESS CRITERIA The success criteria just ends mid-sentence. "You will have successfully avoided causing the screen to flicker if you:" **** we should just remove the fragment and the "success criteria" title or we should add something to the end like " do not include content that will flicker between the frequencies of 3 and 54 hz. " ------------------------------------------- Checkpoint 2.7 Handle input errors, such as misspellings -------------------------------------------- SUCCESS CRITERIA The success criteria currently reads You will have successfully provided more than one path or method to find content if you: - check for misspelled words and suggest correct spellings when text entry is required. - where possible, let the user select from a list of options rather than generate text. **** as per previous discussion - we need to fix the lead in to reflect the new checkpoint. **** we should remove these as checkpoints and put them down below --- or just label them as "strategies for addressing this item" The intro paragraph makes it clear this is new and in discussion. We should keep the content looking like ideas and discussion rather than having things labeled as compliance criteria. EXAMPLE Example is hard to evaluate til we work on this item more.
Received on Thursday, 9 August 2001 14:36:14 UTC