Re: GWT accordion example

All the examples posted recently make me lean toward the adoption of single
or multiselect tabpanel. You could have the toolbar even have a button for
main content, search, navigation, etc. Pressing the button could expand
that region and move you there - much like skip to main content. Both
tabpanel and multiselect are in ARIA today as is toolbar. From a screen
reader perspective we could say toolbar multiselectable or accordion. The
constructs we have.

I took another look at the Sun accordion example:
http://webdev2.sun.com/example/faces/accordion/a11yAccordion.jsp. To me
this again is a toolbar which is responsible for controlling the
multiselectable tabpanel.

I can envision an entire web page with this configuration. The toolbar
would be kind of like a dashboard for the controlling the expand and
collapse of all the sections. Each section could be expandable and
collapsible. By switching to single select (typical tab panel) you could
open one while closing another.

The GWT example should behave like the Dojo tabpanel (single select).

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             Jon Gunderson                                                 
             <jongund@illinois                                             
             .edu>                                                      To 
             Sent by:                  Joseph Scheuhammer                  
             wai-xtech-request         <clown@utoronto.ca>                 
             @w3.org                                                    cc 
                                       David Bolter                        
                                       <david.bolter@utoronto.ca>, Aaron M 
             10/30/2008 03:20          Leventhal/Cambridge/IBM@IBMUS,      
             PM                        w3c-wai-pf@w3.org, wai-xtech@w3.org 
                                                                   Subject 
                                       Re: GWT accordion example           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Buttons should have labels that describe what they do and ARIA has
mechanism for doing this.  So if there is a sequence of buttons the button
labeling can orient the users to the sequence.

One of the major problem that I have with the accordion role is that all
the keyboard models seem very complex and there is no general consensus on
what the keyboard model should be.  I am worried that these model(s) may be
more confusing than helpful to users.  I also don't want to ask developers
to create complex keyboard models that turn out not to be useful to people
with disabilities.


Jon



---- Original message ----
>Date: Thu, 30 Oct 2008 14:40:23 -0400
>From: Joseph Scheuhammer <clown@utoronto.ca>
>Subject: Re: GWT accordion example
>To: Jon Gunderson <jongund@illinois.edu>
>Cc: David Bolter <david.bolter@utoronto.ca>, Aaron M Leventhal
<aleventh@us.ibm.com>, w3c-wai-pf@w3.org, wai-xtech@w3.org
>
>
>Jon wrote:
>> These seem to me little more than buttons the expose and hide content.
I do not think they are a special control.
>I think a wizard or a pager, at least, are more than just buttons to
>expose and hide content.  The essential feature of wizards is that the
>content is presented in a sequence.  The UI is a way to guide a user
>through the content.  Which content is revealed depends on past choices,
>and the path through the sequence is not necessarily straight forward.
>
>In contrast, tab lists and accordions are random access interfaces in
>that there is no restriction that the content be revealed in any
>sequence.  Users can interact sequentially with a tab panel, but they
>are not required to.*
>
>That all four potentially use the same or very similar keystrokes is
>somewhat remarkable.
>
>That being said, if there is no benefit to, say, screen reader users in
>exposing these components as anything more than buttons for showing and
>hiding content, then, well, okay.  The point behind giving more specific
>roles and states is that they describe the HTML to the user in a way
>that helps them understand what they can do.
>
>The question is:  is describing the situation as buttons sufficient?  I
>presume the buttons would include an aria-controls property to indicate
>what content is shown/hidden by them.  What else would be needed?  What
>is the role of the content itself?  Does it need one?  Note that if it
>were described as a tablist, and the content as a tabpanel (with their
>properties/states), the user gets the relationships "for free".  And the
>keystrokes.e
>
>-------
>
>* The fact that wizards and pagers define an ordering implies that there
>needs to be more than just classifying them with role="tablist".  There
>needs to be a property than indicates the order vs. random-access
>aspect.  Is it aria-flowto
>(http://www.w3.org/WAI/PF/aria/#aria-flowto)?  That is, the presence of
>aria-flowto indicates this is a tablist that is sequenced (wizard,
>pager); whereas its absence indicates lack of order.
>
>--
>;;;;joseph
>
>'This is not war -- this is pest control!'
>      - "Doomsday", Dalek Leader -
>
>
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/