Accordion and role="tab"

What is the rational for putting a role="tab" on the elements which trigger
the accordion?
I ask because, on examining some code for a client, I realized that Jaws is
not announcing the element type as heading, because the role="tab" is
present. Using headings as trigger elements is nice because:
1. when javascript is not available, the code degrades into
<h3...><div...><h3...><div...>... which is easily navicable via the screen
reader;
2. navigation by heading with javascript enabled allows one to hear the
accordion triggers without having to tab through every link or read content
line-by-line.

-- Rich

Hi Rich,

Marking up the accordion as a tablist using ARIA is the recommended
approach for accordion widgets. It allows the accordion structure to
be navigated as a composite widget, rather than just a succession of
individual headings. The ARIA markup makes it easier to screen reader
users to understand how to interact with thie accordion (e.g. that
they can expand and collapse accordion sections using the arrow keys,
how many sections the accordion has, etc.).

The rationale is that when ARIA is not supported, the heading elements
will be used as structural fallback because of the benefits you
describe.

The accordion is just as easy to navigate or skip as a heading
structure (when running in application mode), since it only takes up
one stop in the tab order and allows you to navigate the sections with
the arrow keys (while skipping the contents of the sections, so there
is no need to read by link or line by line.)

I agree though that it is not useful that the heading structure is no
longer available to assistive technology because the heading roles are
overridden. Personally, I think that screen readers should still
recognize headings in virtual mode, regardless of whether the heading
elements have been set to a different role or not. This would allow
headings to be used as widgets while without taking away the benefits
of heading navigation.

A possible fix would be to place the ARIA tab markup on the link
elements inside the headings rather than on the headings themselves.
So screen readers running in application mode and keyboard users would
be interacting the the link elements (which have the role="tab" etc.
markup), but users of older technology and screen readers running in
virtual mode would still be able to use the heading structure. The
problem of this solution is that it clutters the accessible structure
of the accordion for modern screen readers, because now you have these
heading elements between the tablist role element and the tab role
elements. An effect of this would be that some screen readers would
not be able to determine how many items there are in the accordion
(for example, NVDA would incorrectly announce "1 of 1" for each
accordion header).

Keep in mind though: If Javascript is not supported, the role
attributes will not be applied so the problem will not occur (the
heading structure will still be navigable. Similarly, for older
technology that does not support ARIA the heading structure will
remain in tact as well.

Hope this answers your question,

Hans

The problem with this explanation is that people don't use application mode
when navigating a webpage.
If you look at the accordion demo page with jaws and switch into app mode
with jawsKey+z, tab to the accordion and click one of the tabs, how do you
then read the content of the tab you just opened? The only way is to switch
out of app mode back to virtual mode.
The sequence then becomes:
1. navigate to the accordion in virtual mode;
2. switch to app mode;
3. press tab and/or shift+tab till you land on one of the accordion tabs
(when you switch modes, its not clear where the real focus will be so you
need to try both tab and shift+tab till you land on the right thing);
4. arrow to the tab you want and press enter;
5. switch back to virtual mode (the virtual focus seems to be on the tab you
just clicked);
6. now successive presses of downArrow should allow you to read the content.

What a pain!

-- Rich

Hi Rich,

Hans

--
You received this message because you are subscribed to the Google Groups
"jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-a11y...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-a11y?hl=en.

Agreed, it's far from ideal to have to switch constantly. It's a
common problem caused by the mixture of rich customized widgets
requiring app mode and static content requiring virtual mode. A
similar problem occurs for grids or treegrids that have expandable
sections containing static content. Application mode works really well
when the entire interface is designed for it (and then user would
navigate all pages in app mode), but in situations like this it can
become a nuisance.

I'm don't think the best solution is to go back to the traditional
approach where every accordion header and focusable elements inside
the accordion sections clutter up the tab order. I think the screen
readers need to catch up a bit and come up with a more clever way to
deal with these situations. JAWS will now automatically switch in and
out of PC cursor mode for some widgets, but in the case of a tablist /
accordion that wouldn't work because of arrow key conflicts. But since
the ARIA specs require us to programmatically associate a tab with its
corresponding tabpanel, why couldn't the screen reader work with that?
For example, why can't the screen reader provide a tablist related
shortcut that allows you to move the virtual cursor into to the
tabpanel associated with the currently focused tab? And similarly,
there could be a virtual mode shortcut to move focus back to the tab
associated to the tab panel the user is currently navigating virtually
(or the same shortcut could be used as a toggle shortcut for both
features).

In this scenario, the procedure would be:

1. You're navigating in virtual mode. When the accordion is
encountered, JAWS automatically switches to application mode.
2. Use the arrow keys to change the selected accordion header.
3. Use the "move into tabpanel" shortcut to move the virtual cursor to
the start of the associated tabpanel (application mode is
automatically disabled to allow virtual navigation).
4. Use the "move back to tab" shortcut to immediately move focus back
to the associated tab (application mode is automatically enabled again
to allow interaction with the accordion widget).

With this approach there would be less need for switching, and less
time wasted trying to find back your position. Do you think that would
be a better solution? Anyway, I guess the wai-xtech mailing list is
probably a better place to discuss this.

As I said, I agree the situation you describe is a pain, but I think
it's a problem that eventually will be caught up with by AT.

Hans

I think this should definitely move to wai-xtech.

Cheers,
D

OK, just re-read your old messages and I think you are correct; we need yet
another "standard" keyboard command to switch from tablist to tab panel which
works in accordion and tab widgets. I wish we could use control+tab for this,
but this allows navigation through Firefox's tabs. However, if this were
strictly implemented in-context (i.e. only if you were focused on an
appropriate widget), then impact on the browser's tab navigation would be
minimal. I think tab is been the defacto "standard" for navigation, so using
a modified tab key command makes sense.
Successive presses of control+tab or control+shift+tab would cycle you between
tablist and panel in forward or reverse direction.

I think one more key could be "standard" on all these widgets; escape. It
should move you out of the widget altogether. I'm thinking of the situation
which requires switching browser tabs while focused on a widget that wants to
use control+tab, or the case where you want to back out of a menu system as I
discussed in my last eMail. It turns out that control+pageUP and
control+pageDown are also standard windows keys for moving from UI tab to UI
tab, and they do indeed work in Firefox and IE. We could use these controls
instead, or use control+tab and leave these for browser tabs.

Thoughts?