Audit: input fields have appropriate type & autocomplete attributes

[paulirish]

There are three related things we want to audit:

1. Input fields use appropriate type/inputmode attributes so they get custom keyboards on mobile
2. Payment forms marked up with autocomplete attributes so they get payment autofill magic.
3. Login forms marked up with autocomplete attributes so they get autofill/autocomplete magic

In all three cases, ideal UX is Lighthouse analyzes each field and validates the appropriate type and autocomplete value is set on it.

---

appropriate input inputmode attributes

We want the user to get a nice keyboard on mobile when it makes sense. https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

(input[type] used to be the hack for this but is a bad choice now that inputmode is everywhere. :)

impl notes: chrome://flags/#show-autofill-type-predictions may help some. It provides this sort of data:

autocomplete for payment forms

See:

• Create Amazing Forms Recommended input name and autocomplete attribute values
• Help users checkout faster with Autofill  |  Web  |  Google Developers
• Autofill: What web devs should know, but don’t - Cloud Four

We'd like to consider the various input fields and suggest which autocomplete attribute value you should use for them. Basically one of the 53 autofill detail tokens or off (if you dont want any autofill to apply (generally discouraged)) or on (if theres no appropriate token but you'd like autofill to attempt anyway)

chrome://flags/#show-autofill-type-predictions exposes what the current clientside and serverside heuristics are determining. We would take a lower confidence level than what Chrome would use to prompt the user, but the confidence rating isn't exposed currently.

autocomplete for login forms

See:

• Create Amazing Forms  |  Recommended input name and autocomplete attribute values
• ensuring_continuity_between_your_app_and_web_site -- apple WWDC (page 177 and on)
• Password Form Styles that Chromium Understands - The Chromium Projects
• Autofill: What web devs should know, but don’t - Cloud Four

input fields should get autocomplete attribute values of username, current-password new-password. This may or may not enable "Smart Lock for Passwords", new password generation, proper password saving, etc. We need to verify these as the documentation is sparse.

---

To enable this we'll need an input-elements.js gatherer:

Get all input elements, maybe grouped by <form>. For each input, we'd want to know type, name, autocomplete, outerHTML snippet (like in a11y gatherer).

[stramel]

Will try to start tackling this middle of this week. Also, those articles are 🔥🔥🔥, bookmarked pretty much all of them lol

[stramel]

@paulirish @ebidel Would this audit fall under DBW category or something else?

[paulirish]

It can go in the dbw folders. Not a big deal really.

…

On Jun 3, 2017 9:06 PM, "Michael Stramel" ***@***.***> wrote: @paulirish <https://github.com/paulirish> @ebidel <https://github.com/ebidel> Would this audit fall under DBW category or something else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1639 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACZF6m_5e0KFHNmo5RC0lTUlWof1Q4Gks5sAi04gaJpZM4L3BuP> .

[stramel]

I'm not having any luck with the chrome://flags/#show-autofill-type-predictions flag. It isn't showing any of them after having enabled and restarted.

[paulirish]

@stramel it doesn't trigger on a lot of fields. In the google login form, I get the prediction info on the password field. and i also get it on the mint.com signin form.

but that said, this data isn't exposed over the protocol so we can't use it. :/

[stramel]

@paulirish that's a shame, I had looked into it to see if there would be a way. I started on this will probably have a couple questions. One that I have now is, is there a good way to check all the way through the Shadow Dom? I have a way to do it already but it isn't super clean.

[paulirish]

#2371 has the best technique right now

[stramel]

@paulirish Maybe I'm over thinking this, how am I supposed to be determining which autocomplete would be best? Is it name and type? I realize email would be easy but what about the others? How would I know if they are using an appropriate type?

Or should I just be checking if they have autocomplete? Should I ensure they are using the appropriate type for the autocomplete?

Sorry, I think I'm confused lol

[stramel]

@paulirish Ping :)

[stramel]

@paulirish Just checking if you may have missed this?

[paulirish]

A few months back DevTools landed a patch which includes analysis for login fields: https://chromium-review.googlesource.com/c/chromium/src/+/606827

I believe it recommends appropriate attributes for the various input elements, including values. They are emitted as Log.EntryAdded so we should be able to use this.

[lbassuncao]

This extremly annooying! I don't want autocomplete on my forms. But since Chrome throw these annoying messages, I added autocomplete to all inputs with autocomple=Off, but it still complaining! WTF!

[c-dante]

Same issue as @assunluis80 -- the validation warning is not respecting the spec: autocomplete="off".

[patrickhulce]

@assunluis80 @c-dante if you folks have an issue with scope of the violations surfaced by Chrome itself, please file a bug over at http://crbug.com/ to hash it out.

[c-dante]

@patrickhulce Thanks -- this was the resource that came up from searching the error -- will use the bug report!