W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: Thinking aloud...Definitions (pre-Guideline 1.1 summary)

From: Wendy Chisholm <wendy@w3.org>
Date: Tue, 26 Apr 2005 16:23:32 -0400
Message-ID: <426EA344.8030703@w3.org>
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?


wendy a chisholm
world wide web consortium
web accessibility initiative
Received on Tuesday, 26 April 2005 20:23:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:39 UTC