- From: John Foliot <john.foliot@deque.com>
- Date: Fri, 1 Dec 2017 08:34:33 -0600
- To: Alastair Campbell <acampbell@nomensa.com>
- Cc: "lisa.seeman" <lisa.seeman@zoho.com>, Janina Sajka <janina@rednote.net>, "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CAKdCpxwd5q6vc=LH26duznh9HBUcBptiHuW8T+_FCoaXjWixrw@mail.gmail.com>
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
Received on Friday, 1 December 2017 14:34:57 UTC