Re: Use of ARIA to satisfy 'Identify common purpose' SC

​​Katie wrote:

>  Here is what I am missing. We already have autocomplete in HTML. It is
not going away. It is an awesome feature of HTML. It does and will help us
all.

​Indeed, however today, the use of @autocomplete is author voluntary. As
you note, using that attribute benefits 'all of us', but today, only when
it is provided by the content author. With this new SC, going forward we'll
see it being used more extensively​, effectively ensuring that the benefit
it does bring is extended to more users. We're making using @autocomplete a
(RFC 2199) MUST instead of a MAY, because we have enough evidence to
support the fact that it benefits users with disabilities, in many
instances disproportionately greater than for all users.

The *first goal* then is not to reinvent the HTML5 wheel, but rather to
strengthen it.


> What this SC is doing is trying to force authors to do something more
than already exists in the HTML - by making developers provide a value for
each and every form field on their pages to enable some version of a
secondary purpose name - above and beyond the accessible name.

​Actually, no, not "...​each and every form field on their pages...", but
rather only those form inputs covered by the existing tokens. (see Bullet
1: "
The input field has a meaning that maps to the HTML 5.2 Autofill field names
​;...​
​"​), and we're not asking for *more* than the current tokens, simply that
they be used. The author lift here is actually quite small.

Additionally, going forward, I believe we need to stop using the term
"name" when discussing this requirement - it's not a (accessible) name,
it's a *purpose*, which are two completely different concepts.

The *second goal* however is that the @autocomplete attribute with it's
fixed list of predefined token values is a *rudimentary taxonomy,* one that
we can leverage today, to, as Jon Avila pointed out, *benefit numerous
users with various and different types of disabilities*.

And, as Alastair notes, it
"... starts a new chapter in our accessibility training materials, we
haven't had
​ (JF: required?)​
non-screenreader metadata previously."
​ Yes, the @autocomplete attribute is currently being used by User Agents
to, well, auto complete form inputs, but the method by which it does so is
by using a specific form of metadata, applied to those form inputs.

SC 1.3.4 is that "foot in the door" that allows us to start socializing the
need for robust metadata to support personalizations. Katie, it *IS* hard,
and trying to eat the "COGA elephant" in one sitting is even harder. The
learning curve for content authors to implement @autocomple is short and
easy (a positive thing) but I bet most authors today do not understand the
accessibility benefits of using @autocomplete, or more broadly of using
metadata at the element level, which is a huge ultimate goal in my mind.

With SC 1.3.4, we now have a reason to educate them further, and at the
same time have the larger discussion about personalization metadata in
general, so that when a spec such as the Personalization Semantics Content
Module <https://w3c.github.io/personalization-semantics/content/index.html>
becomes
a W3C REC, we've already started the educational process to support that.


>  Or, are folks wanting to have a new SC that just says 'always use HTML
5.2 autocomplete attribute on forms' and identify the SC as Autocomplete,
instead of trying to stuff 'purpose of control' metadata via this attribute
as well?

​Fair question. There may be a measurable value in renaming this SC to
something that by its 'handle' is closer to encapsulating what we are
seeking​.

I could support that *editorial* change as long as it does not impact our
Timeline or the W3C process. Possible new 'handles' or SC identifiers could
include:


   - ​Common Inputs
   - Autocomplete​

   - Automated Inputs
   - Metadata on Inputs  (<< This introduces the concept of metadata, which
   may be a positive reinforcement)
   - (something else?)

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

Advancing the mission of digital accessibility and inclusion