Accordion widgets hide several pieces of (usually) small content behind separate headings that must be clicked to be opened and seen. Accordions usually pose a challenge for people using screenreaders and assistive technology. Accordions don’t have to be inherently inaccessible, but they just usually are inaccessible. Here’s an example.
1.This is just example text, y’feel me?
Hey, how you doing ?
2. No alarms and no surprises.
Well I’m doing just fine.
3. Well hey now.
I lied I’m dying inside.
See how the first item was open, but you had to click to see the second and third? Notice how only one item stayed open? Some accordions auto-close like the one above, some stay open or in the state you leave them. There’s no way for the end-user to know!
SharePoint Online, as part of Office / Microsoft 365, now offers a collapsible content function. does not offer an accordion web part, so intranet managers either buy or download a random accordion web part from Microsoft’s AppSource store, get a custom design coded, or rely on the additional web parts provided by a turnkey in-a-box intranet product from a vendor.
Independent intranet vendors (those that don’t rely on SharePoint at all) usually offer an accordion widget because customers demand whizzy features despite the concerns I’ll consider here.
The use cases and challenges
It’s always about choosing to hide content from users. I’m grateful to the intranet managers who tweeted me with their ideas. Let me know what uses I’ve missed in the comments below.
A shorter page, hiding ancillary info
Accordions hide content for an uncluttered, shorter page. The reader can choose to ignore the whole accordion if the headings are not relevant, or they can just select the headings that are of interest.
This sounds ‘user-focused’ as the publisher is allowing the user to choose what to do. Assuming the reader understands that interaction is required…
I’m unsure this is more user-focused than plain ol’ headings and paragraphs explicitly on the page. It’s less cluttered, and a shorter page means less scrolling. Is that enough justification?
I am a big fan of single-topic shorter pages, so you might assume I dislike scrolling. I do not. The eyes can scan down a page, looking for relevant headings and keywords, quite quickly.
Step-by-step guidance
Instructions can be styled as accordions to lead people step-by-step through a process. The first item should be read before the second; you know what I mean. It’s possible to open the fourth item straight away, so long as the heading is information rich and meaningful, otherwise one hopes people will open each item in turn.
Does your accordion auto-close the previous item when the next is opened? Hiding content might seem handy, but some people will need to go back and read the previous item again. Your accordion might have an ‘open all’ control, which is helpful, if the user notices the control.
Assuming the instructions are step-by-step and so every step is important, hiding content can cause a couple of problems.
With some of the items closed, it’s likely impossible to search the page for words; y’know the CTRL + F keyboard shortcut that lets you highlight terms on the page.
It’s usually not possible to print closed accordion items. Yes, additional print CSS (styling instructions that tell the printer what to print) can be provided (and arguably should be) but often isn’t. It just isn’t. So printing the intranet pages usually prints what can be ‘seen’. Any accordion items not opened will not print. This won’t be clear and obvious to all end users.
An accordion that allows all items to show can be printed, but only if the end user realises – and they’d probably have to test – which is wasteful.
Shorter pages, in-page menus, and sidebars
I’m a fan of single-topic pages with links to other pages as needed. It makes sense for maintenance, search results, and reference-ability.
Imagine you’re laying out an explanation (400 words) page that then goes on to lay out the step-by-step instructions in an accordion. I’d argue that this could be two pages that both link to each other. The explanation page links to the instructions page, and the instructions page now has an additional 45 word introduction that clearly links to the explanation page. The explanation is necessary but, in practice, most people just want the instructions.
Longer pages can benefit from in-page menus at the top, where the subheading is “On this page” and then there are links to the section headings throughout the same page. After each section, there’s a ‘Back to top / menu” link. It can be hard to decide between creating a long page rather than three shorter pages, and that’s your job as an info architect, content designer, or communicator.
Lots of intranet pages have a sidebar, usually on the right-side. Sidebars are great for ancillary information, like links to other pages, links to document files, and metadata (info about this page) such as contact details, author, responsible department et cetera. You have to check about page reflow on mobile devices as, depending on layout design, some sidebars can end up reflowing into the very middle of your primary content blocks when viewed on mobile.
Accordion problems, in summary
As partially described above, every time you find a use for your solution, you’ve got to consider the trade offs. Sometimes, it’s more than a trade off; it’s excluding some people from your content.
In summary, here are the concerns with accordions:
- Not everyone will notice that the accordion hides content – so they’ll see (or their assistive tech will read) the item headings, but that’s it. They won’t realise there’s more.
- Opening and closing items may be hard or impossible for people using screenreaders or assertive tech.
- Hidden content will likely not print (to PDF or to paper).
- Many accordions do not allow the user to ‘show all items’ – meaning some content is always hidden and cannot be compared or easily referenced.
- Hidden content cannot be searched for with the on-page CTRL + F trick.
- Some accordions hide the previously touched item, some leave it open. There’s no way for the end-user to know.
- Accordions force active interaction with the content. Like a carousel. Is this effort desirable and necessary? Useful to the end user?
- Obviously, you’ve got to test your accordion solution on different mobile devices.
Here’s my description of accordions:
“Accordion widgets hide content, lead readers through step-by-step process instructions, force interaction by readers for an unknown benefit, usually fail to print, and can be inaccessible to screenreaders and assistive tech.”
Wedge
Caveats
It’s always horses for courses. You and I should choose the format that works best for the audiences. Sometimes that’s a long page with a ‘jump menu’; sometimes that’s a suite of five inter-linked short pages. And maybe sometimes it’s an accordion or a tabbed layout that we’ve developed to be accessible by people on different devices and using different assistive tech.
I wrote this quickly. My habit in past years has been to edit, edit, and re-edit (as I do for clients) and then not publish. I’m returning to what made Kilobox work back in 2005 — publish and be damned!
My thanks
Tweet me your thoughts, join the thread. I’m grateful to the intranet managers on Twitter who shared their accordion uses and concerns, and the accessibility advocates who shared their concerns.
A commission 💷
If you use assistive tech to use your corporate intranet in your daily life (perhaps you’re blind or partially sighted) I’d like to commission £ you for a short article that explains the difficulties and frustrations you face. Hopefully that might include a video of how accordions (or similar design patterns) work or don’t work for you.
Photo credit: Sharon McCutcheon
If you’d like to share or tweet this article, the short URL is: http://kilobox.net/6119