Details

[jrbarnes9]

Use this place to discuss the details component in the ONS Design System

[jrbarnes9]

#189 resolved

[jrbarnes9]

#250 resolved

[jrbarnes9]

#363 resolved

[jrbarnes9]

#580 resolved

[jrbarnes9]

Details needs a default bottom margin

[jrbarnes9]

Issue #1678 raised

[jrbarnes9]

#445 resolved

[jrbarnes9]

#453 resolved

[jrbarnes9]

#508 resolved

[jrbarnes9]

#556 resolved

[jrbarnes9]

#615 resolved

[jrbarnes9]

#741 resolved

[jrbarnes9]

#990 resolved

[jrbarnes9]

#1002 resolved

[jrbarnes9]

#1238 resolved

[mr-nick17]

Could this component use the semantic <details> markup? The browser can hide/show content without JS. The only possible drawback is IE11, the content is still rendered but could potentially lose its semantic meaning

[jrbarnes9]

We did use to, but we had to pull it due to a bug (#741) found during Census rehearsal

[jrbarnes9]

Added a card to the backlog to document why we don't currently use <details>

[jrbarnes9]

Agreed to reinstate the <details> element to resolve #1996

[jrbarnes9]

#1808 fixed

[jrbarnes9]

Raised #1996

[James-Nitron]

WCAG A - Incorrect use of ARIA

The ‘Hide this’ button that is found in the collapsible element contains an aria-hidden attribute. The aria-hidden attribute should not be used on elements that can receive keyboard-only focus. This may cause some disorientation to screen reader users that are able to ‘tab’ onto the element.

<button type="button" class="ons-btn ons-js-collapsible-button ons-btn--secondary ons-btn--small" aria-hidden="true" aria-controls="collapsible" data-ga-action="Open panel">
<span class="ons-btn__inner ons-js-collapsible-button-inner">Hide this</span>
<span class="ons-btn__context ons-u-vh">What is a photovoltaic system? content</span>
</button>

Suggestion remove the aria-hidden attribute.

[jrbarnes9]

Resolved by #2013

[LaurenDowling]

When CSS is turned off, the svg takes up a huge amount of space onscreen. This reduces the usability of the component. The same goes for the accordion component.

Might be worth comparing with the gov one. The following is with css removed:

[Al-Davies]

UR findings on collapsible
tested as part of end-to-end Census testing Feb-Sept 2020

• These have been well tested via census EQ and census website. Are now widely used on the ONS - these reduce page length so page isn't over-daunting for users.
• Users like these - they don't have to read content they are not interested in, but understand how they work and can hide the content again should they wish.

[bothness]

Hi. Is there any update on the intention to revert this to be based on an HTML <details> component?

We have noted an additional issue in the current implementation that an attempt to find text within the page using CTRL-F does not reveal text within the current component, whereas it WILL find text within an HTML <details> component (automatically opening the twisty). You can see this desired behaviour in the GOV UK details component.

As we make increased use of these components on the new ONS website, it's important that users can find the information they need by this method. (Our user engagement thus far suggests that many users rely on CTRL-F to locate information on our pages.)

[rmccar]

Thanks for raising this. The reason why we aren't using the <details> implementation is that there was the need for details components that were closed on a page to automatically open and then close again when the page was printed with CTRL-P so that there was no content missed on the printed page. That is why we went down the JS route with a fallback for when JS isn't supported. We will raise a ticket to have a look into finding a solution to support this alongside the print functionality we already have.

[nimasmi]

You can achieve this without JS with the ::details-content pseudo element.

@media print {
  details::details-content {
    display: contents;
  }

Demo: https://codepen.io/nimasmi/pen/gbbXjeG

It's pretty new, and Firefox doesn't support it yet, but it might be feasible soon. https://caniuse.com/?search=%3A%3Adetails-content

[rmccar]

Cheers @nimasmi, looks promising. Definitely something that we can look to implement soon. Would solve our issue perfectly

[bothness]

Hi @rmccar @nimasmi. Thanks for responding so quickly. It would be great if we can find a workable solution to this issue ahead of the rollout of the Wagtail CMS in July.