- From: Mandana Eibegger <m.eibegger@schoener.at>
- Date: Wed, 20 Jan 2010 15:54:40 +0100
- To: public-pfwg-comments@w3.org
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