The W3.org Accordion Design Pattern has issues that negatively effect accessibility for screen reader and keyboard only users.

This is in regard to the page and section at
http://www.w3.org/TR/wai-aria-practices/#accordion

Section:

3. If the panel is collapsed (its aria-expanded state is 'false' or missing), OR, when the last interactive element of a panel is reached, the next Tab key press moves focus as follows: 
list of 2 items nesting level 2
. If a subsequent accordion panel is already expanded, focus moves to the first focusable element in this subsequent panel. 
. If no subsequent accordion panel is expanded, focus moves to the first focusable element outside the accordion component. 
list end nesting level 2

This design pattern instruction is specifying that an Accordion control should only receive one tab stop, and that the arrow keys should be used to control the accordion nodes that are expandable.

This presents critical accessibility issues for keyboard only users, and for screen reader users regarding document flow and the page reading order.

The above concept is valid for Tab controls, but not for Accordion controls.

For example, the paradigm for a Tab control is as follows:

*List of Tab links*
*Shared insertion container*

This differs from an Accordion, which adheres to the following paradigm:

*Accordion one link*
*Accordion one container*
*Accordion two link*
*Accordion two container*
*Accordion three link*
*Accordion three container*

Since the Accordion may contain any type of data, including form controls as part of a Settings dialog for example, it is important to ensure that all accordion nodes are within the tab order, so that it is possible to easily tab from the content of one container into the control that offers the ability to expand or collapse the next Accordion node in the reading order.

Otherwise, a keyboard only user will have to shift+tab all the way back through the form simply to reach the Accordion node that is expanded, to then use the arrow keys to navigate to another Accordion node to expand, then tab through that list of form fields, only to have to go back up the list by shift+tabbing again to go through the same process, over and over.

It can be argued that the following section addresses this:

. Control+Up arrow - Moves focus from anywhere in the accordion content to its associated accordion header or tab respectively. 
. Control+PageUp - 
list of 3 items nesting level 1
. When focus is inside of an accordion pane, pressing Control+PageUp moves focus to the accordion header of the previous accordion pane. 
. When focus is in the first accordion header content, pressing Control+PageUp optionally moves focus to the last accordion header. 
. Focus will simply move to the header and will require Enter/Space to expand/collapse the accordion pane. 
list end nesting level 1
. Control+PageDown - 
list of 3 items nesting level 1
. When focus is inside of an accordion pane, pressing Control+PageDown moves focus to the header of the accordion pane. 
. When focus is in the last accordion header content, pressing Control+PageDown optionally moves focus to the first accordion header. 
. In the case of an accordion, focus simply moves to the header and requires Enter/Space to expand/collapse the accordion pane. 
list end nesting level 1

These keyboard commands don't take into account that screen readers intercept many of these keystrokes for navigation within the Virtual Buffer, and thus are not likely to work as a result. Additionally, such keystrokes are not likely to be understood or known by most keyboard only users.

Ensuring that all Accordion nodes are in the tab order will ensure that the Accordion is easily navigable by all user types.

Regarding the section:

WAI-ARIA Roles, States, and Properties: 
list of 8 items
. The accordion component must have a role of 
tablist
 and have 
aria-multiselectable
="true" This will enable an assistive technology, such as screen reader, to convey that the tablist is an accordion or a multiselectable tablist. This will also tell the user that the keyboard navigation matches an accordion and not a tablist. 
. Contained within the tablist is a set of tab/tabpanel pairs. 
. Each header tab in the tablist has a role of 
tab.
. The accordion panel uses the role 
tabpanel
 and should have an 
aria-labelledby
 relationship referencing the correponding header having a role of 
tab
. The tabpanel is considered a grouping for all content consisting of that tabpanel. 
. An accordion should manage the expanded/collapsed state of each tab by maintain its 
aria-expanded
 state.  
. An accordion should manage the selected state of each tab by maintaining its 
aria-selected
 state. 
. An accordion should convey the visibility of each tabpanel by maintaining its 
aria-hidden
 state. 
list end

These instructions are incorrect, and result in Accordion controls that are indistinguishable from Tab controls by screen reader users.

The paradigm of a Tab control is supposed to follow a specific user interaction model, which is correctly represented by the Widget instructions documented at
http://www.w3.org/TR/wai-aria/roles#tab
Which is, for a group of Tab links to be followed by a Tab Panel insertion point for all Tabs to reference.

*List of Tab links*
*Shared insertion container*

The Accordion is different, and is a series of Accordion nodes that include content insertion points that directly follow the triggering element for each Accordion node.

*Accordion one link*
*Accordion one container*
*Accordion two link*
*Accordion two container*
*Accordion three link*
*Accordion three container*

As a result, the reading order is broken for screen reader users when this Tab paradigm is applied to Accordions, because the content of the expanded Accordion separates the "Tab" controls that are announced by screen reader users, making it extremely difficult to understand how these Tabs are grouped in the reading order, and how they are related. This is further exacerbated when additional ARIA Widgets are embedded within these Accordion content panels, such as a real Tab control for example, which presents a Widget nesting issue since the second Tab control is included within the parent role=tablist container of the Accordion.

E.G

*Accordion one link*
*Accordion one container with embedded ARIA Tab control*
*Accordion two link*
*Accordion two container with embedded ARIA Tab control*

Since both the Accordion nodes and the embedded Tab controls are all identified as "Tab", it is impossible for screen reader users to identify which elements are proper Tabs and which are not, and what the proper nesting level is for these elements.

Instead, all Accordion nodes should be marked up as ARIA Toggles, which will prevent this issue from occurring. The attribute aria-expanded can still be used to identify which Accordion node is currently expanded.

E.G

<a role="button" aria-pressed="true" aria-expanded="true" ... >