Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Autocomplete values for SC1.3.4 #651

Closed
guyhickling opened this issue Jan 1, 2018 · 1 comment
Closed

Autocomplete values for SC1.3.4 #651

guyhickling opened this issue Jan 1, 2018 · 1 comment

Comments

@guyhickling
Copy link

The Understanding document for this SC1.3.4 contains an apparently quite arbitrary list of autocomplete values with no explanation about how they are derived or where they come from, or how they should be used for WCAG compliance. The immediate question many readers will ask is "Do browsers recognise this list yet?". Only web developers would be aware that this is actually the same list that appears in the HTML5 spec under "Autofill". It is the list of valid values for the autocomplete attribute for input fields so, yes, most browsers and other user agents already recognise and implement it. But the Understanding document currently says nothing about that.

So please, for everyone's benefit, amend the Understanding document to say that's where this list comes from and why it is being used.

Should we be worried about tying this SC1.3.4 directly to the HTML5 spec? It's fine to do that, because this SC is about enabling browsers and AT to use any information available to identify a field, and any value contained in the autocomplete attribute does exactly that. Values in the HTML spec are also future proof; suppose next year another 10 values are added to the HTML list. Then as soon as browsers implement those new values that will be another 10 field purposes that are identified programatically for SC1.3.4 compliance.

Should they be listed here?

In fact, I would go further and suggest that the list of autocomplete field types should be removed from the Understanding because otherwise it will need to be updated any time new values are added to the HTML5 version - if that is not done then the SC would imply that only the ones in its own list should be followed, not any new ones added later.

Either the list should be replaced by a reference to "the list of 'autofill detail token' options and values that appear in the HTML5 specification section 4.10.19.8.1", or it should be made clear in the Understanding document that the list there could become out of date and users should refer to the HTML5 spec for an up to date list of options and values. (It's already incomplete since it does not include the shipping/billing options, presumably for simplicity.)

Other references to the list in this Understanding document should also be improved for clarity. For instance under "Meeting the Success Criteria" (or shouldn't that be "criterion"?), the first item in bold text should read "Providing the purpose of a field or control using the HTML autocomplete attribute" or similar.

For HTML only

The Understanding should also make clear that this list is specifically applicable to web pages written in HTML; these particular fields cannot be made programmatically determined in PDF or Word documents as they do not know about the list, and the Understanding ought not to imply they could use it.

@awkawk
Copy link
Member

awkawk commented Jan 24, 2018

(Official WG Response)
The SC has been updated to use what browsers currently implement, and there was already a great deal of overlap between what was required for inputs, and the HTML list.

Once implemented, it seems unlikely that the browsers (and therefore the HTML spec) would reduce the list, unless there is a security issue with particular items.

In future iterations that expand this requirement, the working group hopes there will be a stable specification to directly reference for that purpose, but this seems to be a reasonable starting point.

The SC text has been updated to show that it should only be used in technologies that support it, and the understanding and techniques will clarify that.

@awkawk awkawk closed this as completed Jan 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants