RE: SC 1.3.4 - Understanding doc update

I agree with Katie’s point of view as quoted below. I think a combination of solutions based on machine learning (implemented on the user’s side as an assistive technology, or elsewhere in the delivery path – including as part of the authoring process) is more likely to be successful than requiring authors to add, and maintain, complex metadata. I think the author-supplied metadata should only be used where machine learning, alternate style sheets or similar approaches demonstrably cannot solve a problem adequately, and that existing markup conventions should be relied upon as much as possible.

Several well coordinated research and software development projects in the area would, in my view, achieve more to improve access for people with learning and cognitive disabilities than this working group is likely to do for quite a long time – especially given the very incremental nature of the progress evident so far, and the fact that authors are unlikely to implement such metadata on a large scale, or to do so correctly. We’re already seeing to what extent ARIA is implemented incorrectly, despite being well specified, leaving screen reader users to work around the implementation shortfalls - which some users with cognitive disabilities won’t be able to do if metadata supporting their needs are widely deployed, with numerous errors and inconsistencies. Misleading information can be worse than none at all, especially if a person’s cognitive disability makes it difficult to understand and work around the authoring errors.

Thus, I think we should rely on author-supplied metadata sparingly, and invest in other techniques (machine learning highlighted here) to do as much of the work as possible; and W3C specifications aren’t initially the right place in which to do it.

From: Katie Haritos-Shea [mailto:ryladog@gmail.com]
Sent: Wednesday, February 28, 2018 2:10 PM
To: John Foliot <john.foliot@deque.com>
Cc: lisa.seeman <lisa.seeman@zoho.com>; Alastair Campbell <acampbell@nomensa.com>; Andrew Kirkpatrick <akirkpat@adobe.com>; W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: 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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.accessibilityassociation.org%2Fcpwacertificants&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=iFCTxIsrQbc1FmS0Cn8315cZP%2B2n1pFrVSX3dmjKmV8%3D&reserved=0>

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fkatieharitosshea%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=dEgNsYeDzugGAoM3rDuSYNgETQdGl2eskc4FcvNgcjo%3D&reserved=0>

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<mailto: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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fpersonalization-semantics%2Fcontent%2Findex.html&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=EQYaZwM1BKY2uvYSke0nHt2NpdXPIqqN43V0sVXs7OM%3D&reserved=0>). 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=ImCktFnfdSJaArQ6uBymzpBHPlmA9GNoBC1U0rgTTqc%3D&reserved=0> 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frawgit.com%2Fw3c%2Fcoga%2Fmaster%2Ftechniques%2Findex.html%23use-semantics-to-provide-extra-help&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=KBcBB7CJZikGIr6Dijx4P6HKm63QodDaWoGpDBY4d90%3D&reserved=0>
​ 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<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.accessibilityassociation.org%2Fcpwacertificants&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=iFCTxIsrQbc1FmS0Cn8315cZP%2B2n1pFrVSX3dmjKmV8%3D&reserved=0>

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fkatieharitosshea%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=dEgNsYeDzugGAoM3rDuSYNgETQdGl2eskc4FcvNgcjo%3D&reserved=0>

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<mailto:acampbell@nomensa.com>> wrote:
AWK wrote:
The ally-resources.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fally-resources.com&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=m8Nxuz0euZqqhF2Ia9QVnbmmHnllMvdKu%2FvyJpcvy68%3D&reserved=0> 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Falastairc.ac%2Ftmp%2Fautocomplete.html&data=02%7C01%7Cjjwhite%40ets.org%7Cb9056a8f57134a95a72a08d57edf70bc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636554420525346975&sdata=P4elFxfT0LCscaTgYhb%2BwPcxshBNLYNZMn%2Bi51FkkoQ%3D&reserved=0>

Thanks,

-Alastair




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


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________