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

> SC 1.3.4 is that "foot in the door" that allows us to start socializing
the need for robust metadata to support personalizations.

This is far from a new topic in accessibility.

There are very mature taxonomies using robust metadata to support
personalization that is been standardized for 10 plus years (by IMS, ISO/IEC,
IEEE, and others), that have been mostly developed for the educational
space (in the a11y context) that include cognitive needs but could
certainly be incorporated into, and improved upon in a W3C Semantic
Metadata for Personalization spec.

There are opportunities where the W3C might want to update and include new
interaction paradigms, to such a spec that Personalization Semantics
Content Module 1.0 is a perfect start and possible home for.

But, Metadata and Personalization taxonomies are not the problem. The
problem, as most of us know, is the 'delivery method' for utilizing those
taxonomies. Having developers put markup on each and every form element
(sort-of the case for 1.3.4) or controls, symbols, and every other user
interface elements/components - is too much of a burden, for such a small
outcome IMO.

That delivery problem/mechnism needs to be addressed from a comprehensive,
well though-out and designed approach.

A great place to address that problem would be the W3C using a modern
machine readable AI approach that removes the heavy lifting from the
development community, and utilizes some of its existing specs.

I actually do not want to see a 2.1 SC that says 'must use HTML 5.2
autocomplete on form fields for covered existing tokens'. Because, as the
SC stands today, it will not allow for symbols to be rendered for
identifying the purpose of those fields. And SCs are not meant to be
"improved upon" at some point. They become a permanent requirement, even
when you come up with the better idea in 2.2.

The functionality that is in HTML itself for autocomplete, just like other
new HTML components that were brought in specifically to improve
accessibility - are wins in themselves.

I so understand why some folks want to start something - somewhere - to
open the road to eventually allow in accessibility metadata for
personalization.
I wholeheartedly want
that to happen - but not via this one HTML 2.1 attribute for forms as a
microset - that cannot lead us to the full result - but leaves developers
still having to do it.

The tool to 'trigger' the functionality of accessibility (and other) metadata
and personalization taxonomy injections - may indeed come from an HTML
element - or RDFa, or microdata, or .... - but this web-wide issue as
Brooke noted - needs a comprehensive, well though-out and designed
approach. Not a last minute Hail Mary that doesn't even land on the field.


** katie **

*Katie Haritos-Shea*
*Principal ICT Accessibility Architect *

*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>

*Cell: **703-371-5545 <703-371-5545>** |* *ryladog@gmail.com
<ryladog@gmail.com>* *| **Oakton, VA **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*

People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to
dictate where we are going.

On Thu, Feb 22, 2018 at 9:02 AM, John Foliot <john.foliot@deque.com> wrote:

> ​​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
>