- From: Jon Gunderson <jongund@illinois.edu>
- Date: Thu, 30 Oct 2008 15:20:05 -0500 (CDT)
- To: Joseph Scheuhammer <clown@utoronto.ca>
- Cc: David Bolter <david.bolter@utoronto.ca>, Aaron M Leventhal <aleventh@us.ibm.com>, w3c-wai-pf@w3.org, wai-xtech@w3.org
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/
Received on Thursday, 30 October 2008 20:20:53 UTC