SC 1.3.5 fields with correct autocomplete inside form with autocomplete="off"

[goetsu]

Hi,

I'm wondering if such case will be considered compliant with Sc 1.3.5

<form autocomplete="off">
...
<label for="name">Family name</label>
<input id="name" autocomplete="family-name">
...
</form>

[awkawk]

I would say yes, this conforms.

The spec doesn't explicitly forbid this type of use, except to suggest that the browser is being informed that it isn't expected to autofill:

The "off" keyword indicates either that the control’s input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the user agent to prefill the value for him; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values.

The Mozilla docs make it clear that modern browsers are selecting to not honor the "off" options for autocomplete, so from an accessibility perspective we can still take advantage of that. This is subject to accessibility-supported concerns, so if browsers all honored the off setting and there was no way for plug-ins or AT to take advantage of the family-name information then the answer would be that this doesn't conform.

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

[goetsu]

@awkawk mozilla doc is only about the login/password input on my case it's more a generic question for any fields that need autocomplete regarding 1.3.5. So the question is more to know if removing native / plugin autofill behaviours will be considered as a failure with 1.3.5.

If I only read the SC 1.3.5 I would personally say no as purpose of fields are correctly identified and can be programmatically identified regardless there is or not autofill capability.

[patrickhlauke]

the point of the SC isn't whether or not the browser actually autocompletes or not. it's whether or not fields are programmatically/explicitly identified. the fact that autocomplete - which is only one possible way to satisfy this SC, though from a practical point of view the only sensible one that has any actual real-world effect at the moment, since to my knowledge there aren't any extra tools/AT that take advantage of anything else like RDFa or similar - also...autocompletes in browsers is more of a happy accident/side effect.

long story short yes, i'd say that this passes.

[jake-abma]

If I only read the SC 1.3.5 I would personally say no as purpose of fields are correctly identified and can be programmatically identified regardless there is or not autofill capability.

exactly, it's not about autofill, but if it can be programmatically determined, and it can.

[mraccess77]

I would be inclined to allow autocomplete off on the form and autocomplete on the inner inputs to provide this information and block browsers from autofill. This would help organizations that have some concern about using this attribute but want to meet WCAG.

[kantoche]

Hi,

What @goetsu points out in his remark is that the presence of an autocomplete="off" attribute (in the form element) inhibits the autocomplete values associated with the form controls.

With regard to the first benefit listed in SC 1.3.5, can we simply say that "People with language and memory related disabilities or disabilities that affects executive function and decision-making benefit from the browser auto-filling personal information" even if autocomplete is not effectively managed at the form level?

So, shouldn't the H98 technique then be completed by a third test condition saying that the parent form should not contain an autocomplete="off" attribute (except for security concerns)?

The MDN article already pointed out by @awkawk says in its introduction: "It is important to know that if you turn off autocomplete, you are breaking the rule 1.3.5: Identify Input Purpose in WCAG 2.1. If you are making a website that should follow WCAG, you should use autocomplete with autofill." This point of view is worth to be considered.

[awkawk]

The MDN article already pointed out by @awkawk says in its introduction:

Ha! I missed that part. But, I also don't agree with it... :)

[alastc]

We seems to be heading towards:

• It is ok (if not desirable) to use autocomplete=off on a form, so long as the relevant fields have autocomplete with the appropriate value.
• The MDN article might need updating.

Has anyone checked that the browser still associates the autocomplete value on the field if it is "off" on the form?

[patrickhlauke]

if you mean "is the property still queriable programmatically", then yes - at least in Chrome (not had time to check others, but i'd be surprised if that wasn't the case.

[patrickhlauke]

i've edited the MDN reference to the following:

Note that the WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose does not require that autocomplete/autofill actually work - merely that form fields that relate to specific personal user information are programmatically identified. This means that the criterion can be passed (by adding the relevant autocomplete attributes to individual form fields) even when autocompletion for the form itself has been turned off.

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

[patrickhlauke]

as an aside, note that Firefox devtools seem to never correctly expose the autocomplete property (even on a form without autocomplete="off", when autofill actually works, an input with an explicit autocomplete just returns null/empty when you query its autocomplete prop)

[detlevhfischer]

Proposed Working Group Reply (lifted from @patrickhlauke's comment):

Thank you for raising this issue.
The WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose does not require that autocomplete/autofill actually work - merely that form fields that relate to specific personal user information are programmatically identified. This means that the criterion can be passed (by adding the relevant autocomplete attributes to individual form fields) even when autocompletion for the form itself has been turned off.

[alastc]

Agreed response from the group:
It is ok (but not desirable) to use autocomplete=off on a form, so long as the relevant fields have autocomplete with the appropriate value. The local autocomplete values on each input are still programmatically available.