Re: SC 1.3.4 - Understanding doc update

Hi Jon,

I am not suggesting that this solution is available today. Nor am I
suggesting that AAPIs not continue to be improved upon and that AT continue
to be built and improved upon. I am suggesting that 'we are not there yet
technology-wise'. And for many areas beyond accessibility these
technologies are being quickly sought. We already have those rich
accessibility taxonomies, pretty much ready to plug in, once the technology
gets 'there'. That is just my opinion. I certainly want to see
accessibility metadata and personalization moved forward - but again I feel
it need to be part of a larger web-wide initiative - at this point in time.

No one is wrong here. None of us can see the future. All we do know, I
think, is that technology is moving very fast (even if it seems slow for
our spec and users needs). But we are not the only group focused on user
needs. I have faith that we will get there, soon-ish.....

** 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 Thu, Mar 1, 2018 at 10:23 AM, Jonathan Avila <jon.avila@levelaccess.com>
wrote:

>
>    - >  I personally think that developers having to add markup to all
>    elements is not the best solution.
>
>
>
> I’ve also heard this argument for language indication.  People are saying
> that machines are good enough that we should not require the lang attribute
> because machines can determine language automatically so this is just
> requiring developers to add an extra attribute that is not needed.   I’m
> not saying I agree with this – but it’s been an argument here before.  I’ve
> also seen pushback about adding additional a11y attributes because it
> increases the page size – especially with ARIA and people’s  claim that all
> that ARIA markup has to be served up to each browser even when users won’t
> be using it.  That costs people bandwidth and page load times.  So user
> agents have discussed detected AT use and only serving it up then.
> Related but not specifically the same, chrome has accessibility options for
> the a11y API that either must be turn on manually or come on when AT is
> detected (at least that is what I can tell).  See the values in Chrome –
> enter Chrome://accessibilility in the address bar of Chrome.
>
>
>
> I fear contrast will go the same way – the user can overwrite the contrast
> in most cases so why require a contrast minimum?  I don’t agree with that
> either.
>
>
>
> Jonathan
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Wednesday, February 28, 2018 2:40 PM
> *To:* Katie Haritos-Shea <ryladog@gmail.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
>
>
>
> 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/
> 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
>
>
>
>
>
>
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>