I'm currently designing an accordion that will be accessible (WCAG 2 AA). For the open/close controls (using up and down arrows or +/x ) should each instance be labelled? e.g. with 'Expand/Minimise'. The issue being that if there are a lot of items for example a long list of FAQs the visual noise will be excessive particularly on mobile screens. Is it better practice to omit labelling or add labelling?
2 Answers
When it comes to accessibility, I find two important things to consider:
- who = Who is affected by the current design? Which of their needs are not accommodated?
- where = Where is the current design causing problems? On which medium, on which device?
A simple design approach:
- Find the favorite solution for your actual customers
- Test if that solution is accessible enough
- Improve that solution through iteration
In your case, if you found that the accordion with arrows or icons works best for your customers, then that's your favorite solution.
Next, you found that it lacks accessibility requirements in regard to labels. I will assume that you checked all the other requirements and they passed (like keyboard navigation, aria states etc.).
To improve your initial solution, you need to know who is affected and where it's causing problems:
- if icons don't work for screen readers, then you can add hidden aria labels
- if icons are not obvious enough, you can increase their size and contrast
- if icons are not suggestive enough, then you can add labels as tooltips on hover/focus
- if the accordion doesn't fit on mobile, then you can provide a custom solution for that medium
- if the accordion is confusing, then you can improve its context (page layout, spacing, headers, etc.) or you might need a completely different UI pattern
Also, keep it mind that it's impossible to make the UI 100% accessible for 100% of the people. There is a lot of diversity when it comes to accessibility. The AA standard means "good enough", so in other words, focus on your actual customers and make it good enough for everyone else.
If the component has been marked up correctly and follows the default interaction for accordions, there should be no need for extra labels.
A keyboard dependent user would expect to interact with the component, using either Enter Key or Spacebar, which would make a screenreader announce the menu as either "expanded" or "collapsed".
If I read your post correctly, you plan on using arrow keys to perform open/close functionality. This is a deviation from the expected interaction and so you should warn users, so they know how to interact with your system. And you need to do it visually in plain text, because not all keyboard dependent users are blind.
Below are two examples of accessible accordions. They are basically identical, but the Gov.uk example has more markup in it, and can be harder to inspect visually. Notice that the interaction is Enter / Spacebar, not Arrow Keys. Third link goes to W3C.
- Designsystem.dk: A simple accordion component example
- Gov.uk Design System: A complex accordion exampe
- W3C: Accordion Pattern. With Keyboard interaction explained
EDIT: Most accordions are built from design systems these days, but if you want to make your own, use the <details>
element. It is accessible out of the box, no fancy markup needed.
-
Welcome to the site! This is a great answer, IMO. Use the right controls (e.g. the HTML5
<details>
element with aname
attribute to show only one at a time) and you get ARIA semantics and keyboard accessibility for free. Commented Aug 8 at 7:56 -
Thanks @KitGrose! I forgot about
<details>
. The answer has been updated. Commented Aug 9 at 8:17