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
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.