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

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

I agree with John on this.  I think it would be very simple for someone to write a favlet/extension that would take the autocomplete values can replace them with symbols.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
jon.avila@levelaccess.com
703.637.8957 office

Visit us online:
Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y/> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>

See you at CSUN in March!<http://info.levelaccess.com/CSUN-2018-Sessions.html>

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Thursday, February 22, 2018 1:09 PM
To: Katie Haritos-Shea
Cc: lisa.seeman@zoho.com; w3c-wai-gl@w3.org
Subject: 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<mailto: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<tel:703-371-5545> | ryladog@gmail.com<mailto: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<mailto: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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion