Take the iterated accordion component to the accessibility clinic #2295
Comments
|
No clinics in August. Have sent an email to accessibility clinic to ask about being put on a waiting list. |
|
We've got a 30 minute session for 26th August 🎉 We'd like to cover
|
|
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:
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.
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 modeIn 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 DragonAnika tested the new iteration (with and without summary line) with Dragon in Chrome. Everything worked as expected. We tested:
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
|
|
We had some existing issues to address some of the above actions, I’ve tweaked them slightly to include this latest clinic feedback:
Created a new card to potentially iterate the design of the summary line 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. |
Solving accessibility issues flagged by the clinicFollowing 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 textIn this alternative prototype, the The summary and the “Show” text were connected to the heading/button with
Feedback from accessibility team on prototype 1The 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” textIn this prototype,
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 2The 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 What we have learnt and next stepsWhat causes the issueThe core issue here seems to be that:
We have confidence that the new GOV.UK accordion works for usersThe 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 inclusion of the summary line inside the button could be an issue for usersThe 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 issueThe 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 issuesTo help mitigate potential issues with the summary line:
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. |
|
A final chat with accessibility clinic booked for 7th October. |
|
Last couple of bits:
|
Notes from the accessibility clinicDragon testing
Update on what we'll put in our guidance re: summary lines
Mention the semantics of buttons now
Heads up on NVDA browse mode
Potential Actions
|
|
Update on the above accessibility clinic feedback:
|
We might be able to address this by including the |
|
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. |
What
Take iterated component to accessibility clinic.
Why
To get expert feedback
Who needs to know about this
Done when
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)
The text was updated successfully, but these errors were encountered: