Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC 1.3.5 Technique "Use type attribute on fields in simple login forms"? #504

Closed
detlevhfischer opened this issue Oct 6, 2018 · 15 comments

Comments

Projects
None yet
5 participants
@detlevhfischer
Copy link
Contributor

commented Oct 6, 2018

In rating some forms against 1.3.5 Identify Input Purpose, I wondered whether the frequent two-field login forms that ask for just email and password would pass this SC already by specifying the type of the field (type=email, type=password). I reckon assistive technology presenting visual cues would not miss the opportunity to display the appropriate image (not sure what these would be, though) to identify the purpose not just on forms that use the autocomplete attribute but also for (those parts of) forms that betray purpose in a programmatically determinable way via the type attribute.
So is there a case for a sufficient technique "Use type attribute on fields in simple login forms", making it clear that it is scoped to just forms which contain no additional fields without unambiguous type?

@mraccess77

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2018

We had this discussion on WebAIM recently. The consensus from some seems to be that type can't be used.

https://webaim.org/discussion/mail_thread?thread=8936

@detlevhfischer

This comment has been minimized.

Copy link
Contributor Author

commented Oct 6, 2018

Yes, I saw that discussion (and the epic exchange between JF and Jared) but I still feel that in a narrowly constrained context such as login, where it is clear that just your email and your password are needed, type should suffice to meet the SC. Why should coga AT not be smart enough to look out for type as well, in the absence of autocomplete, and supply fitting icons when there is an unambiguous match? Once you also have other fields like name that would be of type text, this obviously stops working. But I am talking here about a very common, restricted and conventional scenario.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Oct 7, 2018

i would say type="email" and type="password", in isolation and without any other fields of the same type, should likely be treated as acceptable for a login (compared to, say, two fields just with type="text". i'd say it's pretty unambiguous what purpose those two inputs would have.

though i could see a more pedantic reading that would say the only acceptable way here would be:

<input type="email" ...>
<input type="password" autocomplete="current-password">

in the case of login forms that require a username which isn't necessarily an email though, having a simple <input type="text" ...> wouldn't be sufficient, instead requiring <input type="text" autocomplete="username" ...>

@detlevhfischer

This comment has been minimized.

Copy link
Contributor Author

commented Oct 7, 2018

@patrickhlauke ....which raises the interesting question what you’d have to do in the frequent case that an input field (just like the one I just used to login to Github) accepts BOTH user name AND email. Is it valid for autocomplete to have two values? I guess not (but too lazy to check). So you would, when using autocomplete, misrepresent the purpose either way, simply by omission. What would be the right thing to do on those form fields, and in turn, the right approach in conformance testing?

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Oct 7, 2018

heh, i was thinking about that last night when answering, but didn't want to open that particular can of worms. my reading of https://www.w3.org/TR/html52/sec-forms.html#sec-autofill seems to suggest that you can't assign multiple autocomplete values (and i'm sure somewhere in the complex algorithm described in HTML5.2 there's something relating to how to handle tokens that refer to different purposes being present for the same control, but the techno-babble of that part confuses me). i think the short answer would be that the input has no set/defined purpose, as it's essentially a multi-purpose freeform text entry (which the server then compares to usernames and email addresses), which with current technologies can't be defined unambiguously and is therefore currently exempt from pass/fail.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Oct 7, 2018

(which then raises the question: what happens when technologies do become available to allow things? you'd have to retrospectively pass/fail things that before were N/A. this feels like an "until user agents..." kind of situation in reverse...)

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

Discussed and closed... Detlev still keen to see examples where there are multiple people being added to something.

@alastc alastc closed this Dec 18, 2018

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

Sorry to dig this up again, but: what was the agreed consensus? That it's kosher to just rely on type="email" / type="password" in forms (where UA/AT would likely infer this refers to the person's email/password?)

If so, this part of the understanding doc https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html will likely need to be changed accordingly:

For some input fields, the type attribute already offers a way to broadly specify the intention of the input field, for example, input type="tel", input type="email", or input type="password". However, these are only very broad categories, describing the type of input, but not necessarily its purpose, especially as it relates to user-specific input fields. As an example, type="email" indicates that the field is for an e-mail address but does not clarify if the purpose is for entering the user's e-mail address or some other person's e-mail.

Related, if the answer/decision above was that type="email" and type="password" are acceptable, what about type="tel" and type="url" ? in a simple form, can they be assumed to be the phone/web address for the user themselves?

@detlevhfischer

This comment has been minimized.

Copy link
Contributor Author

commented Apr 24, 2019

@patrickhlauke I think the discussion at the time concluded that even in such a restricted case (login with just email and password), type would not do the trick as new AT would more likely latch onto some unique purpose identifier (for the time being, autocomplete). I remain somewhat unconvinced but accepted that resolution. The text you quote draws on a distinction between 'intention' and 'purpose' which I find somewhat unconvincing - maybe one should better argue that type sets technical constraints for inputs and cannot be extended to cover all input purposes defined in part 7 of WCAG 2.1, so for generality's sake (?) it should not be used even in restricted cases where it might suffice.

@jake-abma

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

that's also how I recall it, only type wouldn't do the trick and requires some heuristic analysis to be sure this is for example a login screen yes/no. Conclusion was: "not kosher"

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

fair enough. have to admit that this kind of speculative requirement (as there's currently nothing, to my knowledge, that really takes full advantage of autocomplete in this way) still rubs me the wrong way, as it's pretty much always a fail in audits that i do unless the authors explicitly added these (to pass the SC for the most part)...but at least it's clear.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

The issue was essentially false positives, i.e. it is not unusual to have forms with multiple names, but only one of which is aimed at being your name. See #642 for even more detail than you probably want.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented May 20, 2019

dropping this here, but worth noting: apparently i was wrong, and a form field CAN have multiple autocomplete tokens (while i knew the spec said it allows an ordered list of tokens, i was under the impression this referred more to the fact that there are optional tokens that can be there as well)

https://twitter.com/patrick_h_lauke/status/1130468323060342784

long story short, for that case of inputs that allow either username or email, it seems that it's valid (though possibly not supported) to use autocomplete="username email" or similar.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented May 20, 2019

ah, wonderful ... there's disagreement between spec writers on this point. good times... https://twitter.com/annevk/status/1130478430313746432

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented May 20, 2019

ignore the above. seems the spec is just vague, but that our original reading (that it does NOT allow these sorts of multiple autocomplete values) was correct after all. as you were...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.