Does autocomplete attribute need appropriate type?

[ajanec01]

This is a continuation of the conversation we had on whether or not the autocomplete attribute value needs to be used with a specific type attribute value (as per the HTML spec)? The question is raised in the context of sc 1.3.5 Identify input purpose.

This issue is closely related to #1541 and I don't think we can submit autocomplete attribute has valid value for a review until we resolve it.

I've created two [test pages for the autocomplete attribute]. One for autocomplete with a correct control group and one for autocomplete with an incorrect control group. The findings are:

• Firefox is providing suggestions for both bday-month and username regardless of the type;
• Chrome is providing suggestions for username regardless of the type and does not provide any suggestions for bday-month
• Safari behaves just like Chrome

In summary, it looks like the browsers do not care about the type and do not provide suggestions/ autocompletion for all autocomplete attribute values.

The situation is slightly complicated given that sc 1.3.5 does not require autocompletion but for the property to be programmatically identifiable. If the rule was purely about autocompletion then I'm sure we should stick with the spec but because using autocomplete for 1.3.5 has somewhat become a secondary purpose of the autocomplete, I'm not so sure the rule should be so strict on the correct type attribute part, especially given that browsers do not seem to care.

It would be good to have a discussion about this during the next call.

[WilcoFiers]

As discussed on the call, the CG agrees with the suggestion.

[ajanec01]

Results for autocomplete with the correct control group tests

As per our discussion in the last CG call, we decided to see how/ if browsers respect the suggestions from the HTML spec regarding the type attribute value being appropriate for an autocomplete attribute value. I’ve put together two pages that have form fields for all types of input purposes listed under sc 1.3.5. One page for form fields with the incorrect control group and the other for fields with the correct control group (links in the first comment). All tested on desktop machines in Firefox, Chrome, and Safari.

For the page with incorrect type value, I used type=”tel throughout with the exception of fields where the type=”tel was appropriate. For fields where type=”tel” was allowed, I used type=”number”. This was the only possible solution given that I wanted to avoid the default validation for other type values.

For the page with correct type attribute value, I used a few type=”number” to compare results with the fields from the “incorrect” page, 1 textarea as it was required for street-address, and 1 select element to confirm some observations.

“Autofilling” does not work for select and textarea elements. It could've been expected for the select element but probably not for the textarea. <input type=”number” /> provides suggestions on mouse click in Firefox and Chrome so it was assumed that the textarea could do the same.

Summary for page with inappropriate type:

• Form fields- 53
• Form fields with type=tel- 45
• Fields with type=number- 8:
• • tel
• • tel-country-code
• • tel-national
• • tel-area-code
• • tel-local
• • tel-local-prefix
• • tel-local-suffix
• • tel-extension

Summary for page with appropriate type:

• Form fields- 53
• select element- 1
• textarea element- 1
• Form fields with implicit type=”text”- 45
• Fields with type=number- 6:
• • cc-exp-month
• • cc-exp-year
• • transaction-amount
• • bday-day
• • bday-month
• • bday-year

Below are lists with autocomplete values that do not support auto-filling. It was easier to list those as there are fewer fields that are not auto-filled than the fields that provide suggestions. For those lists, the autocomplete values that do not support auto-filling (the select and textarea elements) are not included to reduce the noise. Each browser section has a summary that indicates the number of fields that supports auto-filling for each page.

Firefox

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with incorrect type:

• new-password
• current-password
• cc-number
• cc-csc

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with correct type:

• new-password
• current-password
• cc-number
• cc-csc

Note: All input fields which had type=number in the incorrect page have suggestions on the page with the correct type. Conversely, only transaction-amount has a suggestion on the incorrect page.

Note: I realised that I had made a mistake and there were some fields with the same name value but different autocomplete. Those fields were providing auto-filling for each other which indicates that Firefox is also looking at the value of the name attribute. Interesting, given that there is no such suggestion in the spec. Not tested in other browsers.

Summary for Firefox

• autocomplete values that support auto-filling with the incorrect control group - 49
• autocomplete values that support auto-filling with the correct control group - 47 (less by select and textarea)

Chrome

These were tested without logging in to an account.

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with incorrect type:

• honorific-suffix
• nickname
• organization-title
• new-password
• current password
• address-level4
• cc-number
• cc-exp
• cc-exp-month
• cc-exp-year
• cc-csc
• language
• bday
• bday-day
• bday-month
• bday-year
• sex
• url
• photo
• impp

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with correct type:

• nickname
• organization-title
• new-password
• current password
• address-level4
• cc-number
• cc-exp
• cc-exp-month
• cc-exp-year
• cc-csc
• language
• bday
• bday-day
• bday-month
• bday-year
• sex
• url
• photo
• impp

Summary for Chrome

• autocomplete values that support auto-filling with the incorrect control group - 33
• autocomplete values that support auto-filling with the correct control group - 32 (less by the textarea; autocomplete for select was not supported with incorrect type)

Safari

The fields were tested with only the other forms option checked in the autofill preferences.

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with incorrect type:

• country
• postal-code
• cc-number
• cc-csc

autocomplete value for fields that did not provide a suggestion/ auto-filling- page with correct type:

• cc-number
• cc-csc

Note: Interestingly, the country and postal-code fields do not provide suggestions when an incorrect type is used but the entries provided for those fields appear in suggestions for fields with the correct type. These two instances appear to be the only case where the auto-filling works as per the HTML specification.

Note: In contrast to Firefox and Chrome, Safari does not provide suggestions for <input type”number” /> on mouse click. It seems to be because the autosuggestions can be triggered only by using the arrow keys which of course are then used by the input to change the value of the input. However, the entries for fields with input=”number” are saved and provided as a suggestion on the page with incorrect type.

Summary for Safari

• autocomplete values that support auto-filling with the incorrect control group - 49
• autocomplete values that support auto-filling with the correct control group - 49

Summary

Browsers mostly do not care if the type is correct or not for an autocomplete value and provide suggestions. The country and postal-code autocomplete values on Safari were the only case in which the auto-filling did not work with the incorrect type but it did work with the correct type.

[Jym77]

@ajanec01 this looks like it was resolved by #1583 and can now be closed? 🤔