E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Jesse Hausler
Date: Wed, Jun 18 2014 6:32PM
Subject: Accordion semantics?
No previous message | Next message →

Thoughts on the best semantic for an accordion component?

I'm good with the keyboard and ARIA recommendations in the ARIA Authoring
guide:
http://www.w3.org/TR/wai-aria-practices/#accordion

I'm just don't care for the semantics in their only example:
http://www.oaa-accessibility.org/examplep/accordian1/

Paired headings and divs as the way to go?

Thanks,
Jesse

From: Bryan Garaventa
Date: Wed, Jun 18 2014 8:29PM
Subject: Re: Accordion semantics?
← Previous message | Next message →

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?

E.G

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

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

From: Bryan Garaventa
Date: Wed, Jun 18 2014 8:37PM
Subject: Re: Accordion semantics?
← Previous message | Next message →

As a side note, if anybody knows the trick to make Outlook2013 stop breaking
up links, please let me know.

From: Sean Curtis
Date: Wed, Jun 18 2014 9:14PM
Subject: Re: Accordion semantics?
← Previous message | Next message →

Bryan, try adding [ and ] or < and > around them.


On Thu, Jun 19, 2014 at 12:37 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> As a side note, if anybody knows the trick to make Outlook2013 stop
> breaking
> up links, please let me know.
>
>

From: James Nurthen
Date: Wed, Jun 18 2014 9:28PM
Subject: Re: Accordion semantics?
← Previous message | Next message →

I agree with Bryan.
I also find the keyboard navigation very confusing for a keyboard-only user.

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.

Regards,
James

Regards,
James


On Wed, Jun 18, 2014 at 7:29 PM, Bryan Garaventa <
= EMAIL ADDRESS 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?
>
> E.G
>
> ARIA Toggles:
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
> IA%20Accordion%20(Internal%20Content)/demo.htm
>
> Expandable ARIA Links:
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
> IA%20Accordion%20(Internal%20Content)/demo2.htm
>
>

From: Detlev Fischer
Date: Thu, Jun 19 2014 1:36AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

I think in cases where activating one of the tabs automatically closes the other tabs as in this Hillen example

http://hanshillen.github.io/jqtest/#goto_accordion

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

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

http://www.testkreis.de
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 user.
>
> 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.
>
> Regards,
> James
>
> Regards,
> James
>
>
> On Wed, Jun 18, 2014 at 7:29 PM, Bryan Garaventa <
> = EMAIL ADDRESS 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?
>>
>> E.G
>>
>> ARIA Toggles:
>>
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
>> IA%20Accordion%20(Internal%20Content)/demo.htm
>>
>> Expandable ARIA Links:
>>
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
>> IA%20Accordion%20(Internal%20Content)/demo2.htm
>>
>>

From: Birkir R. Gunnarsson
Date: Thu, Jun 19 2014 1:54AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

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
container.
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.
Cheers
-B


On 6/19/14, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> I think in cases where activating one of the tabs automatically closes the
> other tabs as in this Hillen example
>
> http://hanshillen.github.io/jqtest/#goto_accordion
>
> ..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
> appropriate.
>
> 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
>
> http://www.testkreis.de
> 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
>> user.
>>
>> 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.
>>
>> Regards,
>> James
>>
>> Regards,
>> James
>>
>>
>> On Wed, Jun 18, 2014 at 7:29 PM, Bryan Garaventa <
>> = EMAIL ADDRESS 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?
>>>
>>> E.G
>>>
>>> ARIA Toggles:
>>>
>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
>>> IA%20Accordion%20(Internal%20Content)/demo.htm
>>>
>>> Expandable ARIA Links:
>>>
>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/AR
>>> IA%20Accordion%20(Internal%20Content)/demo2.htm
>>>
>>>

From: Jonathan Avila
Date: Thu, Jun 19 2014 7:59AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

[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

From: Don Mauck
Date: Thu, Jun 19 2014 8:34AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

Boy wouldn't that be nice!

From: Bryan Garaventa
Date: Thu, Jun 19 2014 8:50AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

Thanks :) Please let me know the bug number when filed, and I'll be happy to second it.

From: Bryan Garaventa
Date: Thu, Jun 19 2014 8:56AM
Subject: Re: Accordion semantics?
← Previous message | Next message →

Unfortunately [] and <> don't do the trick in this case.
Looks like it's the line length number for plain text messages that is the problem, which is adjustable in File > Options > Email >
Line Length for Plain Text.

From: Detlev Fischer
Date: Thu, Jun 19 2014 10:19AM
Subject: Re: Accordion semantics?
← Previous message | No next message

On 19 Jun 2014, at 15:59, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:

> With a
> standard horizontal tab you will always land in the content of one of the
> tab panels.

Hi Jon,
If I am not mistaken, whether tabbing lands you in a tab panel or expanded accordion tab will depend on whether there are any focusable elements in it (native or made focusable via tab index).
Users not getting or understanding the initial announcement of the tab panel role and arrow navigation behaviour may in both cases have trouble noticing and accessing hidden content - which is why we see so many hybrid versions of tabbed content on web pages supporting both tabbing and arrowing.

There is one difference though: the default state of accordions is usually that content is hidden while horizontal tab panels show the first tab by default. Having said all that, I am quite in favour of not using tab list for accordions. I just would't go so far as calling such an implementation wrong.

--
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Tel +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites