- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sun, 24 Dec 2017 01:28:04 +0000
- To: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
On 24/12/2017 00:17, Alastair Campbell wrote: >> Because if so...this SC would >> only prohibit a small number of scenarios (like "enter the first, third >> and seventh digit of your secret number" or similar) > > Also consider the 2 factor cases, where you have to transcribe a 6 digit number in 30 seconds. > > The aim is to push sites to allow for other methods, such as WebAuth based hardware/OS methods like Windows Hello. But if a site can pass by simply having regular inputs that don't somehow disable autofill, the push (if that's the intention) seems quite soft. I guess the "understanding" doc really needs to clarify some more aspects of this (and again, I'll mention that currently there still seem to be aspects related not to authentication per se, but purely to CAPTCHA, in that understanding doc). >> Password managers/UAs can autofill other types of information as well. > > Yes, but the reliability is not great, and not standardised AFAICT. Sites do strange things to even username/password fields, expanding the range of things that *might* be remembered by browsers /pw-managers doesn't seem like a great approach. Enshrining in normative language the only fields that are allowed as exceptions also doesn't seem a good approach. What happens when reliability improves for even one more type of field? Are we left with a normative list of types of fields which call back to a past time and isn't relevant anymore? (Of course, we could argue "we'll fix/expand that in future / in Silver", but by then you could have technical "fail"s that are real-world passes / passes in Silver...which may seem strange). -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Sunday, 24 December 2017 01:28:33 UTC