Iterate accordion component

[christopherthomasdesign]

What

Iterate accordion component to be more accessible and consistent with how GOV.UK are doing step-by-steps.

We should also consider the details component which behaves in a very similar way.

The output of this stage of the work should probably be to have a prototype to test in user research.

Why

• The accordion in the Design System is not accessible – the section headings in accordions can be mistaken for links, but are treated as buttons. This fails WCAG SC 1.3.1 Info and Relationships.
• GOV.UK are currently working on making their accordions and step-by-steps work more consistently. At the moment they look and behave differently, which I think fails WCAG 3.2.4: Consistent Identification.
• The details component looks like a link but isn’t one – some users ignore it to avoid leaving the page. It may also fail WCAG SC 1.3.1 because it presents itself as a link but cannot be "programmatically determined" as one.

Who needs to know about this

• Most of our team, especially Charlotte, Chris, Rosie, Tim
• Mia & Owen on the GOV.UK team

Further detail

• Backlog discussion on accordions
• Backlog discussion on details
• Sketch file looking at possible step-by-step + accordion designs
• The current version of the step-by-step component, recently improved to fix some issues with screenreaders
• Tim's exploration into making details and accordions the same thing – may only be visible to people on the team

Done when

• Visual & technical approach agreed by GOV.UK and our team
• A version of the component included in a prototype to test with users

[CharlotteDowns]

The accordion component design has potential cross over with other components and patterns

Released

• Details
• Step by Step

In the Community backlog

• Filter a list
• Potentially even sign in / sign out

Other service components

• Collapsible (a sidebar on GOV.UK Pay)

[christopherthomasdesign]

Summary of chat with GOV.UK

• Step-by-step is maybe the most tested component on GOV.UK with users – including those with low digital skills, cognitive impairments etc. so is a good starting point for other accordions
• The team recently made changes to the step-by-step pattern to solve some accessibility issues – using visually hidden spans so each heading says ‘HEADING, show this section’ when read out
• Now GOV.UK have fixed the step-by-step's accessibility issues, now need to bring accordions in line so the two components are consistent
• Their preferred approach is to use an updated accordion from the design system, rather than make their own thing
• +/– icons could be mistaken for add/remove controls and aren't used in step-by-steps
• Accordions should use the same ‘show/hide’ controls as step-by-steps, for consistency
• Discussed whether step-by-steps and accordions should be identical except a step-by-step has numbers at the side

Next steps:

• Work collaboratively on some designs that can work for both (including some experiments with the details component)
• Find examples from services to stress-test the designs
• Agree on an approach that works for both teams and start prototyping it

[christopherthomasdesign]

Notes from accordion backlog discussion

• People put all sorts of things in accordions – lists of checkboxes, dashboard-like displays of data, big lists of links etc. Sometimes it's hard to see where one section ends and another begins.

• Lots of evidence that users can miss the right-aligned +/− controls, and that moving them to the left and adding a word like 'show/hide' helps

• Some support for using the words 'show/hide' on the controls rather than 'open/close' as it's more generic and is maybe a less visual interpretation of what an accordion is doing

• Frankie Roberto helpfully describes the different use cases of details and accordions:

  • the Details component is for revealing more detailed content related to the current context which only some users will need. The revealed content is likely to be 1 or more (but less than 5) paragraphs of prose.
  • Whereas the Accordion component is for presenting several comparable sections of content where it is likely that users will only need or or two of them. The revealed content is likely to be more structured content than simply paragraphs, such as a list, tables, or even form fields.

• Nielsen Norman did a study that found that 'caret' icons (i.e. downward-facing arrows) matched users' expectations most closely, compared to plus icons, no icon, sideways arrows etc.

• There was one example shared of a nested accordion, though I'm not sure this is a common or desirable use of accordions

[CharlotteDowns]

Examples of the accordion component across pages and services

• Check MOT service
• Postgraduate teacher training prototype
• Coronavirus landing page
• Service manual, Accessibility and assisted digital
• The Highway Code (already a variation)
• World pages (Afghanistan example)
• Pension Credit service
• HMRC content style guide
• Hackney Council support for business
• Upload a document to Companies House COVID-19 service

[christopherthomasdesign]

Details and accordions

In theory, details and accordions are very similar – they both conceal additional content under a 'heading' that users can interact with to see more.

Just summarising some conversations we've recently had about each.

Question 1: could we use <details> for accordions?

We've discussed using the HTML details tag instead of the current button + JS approach for accordions.

On the face of it, it seems like a way to get native show & hide behaviour without using javascript. I guess the further implication might be that we could just have one component that replaces the 2 existing ones, covering the need to show & hide content.

TL;DR we probably shouldn't

There's a problem with using <details> for accordions - the <summary> part of <details>, which would contain the heading, treats elements inside it as having no semantics. So putting a section heading inside one would have no effect, it would be missed by screen readers etc.

And there are some problems with <details> generally:

• some browsers (looking at you Internet Explorer) do not natively support <details> so they don't offer a 'script-free' way of doing exandable things – you need a polyfill
• iOS VoiceOver doesn't always the announce correct state of the details element
• there's a bug that means you can't style details elements to override the closed state when you print out a page – if it's not open, it's not seen as part of the HTML

Question 2: should details look more like accordions?

We know the details component has had some usability issues. Some users don't interact with them because they look like links and don't to leave the page they're on. We also know it is a matter of interpretation on whether the component passes WCAG SC 1.3.1 Info and relationships. Similarly, this is because it looks like a link but isn't one.

I think it's worth exploring how details could use similar design cues to those of accordions, given how similarly they behave.

References

• https://daverupert.com/2019/12/why-details-is-not-an-accordion/
• https://adrianroselli.com/2019/04/details-summary-are-not-insert-control-here.html
• https://www.scottohara.me/blog/2018/09/03/details-and-summary.html

[christopherthomasdesign]

Design update

We've been working with GOV.UK on iterating the visual design of the accordion to fix some accessibiltiy issues we've found.

For reasons outlined earlier in this issue, we're aiming for something that:

• makes accordions and step-by-steps more consistent (ideally a step-by-step is an accordion with some big numbers at the left)
• doesn't use link styling for affordance
• has a more button-like appearance
• has clearer open & closed states
• has any controls aligned at the left

For context, here's the GOV.UK step-by-step as it currently works. The headings are buttons, and include some visually hidden spans so that screen readers read them as 'Do a thing, show this section'. The show/hide controls probably still look too much like links, albeit the words 'show' and 'hide' may suggest less that they might link to another page.

I've added a few screenshots below of us starting with the secondary button style and gradually developing them towards something that could work as accordions. There's also a big Figma file with many more design explorations.

Secondary buttons:

Adding chevrons to give show/hide a bit more affordance:

Making them white cos grey backgrounds not great for longer form text:

How that might look as a step-by-step:

Some ideas of how the states could work:

Next steps

I've created a first draft on this branch of Frontend. Have a look at a preview on my design system mess prototype (username:design password:mess). We'll be testing it in user research in the coming weeks... will add a summary of any findings here 👍

[paulrobertlloyd]

Very much like the direction this is headed – as well as the motivations behind it.

At first I wasn’t too sure about the disclosure icon being inside a circle. Circles are not something that appear too often on GOV.UK. That said, the crown logo features circles, and tittles and punctuation marks in Transport are circular too, so it doesn’t feel at odds with anything – in fact it offers some much needed visual contrast.

Will be interested to see where this heads!

[frankieroberto]

One downside of this design as it is might be that each section is a lot taller, at 116px vs 61px for the current design, which might make it harder to scan and compare, as you can see fewer sections at once.