Re: Accessible authentication Updates

I really like Gregg's suggestion to add clarity with "that satisfy this SC."

I also agree with his point that "cognitive function test" is an awkward
(and complicated!) way to describe what these are. They aren't actually
testing cognitive function, but instead requiring cognitive function skills
to test the user's authenticity.

I can live with not changing this much now, given the goals and scope of
this effort. If, however, we think it's worth addressing, here is an
attempted rewrite (put into list form to help me visually process):

Examples of mechanisms *that satisfy this SC* include:

   1. support for password entry by password managers to *minimize
   requiring memorization abilities*, and
   2. copy and paste to *minimize the cognitive burden of transcription*.




On Mon, Aug 22, 2022 at 6:57 PM Gregg Vanderheiden RTF <
gregg@raisingthefloor.org> wrote:

> Nice. Covers it well.
>
> We might just add  context in the lead in  (shown in *bold)  *to make it
> stand by itself a bit better.   Just editorial though.  And it can be
> tweaked for accuracy.
>
> Current note:
> Examples of mechanisms *that satisfy this SC* include: 1) support for
> password entry by password managers to address the memorization cognitive
> function test, and 2) copy and paste to help address the transcription
> cognitive function test.
>
>
>
> However I do wish we could stop using *"cognitive function test"* for
> things that are *not tests of cognitive function* - but rather things
> that are just functions that require cognitive burden or memory.     It
> bends my brain to call copying a password into the field as being a ’test
> of cognitive function’.      But as I said - if we can’t think of a better
> term - I can live with it.
>
> Best
>
> Gregg Vanderheiden
> gregg@vanderheiden.us
>
>
>
> On Aug 22, 2022, at 9:00 AM, Jonathan Avila <jon.avila@levelaccess.com>
> wrote:
>
> Hi Gregg, we already have a note on that – but perhaps it could be
> clarified:
> Current note:
> Examples of mechanisms include: 1) support for password entry by password
> managers to address the memorization cognitive function test, and 2) copy
> and paste to help address the transcription cognitive function test.
>
> Jonathan
> *From:* Gregg Vanderheiden <gregg@vanderheiden.us>
> *Sent:* Monday, August 22, 2022 11:53 AM
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
> *Subject:* Re: Accessible authentication Updates
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> No objection — but we should include a note that "allowing passwords to be
> pasted in - does not require that the person remember a password"    or
> some other wording that
> a) does not sound like we just suddenly are not allowing any passwords to
> be use on the web (that will create a quick firestorm) and
> b) stops the practice of blocking the pasting of passwords into a field
> (thus requiring a heavy cognitive memory task that can be very difficult
> for many really good strong passwords)
>
>
>
>
> Gregg Vanderheiden
> gregg@vanderheiden.us
>
>
>
>
> On Aug 22, 2022, at 2:09 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi everyone,
>
> I don’t think we’ve had any concerns about these updates, but I’ll state
> them concisely here.
>
> Firstly, some fairly editorial updates:
>
> *2. Clarify Accessible Authentication by including "remembering user names
> and passwords" in the SC text #2577 *
>
> Most people agree with the addition, with a couple of suggestions to put
> it in parenthesise and include at the AAA level. PR 2609
> <https://github.com/w3c/wcag/pull/2609/files> has been updated to reflect
> that.
>
> There was a concern about the term “cognitive function test”, but for want
> of a better alternative, they could live with it.
>
> Does anyone object to PR 2609
> <https://github.com/w3c/wcag/pull/2609/files> which adds: (such as
> remembering a password or solving a puzzle) to both versions?
>
>
> *3. Editorial update to accessible-auth exception #2608 *
>
> Tobias made a suggestion which several people agreed with (and doesn’t
> change the meaning), so I’ve updated PR 2608
> <https://github.com/w3c/wcag/pull/2608/files> to reflect that.
>
> Any objections to that update?
>
>
> *New issue 2*
>
> I don’t think there’s a separate issue for it, but in a couple of places
> people have raised that: identifying content the user has provided to the
> website could include passwords.
>
> To resolve this, I’m proposing we use “non-text content” in the
> exception, and remove ‘text’ from the note. This is implemented in PR 2624
> <https://github.com/w3c/wcag/pull/2624/files>.
>
> Any objections?
>
>
> Then a more substantial re-structure:
>
> *New issue 1*
>
> In the thread of Issue 2592 <https://github.com/w3c/wcag/issues/2592> EricE
> proposed to re-structure the SC text so it uses bullet-points for the
> exceptions AND the alternative  & mechanism aspects.
>
> To keep it aligned with the current meaning I suggested it use a structure
> more like the alt-text SC:
> https://github.com/w3c/wcag/issues/2592#issuecomment-1217758169
>
> The question at this point is: Do people think that improves the SC and
> no-one would object?
>
> If anyone objects, we’ll shut-down that approach now rather than take time
> on it but I couldn’t see a problem with it.
>
> Kind regards,
>
> -Alastair
>
> --
>
>
> @alastc / www.nomensa.com
>
>
>