Tech H98 - autocomplete - should test also include check of wrong application of autocomplete?

[detlevhfischer]

The current test procedure of https://www.w3.org/WAI/WCAG21/Techniques/html/H98 checks whether inputs that relate to the user and map on the HTML autofill values correctly use the autocomplete attribute. I gather that authors must not use autocomplete on fields that are NOT about the user. So if I book a ticket for me and my spouse, the fields relating to my spouse's name, email address etc. must not use the autocomplete values. Should the Technique test that autocomplete is not used on fields relating to other persons? (BTW I am not sure what would be recommended for these: autocomplete="off", or no autocomplete attribute?)

[mraccess77]

I think it might also be useful to have a failure of autocomplete being used on a field that is not about the user since the some on the group seemed to agree it was a failure. However, the SC talks about programmatic purpose of input about the user but doesn't seem to forbid use of autocomplete on other fields -- so I am concerned that failing or preventing other fields from using autocomplete might be overstepping what is required by WCAG 2.1. Essentially can we really prevent or fail autocomplete's use on other fields?

[johnfoliot]

Hi All,

...the SC talks about programmatic purpose of input about the user but doesn't seem to forbid use of autocomplete on other fields

The scope of SC 1.3.5 is to ensure that fields related to the user are properly annotated with the required taxonomy (metadata) term https://www.w3.org/TR/WCAG21/#input-purposes(s), of which today there is but one technique to do so: use the @autocomplete attribute. As mentioned previously, work is happening on other mechanisms (attributes) that would allow the "attaching" of these values to the appropriate inputs using different techniques / methods.

HTML5 neither recommends nor forbids using @autocomplete on fields that are NOT related to the end user, but the premise (and assumption) of the attribute when created at HTML5 was that the data stored on the end-user's computer would be related to them, not others. If we think about outcomes, that sort of makes sense: if I had an HR form that collected data on all of my employees, I'd only really expect the inputs related to me would be tagged with the autocomplete attribute, as that would likely be the only data I have stored locally on my machine. This however is a function of the attribute, whereas the goal of our SC is to attach the taxonomic term to the element so that it can be expressed in different modalities, which we achieve today by using that attribute (but we might be able to use a different attribute in the future).

In the use-case where you were collecting data on myself and my family, you might consider adding autocomplete="family-name" for those fields that we shared (like Family name, or perhaps mailing address?) but the functionality of @autocomplete there may or may not be expected or even accurate (I can see it as a benefit in some instances and a detriment in others; my eldest daughter is now using her married name, and my girlfriend uses her maiden name, so for my family, tagging all "Family name" inputs with @autocomplete would be wrong half the time...)

So... the requirement of SC 1.3.5 is for fields related to the actual user ONLY. Inputs related to other users are out of scope for this SC, however authors can (if they believe correct) extend @autocomplete values to input fields external to the actual user (I'd caution against it, but it cannot be forbidden).

Essentially can we really prevent or fail autocomplete's use on other fields?

The bottom line is that adding the metadata terms to fields unrelated to the end user is out of scope, but not invalid or forbidden when using the @autocomplete technique (but, if/when we get our new attribute(s), such as @purpose, then using @purpose on inputs other than those directly related to the end user may very well be non-valid, and a Failure Technique there would be appropriate for that technique).

HTH

JF

On Wed, Nov 28, 2018 at 10:57 AM Jonathan Avila notifications@github.com wrote:

I think it might also be useful to have a failure of autocomplete being used on a field that is not about the user since the some on the group seemed to agree it was a failure. However, the SC talks about programmatic purpose of input about the user but doesn't seem to forbid use of autocomplete on other fields -- so I am concerned that failing or preventing other fields from using autocomplete might be overstepping what is required by WCAG 2.1. Essentially can we really prevent or fail autocomplete's use on other fields?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/544#issuecomment-442522164, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c6JdSOGtX9zRMEZt3NZwx6e6Djvrks5uzsCKgaJpZM4Y32xj .

-- ​John Foliot | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[johnfoliot]

Detlev also wrote:

...checks for inputs that relate to the user and map on the HTML autofill values

Hi Detlev,

I think part of the problem is that we keep getting caught up in the technique, and not the requirement.

The SC DOES NOT say that the inputs need to map to the autofill values, and in fact states (for) "The input field serves a purpose identified in the Input Purposes for User Interface Components section https://www.w3.org/TR/WCAG21/#input-purposes", and the link then points to the full list of purposes, which is part of our WCAG 2.1 Spec (Section 7). The fact that our list and the values for @autocomplete are identical today is secondary (and there is some rumbling that HTML5 may narrow down that list, due to lack of robust support in all browsers, at which our list might be larger / longer than HTML5's).

The moment we stop calling them the "autocomplete tokens" and instead start calling them the "purpose tokens in WCAG 2.1" is the moment when we start to actually disambiguate the requirement. Yes, today the only viable technique is to use the @autocomplete attribute, but the over-arching point of this 1.x.x SC (= Perceivable) is to attach the metadata, not provide the functionality that is part of @autocomplete, and as I continue to remind the group, there are other techniques that are being worked on now (within the Personalization TF, operating under the APA Charter).

I continue to assert that choosing our words carefully here is important, and that collectively we need to stop thinking that the only purpose of this SC is to provide auto-form-filling functionality: that is a benefit of making the inputs programmatically determinable (but not the only benefit), and if that were the only point of the SC, it would have taken a different number (either a 2.x.x = Operable, or a 3.x.x = Understandable)

JF

On Wed, Nov 28, 2018 at 9:35 AM Detlev Fischer notifications@github.com wrote:

The current test procedure of https://www.w3.org/WAI/WCAG21/Techniques/html/H98 checks for inputs that relate to the user and map on the HTML autofill values thnat they correctly use the autocomplete attribute. I gather that authors must not use autocomplete on fields that are NOT about the user. Do if I book a ticket for me and my spouse, the fields relating to my spouse's name, email address etc. must not use the autocomplete values. Should the Technique test that autocomplete is not used on fields relating to other persons? (BTW I am not sure what would be recommended for these: autocomplete="off", or no autocomplete attribute?)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/544, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c5QyhqKmeBtmaKlJD_Z2VW8HV4_Bks5uzq00gaJpZM4Y32xj .

-- ​John Foliot | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[detlevhfischer]

Hi @johnfoliot , all I do understand that this is not about the autocomplete functionality but about a taxonomy to be used by AT - a set of what you call "purpose tokens" above. I accept the argument that this Technique is scoped to fields that "relate to the user of the content and pertain only to information related to that individual". So it is probably better not to include tests on inputs that are not in scope . Still, as you and others know, people we advise will pose questions as to how they should treat other fields that may relate to other people (today, in the absence of other taxonomies or mature AT benefiting from implementations of this SC). For this quite practical question, a clear answer seems to be still missing. Telling a customer that they "might consider adding autocomplete" would not be terribly helpful. Any views as to scenarios where you would recommend, or advise against, autocomplete on fields not related to the user would be very welcome.

Detlev

[johnfoliot]

Hi Detlev,

Fair point. To be safe, I'd personally counsel to ONLY use @autocomplete on input fields directly related to the end user, and avoid any of the potential scenarios where "might consider" would be a potential answer (i.e., keep it simple).

Respectfully, it keeps coming back to what data can we safely presume will be stored on the user's local machine that would pattern match inputs on a random form, and while some power-users may have multiple profiles on their browsers (I do, on the 5 browsers I have that support @autocomplete - but I'm a freak like that), however most users (I would suggest) probably only have the one profile - themselves (i.e. data pertaining to them), so using that assumption and corresponding logic, I would NOT add @autocomplete to any other form input.

The HTML5 spec states this regarding the use of @autocomplete: User agents sometimes have features for helping users fill forms in, for example prefilling the user’s address based on earlier user input. (My read and take on this is that the intent was for just data related to "the user" [singular], but the spec is not more granular or specific than that, so any guidance I would give is based upon this presumption, but it's not a declared mandate or requirement either way.)

HTML5 Spec: further says any input of type="text" with a few exceptions, like type="tel" autocomplete="tel". Other types include URL, MultiLine (one instance), password, month, email, and numeric.

W3C HTML Validator: (See above) - it does not appear that the validator has any AI logic to determine if the input field is scoped to a particular user, so it would accept the attribute on ANY input of the input types listed above (but would generate an error if you tried to add @automplete to input type="checkbox").

WCAG 2.1: Scoped to inputs (or the appropriate type) related to the end user only. (This then further suggests a manual verification at compliance testing time)

HTH

JF

On Thu, Nov 29, 2018 at 3:24 AM Detlev Fischer notifications@github.com wrote:

Hi @johnfoliot https://github.com/johnfoliot , all I do understand that this is not about the autocomplete functionality but about a taxonomy to be used by AT - what you call "purpose token" above. I accept the argument that this Technique is scoped to fields that "relate to the user of the content and pertain only to information related to that individual". Still, as you and others know, people we advise will pose questions as to how they should treat other fields that may relate to other people (today, in the absence of other taxonomies or mature AT benefiting from implementations of this SC). For this quite practical question, a clear answer seems to be still missing. Telling a customer that they "might consider adding autocomplete" would not be terribly helpful. Any views as to scenarios where you would recommend, or advise against, autocomplete on fields not related to the user would be very welcome.

Detlev

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/544#issuecomment-442763753, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c0qpWl-K_MsUZuqUJ8p876BPQH-Mks5uz6fBgaJpZM4Y32xj .

-- ​John Foliot | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[alastc]

In the case of H98, I don't think we should add a reverse-check for mis-use of autocomplete, that would be better done as a separate failure techinque.

Should we have a failure technique? I think that could be controversial, until profiles and multiple tokens are better defined I don't think we could say it was always a failure.

[alastc]

I think this one is pretty bottomed-out now, given the recent mega-thread on the AG list, my conclusion was:

an input would fail only when it is asking for information about the user that matches one of the related metadata tokens, and it does not have any (accessibility supported) metadata included.

Which means adding those values to other inputs is essentially not in scope. Not desirable, but not something to fail the SC.

Any objection to closing this?

[mraccess77]

@alastc could you summarize the outcome because it's not clear to me what the final decision was.

[alastc]

I thought I just had in the comment above!?

There was a lot of back and forth, but I think that was the crux of it.

So to the question:

should test also include check of wrong application of autocomplete?

No.

[awkawk]

WG Response: Thank you for commenting. An input would fail only when it is asking for information about the user that matches one of the related metadata tokens, and it does not have any (accessibility supported) metadata included.

That means adding those values to other inputs is not in scope for Success Criterion 1.3.5. No requirement exists to check for the wrong application of autocomplete.