Open fstrr opened 1 year ago
The following input control purposes are intended to relate to the user of the content and pertain only to information related to that individual.
a one-time code isn't really (personal) information related to the user
I agree with Patrick here. Maybe one could extend accessible authentication to include a requirement for using one-time-code
.
i seem to remember that as far as Accessible Authentication is concerned, as long as you can copy/paste into the field for the one-time passcode (OTP), you satisfy the requirements of that SC
ah, i thought my edits to the understanding https://github.com/w3c/wcag/pull/1898 touched on OTPs as well, but they don't. might be something to add there...i'll have a think
i seem to remember that as far as Accessible Authentication is concerned, as long as you can copy/paste into the field for the one-time passcode (OTP), you satisfy the requirements of that SC
Correct, hence I asked about extending the SC to require it 😉
Ah, that wasn't there when we did the WCAG 2.1 list, perhaps that's something we can add.
There's a task to review other new entries as well.
perhaps that's something we can add
but again, not really a piece of info related to the individual...
Correct, hence I asked about extending the SC to require it
note that 3.3.7 doesn't directly require the use of 1.3.5-specific input purpose identification. at its most basic, it requires that pasting and autofilling (if it works) isn't blocked, nothing more. i.e. you can fail 1.3.5, but still pass 3.3.7. at least that's my reading.
a one-time code isn't really (personal) information related to the user
It doesn't have to be personal info, in this case it is something the user has, and does relate to the user. (No one else should have the same code at that time.)
There's a task to review other new entries as well.
I couldn't see an issue for this—if there is one, clearly I'm not searching for the right thing.
I think the only other new one I can see is webauthn
, which is at the bottom of the table in the autofill processing model section of the HTML spec.
It isn't clear that this is "input", as it says "the user agent should show public key credentials available via conditional mediation when the user interacts with the form control".
I think we can leave that one.
I know I'm really late to this issue, but in response to
It doesn't have to be personal info, in this case it is something the user has, and does relate to the user
The section in question begins with
The intent of this Success Criterion is to ensure that the purpose of a form input collecting information about the user can be programmatically determined
(emphasis mine)
You could also say that what the user wants for lunch right now "relates to the user", but that doesn't make it information "about" the user. Compare the concept of an ephemeral one-time-code, with a typical lifespan of 30 or 60 seconds, to every other value on the accepted autocomplete value list. Everything else is either a long-lived property of the user's identity, or relates to credentials, contact details, residence, or financial info that is likely to remain unchanged for at least days to years.
I do think that WCAG should have an opinion about how to identify OTP fields, but IMHO they should fall into the bucket of "not about the user" and as such be tagged with something that identifies them as not suited for autofill. (Now, if only we could get the Chromium devs to listen about respecting that tag...)
I don’t consider it to be about the user
WCAG 2.1's list of input control purposes lists the relevant
autocomplete
attributes that relate to the user of the content and pertain only to information related to that individual. Included in that list iscurrent-password
andnew-password
, butone-time-code
isn't, but feels like it should be.