Assigned to John Rochford (@JohnRochfordUMMS) https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

Surveyed: https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017/

Closing since the pull request is in place. Comments go there now.

https://www.w3.org/TR/webauthn/ and https://www.w3.org/Webauthn/is the web authetification that is refered to in the techneques . Conforming to it enables complete conformance

This issue is closed - discussion should be over on the pull request.

Dividing into two
1.User Authentication Methods: A mechanism is available that user authentication does not rely upon a user's ability to memorize information; recall information from memory; speak; or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page.
techniques involve being able to reset via an email sent with a new link , or google log in or bimetoics, smart card or allowing browser to rember your password etc.

An alteritive could be to just require A mechanism is provided that enables the user to retrieve or reset their user authetification details

2. Users are not require to memorize character strings, including memorizing correct spellings; or perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or speak unless it is essentisal for the main function of the site

An alteritive could be to just require A mechanism is provided that enables the user to retrieve or reset their user authetification details

are there many examples of sites that do NOT provide you with a "forgot your id / forgot your password" type functionality? i find this to be almost ubiquitous when it comes to sites that allow account creation and login. is the use case for this SC in that form strong?

My bank would be an example. if you get the poassword wrong 3 times you need to drive to the bank to get a new one. but yes, it is not a great option - but we were trying to think of ways to reduce the burden whilst increasing awearness. I am not realy pro that solution myslef

@patrickhlauke I personally believe that we won't get acceptance of an SC (option 1) that can only be fully met by the user of things like smartcards or 3rd party authentication (see my comment below). I believe that at least one of the many arguments against option 1 will be "undue burden".

User authentication on most websites/services rely on the use of a username/password combination as at least one option. Option 2 was proposed (not sure by who), and reworded by me, as an additional SC to improve the accessibility of the cognitive-unfriendly username/password method. Password reset/retrieval is essential for people with cognitive impairments who have impaired long-term memory.

I agree that this is almost universally done, but that ensures that at least this proposal will not be rejected because of "undue burden". Is it inappropriate to propose an SC that has clear cognitive accessibility benefits just because it is more or less standard current practice (and also benefits all users)? I am not sure.

The accepted understanding is that user authentication depends on at least one of the following:

1. Something you know (eg. a password);
2. Something you have (eg. a smart card). arguably Google and Facebook sign-in falls into this category as you have to have a Google or Facebook account;
3. Something you are (eg. biometrics such as a fingerprint).

The "something you know" is the biggest cognitive accessibility challenge because, by default, users have to recall memorized information. In practice, there are widespread "assistive technology" solutions to support people with impaired memory (and the rest of us) such as password managers (e.g. LastPass). It is not possible to propose an SC that directly addresses option 1, but "A mechanism is provided that enables the user to retrieve or reset their user authetification details" is something that can help a person who cannot remember their login details.

The "something you have" option will only provide accessible user authentication to those people who have the required thing(s) (e.g. a smartcard or a Facebook account). I don't believe that it is acceptable to draft an SC that can only be met on the assumption that users have an unspecified something that proves their identity.

Similarly, the "something you are" option usually depends on device-based biometric sensing which cannot be presumed to be available to all users. I do not see how those providing the content can claim to meet an SC on the assumption that users will be able to biometrically prove their identity. In almost all cases, the content authors will have no idea of which users may be able to use device-based biometric identification.

So overall I do not see how the current "Option 1" SC proposal can meet the strict requirements that an SC needs to meet.

I am not convinced that it is possible to draft SC text that solves all of the cognitive accessibility issues associated with cognitive accessibility. Do any WCAG SCs provide such comprehensive solutions to complex processes like user authentication?

In the spirit of addressing avoidable cognitive accessibility barriers that occur as part of user authentication procedures, I offer the following proposal:

A user authentication method is available that does not rely on a user's ability to correctly identify and enter numbered characters from a memorized character string.

NOTE: Some user authentication methods ask a user to, for example, enter, the third, sixth and seventh characters from a word that they have previously chosen. Such mechanisms require users to be able to:

a) correctly locate the correct characters by counting from the beginning of the word;

b) hold the located characters in short-term memory long enough to correctly enter these characters;

c) complete the task without the cognitive resources involved in step a) and step b) interfering with each other.

Such methods present significant barriers for many people with cognitive and learning disabilities. e.g.:

• users with learning disabilities such as discalculia may be unable to accurately perform step a).
• users with impaired short-term memory may be unable to perform step b).
• users that have impaired working memory may be unable to simultaneously perform both step a) and step b).

This SC can be met if such awkward procedures are not used or, if such a method is offered, an alternative method is offered that can be used instead of this procedure.

@mapluke [chair hat off] I agree with Mike here. This brings up the question of what is an 'acceptable cognitive load'. We have to find what that means as I don't think that is clear (and not easy to define). If it is acceptable for COGA purposes that a person can perform task type A, but not type B - then by all means we can look at methods to support task type A - however, every human task has some cognitive overhead.

I also wonder about a 'one size fits all' approach to defining working or acceptable solutions - as this area more than most - is a subjective experience. So we need to be careful about what we define and flexible in what we accept.

On another point, we cannot simply remove all cognitive overhead/load from any task relating to consciousness and I just don't think that should be the goal. We could be doing a disservice to many who maybe just need more usable solutions. So from what I see with many COGA type issues - the actual barriers may not be cognitive issues per se but usability issues.

Based upon feedback from AG members, the COGA Task Force suggests the following revision. Are you content with it? If not, we can have a call with COGA members to discuss. Or, you can just provide any comments to the SC 23 discussion on GitHub. Thank you.

The proposal is to divide SC 23 into two separate success criteria.

SC 1

User Authentication Methods: A mechanism is available that user authentication does not rely upon a user's ability to memorize information; recall information from memory; speak; or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page.

Techniques involve being able to reset authentication credentials via an email message sent with a new link; and/or use third-party authentication, biometrics, a smart card, or allow a browser to remember a password, etc.

SC 2 we could merge this with on task completion -Issue 21 #21 (@awkawk - can you merge this what do you think_

Users are not required to memorize information, character strings, and correct spellings; or perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or speak, unless it is essential for the main function of a web site.

I'm afraid I think that thus proposal is rather a mess. It fails to accurately capture the potentially acceptable stand-alone proposals that were made during the COGA call, and instead tries to merge them into text which is never likely to be accepted e.g. "beyond the mental processes that are required to use a simple web page".

I am confuced mike, You were on the call and I copied this from John's summary to the list. please email me the language that you remember.

@mapluke @JohnRochfordUMMS
Can we just have:
Successfully completing tasks does not rely on users memorizing information character strings, and correct spellings; speak; or perform calculations, such as correctly identifying and entering numbers and letters from a character string or memorizing information presented in the current, or previous, user-interaction dialog steps; unless it is essential for the main function of a web site.

It addresses dialogs, authertification and capture

Ah I see, you are suggesting "A user authentication method is available that does not rely on a user's ability to correctly identify and enter numbered characters from a memorized character string"

What about getting the address right of your childhood home? I think that is included
the problem is people can include too many failures such as sending a string to your phone that you type in. That uses working memory but very few people realize that.

@JohnRochfordUMMS are you OK with this?

What about a simple requirement that users can recover their lost authentication? For a 2.1 that seems reasonably doable.

User Authentication Methods: A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

@DavidMacDonald I believe that this simple requirement is easily doable (i.e. no undue burden) and frequently done. There are also numerous existing well proven techniques to meet such an SC. Such a requirement should not be buried as a technique for the current complex and very questionable #23 proposal.

How about the following
It give two options but one of them must be doable by people from coga groups

For user authentication one of the following is true
-A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.
-A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.

It needs some work but does the gist meet all our concerns? Many sites already conform to the second options (as @DavidMacDonald and @mapluke pointed out) but this requires it to be simple. The point of adding the first option is:

• if people can not have a simple reset option fro security reasons, then another way to conform is available
• it makes it clear what the issues are, and people can see that doing both is better. Also

I am in an optermistic mood. If there are no objections I will update the wording with the last proposal

For user authentication one of the following is true

• A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.
• A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

@DavidMacDonald is that a wording change? It looks the same to me

@DavidMacDonald, a bit of house cleaning. I removed the bit about copying, which seemed to have traction to drop. I've cleaned up some weird left over language "such as including".
I've also removed "see; hear or speak". Two reasons for this: it's a real departure from WCAG guidance to date and there was indication in the thread that a requirement for memorization was the primary issue we were trying to curtail.
That let me remove the semi-colons, and also kept this from needing to be a list within a list.

For user authentication one of the following is true:

• A user authentication method is offered where the user is not required to memorize character strings or other information, or perform calculations such as correctly identifying numbers or letters from a character string.
• A mechanism is available to reset authentication.

For user authentication one of the following is true:

• A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string
• A mechanism is available to reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string, beyond remembering basic contact information.

Note that requiring the user to remember basic contact information such as their name, current phone number or email address is not excluded by this success criteria .

NOTE: I am fine with getting rid of the second bullet and making it a tequnequ of the WG prefers it.

based on survey
Use of or any reference to password retrieval is strongly objected to - so it is removed

Katie suggested: "Accessible Authentication Methods: A mechanism is available to reset any authentication method that relies upon a user's ability to memorize or recall information.” - this is the second bullet with some required additions . However some sites can not use this becuse of security considerations, (such as my bank) SO giving them the option of the first bulet - which can be met with a card, biometrics, phone token , conforming to the W3C''s web authentication specification and other methods make it much more widely addoptable

The end of the bullet point has been removed as it is coverd else were.

Note survey results are at https://www.w3.org/2002/09/wbs/35422/SCs_April_11/results#xq10

@DavidMacDonald @mbgower your cleaner wording does not address the use cases I am afraid. For example, if you require a security question for the reset then you are typicaly baring millions of people from using the service

@lseeman this still includes the "copy information" part which was noted as potentially barring two-factor / multi-factor authentication?

also, is this still fundamentally mixing up the idea of authentication (where a user proves WHO they are, e.g. to access their personal account) and more generic CAPTCHA-style challenges (where a user proves that they are indeed a human, and not a bot)?

the latter scenario can be made a lot tighter in terms of what sites should NOT rely on. but in the case of actual authentication, sites MUST challenge the user in a way that guarantees only that particular user would be able to pass through, and saying a method needs to be there that doesn't require users to memorize (or copy) things seems incompatible with being able to provide solid authentication (or would effectively mandate that every site also invest in some form of biometric security system or similar?)

if this is indeed still mixing the two, i'd strongly urge to disentangle these two scenarios into separate SCs

the act of resetting an account would usually fall across both of the above scenarios. to request the reset, a site would generally only need a CAPTCHA style challenge (as just to request a reset would theoretically not need to check that it's indeed the user herself asking for the reset). but at the completion of the reset request, the user would then be sent an email, text message, or similar (to their registered email address, phone number, etc) which then would require them to either follow a link and/or copy and enter a one-time passphrase/key - and this is the part where copying should be allowed, and it's the part that simply can't simply do away with "copying", as the point here would be that only the individual in question would have access to that particular email address/phone number, and copying a confirmation code would be the act of proving that they indeed are who they claim they are.

@lseeman, as Patrick mentioned, you added back in the "copy" concept. you also added in the nonsensical words I took out in the first bullet. Please tell me what is wrong with:

A user authentication method is offered where the user is not required to memorize character strings or other information, or perform calculations such as correctly identifying numbers or letters from a character string.

In regard to Katie's rewrite of the second bullet...

A mechanism is available to reset any authentication method that relies upon a user's ability to memorize or recall information.

That's an improvement, but it also doesn't prevent memorization from being part of the reset process, which seems to be paramount? So while I feel like this is progressing, I want to make sure the original desires are considered.

@patrickhlauke raises the same point I initially did last fall: this SC mixes apples and oranges. Here's my original comment to the task force:

There seem to be two matters tackled here: one covers an advanced version of CAPTCHA; the other deals with login. A test that verifies someone is a human is arguably different than an authentication process. The former in its current state is a consideration which affects all 4 principles of WCAG; while the latter need not be different in nature from any other user input – however the surrounding process may need to address non-repudiation, authentication and access control.

Any security-related SC really should address those last three matters head on: non-repudiation, authentication and access control.

Looking back over my original submission, I flagged there is an excellent paper referenced in the COGA background info called Security and Privacy Technologies. It tackles the issue differently than the original SC and clearly distinguishes between password authentication, CAPTCHA and two-factor authentication.

I believe that revisiting the recommendations in that paper may be a good exercise to make sure this SC does what you want. It covers 4 different proposed solution areas:

• w3c recommended guidelines and techniques
• ease of use ideas
• Alternative web security and privacy technologies
• CAPTCHA alternatives

@patrickhlauke @mbgower Unfortunately copying is a real barrier and the two stage authentication, although popular, means may people can not use the service. Have the two stage authentication send a web link or token works well.
For example. I do not have a visual memory. Copying accurately is close to impossible. (I think this is discussed in detail in the issue paper.)

Note it is in the original wording - ""perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or " Further copying always requires the use of the user's working memory. - One of the first things to malfunction in dementia.
Whilst I apritiate the wish to "clean up the wording" we need to address the user need and let people carry on loging in and carry on working and functioning independently as long as possible.

If copying is a real barrier, why wasn't it in the original SC language? And why isn't it listed in the considerations backgrounder (and if it is, where)?
I'm trying to understand how cutting and pasting (which requires no memory usage and avoids any transposition problem) or the direct transcription of a simple text string warrants exclusion from this SC. Please provide references. If we want to place a limit on the size of the string based on data, that's one thing. Just saying "it's a barrier" does not provide any insight.

@mbgower I think that you would like to see this two-bullet SC proposal split into two independent SCs. I've been arguing for ages that the existing two-bullet SC is over-ambitious and unlikely to be suitable to turn into an acceptable SC. What I have proposed, to Lisa and John, is that we could have two completely independent SCs:

1. Essential steps in a process can be completed without requiring a user to memorize or copy information or character strings.
   Note: This implies that where methods that rely on memorizing or copying information or character strings are used for essential steps, an alternative method to complete the step is provided that does not rely on memorizing or copying information or character strings.

This would have general applicability to any process, not necessarily to authentication processes.

2. Where an authentication process relies upon a user's ability to memorize or recall information, a mechanism that allows a user to reset their authentication credentials is available.

@mbgower I have shown you above with quotes. It is in the original SC.

" correctly identifying and entering numbers and letters from a character string" sounded to me like it was referring to CAPTCHAs (where the letters/numbers are presented as distorted or somehow obfuscated). I didn't think it applied even if the user received an email with a plain text code that they needed to copy (if on same device, simply using the OS's default COPY/PASTE) into a web form. i can understand how this could prove to be more complex if the code was presented, in plain text, in a text message / SMS on a phone device, and the user had to read it off the phone screen (or get it announced/read aloud by their phone's AT) and type it in on another desktop/laptop computer, but to me (and yes, not an expert) that seems a fairly low burden? or is there a danger that they'd lose track of which character they've already typed/where they're up to if the code is longer than a few characters?

or are we accidentally talking across purposes here, and by saying "copying" you DO mean copying in the sense of "they need to identify the letters/numbers in a visually obfuscated CAPTCHA and write them in a new text field" or similar?

@lseeman

perform calculations, such as including correctly identifying and entering numbers and letters from a character string;

Directly transcribing 4-5 characters does not involve calculation, so why are you quoting this phrase as supporting a need to eliminate "copying"? Can you not agree that "copying" was added into the SC language somewhere along the process since January? The word in this thread first occurs 21 days ago in a post by you.

Further copying always requires the use of the user's working memory. - One of the first things to malfunction in dementia.

I don't see this phrase you quote in the SC language. "Copying" never appears in the original document the task force reviewed for submission last fall, and I don't see it in the body of the SC draft.

Setting aside the minuscule amount of information on copying in any of the COGA source material, I'd like to parse this phrase. As mentioned, anyone using a desktop can cut and paste; no need to memorize anything. So any memorization requirement that may exist does not apply to any desktop user with a keyboard. Do you agree?

For situations where a user cannot copy and paste the supplied string (I assume we're talking about getting a message on a phone and copying it into a different device, for example) is your intent to require that an inability to transcribe a 4-character string be fixed into the web accessibility standard? If that's the case, please supply the supporting studies and data that make a case for this, because we are going to need a lot of persuasive metrics proving this. Show me the data.

Essential steps in a process can be completed without requiring a user to memorize or copy information or character strings.
Note: This implies that where methods that rely on memorizing or copying information or character strings are used for essential steps, an alternative method to complete the step is provided that does not rely on memorizing or copying information or character strings.

This would seem to prohibit things like entering an address in a checkout process (or pretty much any other data entry process). This is an essential step and I need to either have the address in memory or copy it. I know this was originally targeted to authentication but the language had become far too general.

@johnfoliot I understand the requirement for security and the need to comply with regulatory requirements. But I disagree that we should discount the offering of alternative methods like Biometrics. RSA tokens are as tricky for Coga users as they are for blind users but facial recognition or using a fingerprint as one of the factors should not be discounted. My bank recently reduced the number of authentication steps because so many people struggled with them that they had to significantly increase the number of staff in their call centre. I like many others had gone from being able to use the system to being locked out and reverted to calling. Finding the right balance has a strong business case so I think businesses can be persuaded.

@patrickhlauke wrote

to me (and yes, not an expert) that seems a fairly low burden? or is there a danger that they'd lose track of which character they've already typed/where they're up to if the code is longer than a few characters?

What Lisa has been at pains to point out is that this seemingly trivial task is burdensome that is what makes lack of working memory a disability - it prevents people like Lisa and me from carrying out what other people consider to be "normal day to day activities" We quickly lose track and input the wrong characters. This prevents us from being able to access really important things like bank accounts and critical services.

@jnurthen wrote

This would seem to prohibit things like entering an address in a checkout process (or pretty much any other data entry process). This is an essential step and I need to either have the address in memory or copy it. I know this was originally targeted to authentication but the language had become far too general.

Whilst many Coga users will struggle entering addresses and indeed forms in general are problematic - there are usually tools and work-arounds available to help and whilst screwing up your address may mean your parcel goes astray (- let's hope the neighbours are honest) it's not the same as being completely locked out of a service for failing to authenticate.

We need to be clear that this SC applies to Authentication - which TBH I thought it did as that is the name of the SC.

@mbgower some reading on copying

Clinical Assessment, Computerized Methods, and Instrumentation
By F.J. Maarse, L.J.M. Mulder, A.N. Brand, A.E. Akkerman
Particularly relevant is chapter 1:
Computerized measurement of implicit short term memory retention in a digit copying task. There is reference to brain injury in here.

From a neuropsychological point of view, it can be hypothesized that subjects with
brain dysfunctions, as Brouwer (1985) suggested for head injury victims, suffer from
mental slowness because of a decreased trace strength of the connections between nodes
of knowledge and a reduced redundancy of memory representations. Consequently, we
expect memory impaired subjects to have slower IRI’s and we expect their repeated digit
string IRI to decrease slower in comparison to the normal sample. The results of ongoing
studies at this moment point in this direction (Lafosse, et al., 2000).

The repetition of a digit string could
facilitate mental routes creating memory traces. These become stronger each time they
are used. Consequently, frequently activated memory traces are stronger than seldom
activated traces. This could explain the observed interaction effect between the variables
‘repeat’ and ‘trial number’ under investigation, indicating that, with advancing test trials,
the IRI of the repeated digit string decreased in comparison with the IRI of the nonrepeated
strings.

So that repeated use of strings of numbers reduces the IRI which would seem to support what we are arguing that random strings are harder than strings that have been used repeatedly therefore making it more important when it comes to tasks like authentication.

https://books.google.co.uk/books?id=lcJ4AgAAQBAJ&lpg=PA10&ots=Ae6TjF6o0E&dq=copying%20and%20the%20use%20of%20short%20term%20memory&pg=PA1#v=onepage&q=copying%20and%20the%20use%20of%20short%20term%20memory&f=false

mbgower some reading on copying

Thanks, Neil! I'll dig into that.
Ultimately what I'm trying to get clarity on is whether there is a reasonable string limit we can recommend (or similar tactic). Thinking of the parallel with minimum contrast, I think the question needs to be addressed of whether the SC can specify minimum levels for things like transcription of characters, which may allow current security practices to be modified but continued. Minimum contrast assumed users for whom the minimum was insufficient would resort to ATs to fill the gap. Is that feasible in this space?
Hopefully this material can provide some guidance, as can additional comments.
You mentioned RSA tokens. Wanted to point out that there are software-based tokens that are screen-reader compatible now. Similarly, if such a software-based token (which is what would be potentially covered under web guidelines) facilitated a copy and paste mechanism, would that not overcome this issue specific issue? For example:

Pseudo technique 001: Providing a verification code which does not require manual entry
Any re-authentication that involves the transmitting of a verification code includes a method for user input which does not require manual entry of the verification code. Such methods could include a Copy command, which allows the user to paste the code directly into a confirmation field.

@jnurthen I think that it would be pretty straightforward to add an exception that excluded key personal information like name, address, phone number and email address from this proposed wording.

From a cognitive perspective, it will be essential to prevent users only being offered a method that relies on them remembering things that are less familiar to them - such as something mentioned in an earlier step in a process. Many users with memory problems will fail such steps.

@patrickhlauke When I originally drafted wording that now appears as "correctly identifying and entering numbers and letters from a character string", it had nothing to do with CAPTCHA. I was trying to address the increasingly common, and incredibly demanding, task of being asked to enter the third, seventh and eighth characters of a user-supplied memorable word or phrase.

I think there is a strong case for ensuring that there is an alternative option provided that is different to this challenge. Successfully completing such a challenge calls on a complex mix of keeping the details of the challenge in short-term memory, accurately recalling the correct spelling of the word or phrase, being able to identify which is the seventh character of this recalled word or phrase (which calls on the use of working memory), holding in short-term memory the retrieved character until it is entered, and repeating all of this for each of the (say) three characters requested. Nobody with even mild levels of impaired short-term or working memory could complete such a task without at least writing down the personal word or phrase (thereby compromising the security of the method).

I proved that I was not very successful in drafting some words to clearly describe the method that I was targeting. Maybe someone else can clearly explain it so that it cannot be read as referring to CAPTCHA.

After the coga call last night I made two changes.

1. I added the exception if this is not possible with current legislative requirments (Jons request on wcag)
2. I changed an "and" to an "or" however this then required more of a rewite to "on of the following, becues otherwise it was ambigues

Hi,

I think "being already logged in to third-party authentication services (e.g., OAuth, Facebook, etc.)." need to be changed to "being already logged in to a confirming third-party authentication services (e.g., OAuth, Facebook, etc.)." because if I add for example a github connect feature but github authentication is itself not accessible my user will still be stucked

Hi @NeilMilliken,
I finally got a chance to read through the chapter you referenced on digit copying.

My understanding from reading this study is that all subjects, including those from nursing homes, were able to complete the copying of 32 strings of 5 digits each . The study measured the differences in Inter-Response Intervals (IRI) to make some conclusions on how subjects' abilities to focus on tasks affects time to complete the task, as well as the difference it made to the task based on the repetition of strings in the 5-digit sequences. However, one of the unwritten conclusions/assumptions of the study seems to be that everyone was able to complete the task.

So I find myself going back to my original question: do we have any information on the length of strings that can be successfully copied by a range of individuals with cognitive disabiltiies? If we find that the simple transcription of 6-8 characters is achievable then that can form the information on limitations on copying that can be specified here to offer guidance for two-factor authentication methods, etc.

As it stands, we have a requirement to disallow transcribing characters that seems to be based on no data.