Re: SC 1.3.4 - Understanding doc update

Katie wrote:

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

Fair enough, while also noting that we don't make developers add aria
attributes to all elements on a page, just those elements that require
additional semantic information. And, I've previously shown an example of
form inputs (True/False radio buttons) that didn't require @autocomplete,
so suggesting "all" elements will require additional markup is a tad
over-stated.

However, ensuring that sufficient semantic information is encoded into the
page, to support the needs of coga-users, is still the proposed path
forward, and suggesting that "... a viable solution is not available
yet..." is both missing part of the point, as well as reinforcing the
chicken-and-egg problem we have.

We had the same problem with ARIA, and if it wasn't for IBM paying Aaron
Leventhal to add ARIA support to Firefox, then non-sighted users would be
in a similar situation that coga-users are in today: "we don't have a
solution, because we don't have any tools to support a solution, and
because we lack the tools, there is no need [sic] for us to work on a code
solution...and because there is no code solution, there is no need to
develop any tools...(and 'round and 'round we go)".  We didn't tell
visually impaired users to wait for AI to figure out those complex widgets
and controls, we created a specification, then got user-agent support, and
then began the complex task of teaching content authors how to do it
"right".

At some point, one side needs to blink first, or we'll continue to circle
around chasing our tails, and revisiting the chicken and egg time after
time after time.

At any rate, as I have previously suggested, if you believe the mechanism
currently being pursued is 'wrong', the correct place (IMO) to take up that
concern is with the Technical Architecture Group (TAG), and not in the AG
WG.

JF

On Wed, Feb 28, 2018 at 1:10 PM, Katie Haritos-Shea <ryladog@gmail.com>
wrote:

> 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/persona
>> lization-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
>>
>
>


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

Advancing the mission of digital accessibility and inclusion