E-mail List Archives
Re: Accordion semantics?
From: Jonathan Avila
Date: Jun 19, 2014 7:59AM
- Next message: Don Mauck: "Re: Accordion semantics?"
- Previous message: Birkir R. Gunnarsson: "Re: Accordion semantics?"
- Next message in Thread: Don Mauck: "Re: Accordion semantics?"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Accordion semantics?"
- View all messages in this Thread
[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
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.
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Detlev Fischer
Sent: Thursday, June 19, 2014 3:37 AM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Accordion semantics?
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
The OpenAjax Alliance example is different in that expanded tabs stay
open. For this type of accordion, using expandable regios is certainly
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)1577 170 73 84
Tel +49 (0)40 439 10 68-3
Fax +49 (0)40 439 10 68-5
Beratung, Tests und Schulungen fÃ¼r barrierefreie Websites
James Nurthen schrieb am 19.06.2014 05:28:
> I agree with Bryan.
> I also find the keyboard navigation very confusing for a keyboard-only
> I've started telling people to code accordions as a bunch of
> expandable regions.
> I'm going to raise an issue against the ARIA 1.1 Authoring Practices
> to provide an alternate pattern like this for accordions.
> On Wed, Jun 18, 2014 at 7:29 PM, Bryan Garaventa <
> <EMAIL REMOVED> > wrote:
>> Personally I've never been fond of using ARIA Tab constructs for
>> accordions, because it's impossible to tell the difference between a
>> tab group and an inline accordion, because the feedback is the same
>> for screen reader users.
>> E.G if you have a tab group nested in an accordion, how do you know
>> which is which for instance, which may be important because
>> accordions render content inline whereas tabs render content after a
>> tablist group.
>> Is there something wrong with just keeping it simple?
>> ARIA Toggles:
>> ions/AR IA%20Accordion%20(Internal%20Content)/demo.htm
>> Expandable ARIA Links:
>> ions/AR IA%20Accordion%20(Internal%20Content)/demo2.htm
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Jesse
>> Sent: Wednesday, June 18, 2014 5:32 PM
>> To: WebAIM Discussion List
>> Subject: [WebAIM] Accordion semantics?
>> Thoughts on the best semantic for an accordion component?
>> I'm good with the keyboard and ARIA recommendations in the ARIA
>> I'm just don't care for the semantics in their only example:
>> Paired headings and divs as the way to go?
>> >> >> list messages to <EMAIL REMOVED>
>> <mailto: <EMAIL REMOVED> >
>> >> >> list messages to <EMAIL REMOVED>
> > > list messages to <EMAIL REMOVED>
messages to <EMAIL REMOVED>