A visual improvement would be to indent the content, so visually it aligns to the heading.

An indent of 27px or 1.5rem on the content would achieve this.

Currently

Suggested

UR findings on accordions -
tested as part of eQ business survey usability testing Oct 21

• users expected to be able to add their information into the survey introduction page - they expected that by clicking on the show all / show buttons this would reveal a list of questions with a box to input an answer
• users realised on trying to do this that only information was held here, quickly realising they had to use the start survey button
• users using a mixture of show all and show buttons - actions of doing so matched their expectations
• where accordians hold information, users may be less likely to look at these as they become more familiar with the product - this may need consideration if important information is added here that needs to be communicated to users

Accordion Aria Labels For Button Text

"allButton": {
            "open": "Show all",
            "close": "Hide all"
        },

Currently, if we have more than one accordion component on the page with the same button text for opening and closing the accordion component, there will be accessibility issues:

If we have more than one accordion component, both with a show all/ hide all button text (leaving the button texts as it is), especially when we want to be consistent around the accordion allButton property config, where we want the same open and close button text across the page for multiple accordion components, we run into some accessibility issues such as:

• Screen reader ambiguity: Screen reader users often navigate by button list or tabbing between interactive elements.
  • Users might activate the wrong one or waste time guessing.
• Blind or low-vision users lose context.
• Show all/ hide all buttons will be in place when there are multiple accordion components displayed on the same page. They sound identical, so the user has no idea which controls what, and they will have no context.
  • E.g. We can have one accordion component containing glossary terms and another one containing something else unrelated to glossary terms. There can be more than one or two accordions on the same page. All are using the same button text, and this is when accessibility issues arise, such as Screen reader ambiguity.
  • Having the ability to set aria labels for each accordion component will benefit massively in these scenarios and address the accessibility issues mentioned here.

Thanks for raising this. The Accordion component already includes an attributes parameter, which can be used to pass in additional HTML attributes for the button.

For example:

"allButton": {
  "open": "Show all",
  "close": "Hide all",
  "attributes": {
    "aria-label": "Show or hide all glossary terms"
  }
}

This way, you can give each accordion’s button a unique aria-label (or other identifying attributes) to help screen readers distinguish between multiple accordions on the same page.

@precious-onyenaucheya-ons

Thank you for the response. This is really helpful, Precious. Maybe some additional guidance on this or an example in the Accordion Macro Options Table will be helpful, as accessibility is an important aspect that could be explicit here.

I do have some concerns with this approach, as it partly solves the problem, and there are still some gaps:

"allButton": {
  "open": "Show all",
  "close": "Hide all",
  "attributes": {
    "aria-label": "Show or hide all glossary terms"
  }
}

This does not clarify to the user whether their action will show or hide. They would need to work out using the combination of the button label, which may say Show all, and then they may be able to determine which is not ideal.