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

Forgot a difference between accordion and treegrid - accordion looks like
its navigation scheme should be much closer to tabpanel vs treegrid.

Perhaps the fact that no one can say accordion is always just treegrid like
or always just tabpanel-like is reason enough to introduce an accordion
role.

Earl

On Thu, Sep 4, 2008 at 4:47 PM, Earl Johnson <earlj.biker@gmail.com> wrote:

> 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<http://home.adelphia.net/%7Ebmss/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
>