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

>  *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.*

With all due respect, SC 1.3.4 *DOES NOT* demand that authors put markup on
"each and every form element". I think you are misunderstanding what the SC
is asking for.  For example, the following snippet does not require *any*
additional @autocomplete attributes or token values:

<fieldset>
   <legend>Some people still don't understand this SC</legend>
      <label for="answer_1">True</label>
      <input type="radio" name="understand" value="true" id="answer_1">

      <label for=" answer_2">False</label>
      <input type="radio" name="understand" value="false" id="answer_2">
</fieldset>


There are 53 token values defined in autocomplete, and ONLY THOSE INPUTS
that correspond to the token values require being marked up.  Additionally,
adding markup to other "*...controls, symbols, and every other user
interface elements/components...*" is out-of-scope for SC 1.3.4, and has
been since before publishing our CR recommendation.

*SC 1.3.4 is tightly scoped to specific form inputs *ONLY*.*



>  *Because, as the SC stands today, it will not allow for symbols to be
rendered for identifying the purpose of those fields.*

​Huh? Please show the quoted text that supports your assertion​.

The Success Criteria today simply states the following:

The meaning of each input field collecting information about the user can
be programmatically determined
<https://www.w3.org/TR/2018/CR-WCAG21-20180130/#dfn-programmatically-determinable>
 when:

   - The input field has a meaning that maps to the HTML 5.2 Autofill field
   names <https://www.w3.org/TR/html52/sec-forms.html#sec-autofill>; and
   - The content is implemented using technologies with support for
   identifying the expected meaning for form input data.

I do not see any restrictions as to what can or cannot happen, only that
the "meaning" (or purpose) of those specific form inputs (i.e. the ones
identified and defined by the @autocomplete tokens) can be *programmatically
determined, *and that the means of making the input programmatically
determinable uses a methodology that identifies or facilitates the expected
'response' or purpose of that input (aka element-level metadata). That's
it, that's all.

And while *today* we have the @autocomplete attribute as the 'best' [sic]
Technique at hand, we are also seeing an alternative technique being
proposed by the Personalization Semantics Module, and the creation of the
new aui-field attribute
<https://w3c.github.io/personalization-semantics/content/index.html#field-explanation>.
Additionally, while *aui-field* remains a *proposed* new attribute in
February 2018, there is already an existing proof-of-concept that shows how
*aui-field* *CAN* support the use of symbols. (See: https://a11y-resources.
com/developer/adaptable-ui-personalisation#aui-field)

I believe your concern is currently unfounded.

JF


On Thu, Feb 22, 2018 at 9:37 AM, Katie Haritos-Shea <ryladog@gmail.com>
wrote:

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


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

Advancing the mission of digital accessibility and inclusion