- From: Rain Michaels <rainb@google.com>
- Date: Mon, 19 Jul 2021 09:53:07 -0700
- To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CAJO5Hut0hpM-0G7HJJzkU1jVhL0HK8+8jZfjniZaVMfCjVXTsQ@mail.gmail.com>
Update on the accessible authentication show password (#1912) issue: Abi and John R worked with Alastair to understand the specifics of this issue. Abi drafted an excellent revision to Alastair's proposed language, which I have submitted to the issue on Github (#1912) <https://github.com/w3c/wcag/issues/1912#issuecomment-882699239> and added in a survey response <https://www.w3.org/2002/09/wbs/35422/wcag22-accessibile-auth/>. Warmly, Rain On Thu, Jul 8, 2021 at 3:52 AM Steve Lee <stevelee@w3.org> wrote: > Thanks for that Abi, it is really helpful. > > I have one small comment > > > Allowing a user to paste a password with no option to see a password. > So far this has been agreed as sufficient to remove the cognitive > function task of a password field as a user is not editing the password > and the current success criteria wording is acceptable. > > Perhaps once case makes it insufficient - if the user doesn't have the > password in paste-able form but wants to see what they enter to avoid > errors and allow correction. I personally find it *becomes* a coga > challenge if I realise I hit a wrong key and have to figure which one it > was. > > Is that a valid coga requirement? > > Steve > > On 07/07/2021 19:12, Abi James wrote: > > Hi Rain and Lisa > > > > I would like to summarise this discussion into 4 scenarios which I think > > cover the options we are discussing: > > > > 1. Allowing a *user to control and toggle*between showing a password is > > sufficient *on its own* to remove the cognitive function task of a > > password field. The current success criteria wording would be > > acceptable if this was a sufficient technique. However, I don’t > > believe seeing a password would remove all cognitive function as > > there is still the recall and transcription challenge. > > > > 2. Allowing a user to paste a password *and/or* toggle to see a > > password is sufficient to remove the cognitive function task of a > > password field. This option allows organisations to add the toggle > > if it is appropriate. The current success criteria wording would be > > acceptable and the wording proposed below recommends the toggle as > > a best practice. > > > > 3. Allowing a user to paste a password *with no option *to see a > > password. So far this has been agreed as sufficient to remove the > > cognitive function task of a password field as a user is not editing > > the password and the current success criteria wording is acceptable. > > > > 4. *Require*that a user must be able *to control and toggle* between > > showing a password *in addition to* allowing mechanisms to assist > > the user in completing the cognitive function test. This would > > require the current success criteria to be reworded and require > > exceptions to be considered, such when it is technical not possible > > to implement or there are security regulations that do not allow it. > > > > As I have outlined in previous emails, scenario 4 with the tighter > > requirements specifically for password fields would risk many > > organisations removing the whole success criteria from their > > requirements as it breaches their security policies. But we need > > evidence the wider community (e.g. government organisations, financial > > services, e-commerce) to clarify if they would find the extended success > > criteria acceptable. Also, organisations are already working to > > implement WCAG 2.2 requirements so changes now will cause difficulty > > with implementing the success criteria who are proceeding on the current > > requirements. > > > > Please recognise I strongly support the accessible authentication > > success criteria and am very keen to get it implemented to remove > > barriers such as Capthas and improve alternative means of authentication. > > > > I can try to make the first 30 minutes of tomorrow’s call if this is > > going to be on the agenda. > > > > Abi > > > > *From:*Rain Michaels <rainb@google.com> > > *Sent:* 07 July 2021 16:43 > > *To:* Abi James <A.James@soton.ac.uk> > > *Cc:* Lisa Seeman <lisa1seeman@gmail.com>; public-cognitive-a11y-tf > > <public-cognitive-a11y-tf@w3.org> > > *Subject:* Re: COGA action requested: please review draft response to > > Accessible Authentication show password issue > > > > *CAUTION:*This e-mail originated outside the University of Southampton. > > > > Hi Abi, > > > > I'm still working on fully understanding the nuance of the challenge > here: > > > > To confirm, some policies around security would consider allowing the > > *user to control and toggle* between **** and seeing the password (in > > the moment, with **** as default) is considered unacceptable. > > > > Am I understanding this correctly? > > > > Thank you, > > > > Rain > > > > On Wed, Jul 7, 2021 at 2:32 AM Abi James <A.James@soton.ac.uk > > <mailto:A.James@soton.ac.uk>> wrote: > > > > Hi Lisa > > > > I am definitely not suggesting stopping pasting in passwords. This > > is to with implementing seeing password characters and not ***** > > > > Abi > > > > Sent from my iPhone > > > > > > > > On 7 Jul 2021, at 09:04, Lisa Seeman <lisa1seeman@gmail.com > > <mailto:lisa1seeman@gmail.com>> wrote: > > > > > > > > *CAUTION:*This e-mail originated outside the University of > > Southampton. > > > > I am not sure I am following but I strongly disagree with > > diluting the wording of accessible authentication to allow crazy > > , non paistable password ID combinations to be allowed just > > because you can view the password. > > > > Is that the proposal? My current bank has that and I have to > > call my accountant to login for me on a regular basis! > > > > It helps but anther mechanism is much better! > > > > All the best > > > > Lisa > > > > On Thu, Jul 1, 2021 at 10:57 PM Rain Michaels <rainb@google.com > > <mailto:rainb@google.com>> wrote: > > > > Hello COGA task force, > > > > We discussed a new response from COGA to SC 3.3.7 Accessible > > Authentication - add requirement / control to "show > > password" for end-users #1912 > > < > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1912&data=04%7C01%7CA.James%40soton.ac.uk%7C674ebc32e3b54e3e2e5608d9415df975%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637612694134477356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N6G459X4j4kkRFJrPag67ZM4yz29GSPeYjsaFqfjYM8%3D&reserved=0 > >. > > Since the discussion was going long, we decided that I would > > try to draft a response and share it with the group for > > comment. > > > > The new draft response is ready for your comments below. You > > can also review and suggest edits or make comments on the > > Google Doc version > > < > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1SmAbdQG-ei1DrWewx61YX93gGsHUo_VM15-FDLlnP9M%2Fedit%23heading%3Dh.o49dk19joyzp&data=04%7C01%7CA.James%40soton.ac.uk%7C674ebc32e3b54e3e2e5608d9415df975%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637612694134477356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6iDwPSjY7YTiw38GOnde8GtTt6RJByd0jTJpKi%2FjLjE%3D&reserved=0 > > > > if that is easier. > > > > Thank you, > > > > Rain > > > > *For context, our response to the **original issue* > > < > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1912%23issue-923218389&data=04%7C01%7CA.James%40soton.ac.uk%7C674ebc32e3b54e3e2e5608d9415df975%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637612694134487351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W%2FK4IREaz0svl5%2BfHijyNrFrZfI71theqf1v%2FOf5cfw%3D&reserved=0 > >*: > > * > > > > 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. > > > > *Summary of responses since ours:* > > > > * Alastair and Jake still felt it should be a new > requirement > > * Patrick felt that it would be okay to add it to the > > understanding document as long as it was clear it was a > > best practice or suggestion and not required to pass the > > success criterion > > * Alastair proposed adding this text to the understanding > > document: “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. 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.” > > * *On our COGA TF call*, we had concerns about the use of > > the word “helpful,” how this relates to “transcription” > > as a cognitive function test, and whether this was going > > in the wrong direction. ** > > > > *Proposed new response following our COGA TF meeting: * > > > > This is a combined response from the COGA Task Force: After > > reading the responses since our last comment (posted on June > > 24), we feel more strongly now that this should be a > > requirement, but we also feel that it is not a *new* > > requirement, and should, instead, be part of this one. > > > > We have come to this conclusion after re-reading the > > functional definition of a cognitive function test > > < > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG22%2F%23dfn-cognitive-function-test&data=04%7C01%7CA.James%40soton.ac.uk%7C674ebc32e3b54e3e2e5608d9415df975%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637612694134497344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=askx3bqCmwN2i%2FwvKrPl6KytbyU1A39hFAsurrKxHro%3D&reserved=0 > >, > > which clearly includes transcribing characters. > > > > SC 3.3.7 Accessible Authentication > > < > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG22%2F%23accessible-authentication&data=04%7C01%7CA.James%40soton.ac.uk%7C674ebc32e3b54e3e2e5608d9415df975%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637612694134497344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=evgZI7R0Ux0mMv9xtOkEwEN3P060j1WbIh%2BDrriVv8I%3D&reserved=0 > >reads > > “For each step in an authentication process that relies on a > > cognitive function test, at least one other authentication > > method is available that does not rely on a cognitive > > function test, *or a mechanism is available to assist the > > user in completing the cognitive function test.*” > > > > The challenge is that for some individuals with cognitive > > disabilities, password visibility may be essential. To frame > > it from a user perspective: I need to see the password as I > > type it, and I need to see the password after I type it with > > time to review. > > > > We (the COGA task force) realize that this is a challenging > > request and has a lot of implications. Please advise on next > > steps so that we can help bring this to resolution. > > > > *What you, COGA task force member, need to do: * > > > > Please either +1 or -1 this proposed new response. If -1, > > please indicate why and what you would like us to do > > instead. *If possible, please respond before July 3 so that > > we can post our response before many are gone for the > holidays.* > > > > Thank you, > > > > Rain > > > > > > > >
Received on Monday, 19 July 2021 16:53:58 UTC