Awesome Accordions website

General requirements

The following requirements are based on well established best practices that we found online and in addition to those best practices we added some requirements that we find important in terms of usability. These requirements are based on our own research and experience.

Accessibility

The accordion should work propely in screen readers.
While changing the state of an accordion are usually visually apparent to users who can see the page, they may not be obvious to users of assistive technologies. We need to provide a way to programmatically expose dynamic content changes in a way that can be announced by assistive technologies. Read more about this in the codex

The accordion should work by touch.
The accordion should be operated by touch – on smartphones, tablets or desktops/laptops with touch screens.
the panel should be large enough for using touch and users should be allowed to click anywhere in the header area to expand or collapse the panel.

The accordion should be accessible for people using a keyboard.

Keyboard accessibility is one of the most important aspects of web accessibility but is often neglected. Nowadays, Most web interfaces are designed with mouse cursors and touch interaction in mind but there are a lot of people depending on keyboard accessibility:

  • Users with motor disabilities who have difficulty using a mouse, using a touch device, or clicking on small things.
  • Blind or visually impaired users frequently prefer to navigate websites with specific Braille keyboards.
  • Amputees or those with congenital amputation (birth without a limb or limbs, specifically hands in this case) often use special hardware mimicking keyboard functionality.
  • Anyone who simply doesn’t have access to a functioning mouse or touchpad.

Read more about this in the codex

Usability

Expanding and Collapsing panels

By clicking a panel heading the panel opens. You should be able to open multiple panels at the time and we want the user to give full control of the interface that’s why we our default option is that the expanding or collapsing should be handled manually. The animation for expanding/collapsing should be subtle and last no longer than 250ms.

We use plus/minus icons to communicate the state of the block. Expanded has a minus icon and the collapsed state has a + sign.

By default the first panel will be expanded to communicate the behaviour of this panel.

Adding long texts in a panel

You should always have an overview of the accordion panels even when one expanded panel has a lot of content. Therefor the best option is to make the user scroll long texts in the panel.

Making it work with Print screen commands

When the print command is given the collapsed panels should be opened so that the hidden text is also printed.

Toggle All buttons

For accordions with a lot of panels we created toggle buttons to expand / collapse all panels at the same time.

Behavior

We think it is never a good idea to show / hide content without the user intentionally doing it. So from that perspective we decided to keep the interactions intentionally by letting the user always expand/collapse the panels manually.

If you do decide to expand/collapse them automatically then we advice to only use this when all panels are visible in the page, otherwise there is a chance that the closing of the panel will happen outside of the viewport that may create confusion. So be careful with this and also keep mobile in mind with the scarcity of viewing space.

An accordion can have two states

Collapsed panel
The collapsed panel shows the header that should have enough information for people to understand what content they will find when they click it. Next to this header we see a + icon to indicate that this panel can be opened.

Expanded panel
The expanded panel shows the hidden content, the header will have an active state and the icon will be changed to a – to indicate the panel can be closed.