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

Hi;

Responses inline.

Earl

On Thu, Sep 4, 2008 at 3:39 PM, James Craig <jcraig@apple.com> wrote:

> 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.
>

If I had to pick one from a use perspective alone, setting aside the
visuals, I'd say treegrid was closest to how accordion works. I think the
main difference between what is specified for the accordion and the tabpanel
is multiple leaves can be open unlike with tabpanel. The difference between
accordion and tree may only be that accordion can be oriented horizontally
and vertically where treegrids are typically [always?] vertically oriented.

But good or bad, the accordion was designed because it provides a different
user experience, information and function-wise, than tabpanel and treegrid
at least. Maybe these differences are too subtle to the AT user to make it
worth adding an accordion role, but there are use experience differences
from a visual perspective. I think it's appropriate that someday [soon] an
accordion role is introduced.

>
> 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.
>

Is there a better link than this to look at to get a better understanding of
what your proposal? My understanding is it has a single versus modal method
of Actionable/Navigation/Selectable navigation. Are there other URLs you can
point to that help us see the differences in the DHTML SG and VoiceOver's
method?
     http://home.adelphia.net/~bmss/vo/tigervokeys.html

Orca uses modeless navigation in its tables, forms, etc - I'll work on
getting pointers to this too unless its overkill.

Earl



>
> 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.
>>
>>


-- 
Earl
http://www.linkedin.com/in/earljohnson1
earlj.biker@gmail.com