Re: SC 1.3.4 - Understanding doc update

As I have said before, this problem is one that has been trying to be
solved by many great minds, in several standards organizations (W3C, ISO,
IEEE, IMS, etc.) for many years.

But this issue of finding a mechanism to allow accessibility metadata and
other kinds of metadata to be injected-into or utilized-by web content
(pages. ePub, etc), and to add personalized renderings for users, is an
overall problem for the web, and in my opinion - and - a viable solution is
not available yet. I am not as sure as some here are that this SC is the
great first step in the right direction. Nor am I convinced that this WG
has the expertise or is the right place to address this problem. It
requires a comprehensive approach by the larger web community, in my
opinion.

I personally think that developers having to add markup to all elements is
not the best solution.

If I had the answer or solution, then I would be one bright lady.....:-)

** 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 1:44 PM, John Foliot <john.foliot@deque.com> wrote:

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