- From: Wendy Chisholm <wendy@w3.org>
- Date: Tue, 26 Apr 2005 16:23:32 -0400
- To: Becky Gibson <Becky_Gibson@notesdev.ibm.com>
- Cc: wai-gl <w3c-wai-gl@w3.org>
Hello Becky, Good questions. I think the basic answer to all of them is that with JavaScript enabled the user needs to identify the control and what it does; whether it is "Input search term" or "Select date of travel" or "Pick date." It seems to me that most of these examples are covered by using the label element and perhaps in some cases (e.g., Google suggests) a title that gives more info (e.g., "As you type, Google will offer suggestions. Use the arrow keys to navigate the results." - this text appears below, but if you don't know to search for it, interacting with the widget could be very confusing). The issue that I ran into with Google suggests and HPR is that 1. there is no label for the text entry 2. the way that HPR handles text input is to pop-up a window. I enter a search term in the pop-up, press enter, and google suggests sits there staring at me blankly. However, I believe that is a keyboard accessibility issue (should be handled by guideline 2.4) instead of a labeling issue (i.e., not a guideline 1.1 issue). This issue is also related to making state information accessible which in the 4.2 discussions we thought would fit under the new 1.3 (ala "behavior"). Do you feel that covers the issues you raised? If not, can you think of another way to define non-text content that would cover them? Or, do you think we should leave widgets out of Guideline 1.1 all together? If so, can you propose an alternative criterion? Best, --wendy -- wendy a chisholm world wide web consortium web accessibility initiative http://www.w3.org/WAI/ /--
Received on Tuesday, 26 April 2005 20:23:48 UTC