The Australian Government coat of Arms

Communities of practice

Communities of practice

Accordion


#1

Please provide any feedback for the Accordion component

You can also view the component page on our documentation site for the Accordion component.


#4

Just querying why you apply role=“tab” to accordion trigger links. Tabs and accordions are both show/hide patterns, however screen readers will expect them to function differently. In this case you announce your accordion triggers as tabs, and I’m not sure why.
I suggest the accordion triggers are buttons. They are also headings for the content that follows them, yet this is not reflected in the markup.
I suggest that we should use W3C design patterns where possible to encourage universality, e.g. https://www.w3.org/TR/wai-aria-practices-1.1/#accordion


#5

Thank @abca11y. This is good feedback and something we should do. More examples here: https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html

I’m pretty sure the role="tab" was originally used because, as you say, it has both “both show/hide patterns” and is pretty similar in terms of functionality. (Thing A, hides and shows thing B) you can see this in the screen reader example. But yeah, I’d much prefer to use a more appropriate aria role if it exist.

I’m recommending this be added to the backlog, or if anyone wants to take a stab at it too, that would be appreciated :slight_smile:


#6

I agree with the suggestion to use role=“button”, and a suitable heading level for the triggering link.

The use of section tags require a heading as the first child, and depending on how rigorous you want to be with A11y (re the section element’s accessible name computation) they may also need aria-label (or aria-labelledby) attribs too.
Probably easier to simply not use section tags. Once they are out in the wild within a webCMS, it would be difficult to ensure the contents of accordion panels are suitable as sections anyway.

Besides the above, accordions / expanders raise other considerations:
Search engines may treat content within a closed accordion panel with a lower bias, lowering the discoverability of content. Plus would a user need to manually open them all before printing the page?


#7

Additional feedback on GitHub related to the current ARIA roles on the accordions.


#8

We’re using accordions in the new ABS website as a way to visually simplify pages with lots of content. Allowing users to drill down to heavier content if they desire. There have been a couple of users give us feedback they would like an option to expand all or hide all accordions. It isn’t a substantial number of users but enough to consider this option. I was wondering if an expand/ close all option was considered and/or tested as part of the production of these accordions? Would be good to know your insights.


#9

Hi Nathan thanks for sharing - we have actually built that functionality into the Accordion component.

I’ve made a demo that shows the open/close all functionality for the accordion.

I will get back to you with regards to our research/use cases behind this functionality. Anybody else have any thoughts on this?

Thanks,
Raj


#10

Just a heads up - on the HTML snippet on https://designsystem.gov.au/components/accordion/ there’s an incorrect attribute (‘className’):

<ul **className**="au-accordion-group" ...

Took me a while to fix it after pasting it into a prototype so might good to fix it :slight_smile:


#11

Thanks for the pick up James! I’m on it :smile:

edit: fixed now !


#12

Hi Nathan
I wasn’t involved in the design of this component but there would be many examples where you would not want an Open accordion to close on selection of another. Similarly, there may be use cases when an Open all / Close all is useful.

Before you jump into using Open all / Close all you need to assess whether an accordion is the best component to use. Is the content better broken down into multiple pages, or just plain content within headings? If most users are Opening all the content on a page then it probably should not be hidden within the accordion.
Jane


#13

Hi Jane, thanks for your input. We are confident and have confirmed with many rounds of user testing that in this specific page type instance, accordions are a superior solution to multi-pages. I also agree that having an open accordion close on selection of another accordion wouldn’t be a good experience. And not the solution I was seeking. The solution some of our users were asking for is more around offering the functionality to open or close all accordions in an accordion group. And its not most users, as I said its been a few users who have mentioned they would like this functionality.

I would be interested in any user testing findings around that functionality that others may have.


#14

I’ve always thought of Accordions as containing multiple zones that close any previously opened zone before opening the next. Like what the JqueryUI accordion widget basically does.

Perhaps this component is better referred to as an Expanders. But not a big deal.