E-mail List Archives
Re: Accordion semantics?
From: Birkir R. Gunnarsson
Date: Jun 19, 2014 1:54AM
- Next message: Jonathan Avila: "Re: Accordion semantics?"
- Previous message: Detlev Fischer: "Re: Accordion semantics?"
- Next message in Thread: Jonathan Avila: "Re: Accordion semantics?"
- Previous message in Thread: Detlev Fischer: "Re: Accordion semantics?"
- View all messages in this Thread
A lot of tabbed interface design falls partway between pure tabs and
accordions, "tabordions" if you will.
I have seen various versions of the following design:
A page has multiple tabs (not in a tablist), each tab controls its own
inline container div (in other words The content divs come, in content
order, between the tabs.)
When you activate a tab its content is displayed in the associated div
Only one container can be active at any one time.
Arrow key navigation between the tabs is enabled.
This is not a proper pure tab implementation, and one could argue that
it presents a reading order (WCAG 1.3.2) issue, because screen reader
users in particular are not aware of all the tabs, because the content
of the active tab will always separate it from the other tabs (unless
the last tab's content is activated).
So if anyone has ideas on whether this type of design presents
accessibility violations I would be interested to hear about it.
On 6/19/14, Detlev Fischer < <EMAIL REMOVED> > 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 OpenAjax Alliance example is different in that expanded tabs stay open.
> For this type of accordion, using expandable regios is certainly more
> Best, Detlev
> Detlev Fischer
> 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
>> 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
>>> because it's impossible to tell the difference between a tab group and
>>> inline accordion, because the feedback is the same for screen reader
>>> E.G if you have a tab group nested in an accordion, how do you know
>>> which for instance, which may be important because accordions render
>>> inline whereas tabs render content after a tablist group.
>>> Is there something wrong with just keeping it simple?
>>> ARIA Toggles:
>>> Expandable ARIA Links:
>>> -----Original Message-----
>>> From: <EMAIL REMOVED>
>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Jesse Hausler
>>> 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?
>>> >>> >>> messages to <EMAIL REMOVED>
>>> <mailto: <EMAIL REMOVED> >
>>> >>> >>> >>>
>> >> >> >>
> > > >
Work hard. Have fun. Make history.