search

alphagov / govuk-frontend

GOV.UK Frontend contains the code you need to start building a user interface for government platforms and services.
https://frontend.design-system.service.gov.uk/
MIT License
1.18k stars 323 forks source link

Take the iterated accordion component to the accessibility clinic #2295

Closed hannalaakso closed 3 years ago

hannalaakso commented 3 years ago

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: https://github.com/alphagov/govuk-design-system/issues/1706#issuecomment-865908694

hannalaakso commented 3 years ago

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

hannalaakso commented 3 years ago

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

We'd like to cover

vanitabarrett commented 3 years ago

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.

130966953-5d226e39-f1a9-4c72-9548-5ca2747416ed

“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

now

New iteration

new

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.

new-2

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:

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

hannalaakso commented 3 years ago

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.

hannalaakso commented 3 years ago

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.

Screenshot 2021-09-20 at 11 19 38

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:

Screenshot 2021-09-20 at 11 23 55

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

Screenshot 2021-09-20 at 11 29 09

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:

Screenshot 2021-09-20 at 11 29 40

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 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):

Screenshot 2021-09-20 at 11 55 19

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 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 commented 3 years ago

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

hannalaakso commented 3 years ago

Last couple of bits:

vanitabarrett commented 3 years ago

Notes from the accessibility clinic

Dragon 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

hannalaakso commented 3 years ago

Update on the above accessibility clinic feedback:

36degrees commented 3 years ago

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

hannalaakso commented 3 years ago

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.