The Australian Government coat of Arms

Communities of practice

Communities of practice


Please provide any feedback for the Accordion component

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

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.


Thank @abca11y. This is good feedback and something we should do. More examples here:

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:


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?


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

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.

1 Like

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?



Just a heads up - on the HTML snippet on 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:


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

edit: fixed now !

1 Like

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.


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.

1 Like

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.

1 Like

Hello everyone, I’m new to Design System - just installed it locally on my machine via node.js.

Quick question: accordion opening/closing is very slow when I run it thought my localhost. However, it works fine when put on the remote server via HTTP. What do I need to adjust to make it work as it supposed to?

Hi @Lesz! Welcome to the community :tada:

That issue sounds very odd :confused:. We haven’t noticed performance issues when running the component library locally, the build time when running npm run bootstrap can be quite long but other than that…

What web browser and version of Node.js are you using? It sounds the computer is struggling to run the browser-sync web server locally.

Hi @adamzerella I’m running node v10.15.3 and npm 6.4.1 on my iMac 3.5 GHz with 32GB RAM. I don’t think this is computer issue. I’m testing this in latest Firefox… but just discovered that the same URL in Chrome works fine… Any ideas what may cause such behavior on Firefox?

@adamzerella - All good - it was kinda false alarm as turned our it was a browser issue. Thank you for your quick reply :wink:

@Lesz :slight_smile: You’ve raised an interesting point though, I’m able to replicate this in the Firefox 66.0b1 and Chrome 72.0.3626.121 performance profilers. Looks like an issue with the latest browsers render cycle.

Safari 12.0.3 seems ok, we’ll keep an eye on this and try to see if other people are experiencing it.

I notice you’ve tagged the heading in each accordion section as a button rather than h2/h3/h4 etc.

The role of the heading in this case is to toggle the content of the section, making ‘button’ appropriate from that perspective. However, my feeling is that a sectioning element such as ‘section’ should have a heading, especially for accessibility.

Was there any discussion about the most appropriate tag for the accordion headings? What do others think?

Hi @AdrianNH,

Welcome to the forums!

There is an open ticket with regards to this exact issue you are bringing up. I agree, the title should be wrapped in a heading as per the guidelines for the <section> element.


What is the best way (if it is advisable) to trigger a group of accordion elements to expand or collapse at the same time, since the component by default will open and close based on user input on the specific component. I assume that other methods should be used to prevent there being too many accordions on a single page at any given time, but if there are no clear alternatives then a expand all/collapse all trigger might be helpful for the user.