Details (Hidden text)

[govuk-design-system]

AKA: Hidden text, Expanding text area

Use this issue to discuss this component in the GOV.UK Design System.

[timpaul]

In research HMRC have seen some users who are reluctant to interact with this component because it's styled as a link. They're worried that they will be taken away from the transaction and lose their data.

[ghost]

@timpaul There are people who scan straight past it and do not interact with it. This could be because of time or lack of familiarity. But this means people can miss important content.

From an accessibility point of view, they are not treated as links by screen readers assistive technology so the experience is totally different.

A colleague wondered if anyone had thought to use the show-hide links, like in the manuals and learning to drive step-by-step guidance. Something like these screenshots.

[SineadFluent]

When there is text to show/hide. Does anyone have research to support whether it is better to change the label of the link between 'more detail' and 'less detail' or if it is better to keep a link as 'more detail'? Seems like it would make more sense if the link describes what it is doing and say 'less detail' when extra text is being shown but keeping the link labeled 'more detail' may be less cognitive load for the user. Any thoughts?

[hannalaakso]

@dashouse discovered that the native details can't be forced to display its contents when printed (unless element is already open on page load or was opened by user). This is because the visibility of the contents is toggled with open attribute in the markup, and this can't be controlled with CSS print styles.

Bug tracked here.

[joelanman]

Since we're using plus and minus in the Accordion component, I thought I'd see how Details would look with the same symbols, as the behaviour is very similar:

[edwardhorsford]

It looks like if you pass text to the details element it goes directly inside a div. Should it go in a paragraph?

[edwardhorsford]

This came up again on the cross gov slack again.

I think it could be helpful to include an example with more than one sentence - I think the correct thing to do is directly provide some html, but I'm not 100%.

cc @frankieroberto who also had questions on this.

[frankieroberto]

@edwardhorsford yeah, if you use the html option of the macro (or whatever Rails-equivalent you're using) it should be fine to add multiple paragraphs?

My question was about Inset text, which I've raised here, although it's very similar: #822

[paulmsmith]

In Nunjucks you can capture the contents of a block into a variable using block assignments, which might be easier for some users perhaps?

An example

Write the HTML in a separate block using set:

{% set detailsHTML %}
    <p class="govuk-body">
        You might need permission from somebody else to do your project, for example you may need:
    </p>
    <ul class="govuk-list govuk-list--bullet">
        <li>
            agreement from the owner of a heritage asset
        </li>
        <li>
            access rights from a landowner
        </li>
        <li>
            planning permission from the council.
        </li>
    </ul>
    <p class="govuk-body">
        It could also include consent to record audio or take photographs of individuals.
    </p>
{% endset %}

Then reference that variable when using the macro:

{{ govukDetails({
    summaryText: "Examples of what might need permission",
    html: detailsHTML
    })
}}

My other suggestion would be to leverage Nunjucks 'call' within the macro but that would mean rewriting the macro in govuk-frontend and although powerful they would probably add complexity and be a tricky concept to grasp for less experienced users of the toolkit.

[edwardhorsford]

@paulmsmith I use the above approach heavily in my prototype - I wonder how well it's known by others.

[paulmsmith]

@edwardhorsford It is subtly documented in Nunjucks. If I get a minute I might do a pull request with an example for the docs maybe? For my own purposes I could be tempted to write a macro that uses 'call' but then uses the official macro under the hood.. I wouldn't suggest that to everybody because it is another level of abstraction but, it is a possibility.

[NickColley]

Using capturing like that is the safest way to pass HTML as it means you can avoid some cross site scripting vulnerabilities, I think it'd be good to have a general guide for this sort of stuff.

Where possible I have recommended that the Design System examples should use capturing

[paulmsmith]

@NickColley Happy to contribute! Little stacked at the moment but will have more time next week. :)

[NickColley]

It would be good for you to capture some of your thoughts here please: alphagov/govuk-frontend#941 !

[mpwoods]

This component has been added to four questions in the Brexit checker: https://www.gov.uk/get-ready-brexit-check/questions?page=3

The checker provides users with a list of personalised actions that they need to take to prepare for a no deal Brexit. User research has shown that users don't understand why they are being asked certain questions, and how their answers will determine what actions they need to take.

We want to carry out further user research to see how users respond, and to see if we could add it to all/more questions in the checker.

We're also adding customised tracking to the component to help gain further insights.

[querkmachine]

We have numerous bug reports open with the WebKit team regarding VoiceOver not announcing details element states:

• iOS VoiceOver doesn't announce state of details element when using role group reported-bugs#28
• iOS VoiceOver doesn't always announce correct state of details element reported-bugs#29
• iOS VoiceOver doesn't correctly announce expanded state of details element if summary has display: inline-block reported-bugs#64

[lalexander12]

Can I ask about using a details component within a question that contains radios? For example, we have a multiple page question, with several question/radios. In one instance we add a 'details' between the question and the radios. Is it better to keep details outside of the question/radios, for example, above or below?

[eirikbacker]

Can I suggest checking out https://u-elements.github.io/u-elements/?
This project re-implements native HTML elements 1:1 with the W3C specifications, but resolves screen readers issues, meaning you can use all your styling as-is, and opt out and back to native when native details/summary is well supported.

[benchilds]

Update: Showing how "bleeding edge" I am, I now notice this was first raised in February 2019. :-D
#6031 (comment)

Extracting a little (hopefully valuable) output from a lengthy discussion we've been having about the NHS.UK Details component whilst using it in a prototype at NHS BSA...

• In its simplest raw form, a <details> element can have a <summary> element and a raw text node as children.
• Unfortunately though, the text child can then be complicated to style – hence often why the child <div> is introduced.
• However, <div> elements should only be used where there are no better semantic options and only then to group other HTML elements (says the Mozilla specification).

There is no better semantic option here – so the div is fine – but having an unwrapped text child in the <div> element in the example on this page feels like it's not leading designers to implement this component with good HTML in mind.

Shouldn't the basic example of this component – even with just one line of text – use the <details> > <div> > <p> structure instead of <details> > <div> > raw text?

[AnthonyDewhirst]

Hi all,

I've read through the above and we are finding similar issues to others still.
4/4 accessibility testers so far have all had issues with this component:

• looks like link
• screen reader read the hidden text
• didn't know it was more info.

I then looked at the accordion which states that due to this type of research it was changed in 2021 away from looking like a link.
Which begs the question, why does the details still look like a link? I think we are going to try using the accordion as a single element and see what the reaction is.
Based on all the feedback above. Are there plans in place to move this away from looking like a link?

This is from the Learning Records Service (LRS)

[CharlotteDowns]

@AnthonyDewhirst thank you for this feedback, we are trying to work on improving the experience for Voiceover and Dragon users.

Our work is being captured and tracked in the following issues:

• Investigate solution for operating the details component with VoiceOver #5310
• Investigate solution for operating the details component with Dragon #5308

Are you able to let us know what assistive tech your accessibility testers were having trouble with? Currently we don't have redesigning it on the roadmap at the moment but feedback like this will help influence whether we prioritise it.

[AnthonyDewhirst]

@CharlotteDowns So sorry, that I never replied - yes, the screen readers were two actually:

• read aloud
• read and write

[jfranciswebdesign]

Hello - some feedback from a user with accessibility needs (low vision, so uses magnifying/zoom technology):

"That triangle link normally expands and closes. When I see blue underline I think it will take be to a different page. I don't know what to expect with arrow and underline".

[DannyPayne-CH]

Just want to check in (as I'm still getting up to speed with GitHub) but do the issues with voiceover/dragon still exist?

[paige-qldgov]

@edwardhorsford It's a good question and we debated the placement for some time.

We looked at 3 potential positions: above the checkboxes; below the checkboxes (as now); and below the button.

Most of the questions have descriptive text above the checkboxes, and some have additional hint text too. So adding the component into that space felt a bit cluttered.

There was a concern that adding it below the button would cause some users to miss it, and also that links below buttons are often things like 'Cancel' so it could get confused with that. We're also looking to add a 'Skip question' link which might sit in that space.

We asked around for other examples of where the component is being used with questions and we found this which also places it above the button: https://global-entry.beta.homeoffice.gov.uk/register-to-apply/passportNationality

Due to the pace we've been working at, and wanting to add this component before the pre-election period freeze, we've opted for the current placement with the proviso that we'll carry out user testing as soon as we can. We're also adding custom tracking to the component so we can gain insights in the meantime.

Hope that helps.

Curious to know if this ever got tested or if you discovered any insights about the order of the details component?

[steve-oconnor]

I saw a discussion in Slack about accessibility issues with the summary text being underlined. I wonder if making use of the tag backgrounds would be a simple fix?

[selfthinker]

I wonder if the content of the summary text could also help fix things. It could explicitly refer to the action.

Ideally that would be dynamic, so, "show" when it's closed and "hide" when it's open (or similar words). For example, instead of "Help with nationality" it would start as "Show help with nationality".
But maybe there is a way to say it without needing to be dynamic text.

Has anyone tested such a change against the standard component? It would be good to see if that makes people less confused about what the component does.

[JodiB-TPR]

On the topic of users thinking the "link" would take them away from the page, we've had success with simply changing the direction of the arrow icon. We use a downward-pointing chevron in the closed state and rotate it to point up in the open state. When asked, users have said they expected it to toggle something open.

[NickColley]

From https://github.com/skununka315 (original post):

Department of Education (DfE) Register Early Career Teacher service (RECT) Feedback from users with access needs and that use assistive technology

Screen reader users only found out that the guidance link was expandable at the end of that sentence.​

• A participant explained that this makes it harder to scan and understand the page structure and suggested that the expandable status should be announced earlier to prepare them mentally.​

* It is recommended that the component announce that this is an expandable link before reading the link text.

[katja-alcock]

On the Funding Service at the Ministry of Housing, Communities and Local Government, we've just done a WCAG 2.2 audit with DAC and an accessibility issue has been raised with how this component behaves for voice activation users (tested with Dragon). Users expect to be able to find and then move focus to an interactive component by speaking part of the visible label. However, when it comes to the details component, the user can only get to the component if they speak the whole of the summary text (which could be very long).

I have pasted the code and comments from the report here:

Voice activation users were unable to reference the ‘Calculations help’ details component
by using the label. This resulted in the analyst having to use keyboard commands to expand
the component.

Current code ref(s):

#main-content > div:nth-child(2) > div > form > details

<details class="govuk-details">
<summary class="govuk-details__summary">
<span class="govuk-details__summary-text"> Calculations help </span>
</summary>
<div class="govuk-details__text">[…]</div>
</details>

Voice activation user comments:

“This detail element only responds to their visual titles if the entire visual title is
used. Normally when using a visual title to interact with an element the user only needs to
say the first few words of an element in order to interact with. For example, I would have
expected “click calculations” to open the detail element ‘calculations help’ But this did not
occur. This led me to incorrectly assuming that the detail element does not respond to its
visual title leading me to waste time with other methods to interact with the detail
element. I tried using the “click link”, “click button”, and “click list” commands which gives
dragon tags to all possible links, buttons and lists Dragon can identify on-screen
respectively. Unfortunately, no dragon tags appeared on the element, this showed that
Dragon could not identify this detail element as something that could be interacted with.
The only way I thought I was able to open the detail element was to use Dragon to navigate
via keyboard control commands: “press Tab” and the “press space”. Which replicates the
effects of pressing the tab and the space bar keyboard buttons respectively. This
required considerably more commands to Dragon thus it was longer and more tedious.

It was only because I have prior experience with this issue that I realised that they could be
interacted with by their visual title if the entire visual title is used. For example,
“click calculations help”. This is not how Dragon normally interacts with elements and is not
what I would expect at all leading to delay.
Although ‘calculation help’ is a relatively small title this issue persisted for all detail
element encountered throughout the site some of which have much longer visual titles
which would cause this issue to come up later. If the issue with the visual title itself cannot
be fixed at the very least the detail element should be registered as links so that the
command “click link” can interact with it. This will allow Dragon users to more easily access
the element without it delaying and misleading them.”
Examples of additional instances:
Additional instances of this issue may exist on other pages throughout the website;
wherever this issue occurs, they too will need to be resolved.

Solution:

Consider adding the role of ‘button’ to the component but the component has limited
compatibility with Dragon software at the present time.