WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accordion semantics?

for

From: Jonathan Avila
Date: Jun 19, 2014 7:59AM

[Detlev wrote] I think in cases where activating one of the tabs
automatically closes the other tabs as in this Hillen example.. ..the
semantics are quite close to the horizontal tab panels so the tablist /
tab roles seem appropriate. But maybe I am missing something here.

The issues still occur when only one accordion is open. For example, the
behavior related to tab must be dynamic and where focus will land is
likely to be different based on what panel is open and whether is prior to
or after where the current focus is -- this will be confusing for screen
reader users. This occurs because Accordion is presented inline. With a
standard horizontal tab you will always land in the content of one of the
tab panels.

For example, if accordion 3 was opened and I pressed tab from accordion
1's header I would expect focus to move to the first control inside
accordion 3 -- the screen reader user however might not know that
accordion 3 is opened and know that this content is part of an accordion
panel. Perhaps this is something that needs to be solved by screen reader
users but it is a current challenge.

In another case if focus was on accordion 2's header but accordion 1 was
expanded then tab would take you past the accordion content completely.
This is different from how page tabs work.

When multiple accordions are open then it becomes even more confusing as
you can tab from one panels content to another. So I agree with Bryan and
James that the user really needs the ability to access the accordion
headers in line with the content and this likely means putting them in the
focus order with expanded states but still support the keyboard control
pattern with arrow keys, etc.

Jonathan