Comment on 'Design Patterns -> Accordion'

Hello,

i have some comments/questions concerning the Accordion/Tab Panel 
definition.

Related documents:
[ 1 ] : http://www.w3.org/TR/wai-aria-practices/#accordion
[ 2 ] : http://www.w3.org/TR/wai-aria-practices/#tabpanel
[ 3 ] : http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#tab
[ 4 ] : http://test.cita.uiuc.edu/aria/tabpanel/tabpanel2.php (example 
for accordion)
[ 5 ] : http://codetalks.org/source/widgets/tabpanel/tabpanel1.html
[ 6 ] : http://www.w3.org/TR/2009/WD-wai-aria-20091215/usage#managingfocus


* I can imagine an accordion, where the header consists of more than 
just the area to the click to activate a tab panel.
E.g.:
  Some Article 1           Summary 1
  Some Article 2           Summary 2
  ...
  Some Article n           Summary n

  : where "Some Article X" links to the article, and "Summary X" would 
activate the Tab Panel with a summary of the article.

This scenario seams to be supported:
[1] "Keyboard Interaction: ...
If interactive glyphs or menus are present in the accordion header, 
focus moves to each in order."
Furthermore:
[1] "WAI-ARIA Roles, States, and Properties: ...
Each header tab in the tablist has a role of tab."
But:
[2] "Description: ...
tab: the label/title area of the tab panel. This is where you click to 
activate a tab panel "

-> So i guess in the example above, "Summary X" should have the role of 
"tab"?
But what about the tab order then? How should the other links be 
reachable with the keyboard?
And maybe there would be a need of role="tabheader" ?


*
[3] "... authors SHOULD ensure that the currently active tab has its 
aria-selected attribute ..."
But this is neither mentioned in [1] nor [2] and is missing in the 
associated examples [4] and [5].

* There is an error in [4] in the accordion example:
it says "aria-multiselect='true'" an should be "aria-multiselectable='true'"

* The defined keyboard-interactions of accordions and tabs are not the 
same (e.g. for tabs "HOME" and "END" is missing)

* Active Tabs in Accordions:
[6] "... When a previously focused container is refocused, the new 
active descendant should be the same element as the active descendant 
when the container was last focused ..."
While this makes sense for Tab Panels, it seams conflicting for Accordions:
If you look at [4] and e.g. have the 1st option closed an the 2nd option 
open and activate "Carnivore Options" and then tab from the beginning of 
the document, you will reach the checkbox of the 2nd option before you 
reach the accordion-headers.
I find this somehow confusing (from a navigational aspect) and:
[3] "... If a tabpanel or item in a tabpanel has focus, the associated 
tab is the currently active tab in the tablist ..."
  - So either the 2nd option should be active, or it should be activated 
as soon as the user focuses the checkbox (which is useless and 
problematic, because then the user would have skipped the active tab 
without noticing)
  - This functionality is missing in [4].
  - The definition of the tab-keyboard-interaction in [1] should specify 
more clearly, which element gets the focus when tabbing to the widget.


* [6] "... When something in the container has focus, the user may 
navigate through the container by pressing additional keys such as the 
arrow keys to move relative to the current item. Any additional press of 
the main navigation key (generally the Tab key) will move out of the 
container to the next widget. ..."
This is not true for containers having tabpanels, as the content could 
have links etc that can be reached by tabbing. You can see this in [4] 
and [5].
Maybe there is need to differentiate between "navigation"-containers 
(e.g. tab) an content-containers (e.g. tabpanel).
But then again: how should keyboard-navigation work in the example of my 
first comment.


With best regards,
Mandana Eibegger

Received on Friday, 22 January 2010 15:42:32 UTC