Show password fixes

[andysellick]

What

• adds an aria-label to the 'show/hide' button so that assistive tech reads it as 'show/hide password', which makes more sense out of context

Why

• an accessibility audit revealed that the button out of context ('Show') isn't descriptive enough for users of assistive technology, and should be 'show password' instead, but we don't want to change the design because that text is too long on mobile
  Trello card: https://trello.com/c/lNkwruEi/749-fix-accessibility-issues-raised-by-dac

Visual changes

None.

Needlessly detailed further background reading

Problem

Our password button says 'show' or 'hide', which has been highlighted as an accessibility fail because the button out of context doesn't make sense.

Non-Descriptive Labels (AA)
Labels did not sufficiently describe the topic or purpose of the content.
WCAG Reference:
2.4.6 Headings and Labels (Level AA)

The solution proposed by the audit is to add the word 'password' as a visually hidden field. Sighted users would still see the button as 'Show' but screen reader users would hear it as 'Show password'. EDIT: we've chosen to go with a different solution due to all this stuff below here.

This works in English but other languages may have problems, specifically:

• the word 'show' may be different by itself compared with when it is immediately followed by 'password'
• we can't be certain what order the words should appear in, 'show password' in other languages might translate as 'password show'
• 'show password' might be a single word in some languages?

Since this would be in a separate element we need to keep the words 'show' and 'password' separate in the translation file.

Languages on GOV.UK

We should consider the impact this will have based on the languages it might be translated into. Starting with the totally unscientific approach, here are the largest translation files in government-frontend:

• en.yml English
• ar.yml Arabic
• ta.yml Tamil
• ru.yml Russian
• cy.yml Welsh
• be.yml Belarusian
• hr.yml Croatian
• mt.yml Maltese
• uk.yml Ukrainian
• sl.yml Slovenian
• gd.yml Gaelic

...but this text is used in elements like components and navigation, not published content.

As a more scientific approach (thanks @kevindew) this is a breakdown of what’s in Publishing API by locale:

irb(main):004:0> Edition.with_document.where(content_store: :live).group("documents.locale").order("COUNT(*) DESC").count
=> {"en"=>695250, "cy"=>7801, "ar"=>3619, "es-419"=>3450, "ru"=>1454, "hi"=>1286, "zh"=>1156, "ur"=>1071, "pt"=>1071, "fr"=>673, "ja"=>521, "es"=>448, "ro"=>369, "uk"=>343, "it"=>299, "pl"=>298, "zh-tw"=>290, "de"=>264, "lt"=>238, "ko"=>222, "th"=>205, "bg"=>195, "bn"=>193, "so"=>189, "he"=>185, "el"=>181, "cs"=>178, "lv"=>173, "uz"=>167, "vi"=>159, "sq"=>158, "tr"=>145, "id"=>114, "si"=>113, "ta"=>112, "sr"=>104, "fa"=>83, "pa"=>63, "hy"=>45, "be"=>38, "gu"=>35, "et"=>24, "hu"=>24, "nl"=>21, "kk"=>18, "dr"=>16, "az"=>15, "sk"=>13, "pa-ur"=>5, "hr"=>4, "sl"=>4, "da"=>4, "no"=>4, "ps"=>4, "sv"=>3, "mt"=>3, "fi"=>3, "is"=>3, "gd"=>2, "zh-hk"=>2}

Top results are:

• "en"=>695250 English
• "cy"=>7801 Welsh
• "ar"=>3619 Arabic
• "es-419"=>3450 Spanish
• "ru"=>1454 Russian
• "hi"=>1286 Hindi
• "zh"=>1156 Chinese
• "ur"=>1071 Urdu
• "pt"=>1071 Portuguese
• "fr"=>673 French

A few hits of Google Translate later...

(note that I've had to put some filler text into some of these columns because both my local editor and github automatically changes some of the non Roman character set words based on the words that follow them, so please ignore AAAA in the following table. I don't know why it's doing this, I suspect it's changing the word order because they're right to left languages)

Language	Password	Show	Show password	Hide	Hide password	Ordered like English
English	password	show	show password	hide	hide password	Yes
Welsh	cyfrinair	sioe	dangos cyfrinair	cuddio	cuddio cyfrinair	Yes
Arabic	كلمه السر	AAAA تبين	AAAA عرض كلمة المرور	AAAA إخفاء	AAAA اخفاء كلمة المرور	unsure
Spanish	contraseña	show	mostrar contraseña	esconder	Contraseña oculta	No
Russian	пароль	Показать	показать пароль	Спрятать	скрыть пароль	Yes
Hindi	पारण शब्द	प्रदर्शन	शो पासवर्ड	छिपाना	पासवर्ड छिपाएं	unsure
Chinese (simplified)	密码	展示	显示密码	隐藏	隐藏密码	Yes
Chinese (traditional)	密碼	展示	顯示密碼	隱藏	隱藏密碼	Yes
Urdu	پاس ورڈ	AAAA دکھائیں	AAAA پاسورڈ دکھاو	AAAA چھپائیں	AAAA پاس ورڈ چھپائیں	unsure
Portuguese	senha	mostrar	mostrar senha	ocultar	esconder a senha	Yes
French	le mot de passe	Afficher	montrer le mot de passe	cacher	masquer le mot de passe	Yes

Observations

• I am in no way an authority on any language
• the Spanish for 'show' is 'show' unless it's in front of 'password' in which case it's 'mostrar'
• something similar appears to happen for 'show' in Chinese, and in French but also for 'hide'
• most of the languages appear to have 'password' unchanged at the end of the sentence for both, only Spanish changes the order for 'hide'

Objective recap

• We want a button that says 'show' or 'hide' for sighted users.
• We want a button that says 'show password' or 'hide password' for screen reader users.
• We want the button to make sense.
• We don't want a button that says 'password' for sighted users.

Solutions

aria-label, as suggested by the mighty @injms

[injms]

Apologies for sounding like a broken record on this. I'd like to question again why the word 'password' in 'show password' or 'hide password' needs to be hidden from anyone.

My thinking is that things should be available whether you use a screen reader or not - for example, the new guidance on image alt text is based on getting information to everyone regardless of how they access it. I think the same should apply for form fields - so having the full phrase will make it easier for everyone to use.

[andysellick]

@injms I've tried pushing back on the design on this but to no avail.

Herewith a better response.

You're not sounding like a broken record, thanks for raising this. I agree on your point that things should be available whether you use a screen reader or not, but that's precisely what this change is designed to fix. Screen reader users have a unique problem - they can access the button without any context, which is why they need the more verbose text.

However, sighted users also have a unique problem - page layout. They already have a visual cue to associate this button with the password (they can see the label, they can see the button is 'attached' to the input) but that has to fit into a narrow space. We could push the button down beneath the input on mobile, but that brings in new problems, like whether it still looks like a button.

I can honestly see the argument on both sides, but I think this is the simpler solution, and it's the one DAC themselves suggested, who raised the issue in the first place.

[injms]

A thought for another time is whether having the button on the far right is a good thing for people who use screen magnifiers - the accordion component has just been updated to move the show / hide control to the left for that reason, so I wonder if this will need tweaking in the future for similar reasons.

[injms]

To misquote Voltaire, the perfect is the enemy of the good. This is really nice improvement that makes things better and should be in front of people as soon as possible.