govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Details (Hidden text)
AKA: Hidden text, Expanding text area
Use this issue to discuss this component in the GOV.UK Design System.
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.
@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.
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?
@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.
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:
It looks like if you pass text to the details element it goes directly inside a div. Should it go in a paragraph?
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.
@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: https://github.com/alphagov/govuk-design-system/issues/822
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.
@paulmsmith I use the above approach heavily in my prototype - I wonder how well it's known by others.
@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.
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
@nickcolley Happy to contribute! Little stacked at the moment but will have more time next week. :)
It would be good for you to capture some of your thoughts here please: https://github.com/alphagov/govuk-frontend/issues/941 !
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.
@mpwoods I'm curious about your placement of the details component after the checkboxes. Do you have any details of research / thinking behind this? I might speculate it's seen as less important than the main question - but with the downside that some AT users won't get to it till after answering the question.
My team were just discussing a similar thing - how to use details elements within questions (and what markup would be correct) so would be keen to hear your thinking.
@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.
We've got a details component on our apply journey on JSA, when we went through accessibility testing it was flagged as looking like a link, but doesn't respond to "Click link" when using Dragon, but does respond to "Click button" As a result we failed this test on the report:
- Confirm that saying "Click Link" numbers all the links on a page. (NB: If there is only one link visible it will automatically be selected.)
- Confirm the correct link opens when the user says "Choose
". - Say ‘Go Back’ to return to the testing URL.
- Activate each of the links in turn, by repeating steps 1-3 and selecting each number in turn.
- Repeat with "Click Link" NB: Where the user "clicks" a single, unique link, Dragon takes the user straight to the relevant page
I have tried to give it a role of link to both the <details> and <summary> tags but the permitted roles are none for these tags and summary has an implicit role of button so always renders with role of button.
The issue was flagged by an accessibility testers originally, though we did have a real Dragon user test this application journey also and the report said they were able to expand the link successfully, but it doesn't mention which Dragon command they used.
This is how it's being used in our apply journey:
I believe this was chose so they could hide the continue without providing bank details link as missing bank details is a common cause of delayed claims. Not 100% sure on this as it was done by a supplier and handed over.
We've just run 5 UR sessions for a service we've inherited. It uses the details component heavily. All participants said they expected that the "link" would take them to a new page. And as per @timpaul's first comment on this component, participants were concerned that they'd loose their progress if they clicked the perceived link.
@roobottom thats really useful thanks, can you say any more about the context of the service? Can you upload a screenshot?
Sure, it's for the "File your company tax return" service. Which is old, but does use a version of details that looks pretty much the same as the modern one. Here's a couple of screenshots:
- Before the user starts we offer some guidance:
- Once in the service, we use
detailsto explain what each line-item is related to.
It is my understanding that this would indeed fail WCAG SC 1.3.1. It presents itself as a link but cannot be "programmatically determined" as one.
We discussed the general issue of buttons looking like links and specific examples like the details component among a group of accessibility specialists at GDS.
WCAG SC 1.3.1 says:
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
When the link button text makes it clear what it is doing, that is not a fail. For example, the accordion's "Open all" link button looks like a link but makes it clear what to expect from the text alone.
Otherwise we decided that a button that looks like an interactive thing without looking too much like a link is also not a fail. But this is where it gets tricky because the decision if something "looks like a link" is very subjective.
When we discussed the details component within the group we asked ourselves "Does this look like a link?" and found Yes, technically it looks quite a lot like a link. (They are blue and underlined.) But when we asked ourselves "When you click on it, would you expect it to lead you to a different page?" the answer from all of us was No. We found the main reason for that was the triangle before the link.
So, we thought we wouldn't fail the details component on 1.3.1. But as I mentioned, this is very subjective. We know from feedback on this very page that different users have confused it with a link. That makes this difficult to judge.
On the other hand, we found the accordion section link buttons technically look less like a link (they are blue but bigger and bolder and not underlined), but when we asked ourselves "When you click on it, would you expect it to lead you to a different page?" we all said Yes. Although the big plus makes it look different, it is so easy to ignore when it is out of the way on the right-hand side. And we know some users had issues interacting with it as well because they thought it was a link.
Sorry that this is a somewhat less satisfying statement because some elements of it are so vague. Does anyone have any alternative views on this subject or other insights?
@selfthinker really appreciate the update.
Is there a risk that only asking the GDS Design Team how they expect the details component to work has biased the result? If GDS built it, and as designers in Government, we've all used it, we would probably all agree that we'd expect it to expand, because we all know for a fact thats what it does.
However, I have seen first hand that in user research sessions people often do not interact with details components because they don't understand what it is.
I appreciate that WCAG is very subjective, but I am a bit worried that we could do our users a disservice if we mould the subjectiveness of WCAG to fit our own understanding of how a component already works.
@abbott567, just to clarify, no-one from any design team was involved in that decision. (I don't think there is a "GDS Design Team", so I might potentially misunderstand what you mean by that.) At least one person in the group was quite new to GDS and didn't know the Design System very well.
But yes, obviously we're all biased in some ways. Although I think it's more likely we were more biased by knowing how the web works rather than how the Design System works. (I remember someone mentioned the browsers' default styling of the details component and that it's very similar.) All we can do is to try to be objective. But it's difficult to achieve full objectivity within a WCAG audit setting. I'd be very thankful for any tips on how to improve that.
Most of us also knew the accordion quite well and failed it, even though we knew how it was supposed to work. So, I don't think 'knowing the Design System' is the one factor that might make us biased. DAC did a WCAG audit of the Design System and didn't fail the details component. They are a third party auditor and don't work for GDS. Although I guess you could argue they know web design in UK government quite well because they've been auditing government services for years.
We're not saying that there isn't an issue. And I agree that this component should be improved. We're just saying that we don't think it's a strict WCAG fail.
@selfthinker thanks for the clarity. Apologies, when I said GDS Design Team I just meant the team responsible for maintaining the Design System.
It's reassuring to know it was usable when tested by the DAC.
Just for feedback, on the Design System accessibility statement it says a 'sample audit' was done on each of the page types. It lists 'a component page' as one of those, and the link just goes to the radio buttons component, so it is not clear that DAC has tested the details component. It reads (to me at least) that just the radio button component was tested in the sample audit, which if it's not true is probably doing GDS a disservice.
Noting for any future explorers:
Today we were contacted by a developer, saying that an external auditor had flagged the Details component as having an issue, as screen readers were announcing the (seemingly superfluous) text "disclosure triangle" in Google Chrome. In this instance, the test was using TalkBack on Android 12.
We have previously noticed this in 2018 when using macOS VoiceOver with Google Chrome. Checking again today, this is still the case.
Help with nationality, collapsed, disclosure triangle, group
Further testing found that this is part of Chrome's accessibility tree for the details/summary elements—"DisclosureTriangle" seemingly being the accessibility tree's name for the summary element—and is not specific to our implementation.
We therefore do not consider this to be an issue with the component.
We got some usability feedback on this component in an accessibility assessment conducted by DAC recently.
Voice activation users noted that the expandable option ‘Help with subject matter of dispute’ at the bottom of the page does not get picked up by voice activation software. This leaves the need for keyboard only commands to be used which, is a slightly longer and more difficult way to access content.
Current code ref(s): #new_client_vehicle_details_form > details > summary > span Help with subject matter of dispute
Voice activation user comments: “The accordion above the ‘save and continue’ button does not get picked up by Dragon. This meant that I had to use keyboard commands to tab onto it.”
I've captured the page html as a gist as @christopherthomasdesign suggested the specifics of the page around the component might be useful in replicating the issue. The page is several pages into the user journey on our service, requiring particular answers to reach it, but I can provide these as replication steps if that's more helpful.
