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

I think Al's point is well-taken in that it takes a long time for all
browsers and APIs to integrate a new role. On the other hand, developers
(in my company at least) are all about symantic goodies. So if we are
talking about accordion, they'd like to see a role of accordion.
But definitely, we will have to go for compromise since usability calls
for it. :)
V
 

________________________________

From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Earl Johnson
Sent: Thursday, September 04, 2008 5:01 PM
To: James Craig
Cc: wai-xtech@w3.org WAI-XTECH
Subject: 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