Take the iterated accordion component to the accessibility clinic

[hannalaakso]

What

Take iterated component to accessibility clinic.

Why

To get expert feedback

Who needs to know about this

• GOV.UK Accessibility team
• Design System developers, designers

Done when

• Book session
• Prepped a discussion plan for the session
• Arranged a notetaker for the session
• Attended the session
• Recorded feedback

Further detail

List of things to discuss here: https://docs.google.com/document/d/1CG0OUT1tzy7q9juK4O0Iv974854hiBK5GMGF9_0ma08/edit#heading=h.8n015y3xrh1t

Previous accessibility clinic findings:
alphagov/govuk-design-system#1706 (comment)

[hannalaakso]

No clinics in August. Have sent an email to accessibility clinic to ask about being put on a waiting list.

[hannalaakso]

We've got a 30 minute session for 26th August 🎉

We'd like to cover

• the Firefox High Contrast mode behaviour
• testing the accordion with Dragon Naturally Speaking
• whether there are any potential issues with having the heading, summary and icon button inside a <button>
• show how the accordion presents when CSS is disabled but JS isn't (this is a real edge case but it would still be good to get an opinion if there's time): Improve accordion with summary line semantics and presentation when JS loads but CSS doesn't  #2327

[vanitabarrett]

We took the new iteration of the accordion component to the accessibility clinic on 26/08/2021.

Generally, comparing the live version to the new iteration, we agreed that visually it is an improvement due to the following:

• removal of the plus/minus icon on the right-hand side which can be easily missed
• the button element no longer looks like a link

However, there are concerns about so much content being included inside the button element now. In that sense, code-wise this new iteration may be worse than the live version. There was the suggestion of doing user research to determine whether this is a small or big problem for users.

Anika showed the new iteration with CSS-disabled, to help demonstrate the issue with long button content and show visually what a screenreader user will hear when navigating the accordion.

“If you showed this to a content designer and said ‘is this good content for a button’, I’m pretty sure they would say it’s not.”

The general feeling seems to be that it’s the summary line which pushes this button content over the edge and into an area of concern. One approach may be to move the summary line out of the button and below the ‘Show/Hide’, but we’re not sure if this will make things more visually confusing. Probably needs a discussion with a designer to test out a few approaches.

Firefox High Contrast mode

In Firefox High Contrast mode, the new iteration of the accordion component displays as large white buttons with heading text, summary line and show/hide - compared to the live version where only the heading text is within a button element and so only that text is highlighted with a white background.

Currently live version

New iteration

There may be an issue with the accordion sections all looking like one big thing. The suggestion here would be to add a more obvious divider (line/border) to help differentiate between each button.

The team showed a potential change where the button is limited to the width of the content rather than being full width, so it visually looks less like big white blocks. Gut instinct is that this may be a better version, but it may still be an issue that the button contains so much content as this isn’t something you see very often. It may also confuse things further as the click area would still be the whole button even if that wasn’t highlighted as white in high contrast mode.

Testing with Dragon

Anika tested the new iteration (with and without summary line) with Dragon in Chrome. Everything worked as expected. We tested:

• ‘click show’ and ‘click hide’
• ‘click show all sections’ and click hide all sections’
• ‘click [section heading]’
• ‘click [some text inside the summary line]’

Even though the testing went as expected, it’s possible the new iteration may make things take longer for Dragon users. In the live accordion, the button looks like a link, therefore it looks interactive and Dragon users would probably open a section by saying ‘click [section heading]’. However, in the new iteration, the accordion buttons don’t look very interactive other than the Show/Hide, and so it’s likely a Dragon user would need to say ‘click Show’ and then ‘click show [2]’ (for example) to target the section they wanted.

It’s likely that a Dragon user may start to understand the pattern better after interacting with one or two sections, as the focus state hints that the whole area is a button, so the above problem may not be a problem for users who are familiar with the accordion.

The accordion buttons not being obviously interactive shouldn’t be a big problem for screenreader users. Screenreader users who can still visually see the screen may be confused, but should understand once the screenreader provides them with the context that it is a button. But it might not be ideal that we’ve gone from a button that looks like a link (currently live) to a button that doesn’t really look like a button.

Potential actions

• Work with designer to see if it's possible to move the summary line text out of the button
• Tweak accordion in high contrast mode to visually separate accordion buttons/sections a bit more
• User research with screenreader and Dragon users to test if the long button content is an issue
• User research to see if users understand that the accordion buttons are interactive

[hannalaakso]

We had some existing issues to address some of the above actions, I’ve tweaked them slightly to include this latest clinic feedback:

• Improve accordion presentation in Firefox High Contrast mode #2321
• Improve accordion with summary line semantics and presentation when JS loads but CSS doesn't  #2327

Created a new card to potentially iterate the design of the summary line

• Review the accordion summary line design #2336

I'm closing this issue as completed but we'll review the clinic feedback again in our catchup to see if any more cards need to be raised.

[hannalaakso]

Solving accessibility issues flagged by the clinic

Following the findings from the accessibility clinic, the Design System team have since sought feedback from the clinic on two alternative prototypes where the summary line is placed differently in the markup.

The visual design didn’t change in these prototypes.

Prototype 1: The heading/button only contains the heading text

In this alternative prototype, the <h2> and <button> only contained the heading text. The summary and the “Show” text were in separate divs below.

The summary and the “Show” text were connected to the heading/button with aria-describedby.

Feedback from accessibility team on prototype 1

The feedback from the accessibility clinic was that this most likely would be a WCAG fail since the heading looks like a heading and not a button so this could confuse users since screenreaders would announce the elements differently than is indicated by the visual design, as demonstrated by the following screen grab:

Prototype 2: The button only contains the “Show” text

In this prototype, <button> only contained the “Show” text. <h2> only contained the heading text and the summary was in its own div below. The heading was connected to the button with aria-describedby on the button

The summary line was deemed secondary information by the accessibility team so we followed their advice by not connecting it to the button.

From our team’s point of view, this prototype would need user testing to find out whether sighted users understand the focus state when only “Show” has a visual focus state, as shown below:

This diverges from the new GOV.UK version which has a visual focus state on the heading, summary and “Show”, and the current Design System version shows a focus state on the heading text.

Another potential issue, noted when our team tested prototype 2 with screen readers, was that the reader mode in both Jaws and NVDA treats the heading text and button as separate elements when the user navigates the page which is different from the behaviour in the current Design System version and the new GOV.UK version.

Feedback from accessibility team on prototype 2

The feedback from the accessibility team was whilst this version was semantically robust (the button only contains the call to action text), it would be changing the touch area to only cover the “Show” text; this could be a usability issue since we know from research that users often click on the heading to open the accordion (this is how accordions typically work). If we made the touch area to cover the whole section header to fix this (but still only have the “Show” inside the button), it could be a WCAG fail (further confirmation on this would be needed) since the heading wouldn’t be available to keyboard users as an interactive element (unlike mouse users who could click anywhere in the section header). Also, users who change colours in their browser might see the button element only around “Show” even though the whole section header would actually interactive. More user research would be needed to understand how well this solution would work for users.

More user research would also be needed to understand whether separating the heading and button text in Jaws and NVDA reader mode (as discussed above) could be an issue for users.

Prototype 2 could be improved with an aria-label that contains [heading text][“Show this section”] on the button, since using aria-describedby to connect the heading makes the heading text read out quite late (after "Show this section" and information about the button element) in screen reader announcements. We could add this aria-label content in JavaScript to avoid asking teams to duplicate the information in their markup.

What we have learnt and next steps

What causes the issue

The core issue here seems to be that:

1. The new GOV.UK design for the accordion includes more textual information about how the accordion works (“Show this section”), both to help to solve the known accessibility issue but also to help to improve the general accessibility of the component since we know that not all users notice accordions or understand how they work; the second point was one of the main messages from the Working Group when they recently reviewed the accordion.
2. The accordion is a complex component with many moving parts, even before the inclusion of the summary line. This design change to include more text in the core design has made the summary line text problematic by being yet another piece of information that needs to be announced to users when they interact with the accordion.

We have confidence that the new GOV.UK accordion works for users

The new version of the accordion designed by GOV.UK has been in use on GOV.UK since earlier this year (although only the Service Manual is using the version with the summary line) so we have sufficient confidence that it works for users. The new version, without the summary line, has also undergone lab user research with users of assistive technologies and no issues were observed.

The new design was agreed by the accessibility team to be an improvement on the existing Design System version as it solves:

• the existing WCAG fail which we need to fix
• the other existing issue listed in the current guidance about users potentially missing the + icon when zooming in

The inclusion of the summary line inside the button could be an issue for users

The accessibility clinic advises that they can’t say whether including the summary line inside the button is definitely an issue for users, but it also doesn’t seem ideal to include so much content in the button. More user research would be needed to establish whether it could confuse users.

The problem definitely appears worse when both the heading and the summary are very long, as in the below screenshot (this is what is rendered if stylesheets fail to load but JavaScript loads - this representation can be how screenreader users conceptually perceive the elements):

The inclusion of "Show this section" text inside the heading could be a minor issue

The accessibility team flagged that the inclusion of "Show this section" inside headings could be a minor issue but not a WCAG fail.

How we're going to mitigate potential issues

To help mitigate potential issues with the summary line:

• we're going to change the Design System guidance to advise against using the summary line in most situations
• where the summary line is used, we will advise that the heading and summary should contain six words in total
• we will encourage teams to look out for any issues in research and user feedback to help us iterate the guidance if necessary in the future
• we're going to test adding a comma character in the button markup after the summary line - see Improve accordion with summary line semantics and presentation when JS loads but CSS doesn't  #2327 (comment)

We will also include the information about "Show this section" text inside headings as a minor issue either in the guidance or the backlog and ask teams to look out for any issues in user research and feedback.

[hannalaakso]

A final chat with accessibility clinic booked for 7th October.

[hannalaakso]

Last couple of bits:

• Dragon testing
• Update on what we'll put in our guidance re: summary lines
• Mention the semantics of buttons now Improve accordion with summary line semantics and presentation when JS loads but CSS doesn't  #2327 (comment)
• More just a heads up but we found this bug Accordion NVDA browse mode adjustment causes long announcements to be cut off in NVDA browse mode #2373 and ended up removing the NVDA adjustment

[vanitabarrett]

Notes from the accessibility clinic

Dragon testing

• No problems observed.
• Tested ’show/hide all sections’; click ‘Vaccination’ (accordion heading); ‘click show, choose 1’; click ‘show all’; ‘click vaccination show/hide’. Tested in Chrome and IE11. Also tested with the summary line version in IE11 and it works as expected.

Update on what we'll put in our guidance re: summary lines

• Not deprecating, recommending against using it. Avoid using it if you can, as it makes the content unnecessarily complicated.
• Do we want to say it will be taken out in the future? We want to keep things as flexible as possible. We don’t know for sure that it’s a problem. We don’t have lots of evidence.

Mention the semantics of buttons now

• Added a second comma into the button. Comma after the heading, and also after the summary text. Helps divide things up a little bit. The comma is visually hidden.
• What about if there is a comma in the summary text? Probably not making things worse though.
• Comma not just for screenreaders, also for Google search results - might want to make a note that this change helps with that. Anika said that the new version ‘show this section’ will appear in search results now? Hanna mentioned there might be a blog post by GOV.UK (maybe Andy Sellick) about using a visually hidden comma to break things up - maybe about step by step?
• Anika - overall the changes improve more than they make things worse
• Anika noticed the text with CSS disabled but JS enabled - some of the text appears larger. Not a concern, but a bit weird. Assumed it was because it has the govuk-body class, but that can’t be the cause if we’ve disabled CSS. This was in Chrome. Anika says it looks ok to her when checking in her browser (also Chrome). This could have been an earlier screenshot? Hanna also can't seem to replicate now.

Heads up on NVDA browse mode

• More just a heads up but we found this bug Accordion NVDA browse mode adjustment causes long announcements to be cut off in NVDA browse mode Accordion NVDA browse mode adjustment causes long announcements to be cut off in NVDA browse mode #2373 and ended up removing the NVDA adjustment
• Text being cut off, have to press down key to read the next ‘bit’. But we were seeing the line getting clipped, but when you pressed down it never read out the rest of the line.
• Pseudo element had been added to make inline elements appear block. Taken it out to stop the clipping of the announcements.

Potential Actions

• Find the blog post that GOV.UK wrote about adding a visually hidden separator. We think this might have been a blog post by Andy Sellick about the step by step nav.
• We could investigate the text styling issue when CSS is disabled but JS is running - probably not worth spending much time on it, if any
• Anika mentioned our changes might mean the show/hide button now appears in Google search results - do we need to confirm this and do something about it and/or document that change?

[hannalaakso]

Update on the above accessibility clinic feedback:

• Here's the GOV.UK blog post - the comma character tested well there, this is why the GOV.UK team chose the comma character for this design iteration. As per Anika's feedback, we could explore whether a semi colon would be more appropriate. But for now we'll go with the GOV.UK team's implementation, it worked well in our screen reader testing.
• It turns out that the screen shot with the different text size in the button was taken when I'd blocked only the GOV.UK Frontend styles and not all other stylesheets; for testing purposes the example page had some other GOV.UK styles present that got applied to .govuk-body... I've updated my screenshot here now with all stylesheets disabled.
• The issue with the word 'show' potentially being indexed alongside the heading text by Google was noted also in an earlier accessibility clinic which GOV.UK attended, there's a bit more about it here: https://docs.google.com/document/d/1aFz6VzaPeCc3u7EkAFkeaMZ34FjdUpFnEZOAE1Tyhb8/edit#heading=h.kobyzyyak0v I might leave this card open just to have a conversation with the devs about it although I'm not sure there's much we can do to change how Google indexes the heading text.

[36degrees]

• The issue with the word 'show' potentially being indexed alongside the heading text by Google was noted also in an earlier accessibility clinic which GOV.UK attended, there's a bit more about it here: https://docs.google.com/document/d/1aFz6VzaPeCc3u7EkAFkeaMZ34FjdUpFnEZOAE1Tyhb8/edit#heading=h.kobyzyyak0v I might leave this card open just to have a conversation with the devs about it although I'm not sure there's much we can do to change how Google indexes the heading text.

We might be able to address this by including the data-nosnippet HTML attribute to the 'Show' / 'Hide' text.

[hannalaakso]

Closing this as the work has been completed.

I've made a note for myself to create a card to look at the non-indexing of the 'Show' text as discussed above, will link to it from here when done.