An accordion is a series of expandable vertical panels, designed to save space on a page by hiding content and revealing it as required.
Accordions can work well for people who use a service regularly, or who need to perform familiar tasks quickly.
Only use an accordion if there’s evidence it’s helpful for users to:
The details based accordion is the default and recommended implementation.
Test your content without an accordion first. Consider if it’s better to:
Do not:
The optional collapse all/expand all functionality allows users to perform the action to all accordions, reducing time and clicks to reach the required information. It can be removed or added as required.
This function should not be used to help users locate information within accordions. If a user is expanding multiple accordions because they are unsure of the content they contain, consider more descriptive titles or removing accordions all together and displaying the content separated by headings.
By default, all panes in an accordion are closed.
open attribute to any <details> element that should start open. The progressive enhancement layer leaves the native open state intact, adds role="region"/aria-labelledby to the panel, and wires the optional toolbar when present..nsw-accordion__open class on the .nsw-accordion__title element. Without JavaScript, all panel content remains visible. When JavaScript runs, it hides panels and reopens only those marked with .nsw-accordion__open, then keeps aria-expanded/aria-hidden in sync.Use clear labels
Accordions hide content, so the labels need to be clear. Ensure the headings used are brief and explicit about what is contained in the hidden panel. Intuitive headings help the user build a clear mental model of the content.
Do not disable sections
Accordions can be set open or closed. They can be configured to only allow 1 panel to be open at a time. Do not use with only 1 panel allowed to be open at once, if people need to compare items in different panels.
Disabling controls is normally confusing for users. If there is no content for a section, either remove the section or, if this would be confusing for your users, explain why there is no content when the section is opened.
Consider tabs if the user would likely need to flick between content sections.
The details based accordion (.nsw-accordion--details) is the default and recommended implementation. It uses native <details> and <summary> elements for the disclosure pattern, which provides built in semantics, keyboard support and state announcement for assistive technologies. This version delivers the core expand and collapse interaction without requiring JavaScript and is progressively enhanced when JavaScript is available.
<summary> behaviour and markers. While the Design System normalises the visual presentation, very heavy or unusual customisation of the header or marker is not supported.<summary> receives focus, we apply focus styles at the header or container level. Implementers should avoid additional overflow or clipping on parent containers that would cut off the focus ring..nsw-accordion--details on the accordion container to render the details based variant.<details> for each item and <summary> for the clickable header, following the markup in the examples..nsw-accordion__toggle with "Expand all" and "Collapse all" buttons. When JavaScript is available, these controls are wired up automatically.<details> and <summary>. In those cases, consider the legacy JavaScript accordion.The legacy JavaScript accordion (.js-accordion) is the original implementation and remains fully supported for backward compatibility and when advanced programmatic control or legacy behaviour is required.
aria-expanded and aria-hidden attributes and adding roles for assistive technology..nsw-accordion__open, then keeps aria-expanded/aria-hidden in sync as users interact.All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly. The details based accordion is the default implementation and meets these standards when implemented as intended, and the legacy JavaScript variant can also meet these standards when used correctly, but relies on additional scripting.
Uses native <details>/<summary> for built-in semantics, keyboard support and state announcement. Works without JavaScript; the progressive enhancement layer adds panel region/label ARIA and wires the optional "Expand all / Collapse all" controls without altering the native open state.
Without JavaScript, the details based accordion remains keyboard accessible through the native <summary> element.
Retained for advanced scripting needs. It manages state via JavaScript, handling aria-expanded/aria-hidden and roles. Without JavaScript, panel content remains visible; when JavaScript initialises it hides panels and reopens those flagged with .nsw-accordion__open, then keeps attributes in sync as users interact. This extra scripting can add load overhead compared to the details based approach.
Build content into the sprint from day one. Treat words as part of the product, not an afterthought. Add content tasks to the backlog and review them in stand ups alongside design and development.
Collaborate with product owners to define a clear Definition of Done for content. Encourage early reviews of copy within design critiques so language decisions move at the same pace as the interface.
Start by naming the single outcome the user needs to achieve. Remove anything that doesn’t help them get there.
Structure the page like a conversation: set expectations up front, group related steps, and explain why you’re asking for information.
Make it easy for SMEs to help. Share a short agenda and a live doc. Ask them to walk a realistic scenario instead of describing the system.
Capture source links and who approved wording so changes are auditable. Follow up with a redline or prototype to make feedback fast.
Bring content into every stage of the sprint, not just the end. Treat it like any other design asset: plan it, review it, and test it early.
When copy and interface evolve together, teams avoid last‑minute rewrites and mismatched intent.
Help users reach their goal quickly. Use strong verbs and avoid multi‑step sentences that hide the action.
Sometimes a simple label swap or reordered field makes the biggest difference.
Ask SMEs to explain how people actually use a service, not just how it works on paper. Listen for pain points or unclear language that can inform your content choices.
Keep notes visible to everyone so edits don’t get lost. A few short comments are better than one long document review.
Follow up with a quick playback—what you heard, what will change, and what stays the same.
Buying or building your first home? You may be eligible for a $10,000 grant under the First Home Owner's Grant (FHOG) scheme.
This grant scheme only applies to buying or building a new home.
You can make a claim if:
If you are building a new home, you could also be able to apply for the Australian Government grant of $25,000. To be eligible you must:
HomeBuilder complements the NSW Government’s existing First Home Owner Grant and stamp duty concessions.
The NSW Government recently announced increased thresholds for purchases of new homes and vacant land to build a new home from 1 August 2020. The threshold for existing home purchases remains unchanged.
In your team there may already be a sprint cadence that includes content design. Become familiar with agile practices such as the Kanban wall, daily stand ups and sprint planning. Understand the user journey and their needs. Get involved in usability testing sessions and iteration.
Otherwise, the content workflow may be separate from the product team. At the very least, make sure the team has real content to use, when they’re building a prototype. Also ensure your team uses real content when it does usability testing. Attend playbacks from this testing, to know how your content needs to change.
As well as designing the user experience with product team members, a content designer works to know the facts with subject matter experts.
Your aim from the outset is to simplify everything for the user. Your main task will be to set up a clear path for them to achieve their goal.
Start with a user story. You should create one for each piece of content, from user research. If you’re part of a multidisciplinary product team, everyone is likely to be using them as you design and build.
A user story will help you to pinpoint the user need from the outset. It puts the user front-of-mind and gives you a focus when designing and writing the content.
Next, create a structure for your page, based on the user story. Write up meaningful H2 headers to serve as signposts to help the user do what they need to do.
Share your way of working with your subject matter experts – in person if possible.
They're a great way of introducing your approach to a subject matter expert, which may be completely foreign to them. It will show them how you're focusing on the user, and what you're trying to solve. Ask them for feedback. Find out if there’s anything missing and if you’re on the right track.