- From: E.A. Draffan <ead@ecs.soton.ac.uk>
- Date: Wed, 7 Oct 2020 15:32:31 +0000
- To: Steve Lee <stevelee@w3.org>, "Rochford, John" <john.rochford@umassmed.edu>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
You are spot on Steve with your points. I agree this is a coga issue as colleagues have already said there is an issue when you cannot see what you are getting, so you are wary about trying it. I would say this happens more often when one has a cognitive impairment. In our case as you suggested some parts should not require a login - for example guest for Global Symbols - you see all the symbols but cannot download. However for Board Builder guest access would have to allow a person to have fun creating a board, but not saving it and seeing public charts but not downloading them. All possible ... Best wishes E.A. -----Original Message----- From: Steve Lee <stevelee@w3.org> Sent: 07 October 2020 16:23 To: E.A. Draffan <ead@ecs.soton.ac.uk>; Rochford, John <john.rochford@umassmed.edu>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org> Subject: Re: Login Walls Thanks for the feedback. > I am really interested in this dilemma, What do you see as the dilemma? That some parts should NOT require a login? Or whether to insist a login is created in order to access all the site when only one part actually requires it > "If you want to save communication charts to a repository you need to have a login to keep your charts in a private store that you alone can access at any time." OK, I think it fits in the proposed cases like this: > 1) it is *necessary* to keep user specific data for a section of a website / app the user is visiting (eg checkout) Yes, only require the account when / if user wants to *save* a chart. Let them browse etc before then. Amazon used to do this. Technically, some routes (URLs) are public and some require authentication to protect private . Note info could be public AND user specific but a search / browse / filter option could be better than having an account. > 2) it benefits the user, not just the site owner Definitely. They want to save charts. > 3) a *guest* option is available Hmm, that probably doesn't makes sense. It would imply not saving a chart and a throwing it away. But perhaps there *is* such a use case? Having said all that the question for inclusion in the Pattenrs is - is this a cognitive issue or just good usability design? I think it is as having to create an account with passwords etc is a barrier. it's just become somewhat lazy standard practice. Steve On 07/10/2020 16:07, E.A. Draffan wrote: > I am really interested in this dilemma, as we have this problem and need to solve it as soon as possible! Beta sample https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.globalsymbols.com%2F&data=01%7C01%7Cead%40ecs.soton.ac.uk%7Cf0cbfbd4bde240b615b808d86ad4e2ee%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=vnB1vgKuSIA%2Bk%2BYa4hFWZhI4s7%2F1jOJBvauOdZ7Niug%3D&reserved=0 If you want to save communication charts to a repository you need to have a login to keep your charts in a private store that you alone can access at any time. > > I could not find any good examples where a website / app clearly offers John's list of benefits, without a lot of descriptions as with TripIT in the NN group article, although I liked the video with captions https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tripit.com%2Fweb&data=01%7C01%7Cead%40ecs.soton.ac.uk%7Cf0cbfbd4bde240b615b808d86ad4e2ee%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=8JwUxrgQeURABuvRW9qHT8HUHhhVVLHVpCUnVKCezRk%3D&reserved=0 . It has obviously changed since 2014, but still requires login to see their full website! > > I would like to say +1 to these needs: > > 1) it is *necessary* to keep user specific data for a section of a > website / app the user is visiting (eg checkout) > 2) it benefits the user, not just the site owner > 3) a *guest* option is available > > If anyone finds an example, please let me know and we will happily try to put something similar into practice that can be used by the graphic designers for the relevant pattern! > > Best wishes > E.A. > -----Original Message----- > From: Steve Lee <stevelee@w3.org> > Sent: 07 October 2020 10:38 > To: Rochford, John <john.rochford@umassmed.edu>; > public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org> > Subject: Re: Login Walls > > On 06/10/2020 18:50, Rochford, John wrote: >> How do you think we could apply this to Accessible Authentication? > > By stating you should only require account creation and login when: > > 1) it is *necessary* to keep user specific data for a section of a > website / app the user is visiting (eg checkout) > 2) it benefits the user, not just the site owner > 3) a *guest* option is available > > Assuming we have coga research to back this up, or we feel this article will support cognitive accessibility as well as User Experience. We might need to backfill the Research and Gap Analysis documents. > > Can you provide the 'How it helps' part? > > Fitting these requirements into our Patterns is a little complex. They are relevant to: > > - Objective 6 : Ensure Processes Do Not Rely on Memory > - Provide a Login that Does Not Rely on Memory or Other Cognitive > - Allow the User a Simple, Single Step, Login > - Provide a Login Alternative with Less Words > - Objective 4: Help Users Avoid Mistakes or Correct Them > - Keep Users' Information Safe and Help Users Understand Known > Risks > > We don't really want to repeat this requirement in all these patterns > but it doesn't fit exactly and exclusively with either Objective > > So we could add a new Pattern, probably best fitting in Objective 6 > > - Do not require account creation and login until it is necessary > > However, there is already a lot of Patterns. So, we could consider adding the above requirements to: > > - Provide a Login that Does Not Rely on Memory or Other Cognitive > > Explaining the "no login" is the best solution if it is not required. On balance, I prefer adding a new pattern. > > Note, the Web Design Guide will probably have a 'Related Patterns' > sidebar which can help ensure the related Patterns are considered, > whichever choice is made (if any) > > I suggest we discuss and add it to the actions as required. > > Steve > >> John >> >> John Rochford >> >> University of Massachusetts Medical School >> >> Eunice Kennedy Shriver Center >> Director, INDEX Program >> Faculty, Family Medicine & Community Health >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >> d >> isabilityinfo.org%2F&data=01%7C01%7Cead%40ecs.soton.ac.uk%7C2fcd6 >> 4 >> de5dac4b8d0a1f08d86aa4a984%7C4a5378f929f44d3ebe89669d03ada9d8%7C0& >> ; >> sdata=7VPfjrFQj6Nguxtp%2BKH2NugfV6IcBSVHDJuRMgI7tFQ%3D&reserved=0 >> >> About Me >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjo >> h >> nrochford.com%2F%3Fpromo%3Demail_sig%26utm_source%3Dproduct%26utm_med >> i >> um%3Demail_sig%26utm_campaign%3Dedit_panel%26utm_content%3Dplaintext& >> a >> mp;data=01%7C01%7Cead%40ecs.soton.ac.uk%7C2fcd64de5dac4b8d0a1f08d86aa >> 4 >> a984%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=l9P27Y2%2F9rsNC >> 8 4AERFkCjPfGDuM5vkPlsqX4wvjIvk%3D&reserved=0> >> >> EasyText.AI >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fea >> s >> ytext.ai%2F&data=01%7C01%7Cead%40ecs.soton.ac.uk%7C2fcd64de5dac4b >> 8 >> d0a1f08d86aa4a984%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=XN >> t ncf3f1I6J5CbZ1%2BUnsjaevwKezYMyeFQ%2FCtm9WiI%3D&reserved=0> >> >> Schedule a meeting with me. >> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit. >> ly%2FCallJR&data=01%7C01%7Cead%40ecs.soton.ac.uk%7C2fcd64de5dac4b >> 8 >> d0a1f08d86aa4a984%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=o5 >> z kkf5xlwjgTS7ht7yTXH9C%2FVo76pSaYLal%2BcpTlY8%3D&reserved=0> >> >> /_Confidentiality Notice:_/ >> >> /This e-mail message, including any attachments, is for the sole use >> of the intended recipient(s) and may contain confidential, >> proprietary, and privileged information. Any unauthorized review, >> use, disclosure, or distribution is prohibited. If you are not the >> intended recipient, please contact the sender immediately and destroy >> or permanently delete all copies of the original message./ >> >> *From:* Steve Lee <stevelee@w3.org> >> *Sent:* Tuesday, October 6, 2020 4:26 AM >> *To:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org> >> *Subject:* Re: Login Walls >> >> Here's a direct link to the related article for those whom do not >> like videos >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> nngroup.com%2Farticles%2Flogin-walls%2F&data=01%7C01%7Cead%40ecs. >> s >> oton.ac.uk%7C2fcd64de5dac4b8d0a1f08d86aa4a984%7C4a5378f929f44d3ebe896 >> 6 >> 9d03ada9d8%7C0&sdata=hTlU4njge93lCjE9m67efil%2BYTIxdRmDAcusXCIsPN >> M >> %3D&reserved=0 >> >> Steve >> >> On 06/10/2020 10:22, Steve Lee wrote: >>> Given the most accessible login is NO login, I suggest we add that >>> point to the login pattern >>> >>> Necessary account creation and login is a point that really annoys >>> me personally. >>> >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w >>> .nngroup.com%2Fvideos%2Flogin-walls&data=01%7C01%7Cead%40ecs.sot >>> o >>> n.ac.uk%7C2fcd64de5dac4b8d0a1f08d86aa4a984%7C4a5378f929f44d3ebe89669 >>> d >>> 03ada9d8%7C0&sdata=yJpNuakAVDvF4k2LbvL%2F3GwdkoVrSiHPHUB7dFQl7Qc >>> % >>> 3D&reserved=0 >>> >>> Steve >>> >> >
Received on Wednesday, 7 October 2020 15:32:49 UTC