Re: What is the current situation with ARIA and accordion?

The discussion in today's call was whether or not the accordion  
control could be handled by one of the existing roles such as tree,  
tabpanel, or list. I submit that Earl's example conforms to the  
behavior of a single-column treegrid. Single-select accordion panels  
could be treegrids as well.

We still need to address the expected behavior of widgets within  
widgets. My opinion, although admittedly biased, is that VoiceOver's  
"interact with [widget]" navigation model is the best approach, and  
would eliminate the need for most of the excessively complex keyboard  
interactions defined in the AOL style guide.


On Sep 4, 2008, at 3:21 PM, Earl Johnson wrote:

> If you'll accept a buggy keynav example for the accordion component,  
> check out the following link - you may need to use the mouse or get  
> lost visually ...:
>    http://webdev2.sun.com/example/faces/accordion/a11yAccordion.jsp
>
> btw - Sun was correct when the keysequence proposal was approved,  
> now I'm a free agent.
>
> ej
>
>
> On Thu, Sep 4, 2008 at 1:35 PM, Al Gilman wrote:
>
> On 2 Sep 2008, at 7:19 PM, Victor Tsaran wrote:
>
> Hello all,
> I know that in early stages of ARIA there was a proposal for  
> accordion. Earl Johnson from Sun has written a "complete proposal"  
> for accordion http://dev.aol.com/dhtml_style_guide#accordion as part  
> of the DHTML Style Guide,. However, there are no ARIA roles and  
> states that describe the actual widget in all its incarnations, e.g.  
> single panels, multiple expanded panels etc. I understand that one  
> of the suggestions is to use appropriate roles and states for the  
> job, e.g. menus, tab panels, treeviews etc. However, this may not  
> always be a desirable option, particularly for distributable  
> components.
> What is the plan for accordions going forward?
> Should we contribute our own findings and/or proposal for this widget?
>
> There are serious problems with adding a special role for the  
> accordion widget.
> The accessibility APIs and assistive technologies don't know this  
> role at present.
>
> .. but we're (PFWG) weakening, and have decided to give it a second  
> look.
>
> Can we have references to some live examples from the web?
>
> Worked examples illustrating a proposed design pattern for the best  
> practices
> would be the ultimate; but for now just some examples that work with  
> eyes
> and keyboard showing multi-selectability and some or all of Earl's  
> keystroke
> functions.
>