- From: David MacDonald <befree@magma.ca>
- Date: Wed, 20 Sep 2006 22:30:17 -0400
- To: "'Becky Gibson'" <Becky_Gibson@notesdev.ibm.com>, <public-wcag-teamc@w3.org>
Thanks for the responses Becky My responses are inline > http://w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=1078 >Becky: I don't think we need a technique describing how to style TH elements since that is just basic CSS functionality and does not solve a particular accessibility feature. This issue falls into the basic category of "AT push" and whether we move this to advisory or not depends upon the outcome of the AT push discussion. David: I don't think the fundamental intention of the WCAG WG is to be a lobbying body to AT vendors. I think our job is to provide techniques that work in today's technology. That's why we separated out the non-technology specific Guidelines from the "evergreen" non normative techniques. I think our techniques should neither be outdated nor a wish list for future AT features. They are things that work today, and when there are issues we add a note. There will always be lots of people who don't follow our guidelines and that I think is the source of the AT PUSH. That is why AT can read link context today and navigate through layout tables, because people did not follow the WCAG 1.0 guidelines. The WCAG 1.0 didn't need to push AT...the non-compliant community did that. I think we need a technique to style the TH element because the reason authors would use the non-supported <scope> element is because they think the TH styling features handcuff them to Bold, Centered. If they use the scope element lots of people will not be able to use those tables so we need to show them they can get the results they want from CSS. --------------------------------------------- >Becky:> LC 979 http://w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=979 I think Al is trying to say that we need to be more specific. He wants to see clear identification of the error at level 1 and more information to help correct it at level 2. In the login example, the error should be specific as to whether the problem is a bad username or a bad password. This could be identified with the proper return of error codes. His example is that people following the SC as written could provide text that says, "bad password" for all login errors rather than just the specific error of bad password. And, if the error code was more specific, an AT could interpret and provide the correct error (either bad password or bad username). I agree that we should include the response of 626 do address his concern about text vs. metadata. The better way to address his concern might be in the how to meet section by explaining the error should be specific as possible. We might also want to include and example that allows the AT to present the user with the information. Example: A login form has fields for user name and password. A form submitted with a bad username will be reloaded. The form will contain an textual error message a the top which states, "invalid login". The username field has been updated with metadata indicating that the value was invalid. When the user sets focus to the username field, the user agent and/or AT will interpret the metadata and indicate to the user that the current value is invalid. Thus, the user is aware from the text message in the form that the login was invalid and the user agent and/or AT can interpret additional information about the specific error (invalid username) and present it to the user. David: I'm ok with that your suggestion although I didn't read it as you have. The biggest thing I came away from the comment with is his proposal to move the description of the error to a lower level(Although he is also calling for it to be more detailed and delivered via metadata). Al's Proposal: "Separate identification of the bad data from explanation of how it is bad. Move explanation of nature of error to lower level. Allow satisfaction by either text message or metadata understandable by user's automation." I have adjusted the response as per your suggestion and added an action item to the intent and an action for a meta example (I don't know of any AT products right now that use meta data from web page <head> sections for error messages) And I've changed it to a partial accept. Becky > LC 730 > http://w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=730 Hmm, is he asking that the W3C address adding a mechanism to HTML to provide for context sensitive help or that WCAG provide and HTML technique for this? Since the comment was addressed to WCAG I would assume the latter but we should clarify that we are adding and HTML technique. I'm just curious - what do we think this technique is? Providing an additional link to more information? Does the link open a floating popup or alert, go to a new page??? There might be a DHTML technique here as well - using the describedby property or alert role. David: I was thinking of tool tips but certainly we could use JavaScript (or DHTML) Cheers David
Received on Thursday, 21 September 2006 02:30:41 UTC