Accordions suffer from a phenomenon I have coined as 'Sinkhole', which in its worst cases can cause both confusion and disorientation to the user. Sinkhole is however avoidable by using  Closable Panels, a pattern that is very similar looking, but behaves differently to Accordions.

What is an Accordion?

The Accordion component is made up of two distinct elements; the panel title and panel content. This pair of elements are repeated as needed to house different sets of information.

Accordion example - Sinkhole

Only one instance of the panel content is viewable at a time, and a user switches between content views by invoking the panel title. It is this event of changing content views that brings about the Sinkhole phenomenon.

Sinkhole

When an Accordion grows in height, the content below it is pushed downwards. Should an Accordion's height shrink, then elements below shift upwards to occupy the newly vacated space. An Accordion can grow or shrink each time the user invokes the Accordion's Panel Titles. This interaction brings about the phenomenon I have coined as a Sinkhole.

Microsoft's website uses a Mega Menu on large screen devices for its global navigation, and changes it into an Accordion for smaller screens. The small screen version of their navigation suffers from Sinkhole, exhibiting the undesirable traits I described, which is demonstrated below:

[kad_youtube url="https://www.youtube.com/watch?v=-809-1O0Vv8" modestbranding="true"]

In the video the user first opened 'Products', and after scrolling down the product list, they then chose to look at 'Downloads'. When 'Downloads' was tapped it caused 'Products' to collapse, which shrank the height of the Accordion substantially. At that moment in time (8 seconds passed) the user can no longer see the navigation menu. It has disappeared from view, as it is now above their viewport, and this can cause confusion and disorientation to the user.

Remedying Sinkhole

Sinkhole, what the video above just demonstrated, is quickly remedied by switching from an Accordion to Closable Panels. Then panels are independent from each other; they only close when a user clicks/taps it again (a toggle), and opened panels remain open should the user choose to open another panel. The opposite of what an Accordion does.

In order to close a panel, the user must first scroll up to see the panel title, so that they are able to click/tap it. The page content then flows upwards towards the user's viewport, which means the user's viewport is not changed by the page reflow, keeping them where they where before invoking the panel title.

Inline Scroll

An Accordion's height can be fixed using CSS. When the Accordion's content becomes too much for it to display, a scrollbar is provided so that all of the content can be viewed. The trouble then is how big to make it? Too small when displaying lots of content and it becomes troublesome to consume that content. Too large, and it starts taking up more page space than necessary, which contradicts its very purpose of existence.

Inline scroll has its very own phenomenon too, which I have called 'Treadmilling'. This happens when you scroll down a page using a mouse-wheel or trackpad gesture and your cursor passes over the area where the inline scroll is. Then your scroll begins to scroll through that content instead of the page, with you moving but the main page remaining still. This is a topic I plan to cover shortly, so I won't go into this any further here.

Considering this, I personally cannot find an argument against using Closable Panels instead of an Accordion, with or without inline scroll. Please let me know your thoughts using the comment section below!