Purpose of Controls - (Part 1): Form inputs

Hi all,

Regarding the fixed list of terms that I believe is a critical part of this
SC: splitting the list into two columns (form inputs || controls, buttons,
link-types), I'd like to focus first on form inputs. If we can come to an
agreement on this part of the proposed SC, then we'll have effectively
addressed close to half of the terms currently being proposed.


Currently, HTML 5 (specifically HTML 5.1 2nd Edition
​ and beyond
)
​
has the @autocomplete attribute (
​​
https://www.w3.org/TR/html51/sec-forms.html#element-attrdef-autocompleteelements-autocomplete),
that has a fixed token list as part of the specification: the value of the
@autocomplete attribute can only be one of those fixed values.

While "name", "family name" and other related personal identifiers do have
cultural issues related to them, they are but a few of the 51 token values
that are there: terms such as *street-address, address-line1,
address-line2, address-line3, city, area, postal-code, country, email,
**cc-name,
cc-number, cc-exp-month** (*which are all also part of that list), have
already been internationalized and are being used by developers in numerous
languages and locales today (e.g. a token term of *cc-number *is the fixed
value string that represents the idea (PURPOSE) related to the form < label
> of クレジットカード番号 in Japanese, Kreditkartennummer in German,
หมายเลขบัตรเครดิต in Thai, etc., and developers in those locales appear
clear today on how to use the autocomplete tokens). Additionally, virtually
every major browser supports that fixed list of tokens (
https://caniuse.com/#search=autocomplete), and web developers around the
globe are already using that token list when building their forms.

Creating a requirement that essentially says that if and when you have a
form input that maps to one of those "common input terms", then the SC
mandates the use of @autocomplete with the token value seems on the surface
to be a fairly light lift and demand for accessibility needs. In
conversations with multiple developers of all stripes, the overall feedback
*I've* received is that this is a bit of a no-brainer (fully recognizing my
enthusiasm and passion for this is likely clouding my input receptors :-) )
Still, it really isn't asking for that much...

The full list of token values, along with prose definitions and examples
can already be found in the HTML 5 specification at:
https://www.w3.org/TR/html51/sec-forms.html#autofill-field .

Finally, to address any uncertainty or i18n concerns, we could also
re-reference the current NOTE from the HTML 5 spec in our Understanding
document as well:

Generally, authors are encouraged to use the broader fields rather than the
narrower fields, as the narrower fields tend to expose Western biases. For
example, while it is common in some Western cultures to have a given name
and a family name, in that order (and thus often referred to as a
first name and
a surname), many cultures put the family name first and the given name
second, and many others simply have one name (a mononym). Having a single
field is therefore more flexible.



​So... can we arrive at any consensus​ around the fixed token list in HTML
5? The current list of 61 proposed buttons, controls and link types still
needs to be looked at, but if we can clear form inputs now, we'll have made
good progress.

Thoughts?

JF
-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion