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

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


                                                                           
             "Earl Johnson"                                                
             <earlj.biker@gmai                                             
             l.com>                                                     To 
             Sent by:                  "James Craig" <jcraig@apple.com>    
             wai-xtech-request                                          cc 
             @w3.org                   "wai-xtech@w3.org WAI-XTECH"        
                                       <wai-xtech@w3.org>                  
                                                                   Subject 
             09/04/08 06:47 PM         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