New Failure Technique F109 for Issue #1918 Accessible Authentication needs better techniques

[dan-hw]

• Created new failure technique F109 for forcing transcription of individual password characters, including some examples of failures I've seen in the wild
• Linked out to this new failure technique from the Understanding pages for SC3.3.8 and 3.3.9

#1916

[dan-hw]

changes made

[patrickhlauke]

thanks @dan-hw :)

[mbgower]

Thanks for putting this together @dan-hw .
Generally speaking, failure techniques are the toughest to write, as if one meets the test, it is a clear failure of a requirement. As such, I suggest it might make sense to split these out into separate failures, so that they can each have very specific test steps that lead to consistent outcomes.
I haven't looked carefully enough through this technique yet to see if that is the case here, but at a glance, I'd say I want 'prevent pasting' and 'require specific characters in a string' to be two different failures.

[dan-hw]

Thanks @mbgower. This is a helpful clarification that's made me think through exactly what the failure is here.

I suggest it might make sense to split these out into separate failures, so that they can each have very specific test steps that lead to consistent outcomes. I haven't looked carefully enough through this technique yet to see if that is the case here, but at a glance, I'd say I want 'prevent pasting' and 'require specific characters in a string' to be two different failures.

I agree that 'prevent pasting' is a separate failure from what we are focussing on here. (Let me know if it's helpful for me to add another failure technique for this under this PR or a separate one - happy to do so). I was aiming to focus this technique on 'requiring specific characters in a string'.

I've amended that in the commit above to make that focus clearer. I've also attempted to make clear that the failure is really about forcing users to enter the password in a different format from which it was originally created. I.e. Even if you are able to paste text into the fields in question, the fact that the password input is split across multiple fields in a way that it wasn't when the password was set up, means that password managers (or similar) can't take advantage of this ability to paste. This encompasses examples other than the "Enter the 2nd, 6th and last characters of your password", such as "A password input fieldset composed of elements that requires a user to select each character of a fixed-length password from individual dropdown fields". Edits gratefully received

[mbgower]

Looks good!

[mbgower]

(Let me know if it's helpful for me to add another failure technique for this under this PR or a separate one - happy to do so)

It'll be faster to just keep this one separate, I think. The other one is going to be pretty fast to do once we get this one approved. I think we probably want to cover both the username and the password inputs?

Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing pasting in login inputs

The only technique I know for this is

onpaste="return false;"

Tests

Procedure

For each input in a login process:

1. Check if the user is prevented from pasting.

If step #1 is true, then this failure condition applies and content fails the Success Criterion.

[dan-hw]

Committed changes

[awkawk]

There needs to be some context-setting before the test bullets, for example, For each input field designed to accept a password...

[awkawk]

Is this title just saying "Failure of .... due to requiring manual entry of passwords"? Would that be simpler?

[alastc]

Suggested change

<p>Requiring users to authenticate by entering a password or passcode in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authenticaton methods are available). If a user is required to enter individual password characters across multiple fields, in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password or passcode. This means users cannot avoid transcription, resulting in a <a href="../../understanding/22/accessible-authentication.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>

<p>Requiring users to authenticate by entering a password (password, passcode, passphrase or any string of characters the user has to remember or record to authenticate) in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). If a user is required to enter individual password characters across multiple fields, in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password or passcode. This means users cannot avoid transcription, resulting in a <a href="../../understanding/22/accessible-authentication.html#dfn-cognitive-function-test">cognitive function test</a>. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.</p>

[alastc]

I'm closing this PR as there are conflicts I can't resolve.

Nothing wrong with the work, it's just because it's an external branch.

We can continue over in #3174