Re: Accessible Authentication and issue responses

> Two-factor transcribing usually involves a freshly generated number/code, which can't be auto-filled by UAs.
    
That is most common, but the *whole point* is that it is not the only method.
(I went through those here: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0680.html) 

With WebAuth you can let people use their device, e.g. Windows Hello, YubiKey, whatever the device provides and the website doesn’t have to know what that is.

There are other options as well, but as explained previously they come with more overhead than I’m happy with demanding from all websites.

That does make the SC dependant on WebAuthN, but 3 of the major browsers are already in beta-testing, it seems on track for 2018Q2 when WebAuthN should finish.


> CAPTCHAs themselves are orthogonal to the issue though. A login could 
> also rely on color alone, or some widget that only works with the mouse 
> (e.g. an on-screen number pad that only works with the mouse) or some 
> other accessibility problem...doesn't mean that those also need to be 
> included here?
 
No, this is the “don’t make the user recall unusual stuff or transcribe things in order to login” SC. A CAPTCHA can fail in multiple other ways, but this way is scoped to login.

We have SCs for not relying on a mouse, and not relying on colour, this is about not relying on memory/transcription for a specific (but common) task. That is the gap it is trying to cover.

Cheers,

-Alastair

Received on Tuesday, 2 January 2018 12:12:52 UTC