Open bencullimore opened 5 years ago
andyjones81
commented
5 years ago Hi, I was looking at your implementation of this as an alternative to the GDS accordion. We have a concern that some people using screen magnifiers miss the +/- to the right. However, your Expander could resolve this issue. However, have you done any work around being able to open/close all in a group at all? If not, as I'd like to use your expander in our service, I may look to add this feature if poss?
davidhunter08
commented
5 years ago Hi @awjdigital, we haven't done any work around being able to open/close all in a group but we do think it is something worth exploring. If you would like look into adding this feature then that would be great, as I am not sure when we would get around to looking into it ourselves.
bencullimore
commented
5 years ago Hi @awjdigital, I've done some work on an open/close all expander on our medicines https://www.nhs.uk/medicines/ pages.
We have several 'common questions' at the bottom of each medicine page and in the lab, we found many users finding more than one question useful. Our assumption was by having an 'open all' link at the top, it would be easier for them to access more information.
We tested an open/close all link on our beta pages which has a significant number of visitors for around a month (2 of our sprints). We found no one used this function.
I've had questions over the placement of our 'common question' section, so we decided to not progress with the open/close all link and look into how we could make them work better on the page - starting by separating them and placing them next to related information.
As the expander works really well for 'progressive disclosure' I always felt that having the option to 'open/close all' kind of defeats the point - if your user is routinely needing the information in more than one expander, maybe reduce the number of expanders or don't hide them in the first place?
Hope this helps!
andyjones81
commented
5 years ago Hi @bencullimore and @davidhunter08
Thanks for the quick replies and I fully agree with what you say Ben.
We’ve not gotten to a position to do any user research yet, but I’m anticipating how a user might interact with a particular page we have.
It’s basically a 3 year action plan with 6 themes in each year. It’s basically 18 tables with actions in each quarter of the year to be achieved. I’ve used the accordion pattern to contain each table for each theme and have 3 groups of accordions. Theoretically the pattern seems to support the content and the display.
I’ll have a bit of a think about the original idea I had which made me ask the question and also see what comes out of research.
zoobeartie
commented
5 years ago Hi @bencullimore / @davidhunter08 - we are planning to use this component on one of our main pages on eRS. The only problem we've encountered is the lack of contrast (as we use a white background in comparison to your NHS grey), hence us having the blocks (see attached).
Also, given that we could have a total of nine groupings, we also feel an 'Open all' option would be useful and will be implementing this additionally to the component, unless it's added sometime soon :)
Thanks, Z.
davidhunter08
commented
4 years ago Question raised on Slack around whether the page structure is accessible if expanders are used in this way.
Essentially the expander name is a de facto replacement for an H2, but it's not tagged as an H2 in the HTML.
And related to this, what level should headings be inside an expander? Technically there is no h2 on the page, so would they have to be h2s? or would this lead to issues because the headings are actually subsections (h3s) of the expander labels?
Possible solution
We know screenreader users navigate pages using headings and links, so users might miss the information, which is a problem. (Expanders are not technically links so do not appear in the list of links.)
One solution could be to add headings (H2) to the expander.
For example:
<details class="nhsuk-details nhsuk-expander" nhsuk-polyfilled="true" id="nhsuk-details0" open="">
<summary class="nhsuk-details__summary" role="button" aria-controls="nhsuk-details__text0" tabindex="0" aria-expanded="true">
<span class="nhsuk-details__summary-text">
<h2 class="nhsuk-u-margin-bottom-0">Negative result</h2>
</span>
</summary>
<div class="nhsuk-details__text" id="nhsuk-details__text0" aria-hidden="false">
<p>A negative result means...</p>
<h3>When you can leave your home</h3>
<p>Following the general...</p>
</div>
</details>
markasrobinson
commented
4 years ago @davidhunter08 there are some more potential use cases emerging for the above solution (i.e. allowing expander text to be marked up as h2/h3/h4/none) for coronavirus content. We believe this will be useful where users need to be aware of different scenarios but will not need the detail for each of them (test results, how long you need to self-isolate for).
I know that the expanders have tested very well when used in this way on pregnancy and baby.
In addition to being marked up semantically as headings, it may also help if the expander text was styled more like a heading in terms of font size and weight.
davidhunter08
commented
4 years ago Here's an updated version of the expander https://nhsuk-design-system-testing.herokuapp.com/expander
Proposed design changes include:
The updated style will match that of the proposed card component.
Next steps:
mkingshott
commented
4 years ago Hi. I am working on the NHS app and we came across an issue on IE11 where the expander doesn't respond to keyboard and mouse commands. Looking into it further it appears the component uses elements and styles that are incompatible with ie11 (see the link below). I'm not sure what the solution to this is, but we have determined that we cannot fix the issue via the app without considerably rebuilding the component.
chrimesdev
commented
4 years ago Hi @mkingshott have you included the required Javascript polyfill for this component, found in the NHS.UK frontend, in your application? https://github.com/nhsuk/nhsuk-frontend/blob/master/packages/components/details/details.js
chrimesdev
commented
4 years ago Hi @mkingshott did this solve your issue?
samanthasaw
commented
4 years ago Thought I should flag something we observed in testing on the NHS App around expanders.
We observed a user think that they could select a day within the expander to get a call back from their GP surgery. The user believed that by clicking one of the days listed, they had selected a day they wanted to receive a call back.
Quote from user: “If you click on that [same day response times expander], then you can click which time you prefer for them to call you.”
Design tested:
sarawilcox
commented
2 years ago Our guidance says not to use them on pages with other interactive elements, such as buttons or text input as there's a risk that expanders will distract users.
Expanders have been used in COVID-NBS and Grab a Jab start pages:
Also being trialled in the Account team on a page with a Continue button. To keep the page short and avoid interrupting the journey by signposting people elsewhere for info.
jasonprice2
commented
2 years ago Hi all, just following up on an NHS.UK Slack thread.
I've used and been involved in testing stacks of expanders on a range of NHS.UK pages over the last few years and most recently on the COVID vaccine services such as the NBS and the walk-in service finder.
We tried using them as a way to deliver complex policy information in response to urgent COVID vaccine updates. This is mostly because we had very little notice and no ability to incorporate the information as part of the actual service journey (again, due to time constraints).
However, before I left the team we were planning to move away from using them as prominently on service start pages and relegate them to 'terms and conditions' information at the bottom of the page, or avoid using them at all.
They were really only effective when it's not crucial for users to read the content. We've found it's better to deliver that kind of information as part of the service wherever possible. Users generally wanted to quickly orient themselves and check that they're in the right place, then find the 'Start' button and expect to be guided through the process. Rather than read lots of details about who is eligible to use the service and make their own mind up.
We did also experiment a few years ago with moving some common questions onto a new MMR vaccine page using groups of 3 stacked expanders: https://www.nhs.uk/conditions/vaccinations/mmr-vaccine/
This page in general tested really well with users and they would occasionally open an expander if they were interested in the answer. Otherwise they scrolled past to get to the H2 heading they were looking for. This was the intended use and I would be happy to continue using them in this way.
So, the common themes from my experience of testing them:
The last point might seem a given, but this was specific to the situation and worth noting in case it comes up again.
sarawilcox
commented
2 years ago Two blog posts worth looking at:
albfreeman
commented
2 years ago Following a couple of recent conversations, I'm just logging my thoughts on the accessibility of expandable components that contain subheadings.
If the components continue to work as they do now, we may need to add to the guidance in the service manual to explain if and how to use subheadings in expandable components. This should help content designers to think about how such subheadings relate to other headings on the page, given the fact that the expander itself is not classed as a heading.
The simplest solution to ensure maximum accessibility might be to recommend never including any subheadings within an expander. But subheadings are often needed.
For example, each medicine on NHS.UK includes a page of expandable common questions. Occasionally, the answer to a question includes subheadings. The page of common questions about Beclometasone tablets is a good example of this in practice. The question about steroid cards includes subheadings and warning callouts (a component that includes a subheading).
albfreeman
commented
2 years ago Activating expanders using voice control software can be problematic. I use Dragon and there are 2 differences between the way expanders work compared to normal hyperlinks.
The first difference is that with regular links, I don't need to speak the full link text in order for it to work. I can just say part of the link text, even just one word from the link text, and the link will be activated. This is similar to a user of a mouse, who would just need to click one word in the hyperlink. But expanders only respond with Dragon if I say the full text of the expander. This isn't much of a problem with expanders that have short names. But it can be a usability barrier with expanders that have long titles.
As an example, on the beclometasone common questions page, I can simply say "click herbal" to activate the hyperlink at the bottom of the page. I don't need to speak the full link text which is quite long ("Taking beclometasone tablets with other medicines and herbal supplements"). However, if I want to find out what's in the expander about drinking alcohol with the tablets, I have to say "click can I drink alcohol while taking beclometasone". I can't simply say "click alcohol".
Another way to activate normal links using Dragon is to say "click link" or "show links". This will display numbers next to every clickable link on the page. This can be a quick easy way to navigate using Dragon. The Dragon user then just needs to say "choose [number]", and the corresponding link is followed. However, expanders are not included in the list of numbered options, presumably because they are not standard hyperlinks and are not recognised. So the only way to activate expanders is using the above method, saying the full title of the expander in a command.
mcheung-nhs
commented
2 years ago I agree with @albfreeman that guidance may need to be updated with regards to the usage of headings/subheadings and page structure when using the expander component.
The expander text is not a heading and even if we could change the markup to add a <h> in the summary element of the component, this will not work.
The latest versions of JAWS, VoiceOver and Narrator do not recognise the heading element - the text is announced as a button. Therefore in these screen readers the expander text will not appear in any headings list and would not be navigable. Only NVDA will announce the text as a heading (as well as a button).
I also agree with @sarawilcox that the accordion component from gov.uk is worth looking at. I believe it would provide more flexibility for content designers when structuring content. It does not use the details/summary markup and uses 'proper' headings which will improve any page structure issues.
Graham-Pembrey
commented
2 years ago We are currently testing expanders as one possible way to break up NHS App privacy policy content. Here is a Mural board about this work, which includes a link to our prototypes.
In some initial usability testing last week, we tested versions of the current page that use a) expanders and b) a contents list (as a table of contents). The sessions included information-seeking tasks. At this stage of our testing, it’s not clear which format has been more helpful. But participants have broadly told us that both components would help them to navigate a long page of legal content like this. Some told us the expanders helped to make the page "less overwhelming" and "more informal and user friendly".
None of the participants so far have had particular access needs that we know of. But we've put a request to the internal accessibility network, and from that should have feedback from screen reader users in the next few weeks. We will share updates here about any further findings. We’ll also make sure to keep in line with any discussions and decisions that are made here about the use of expanders.
sarawilcox
commented
2 years ago I checked in with @mcheung-nhs about Dave Hunter's suggestion above that we style buttons in expanders as headings.
Several people have asked me recently if we could make it work more like a heading.
Michael says that adding a header in the markup won't work in that screen readers do not recognise the header. They will announce it as a button and ignore the header tag. (@Graham-Pembrey, for info.)
The App team is doing some UR into how users with access needs find using expanders. It'll be good to understand the issues better.
Graham-Pembrey
commented
2 years ago In research with participants using screen readers, we saw some variation in whether expanders were announced as ‘collapsible’:
Two of our four participants found that when they reached the title of an expandable section, it was announced as standard text. There was no cue that they could open the expander. Both people were using VoiceOver for iOS.
The other two participants found that the expanders were announced correctly as collapsible. They found the expanders easy to use. They liked that more detailed information was hidden until they chose to reveal it. However, one commented that they found it confusing how we had used expander titles to structure the page, in place of headings, which they relied on for navigating. One of these two participants was using VoiceOver for iOS. The other was using JAWS for PC.
We also tested the same content with some people who had no stated access needs. They responded positively to the expanders. One person told us that being able to open one section at a time helped them to focus.
The prototype being tested was an NHS.UK template page, showing a possible presentation of the NHS App privacy policy.
@sarawilcox @mcheung-nhs
markasrobinson
commented
2 years ago 111 online have recently launched a new homepage (https://111.nhs.uk/). On mobile, the page is all expanders - would be good to link in with them to find out about any testing done on this and how the page performs in live.
Demotive
commented
1 year ago Sorry for the slow reply!
We do use expanders heavily on the 111.NHS.UK homepage, as a way to handle the varying incoming user needs and journeys (not all of which are best served by the core triage product).
Some background to those design decisions here and here
During usability and popup testing, we found that users without any additional assistive technical needs were much more successful at finding and navigating the options than when we used a long-form page, particularly on mobile devices.
Our standard production testing does include NVDA, JAWS, VoiceOver and as far as I know no issues were reported. We've had no user feedback I'm aware of around issues either.
On the Jaws related points above, it seems we avoid those particular gotchas by not using subheadings and not using long summary elements.
I will make a point of ensuring any upcoming assistive-tech usability sessions pay serious attention to these elements.
Points above about exploring the GOV accordian pattern are interesting too. I wonder if it's worth looking at ways to use different underlying code to create expanders that don't rely on a details element?
meeraexpress
commented
1 year ago We've recently carried out some usability testing where some users thought the expanders signalled the end of the page. Has anyone else come across this insight before? We are planning to run some scroll tests when our pages go live to see if there is more evidence for this
aviangel-NHS
commented
1 year ago We recently tested some pages within the contact us hub that use expanders stack one above the other. https://www.nhs.uk/contact-us/find-out-how-book-cancel-change-appointment 2 of the participants were blind and used a screenreaders (Jaws and VoiceOver)
The both had issue with the expander components as they are not read out as interactive elements and so the participants were not aware they were interactive and contained further information
Have attached 2 screen recordings on how they are read out using VoiceOver (iPhone)
sarawilcox
commented
1 year ago Thanks @aviangel-NHS . Yes, we're picking up various comments around this. @roshaanbajwa, for info.
aviangel-NHS
commented
1 year ago Attached are some accordion examples of Google and GOV accordions and how VoiceOver interacts with them
NHS.uk has been using stacked expander components and there's been questions around whether expanders should be used this way. GOV.UK have updated their accordion component "The accordion component lets users show and hide sections of related content on a page."
https://design-system.service.gov.uk/components/accordion/
Blog: How we made the GOV.UK accordion component more accessible (2021) https://insidegovuk.blog.gov.uk/2021/10/29/how-we-made-the-gov-uk-accordion-component-more-accessible.
This might not be the right thread for this but I would query wether we should update our expander component in line with GOV or create a new pattern based on GOV's which would allow us to show or hide sections of related content.
ONS also has an accordion component that is styles slightly differently (I haven't checked how this works on a screenreader) https://service-manual.ons.gov.uk/design-system/components/accordion
What
Use this issue to discuss the expander in the NHS digital service manual