RE: Updated: Live Code for APG: ARIA Accordion design pattern ready for review

Basically, for a tab, the tablist container is separate from the tabpanel container and all role=tab elements are grouped together, which is why single arrow focus navigation is helpful for tabbing into and out of this widget construct. This paradigm is true for both vertical and horizontal tabs, where these two panels are either one above the other or side by side. In both cases they are separate containers however.



In contrast, an accordion construct is when the dynamically displayed panels are rendered inline with the triggering element, requiring them to be inserted within the DOM between one accordion toggle and another accordion toggle, which breaks the ARIA Tab paradigm, because it is impossible to program single focus navigation for the tablist without also introducing significant reading order issues for non-sighted screen reader users and navigation issues for keyboard only users.



As a result, it is necessary to ensure that all accordion toggles are in the tab order, even if arrow key navigation is included, which also breaks the ARIA Tab paradigm because it guarantees that two widgets that behave differently will be mapped to the same control type in the accessibility tree and be impossible for non-sighted screen reader users to differentiate.



So it is much simpler to provide a consistent and reliable accordion model that supports all of these things while also allowing for enhancing in the future as needed, which is the logic behind the button toggles and other role usage.



So I disagree that an accordion that opens one branch at a time is the same as a Tab, because of these fundamental differences.



I think it would be very confusing to have a totally new widget with different roles for one accordion that opens one branch versus another accordion that opens multiple branches, because there is literally no difference between them other than this behavior, which is very common with accordions.



To be Clear, an accordion is typically grouped with other related toggles that when toggled, causes the other accordion branches to act in a certain way such as closing automatically.



E.G Definition

https://en.wikipedia.org/wiki/Accordion_(GUI)#User_definition#Developer_definition

"Several buttons or labels are stacked upon one another. At most one of them can be "active". When a button is active the space below the button is used to display a paned window<https://en.wikipedia.org/wiki/Paned_window>. The pane is usually constrained by the width of labels. When opened it shifts labels under the clicked label down according to the height of that window. Only one button or pane combination can be active at any one time; when a button is selected any other active panes cease to be active and are hidden."



A basic show/hide widget is similar, but is totally independent and is not explicitly bound to any other toggles on the same page, which would define a standalone toggle control. This is not the same thing as an accordion.



Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

bryan.garaventa@ssbbartgroup.com

415.624.2709 (o)

www.SSBBartGroup.com





-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Thursday, July 21, 2016 10:58 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: public-aria@w3.org; 'Matt King' <a11ythinker@gmail.com>
Subject: RE: Updated: Live Code for APG: ARIA Accordion design pattern ready for review



What confuses me here is that the demo example acts exactly like a tab widget.

When you expand a section the other sections automatically collapse.

Isn't accordion a pattern where you should be able to expand more than one section, or at least where you can expand and collapse a section independently of any other section?

With the 1.0 accordion pattern, using tab with multi-select you can expand/collapse any tab without it automatically affecting the other tabs. It's just the markup for it that is confusing and overly complex.



I can see that there may be patterns that land somewhere between a pure tab implementation and what I call an accordion (where you can expand and collapse any accordion panel without it affecting other panels in the set).

Should we invent a third widget to explain those, or just leave that up to the author?

The most common pattern I come across in my audits for accordion are expandable sections that are independent of each other, so I want to make sure we offer an example of those, whatever we call it.

Again, as you said, just tweaking your variables creates that, and the demo is awesomely coded as always. But I am just a bit confused what we are trying to achieve conceptually and want to make sure we are all on the same page with regards to expectations and documentation.



For plain tabs I think the current implementation using tablist/tab with aria-select actually works quite well.





-----Original Message-----

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]

Sent: Thursday, July 21, 2016 11:29 AM

To: Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>

Cc: public-aria@w3.org<mailto:public-aria@w3.org>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>

Subject: RE: Updated: Live Code for APG: ARIA Accordion design pattern ready for review



The variables can be tweaked in the APG once added however people want this to show up when displayed on the landing page, however it is a common accordion paradigm to have one branch open and remain unclosable until another is opened.



I think it may be overkill to disable an accordion trigger in addition to having it be expanded, because it's not a disabled widget, just a locked one in it's current state.



Also, this really doesn't make it more accessible by requiring another attribute be present sometimes but not others.



Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>

415.624.2709 (o)

www.SSBBartGroup.com<http://www.SSBBartGroup.com>



-----Original Message-----

From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]

Sent: Thursday, July 21, 2016 7:03 AM

To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>

Cc: public-aria@w3.org<mailto:public-aria@w3.org>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>

Subject: Re: Updated: Live Code for APG: ARIA Accordion design pattern ready for review



Bryan



I am still a little confused.

Why are all the accordion buttons expand only in the demo?



I think the most common use case for accordions are sections that can be expanded and collapsed at will.

We can easily tweak it using the variables in your Javascript file, but I am just curious why you chose this implementation.

I would vote to have the first section expanded by default, but clicking the button will collapse it, then expand it.

The second example should be collapsed by default but the button can be activated to expand and collapse it.

The third example could be a expand only demo.

That being said, if it is expand only, I think we should use a visual indication and aria-disabled="true" on the button in its expanded state to show all users that -- once expanded -- the section cannot be collapsed again.

Cheers

-Birkir



On 7/18/16, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

> Hi Matt and others,

> I've made the coding changes, so the below urls can be used for

> accessing the live code plus download for integration into the APG.

>

> View the setup.js file to see how the following variables change the

> accordion functionality like so:

>

>             // Allow for each toggle to both open and close individually

>             var allowToggle = false,

>

>             // Allow for multiple accordion sections to be expanded at the same time

>             allowMultiple = false;

>

> Simply change false to true as desired and you will get the

> functionality that you wish.

>

> To reiterate the value of the new model, the reason why this is

> important for an accordion like this is scalability. It should not be

> necessary to completely revamp all role usage and keyboard

> functionality simply because one setting is changed from true to false

> to enable single accordion panel opening versus multiple. Also there

> is no reason having to do with accessibility that would require this.

>

> The code is ready for modification, and the areas that can be deleted

> and new content added as you wish are clearly documented in the demo.htm file.

>

> Live page:

> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm


>

> Download:

> http://whatsock.com/test/w3c/ARIA%20Accordions.zip


>

> All the best,

> Bryan

>

>

>

>

> Bryan Garaventa

> Accessibility Fellow

> SSB BART Group, Inc.

> bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>

> 415.624.2709 (o)

> www.SSBBartGroup.com<http://www.SSBBartGroup.com>

>

> -----Original Message-----

> From: Bryan Garaventa

> Sent: Sunday, July 17, 2016 11:57 PM

> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; ARIA Working

> Group <public-aria@w3.org<mailto:public-aria@w3.org>>

> Subject: RE: Live Code for APG: ARIA Accordion design pattern ready

> for review

>

> Okay, files moved, please try this again...

>

> Live page:

> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm


>

> Download:

> http://whatsock.com/test/w3c/ARIA%20Accordions.zip


>

> Bryan Garaventa

> Accessibility Fellow

> SSB BART Group, Inc.

> bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>

> 415.624.2709 (o)

> www.SSBBartGroup.com<http://www.SSBBartGroup.com>

>

> -----Original Message-----

> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]

> Sent: Sunday, July 17, 2016 6:28 PM

> To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>

> Subject: Live Code for APG: ARIA Accordion design pattern ready for

> review

>

> Hi,

> The code for the accordion wireframe is ready, which can be tested at

> http://snoringfoot.dyndns.org/Webserver/ARIA%20Accordions/demo.htm


>

> At present this is just the coded implementation since my primary

> objective was to simply build out what works first, then document it

> after we finish any tweaks. For this reason, I'm hosting this temporarily on a test server.

>

> Also, you can download this zip file at http://snoringfoot.dyndns.org/


>

> Included within this is a vanilla JavaScript helpers lib I've cobbled

> together over some years now, which should aid in the process for

> building out these widgets in the future. This is included within the

> file "helpers.js'.

>

> The design pattern uses the new model for Accordions, which is the use

> of individually focusable toggles in combination with aria-expanded to

> convey the active state of each toggle.

>

> The setup for this type of implementation is automatically scalable,

> meaning that it can include any type of embedded control type within

> the dynamically expandable sections, including other complex ARIA

> widget controls, or even embedded accordion controls to nest

> functionality. This is why the named regions are important for intuitive grouping.

>

> This too works on mobile touch screen devices, and within setup.js,

> redundant event handling shows how the same script can be applied to

> non-native triggering elements such as Div or Span elements in place

> of native links or buttons for use as accordion toggles.

>

> Within this demo, the styling and content are just what I've thrown

> together, but all can be changed however you like. It probably needs

> some positioning work for the accordion section content for instance.

> The triggering elements are presently A tags, but these can be changed

> to native buttons, or even simulated elements like Div or Span with

> tabindex='0' and role='button', and the scripting will still work accessibly.

>

> Also, please feel free to use the helpers.js file for whatever you

> wish as well, it may make this process go faster.

>

> All the best,

> Bryan

>

>

>

>

> Bryan Garaventa

> Accessibility Fellow

> SSB BART Group, Inc.

> bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>

> 415.624.2709 (o)

> www.SSBBartGroup.com<http://www.SSBBartGroup.com>

>

>

>

>





--

Birkir Gunnarsson, CPACC

Senior Accessibility Subject Matter Expert | Deque Systems

2121 Cooperative Way, Suite 210

Herndon, VA, 20171



Ph: (919) 607-27 53

Twitter: @birkir_gun