The authoring guidance for Accordions includes conflicting information with related ARIA Tab constructs, including contradictory keyboard support for the same ARIA Tab constructs, as well as references to role and state attribute functionality that does not exist within the UAIG or ARIA authoring spec documentation.

Guidance for Accordions:
http://www.w3.org/TR/wai-aria-practices/#accordion

Issues with Accordion guidance:

The use of ARIA Tab markup for accordions conflicts with documented layout structure for actual ARIA Tabs, as documented at
http://www.w3.org/TR/wai-aria-practices/#tabpanel

From a screen reader perspective, both sound exactly the same regardless of markup differences, because both use ARIA Tab markup to convey functionality.

As a result, it is impossible for screen reader users to identify the differences between an Accordion where content is rendered inline with the triggering element, and a Tab group where content is rendered after or adjacent to a list of tab controls, because both are identified as "Tab".

This also presents reading order issues for screen reader users, where if a Tab is activated for an accordion and content is rendered inline, it pushes all other Tabs below that point in the DOM reading order, making it appear that orphaned Tab controls are located elsewhere on the page, causing further confusion if an expanded Accordion panel includes an actual Tab group that also includes ARIA Tab markup where its content is rendered after the Tablist according to spec.
http://www.w3.org/TR/wai-aria/roles#tabpanel

Regarding keyboard controls, both Accordions and Tabs specify one tab stop for the triggering element group for each.

This is confusing when content for Accordions is rendered inline with the triggering element, since content for Accordion panels may be of any length, and tabbing through this content visually would then skip the remainder of the Accordion triggering elements that appear visually after the rendered content; focus would instead have to be moved back up to the original location or the user would need to be aware of all of the requisite keyboard commands for jumping to the next Accordion triggering element while focus is still within the Accordion panel.

From a usability perspective for Accordions, it makes more sense to ensure that all Accordion triggering elements are in the regular tab order, which will then coincide with the reading order of the page to ensure cognitive accessibility.

Additionally, the following keyboard guidance is stated for both Accordions and Tabs, and are in many ways contradictory:

Accordion:
"When focus is on the accordion header, a press of up/left arrow keys moves focus to   the previous logical accordion header."

Tabs:
"Left Arrow - with focus on a tab, pressing the left arrow will move focus to the  previous tab in the tab list and activate that tab. Pressing the left  arrow when the focus is on the first tab in the tab list will move  focus and activate the last tab in the list."

Accordion:
"When focus is on the accordion header, a press of down/right moves focus   to the next logical accordion header. 
When focus reaches the last header, further down/right arrow key presses optionally   wrap to the first header"

Tabs:
"Right Arrow - with focus on a tab, pressing the right arrow will move focus to the  next tab in the tab list and activate that tab. Pressing the right  arrow when the focus is on the last tab in the tab list will move focus  to and activate the first tab in the list."

Accordion:
"Up arrow - behaves the same as left arrow 
Down arrow - behaves the same as right arrow"

Tabs:
"Up arrow - behaves the same as left arrow in order to support vertical tabs 
Down arrow - behaves the same as right arrow in order to support vertical tabs"

[All of the following key assignments are unreliable for screen reader users, which intercept these keystrokes]

Accordion:
"Control+Up arrow - Moves focus from anywhere in the accordion   content to its associated accordion header or tab respectively."

Tabs:
"Control+Up Arrow - with focus anywhere within the tab panel, pressing Control+Up Arrow will  move focus to the tab for that panel. This is not standard behavior -  is this something we want to implement? Is it necessary if we provide a  mechanism to change the active tab? Similar to Control+PageUp/Control+PageDown in  Firefox to switch tabs?"

Accordion:
"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."
"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."

Tabs:
"Control+PageUp - When focus is inside of a tab panel, pressing Control+PageUp moves focus  to the tab of the previous tab in the tab list and activates that tab.  When focus is in the first tab panel in the tab list, pressing Control+PageUp will move focus to the last tab in the tab list and  activate that tab. 
Control+PageDown When focus is inside of a tab panel, pressing Control+PageDown moves  focus to the tab of the next tab in the tab list and activates that  tab. When focus is in the last tab panel in the tab list, pressing Control+PageUpwill move focus to the first tab in the tab list and  activate that tab."

[Additional conflicts in the documentation]

Accordion:
"Enter/Space - When focus is on an accordion header, pressing Enter/Space toggles the expansion of the corresponding panel.
If collapsed, the panel is expanded, and its aria-expanded state is set to   'true'. 
If expanded, the panel is collapsed and its aria-expanded state is set to   'false'."

Tabs:
(Nothing specified)

Additionally, the following statement for Accordions is unclear, and is not supported in any user agent or Assistive Technology, nor is it documented in the spec as an acceptable behavior for any of these ARIA role and state attributes:

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

I would like to propose a simpler design format for Accordions, that I think would address all of these issues as well as deal with screen reader conflicts regarding textual equivalents. It would also be easier for developers to implement.

1. Use an explicit heading or role=heading to identify the Accordion header.
2. Within the Accordion heading container, include a link or button or role=link/role=button equivalent to convey the actionable element for screen reader users, all of which would be in the normal tab order.
3. Use aria-expanded to convey the expanded state of the associated Accordion upon the link or button, and associate the link or button with the Accordion container using aria-controls. (Buttons may optionally be represented as Toggles using aria-pressed)
4. Include role=region on the dynamically generated Accordion panel content, which is rendered inline with the triggering element, to identify its boundaries for screen reader users, and include aria-labelledby to point back to its relevant Accordion heading. This conveys contextual boundaries for screen reader users regardless of the amount or type of content included within an Accordion panel, and provides a mechanism for skipping past it.

Live demos:

Accordion using ARIA Toggles:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/ARIA%20Accordion%20(Internal%20Content)/demo.htm

Accordion using Links:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/ARIA%20Accordion%20(Internal%20Content)/demo2.htm