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

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

From: <Becky_Gibson@notesdev.ibm.com>
Date: Mon, 25 Apr 2005 17:28:33 -0400
To: w3c-wai-gl@w3.org
Message-ID: <OF5F92D923.F84E21B1-ON85256FEE.0071C4E7-85256FEE.00762B66@notesdev.ibm.com>

Wendy's post included some proposed definition of terms - several of which 
have been discussed on the list.  She then made the following statements:
<wendy>
If these terms are defined in these ways (or something similar) then 
non-text content includes:

   1. "widgets" that are created by attaching an event handler to an image
   2. groups of widgets that form a Web application or a flash 
application.
</wendy>
Then Wendy included the example of the Flickr application.   While I could 
see the analogy with the Flickr application, I have a hard time 
extrapolating to other web widgets and how I might label them. 

For example what about Google suggests [1]  which is a modified text entry 
field that provides a drop down list of suggestions as you type characters 
into the text field.  It is currently in beta.   I assume that this is 
implemented via Ajax (see [2] for a description of Ajax).  If the baseline 
does  NOT include  JavaScript and other necessary support, I assume the 
text alternative for this component would be a simple text edit field with 
no suggest feature.  But, if the baseline includes the necessary supported 
technologies, would this still need to be labeled as non-text content? 
How?

Another example is a calendar popup like those used on most airline 
reservation systems.  If there is no JavaScript support, the user is just 
presented with an edit field to enter the date.  With JavaScript in the 
baseline the calendar popup is allowed as long as it is accessible. But, 
again, I am confused as to how it would be labeled or marked as non-text 
content.

Technically these two examples are single widgets.  A more complex example 
might be a calendar scheduling page.  When the user selects the type of 
event to schedule, the application uses JavaScript to hide or show a set 
of controls applicable to the selected event type.  These controls might 
also be widgets (date pickers, time pickers, room selection, etc.)  - thus 
meeting definition number 2 above.   If there were no JavaScript support 
assumed, each event type would likely be supported by a separate page. 
With JavaScript support assumed, the appropriate controls and hidden and 
shown as selections are made on the page. 

I like the spirit of Wendy's proposal but I can't quite figure how to 
apply it to these examples.  These are not as obviously "non-text content" 
as a flash example but I do believe they meet the definition of non-text 
content that Wendy is proposing.

Wendy, can you help clarify?

thanks,
-becky

[1] http://www.google.com/webhp?complete=1&hl=en
[2] http://www.adaptivepath.com/publications/essays/archives/000385.php

Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
Received on Monday, 25 April 2005 21:28:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:37 UTC