Re: Feedback on Success Criterion 2.2.6 Accessible Authentication

Lisa wrote:

> It is however,  also an accessibility requirement


​While this is indeed true, we also need to remember that the content
author of "Bob's Local eCommerce Site" can only do so much to address that
problem with the technologies we have available to us today.​.

As noted, the real solution to this problem involves a number of different
actors (including the end user, who MUST also be part of the mix), as the
larger solution needs to be significantly more holistic then we can achieve
in WCAG (N.B. we need to be sure that Project Silver team is tracking this
one).

I would support Alastair's new draft language as being useful towards the
greater goal, but agree that at this time, we aren't going to get
everything hoped for in this SC.

JF


On Fri, Dec 1, 2017 at 6:40 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Lisa,
>
>
>
> Well, it means we have several different requirements going on (for this
> late stage):
>
>
>
>    1. A *user requirement* to make use of the built-in password manager
>    in the browser.
>    If you use the built in one, then your authentication is via the OS,
>    e.g. touch ID, or whatever you use to login to the computer.
>
>    2. A *content requirement* to not prevent password managers (for which
>    we do not have text, and it doesn’t fit into the current text easily).
>
>    3. A content/*functionality requirement* to use a method that doesn’t
>    require remembering / copying for re-authentication.
>
>
> These are three different things, and having the first makes the third
> (current text) redundant.
>
>
>
> I’d be happy to have an SC about not blocking password managers, it would
> fit nicely under guideline 4.1, something like:
>
> “Authentication tools: User interface components which gather
> authentication credentials do not prevent automatic entry.”
>
>
>
> NB: Not marking up an input as password properly could be failed under
> 1.3.1 and possibly 4.1.1 already.
>
>
>
> However, we are a bit late in the 2.1 cycle for a new SC!
>
>
>
> *So the question is:*
>
>
>
> Would you like to proceed with this (in my view) redundant SC requiring
> sites to provide a non-password method of re-authentication for
> single-factor auth?
>
>
>
> *The only other (useful) option* I can see is that we assume people can
> use a password manager.
>
>
>
> In which case, we could re-scope the SC to ensure that sites which do use
> 2 factor make it simpler for re-authentication:
>
> -----------
>
> Essential steps of a *multi-factor* *re-*authentication process which
> relies on recalling or transcribing information has alternative essential
> steps which do not rely upon recalling or transcribing information, unless
> there are legal requirements for a recall or transcribe method of
> authentication.
>
> -----------
>
>
>
> That basically says: You can use username/password, but for 2nd factor
> you have to provide a mechanism for re-authentication which doesn’t require
> typing things in.
>
>
>
> The options for that are then:
>
>    - Save the person’s cookie, only re-auth after 30 days or with a new
>    browser.
>    - WebAuth (later).
>    - ‘Magic’ link.
>
>
>
> Having it apply to second-factor re-auth makes it more feasible, it would
> have a chance.
>
>
>
> -Alastair
>
>
>
>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion