autocomplete value support

[LJWatson]

Research completed during the WCAG2.1 lifecycle indicates that a number of autocomplete attribute values are not supported in browsers. Should the autocomplete part of the spec be updated to reflect this?

[domenic]

This is great stuff, thank you! Yeah, there's lots to learn here. Probably a mix of easy wins and larger discussions.

Off the top of my head:

• Can we encode this investigation into web platform tests in any way? Probably will require new WPT infra of some sort, but those folks have been working magic recently, so I'm optimistic. /cc @foolip.
• I'm very surprised browsers don't support the new-password and current-password values, given that most browsers seem to be in favor of autofilling (and even auto-generating) passwords. I'd like to learn more about those failures and talk to the browser folks to figure out the disconnect there.
• A few times we've run into situations where a spec adds value not only through direct browser engine implementations but also through possible extensions, or through other browsers that use the same engine.
  • E.g. among the four browsers put out by the four engine implementers, #3870 may only be useful to the two browsers with built-in translation functionality (Chrome and Edge), but extensions for the other two could key off of it, and other browsers beyond the ones that are put out by browser-engine companies could use it.
  • Similarly only Apple has so far expressed interest in #4000, but you could easily imagine extensions for Chrome, or a Chromium-based browser like Brave, using it as well.
  • Regarding the OP, many of the autofill values were shown to have value in LastPass, even if not in browsers directly.
  • In general these cases sit uneasily within the current WHATWG working mode, and there may be a larger discussion to have here. At the very least we should try to more actively seek out involvement from the vendors of software like LastPass, or of multiple browsers (not just browser engines).
• Just skimming, it seems that there are at least some values which are supported correctly by no software, and maybe our default course of action there should be removal. Similar for the ones that are only supported by LastPass-with-user-customization.

[tabatkins]

When was this research done? I don't immediately see a date on the wiki page. I ask because I think Chrome supports new-password and current-password now; at least, yesterday I saw an internal slide deck pointing out sites being weird about autocomplete, and the new-password value was mentioned as being used.

[LJWatson]

tabatkins AIRC it was April/May 2018. Testing was done the hard way, so having some WPT as @Domenic suggests would help us make sure the results are current.

[mnoorenberghe]

Thanks for raising this issue, it's something that's been on my mind for a while. Here are some thoughts:

• Even if a UA doesn't autofill a value, that doesn't mean that it's not helpful for the autofill heuristics engine e.g. having the author tell the UA that a field is autocomplete="honorific-prefix" is still useful so the UA doesn't try to incorrectly guess that some other type of information should be filled… it's a strong negative signal.
• I would be in favour of removing transaction-amount and transaction-currency as Firefox has no intentions of using them and it seems like nobody supports them. They are also outliers because their main use was originally to convey information from the author to the UA for use in the requestAutocomplete UI, a feature which was removed from HTML a while ago. In theory a UA could pre-fill transaction-currency to match the credit card the user has chosen but that seems like it would be a better fit for a cc-currency value.
• Firefox does support credit card autofill but it's currently only in Firefox Nightly, not in release. That will hopefully be changing next year.
• Firefox does support address-line2 and address-line3 values for autofill.
• Firefox recently added autofill support for address-level3 as part of expanding support for countries outside of US/CA/DE but it's not exposed via the autocomplete IDL attribute yet.
• Firefox does support tel-local-prefix and tel-local-suffix.
• Firefox doesn't plan to support autofill via cc-csc but we do plan to treat it like the value off for the purposes of (single field) form history so it's still useful. current-password and new-password will also be treated like off for form history.
• Firefox does plan to support new-password but only once password generation UI is available. This is to prevent the use of new-password to replace off which browsers have started ignoring.
• Support for current-username and current-password are great for sites trying to help password managers but can also be abused to break them like off did. We are hesitant to adopt them until we have more time to measure and mitigate abuse.
• Testing via WPT will be very hard since parsing of the attribute doesn't imply support in some browsers. Until recently Blink didn't implement the processing model for the attribute but now that it does, it accepts field names even if they aren't used by the browser. See #2577.
• There seems to be some problems with the testing methodology used since there are many fields which Firefox has supported for a while which were incorrectly labelled as "Not supported". You need to have relevant information to be filled in order for the browser to actually fill it. e.g. with address-level3 and address-line2 and address-line3, your saved autofill profiles need to actually have those values saved.
  • Note that address autofill is only supported in en-US builds for Firefox users in the US for now. That will expand to include CA next year and we're still figuring out country rollouts after that.

Thanks again and let me know if you have any questions about autocomplete/autofill in Firefox.

[battre]

I can confirm that Chrome uses new-password, current-password and username (though we take the liberty to override those if we believe that annotations are wrong).

[foolip]

@LJWatson, is http://john.foliot.ca/demos/autofill.html the test that would have to be automated? Would testing this require reading out what the autocomplete suggestions are, or is there more to it?

Probably a WebDriver endpoint that lists the autocomplete suggestions for the currently focused element wouldn't be too hard to define. I suppose that it would be best defined in the HTML spec, since this is where autocomplete overall is defined?

[mnoorenberghe]

@LJWatson, is http://john.foliot.ca/demos/autofill.html the test that would have to be automated? Would testing this require reading out what the autocomplete suggestions are, or is there more to it?

You would also need a way to save addresses, credit cards, and passwords in the browser so that the suggestions would be something expected.

IMO it would be best to get all browsers to only parse the autocomplete tokens that they ever use, like Firefox and Safari do, and then the existing WPT will be a good starting point assuming browsers don't make mistakes. See #2577.

[LJWatson]

@foolip I assume that is the test, yes. Ping @JohnFoliot for confirmation though.

[foolip]

IMO it would be best to get all browsers to only parse the autocomplete tokens that they ever use, like Firefox and Safari do

That sounds like a good idea, yeah. Are there bugs for Chrome and Edge around this?

[battre]

I guess I will put it here instead of opening a new issue, please let me know if you would prefer that though:

In Germany it is pretty common that websites ask you to enter your street name and street/house number into separate fields. I heard the same applies to UK websites. I think that there is no way to express that today.

Here are some prominent examples:

• DHL, DPD, Hermes - i.e. all major companies that ship packages except for UPS
• flatex.de, deutsche-bank.de, www.commerzbank.de - some representatives of the finance sector
• I guess I can find many more...

Specifying the city is complicated as well: While we do have states (e.g. Bavaria to name the probably most well known one outside of Germany), some websites ask for them (mostly foreign owned companies) while the majority does not bother because Zip Code + City are sufficiently specific. Unfortunately, this means that address-level1 has (IMO) no well defined meaning in Germany.

Would it make sense to have specific fields with more defined purposes for i18n? For Germany we would need concepts such as:

• street name (missing)
• street/house number (missing)
• zip code (sufficiently covered by postal-code)
• city (missing)
• country (sufficiently covered by country-name)

I could imagine that other countries may require different concepts, so the list may grow. But today, I think it is impossible to use autocomplete attributes correctly if you want the respective components of an address to be put into separate fields of a form.

[mnoorenberghe]

IMO it would be best to get all browsers to only parse the autocomplete tokens that they ever use, like Firefox and Safari do

That sounds like a good idea, yeah. Are there bugs for Chrome and Edge around this?

I don't know about Edge and have never filed an Edge bug before. For Chrome there is just this comment I referenced before but there was no reply. I guess a separate issue would be better.

[foolip]

@tkent-google, what do you think about "only parse the autocomplete tokens that [we would] ever use"? Do you know of an existing bug for it?

[thw0rted]

@battre I came here for exactly this reason, to suggest the addition of a value meaning "name of street but not number". Is that worth its own entire issue or do we think that simply mentioning it here will get it considered for addition? As a user, I'm sick of having "Meinstrasse" and "Meinstrasse 123" in all my autofill suggestions, apparently chosen at random.

[johnfoliot]

@foolip (and others) Sorry for the delay in responding, I have been on the road non-stop since before TPAC 2018. I'll try and answer the questions & comments that have been posed either directly to me, or as part of the larger discussion.

First, as @LJWatson noted, I performed this very manual test and test suite in spring 2018 (yes, I should have dated it, my bad). A quick check of my server logs, and I uploaded the test page(s) Feb 27th, 2018, so safely presume the testing was done within a week or two of that date.

The process was quite manual as well: each user agent (whether browser or helper tool) allows for a 'pre-population' of fields as part of the Settings config, and so I manually added as much data as each tool would allow me to enter, and went from there. (apologies for not noting builds of browsers either).

@domenic wrote:

In general these cases sit uneasily within the current WHATWG working mode, and there may be a larger discussion to have here. At the very least we should try to more actively seek out involvement from the vendors of software like LastPass, or of multiple browsers (not just browser engines).

A huge Plus One. Assistive Technology (for one) is often dependent on the HTML spec as well, even if their interest is not the same as browser engines. In this case, the Accessibility folks are looking to "repurpose" the attribute and fixed token values to actually extend the functionality of the attribute beyond just auto-filling inputs. The attribute+fixed token construct is allowing us to use that fixed token list as a taxonomy that could be used for UI personalization (to meet the needs of users with cognitive issues). For example, I have a PoC (Chrome) extension that essentially uses the attribute and fixed token pattern as a CSS selector, which then allows me to overlay icons over the text labels, for those users who use symbols as their primary "written language". (eg. [autocomplete="fixed-token"] {styled here} )

@foolip asked:

Would testing this require reading out what the autocomplete suggestions are, or is there more to it?

?? As previously noted, all of the tools I tested on that sample page had a feature in their settings that allowed me to pre-populate the expected values for the fields that the tool supported. As I recall, all of the browsers also afforded me the possibility to store multiple "profiles", and for my test I created a full profile for "John Q. Tester" (complete with dummy cc-number data) in each browser and password-manager I tested. For fields that are supported, the expected result is that the user-agent presents the option to auto-fill the fields (and that option needs to be signaled to the non-sighted user as well). If accepted, the values are added, at which point the screen reader user can then verify the value in any individual input. I do not think that a screen reader user would want to hear each field being populated (i.e. a spoken run-down of all fields being filled would be overly verbose), however the "hint" that shows the user the possible profile choices (when more than one exists) MUST be exposed to the screen reader user, as that hint is a critical decision factor. (Does that answer the question?)

@mnoorenberghe notes:

You would also need a way to save addresses, credit cards, and passwords in the browser so that the suggestions would be something expected.

This functionality already exists in all of the tools I tested. Firefox was the least "friendly" in that there does not appear to be a master page where I can add or modify field data strings (see: https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms?redirectlocale=en-US&redirectslug=Form+autocomplete), however in Chrome and other Blink-based browsers (Vivaldi, Brave) it's generally Settings >> People >> Addresses and more. It appeared at the time of testing that neither IE nor Edge support this attribute.

IMO it would be best to get all browsers to only parse the autocomplete tokens that they ever use, like Firefox and Safari do, and then the existing WPT will be a good starting point assuming browsers don't make mistakes

IMO, it would be best if browsers supported all of the token values authored into HTML 5 (and that have been there for a number of years now), similar to what at least one password manager (Last Pass) does. I'd be curious to know if there is a technical hurdle that needs to be overcome to extend the exact functionality being seen for some inputs to the remaining inputs. Additionally, comments on this thread (@battre, @thw0rted) suggest that there may in fact be a need for more token values, not less.

Finally, @domenic also suggests:

Just skimming, it seems that there are at least some values which are supported correctly by no software, and maybe our default course of action there should be removal.

Anticipating thinking along those lines, the WCAG 2.1 Rec "imported" the existing list of token values directly into that spec, as part of a new WCAG 2.1 Success Criteria (see: Success Criterion 1.3.5 Identify Input Purpose - https://www.w3.org/TR/WCAG21/#identify-input-purpose as well as Input Purposes for User Interface Components - https://www.w3.org/TR/WCAG21/#input-purposes)

Should the bigger decision be to remove some of the token values from "active" support, it is critical that the status be changed to "deprecated" and not "obsolete/non-conforming", as we took that list in good faith to be used for a secondary purpose. (See: Understanding SC 1.3.5 - https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html) It would be counter-productive to start generating error warnings against that token list this late in the game (as we've essentially built on top of what was previously published - so please do not yank the floor out from under our work :D )

HTH

[foolip]

Thanks @johnfoliot, that does suggest that automating tests for this has at least one more part to it. You 'created a full profile for "John Q. Tester" (complete with dummy cc-number data)' and presumably automated tests for this would have to do the same, since a browser starts out without anything to autofill.

However, those settings are presumably tied to browser-specific UI, and not all browsers might have separate settings for all values or all UI languages. That's a wrinkle.

So, I'm afraid that automating the tests for this seems like more effort than it's probably worth, ultimately. Manual testing and generating reports like https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research is certainly enough to figure out the current state of things.

[annevk]

I'm not sure how to turn this issue into something actionable for the HTML Standard. Anyone any recommendations?