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

Hi James,
I am from Windows world primarily but do completely agree with you that
Voiceover's approach to interacting with complex widget is the best one.
It does get a bit tedious at times, particularly for simple widgets, but
for complex ones I don't think there is a better solution.
"Interact with" approach would elliminate a lot of keyboard presses and
will make for a more granular object-oriented interaction model.
The only issue will be educating the user and necessary tweaks for the
Windows AT software.


From: [] On
Behalf Of James Craig
Sent: Thursday, September 04, 2008 3:40 PM
To: Earl Johnson
Subject: Re: What is the current situation with ARIA and accordion?

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.

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.

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 ...:
	btw - Sun was correct when the keysequence proposal was
approved, now I'm a free agent.
	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
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
		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

Received on Thursday, 4 September 2008 23:22:54 UTC