Steve Lee also mentioned this issue and it really can help to see what has been written as a password when having to use particularly long and complex ones that have both numbers and capitals and even symbols etc.

I think this is a new requirement though, as 3.3.7 is essentially asking that people don't have to enter passwords.

As COGA, we recommend that there should be a feature that is a toggle that says “show password/hide password” that enables the user to see their password as they enter it. At the same time, this is something that should be in the understanding document. This is technically not a cognitive function test, which is what the SC is about.

If added to the understanding document, it should clearly be added as a note that makes it clear this is not required to pass the SC - a best practice/suggestion

I've added PR #1940 as a draft.

Personally, I think it is a new requirement and doesn't belong in this document, but we'll put it to the group.

Also I can't see it otherwise than that it is a new requirement, a good one though

I could be persuaded to see the addition of this as a "mechanism [...] to assist the user in completing the cognitive function test", looking at it under a certain light. still doesn't help in terms of users needing to remember their actual password etc, in isolation, but at least it removes the need to then also remember in the very immediate/short term "which characters have i already typed in?" or "did that paste command actually paste it correctly?"

i.e. not a change to the normative wording, but just needing to be mentioned and explained. question is though, would a site that JUST offers this in isolation pass the SC? and conversely, would a site that DOESN'T offer this fail the SC? (i'd strongly argue that the answer to both of these is no, so feels more like a best practice/nice to have that should be mentioned ... otherwise, need to start building a cascade of requirements - "at least two of these are implemented:" or something)

The text in the PR is:

Another factor that can improve the chances of success for people with cognitive disabilities is being able to see the password as it is typed it. Password visibility is not a requirement of this criterion, but a good way of reducing the cognitive load, so including a feature to optionally show the password is very helpful.

I think that aligns with "just needing to be mentioned and explained".

Update: COGA are doing to take a pass at the wording prior to adding.

Thank you for your patience with our review. I've added this to the survey:

COGA (special thanks to Abi James and John Rochford) created the proposed adjustment to the current language in the pull request:

"Another factor that can contribute to the cognitive load when authenticating is hiding characters when typing, such as in a password field. Providing a feature to optionally show a password can improve the chance of success for people with cognitive disabilities or those who have difficulties with accurately typing. However, this support mechanism on its own does not remove all of the cognitive task when transcribing characters."

Our concerns with the current PR, which the proposed language above addresses:

1. After re-reading the functional definition of a cognitive function test (https://www.w3.org/TR/WCAG22/#dfn-cognitive-function-test), we realized that transcribing characters is very clearly included as a cognitive function test.
2. To say that "Password visibility is ... a good way of reducing the cognitive load, so including a feature to optionally show the password is very helpful" minimizes the severity of the impact for some individuals. We are concerned some may read this to think that this type of support may be sufficient to support all individuals who experience difficulty with transcription.

Hi Rain,

Reading this (and the original proposal), I think they both confuse the requirement a bit. I'm going to suggest this in the meeting:

Another factor that can contribute to cognitive load is hiding characters when typing. Although this criterion requires that users do not have to type in (transcribe) a password, there are scenarios where that is necessary such as creating a password to be saved by a password manager. Providing a feature to optionally show a password can improve the chance of success for people with cognitive disabilities or those who have difficulties with accurately typing.

creating a password to be saved by a password manager

this seems related to account creation scenarios, rather than authentication/login scenarios that this SC addresses

@patrickhlauke - indeed, it is a scenario where you might type it in, rather than being part of the auth flow. This whole paragraph is separate to the requirement.

Request to slightly update Alastair's proposed text:

Providing a feature to optionally show a password can improve the chance of success for people with cognitive disabilities or those who have difficulties with accurately typing.

to

Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.

so that we don't accidentally imply that this will solve the issue for everyone.

I believe this thread has missed my original intent.

Things like transcription errors, cognitive load, etc all rely on a before and after - meaning that the user has to know what was typed (or paste in for them, or submitted for them) and compare it to what should have been typed (pasted, etc.). If the login relies on the users ability to "compare" it is by definiton relying on cognitive function. This cognitive function is above and different than the function test to "remember". To be able to "compare", the user has to be able to see or remember what was typed (pasted, etc.) with what should have been. If at first the app doesn't supply both, then the cognitive test is blocked (prohibited) and fails. And then secondarily, without them being both diplayed, the users has to do a second cognitive test to compare the "supposed password" to what the may or may not remember to have typed in correctly (pasted in correctly, etc.). In others words, there are two sequential cognitive test, and without both passwords being displayed, is impossile to complete without the ability to "compare".

So it may well be a new requirement.

phil, comparing passwords sounds like a step in registration (enter your new password, then enter it again just to make sure), but this SC is scoped only to authentication (i.e. login)

Its about "comparing" what was typed in with what should have been typed in. User can't compare if they can't see both. Applies also to BOTH the registration step (comparing new passwords typed in twice) as well as the log-in step (comparing the typed or pasted in pasword to the required/valid password). So not being able to display the passwords in the requistration step would also fail the (new?) SC. Not being able to display the "about-to-be-submitted" password would fail the (new?) SC.

but the point of the SC is not having users having to transcribe/compare things, and they wouldn't normally need to check that what was pasted in is actually correct - the assumption is that pasting will work without messing things up?

So it may very well be a second SC. After the user is enabled to "paste in", and it fails, how will the user know why it failed if they can't see what was pasted in for them (or they typed in) without being able to see it. That is the cognitive test that is blocking a lot of users.

I don't have any study data, but the feature to "show password" was not added for disability reasons, but more of a general usability / enabling more users to be able to successfully log-in, debuging issues, etc. The source of log-in failures are almost impossible to know for sure without being able to see what was typed/pasted it. Many help desks are dealing with, "I swear I typed in blah blah blah", but can't prove it without a video / keyboard recording, etc.

oh, and the test to "enter your new password, then enter it again just to make sure" is a test to ensure a higher probablilty that the user is in fact remembering and typing in their desired password. This helps eliminate typing mistakes, typos, cognitive ability to remember it long enough to type it correctly in twice. When it fails to match for anyone, with a disability or not, and there is no "show password option" the user has no choice other than to type them in twice again and hope they get it right this time.

The ability to show what they typed in enables the user to determine their mistake. That enablement is the SC I'm advocating for.

not come across login scenarios that force users to enter the password twice. this is usually only something you find in registration flows, not authentication flows. hence out of scope for this SC, but would suggest starting a separate/new thread suggesting a new SC (for 2.3?)

if a paste/autocomplete failed, it's either because the site didn't actually allow a proper paste and instead somehow cuts/modifies what was pasted (so would fail 3.3.7) or because the password the user had stored in their browser/password manager was wrong (which is outside of the scope of 3.3.7). so i would say this needs fleshing out more into a separate SC if you want to make it a hard requirement. as the core of this SC tries to essentially avoid users having to perform cognitive tests (including transcribing or comparing things), it probably would be odd to have a failure here for not allowing the comparison to be done since the comparison would not even be necessary if the SC was satisfied correctly.

Opened #2180 becasue the paragraph added by #1940 to close #1912 does not address the issue of making authentication accessible to more users:

[EDITOR: Removed the rest of the comment as it duplicates #2180, and I don't want the same discussion in 3 places.]