RE: proposed responses

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