Re: SC 1.3.4 - Understanding doc update

​​Katie wrote:

>  Because requiring authors to add markup to everything, which the
personalization identified portion of this SC is trying to do (via tokens
that match the autocomplete values), sets a precedent for
sending personalization down that road. That, in my opinion, is not the
best way to tackle this very complicated problem that the web has been
trying to solve for some time.

...and yet... that is *exactly* the path that the Personalization Module
and the COGA TF is proposing (
https://w3c.github.io/personalization-semantics/content/index.html). If you
disagree with that approach, I will suggest that the AG WG isn't the place
to pursue that concern: it sounds like a TAG <https://www.w3.org/2001/tag/>
concern instead.


> ...using AI to allow Accessibility (and other) metadata to be
injected-into or utilized-by a web page is the probably
a better route to address this problem overall, for the web.

​Sure, but AI needs to "learn" from something - it cannot learn in a
vacume.

The Personalization Semantics effort, which is happening inside a TF under
the ARIA WG & APA WG, began in part because the former chair of the ARIA WG
(Rich S.)​ was instrumental in standing it up (to the point that at one
time, Lisa Seeman was using an IBM email address), and I believe that the
direction that the COGA TF is undertaking was informed, in part, by IBM's
understanding of AI and their 'super-instance' of Watson when the TF was
formed.

Further, the COGA TF has been pursuing this type of proposal since at least
2015, when they first suggested a collection of new *aria-** attributes at
TPAC in Sapporo (see:
https://rawgit.com/w3c/coga/master/techniques/index.html#use-semantics-to-provide-extra-help
​ for 2 examples: *aria-feedback* and *aria-explain*)​
, which then got changed to *coga-** attributes, and is now incarnated as
*aui-** attributes.
​ None-the-less, they have always envisioned and pursued this "use an
appropriate attribute" approach.​

With no offense intended, it's easy to say "AI will learn this stuff", but,
the real question is, "how?"  The COGA TF and ARIA WG are suggesting that
adding additional semantic information to page elements (controls, inputs,
etc.) via use-specific element-level attributes facilitates this
machine-learning and machine-transformations.

If you believe this is the wrong way forward, what specifically would you
propose as an alternative mechanism?


JF




On Wed, Feb 28, 2018 at 11:56 AM, Katie Haritos-Shea <ryladog@gmail.com>
wrote:

> Alastair,
>
> As I said before, you did a great job starting of this new Understanding
> content. As I wasn't sure we were going to go this route, I didn't suggest
> anything - but I'll take a look again. But it does seem that there is this
> security risk with autocomplete that may have us rethinking this SC
> again.....
>
> ** 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 Wed, Feb 28, 2018 at 12:47 PM, Alastair Campbell <acampbell@nomensa.com
> > wrote:
>
>> *AWK wrote:*
>>
>> The ally-resources.com site shows one example of this, but doesn’t cover
>> all HTML autocomplete attribute values though.
>>
>>
>>
>> AC: I think it uses the coga or aui attribute though?  Not to be picky,
>> but if the implementation *sites* we have use the autocomplete
>> attribute, that won’t match the a11y-resources UA. It’s an easy(ish)
>> change, but would need to be made soon, I assume?
>>
>>
>>
>>
>>
>> AWK: I don’t agree on calling it “autocomplete” as that is tied to the
>> attribute name for HTML and we hope to not only allow other attributes at
>> some point in HTML but also other technologies.
>>
>>
>>
>> AC: Fair enough, happy to change it.
>>
>>
>>
>>
>>
>> AWK: I also am not thrilled with the idea of relegating this SC to “input
>> assistance”, even though this is part of the benefit it isn’t everything,
>> and it is paired with 1.3.5 which is not about input assistance at all.
>>
>>
>>
>> AC: For the current SC, the input assistance is the primary thing, as it
>> is the benefit we can show now.
>>
>>
>>
>>
>>
>> *Katie wrote: *
>>
>> But we could also just suggest they use Autocomplete for this purpose
>> without an SC)
>>
>>
>>
>> AC: Do you mean ‘they’, as-in: an education process for end-users to
>> learn about autocomplete in the browser? That’s useful, but we would also
>> need the sites to use it. If the authors don’t add the meta-data, the
>> results are rather hit & miss. There still needs to be a requirement to use
>> the attributes.
>>
>>
>>
>>
>>
>> Katie: We will need to be explaining to people why we have this SC and
>> who it is for.
>>
>>
>>
>> Are there any additions you could suggest?
>>
>> https://alastairc.ac/tmp/autocomplete.html
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -Alastair
>>
>
>


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

Advancing the mission of digital accessibility and inclusion