Pages with 2+ password fields must use different programmatic labels for 'show' and 'hide' buttons on those password fields

[dav-idc]

This issue is from May 2023 external accessibility audit report.

WCAG Reference: 2.4.6 Headings and Labels (Level AA) Understanding Headings and Labels | How to Meet Headings and Labels

Issue ID: DAC_Non-descriptive_Labels_01

URLs: URL: https://signin.account.gov.uk/create-password

Screen shots

Both of the ‘Show’ buttons presented for users have been provided with an ‘aria-label’ to offer users of screen reading assistive technologies additional context that they are to show the password. However, both buttons have been provided the same name of ‘Show password’, meaning that screen reader users are not able to distinguish which button relates to which field. This same occurs when the button is activated, and the label is changed to ‘hide’.

Current code ref(s)

#main-content > div > div > form > div:nth-child(3) > div > div > button

<button class="govuk-show-password__toggle" aria-controls="password" type="button" aria-label="Show password">Show</button> […] <button class="govuk-show-password__toggle" aria-controls="confirm-password" type="button" aria-label="Show password">Show</button>

Screen-reader comments

“I found that two buttons announcing as ‘Show password’ were present on the page which when selected updated to read as ‘Hide password’. The label of each button was duplicated but related to different password fields. It was not immediately clear when situated out of context which button related to which password field potentially leading to the user making an incorrect selection. Although I was not personally affected in this instance some screen reader users may become confused. Giving each button label unique content will enable all users to make an informed selection both in and out of context.”

Solution

Ensure that labels are descriptive enough for users to identify their purpose and to which content they relate. The label for each ‘show’ button should inform users of screen reading assistive technologies to which field they relate. The second button should have an ‘aria-label’ value of ‘Show re-type password’ for example.

[dav-idc]

This issue has been assessed to not be a high-severity accessibility concern. It only meets 2 of our 3 criteria for a high-severity accessibility concern.

• There is reasonable evidence that it makes it difficult or impossible for some people to complete certain tasks. ✅ The evidence:
  • It is related to a WCAG level AA failure.
  • It was assessed in an external accessibility audit as a 'high' priority accessibility concern.
• It appears to affect the accessibility of a piece of critical infrastructure (GOV.UK One Login). ✅
• There is no blocker to individual service teams efficiently resolving it on their own, and it should be a fairly easy fix. ❌

As such, this will not be flagged as a high-priority issue.

We plan to reach out to the One Login team soon, to inform them of the accessibility concern and how it affects their service.

In the coming weeks we will investigate whether it fails WCAG level AA criterion: 2.4.6 Headings and Labels.

[dav-idc]

Hey @claireashworth, I'm thinking for this DAC audit ticket that the best thing to do might be to just add guidance to the 'passwords' component for now. We might have a show/hide password component variant in the future, but for now we don't.

I'm thinking it could be guidance added to the end of the 'Hide passwords by default' section?

Thinking it could look something like this:

Hide passwords by default

Users might be in a public space when entering or creating a password, so you should hide passwords by default.

To help users meet your password constraints and prevent mistyped passwords, you can:

• let them see their password if they want to
• show the last typed character of their password
• make them enter their password twice and automatically compare them

When there are two or more password fields on a page, the 'show' and 'hide' labels for each password input need to be different. For example, for an input labelled "Password" the label could be "show first password". And for a second input labelled "Re-enter password" the label could be "show second re-entered password".

[claireashworth]

When there are two or more password fields on a page, the 'show' and 'hide' labels for each password input need to be different. For example, for an input labelled "Password" the label could be "show first password". And for a second input labelled "Re-enter password" the label could be "show second re-entered password".

Yes, this seems like a good plan to me. A couple of minor tweaks suggested below:

When there are two or more password fields on a page, the 'show' and 'hide' labels for each password input must be different. For example, you can label the input "Password" as "show first password" and label the second input "Re-enter password" as "show second re-entered password".

[dav-idc]

Works for me, yep! Do we want to go ahead and just make a one-off PR for this piece?

I'm unsure how to approach, because it's not technically related to WCAG 2.2, but it is a guidance update for accessibility. It also seems like something we could easily merge and check off as done rather quickly.

[claireashworth]

Yes, it's a simple change for now. We can do further reviews and changes if we amend the component or make an addition. I'd like @calvin-lau-sig7 to have final sign off as the site's content owner.

[dav-idc]

I've opened a PR for this (which i think is the next step), and noticed that some more contextual info is needed. So I've also added a draft of some info on 'what exactly is a show/hide password button?'

• https://github.com/alphagov/govuk-design-system/pull/2861

[calvin-lau-sig7]

Thanks both! I've put in an edit suggestion and comment. Overall, I'm hoping we can find a quicker/simpler/lazier way to setup the context for these messages.