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

Hi Rich;

Finishing the harmonizing shouldn't be a problem, I've provided feedback
besed on James' diferences table explaining differences and correcting the
Control+F10 type-o.

I'm not groking your hasPanel, managesPanel suggestion tho. Mentioning ID
suggests the answer is no but, is this suggestion aimed at helping AT know
when the widget with focus is a tabpanel or accordion? If yes and because it
seemed like an easy way of addressing this rdf-less dilema, what ever
happened to Aaron's proposal that included suggesting a comma separated Role
list? as a way to do this?

ej

On Sun, Oct 5, 2008 at 6:13 AM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> Earl, James,
>
> A challenge we have is each element in the tree is considered a treeitem.
> AT's accustomed to dealing with tree widgets are not aware that the tree
> item would represent a container for a panel. To deal with this I believe we
> need to clearly articulate this to the AT. Perhaps a hasPanel property or
> managesPanel property containing an ID for the panel container. This could
> help ATs with tabpanel too. With that in hand then I think the thing to do
> is to define a standard set of keys to navigate in and out of the panel.
> Also, like owns, the panel could be anywhere in the DOM as it won't show up
> in the accessibility api if it is not visible.
>
> I like this approach as we could take a similar approach to treegrids where
> one could place an excerpt from the mail in the panel and you could in fact
> have multiple panels open at a time.
>
> Thoughts?
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
>
> [image: Inactive hide details for "Earl Johnson" <earlj.biker@gmail.com>]"Earl
> Johnson" <earlj.biker@gmail.com>
>
>
>
>     *"Earl Johnson" <earlj.biker@gmail.com>*
>             Sent by: wai-xtech-request@w3.org
>
>             09/04/08 06:47 PM
>
>
> To
>
> "James Craig" <jcraig@apple.com>
> cc
>
> "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>
>
> Subject
>
> 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*<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
>          *<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*<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*<http://www.linkedin.com/in/earljohnson1>
> *
> **earlj.biker@gmail.com* <earlj.biker@gmail.com>
>