Re: HTML5 default implicit semantics

On 6 November 2015 at 15:32, John Foliot <john.foliot@deque.com> wrote:
> Finally, during last week's TPAC Face-to-Face meetings (http://www.w3.org/2015/10/27-aria-minutes.html#item04), Rich Schwerdtfeger stated: "most of what we have done w/aria is interoperability. What we are doing here is new semantics to drive the UI".

You both articulated my thoughts much better than my verbal groping :)

> Yet, in my previous discussions with representatives of the various browser vendors in the past, they are all adamant that ARIA is for exposing role, state and property to the Accessibility APIs, AND NOTHING MORE, and that they are quite insistent that ARIA *NOT* have an impact on the UI. If nothing else, this raises a very serious red flag for me going forward.

So ARIA is for describing existing UI elements only? Allow in AT to
transform it? Hmm. So How will the work By Mozilla, Microsoft and
others on javascript interactions with a11y APIs impact that? I'd say
it will open it right up to experimental approaches including those
that manipulate the DOM (which I think is what you are indicating
there is resistance to, at least for built in semantics).
Scriptability is good in my book. "Embrace the caos" and make life
better for users. :) I guess they are concerned about adding further
complexity to the predefined browser behaviour; scripting is someone
else's problem.

> Personally, I still hope to look to more native methods to address many of these issues, resorting to coga-* attributes as a last resort solution, rather than a first-pass one. My other fear is that by collecting all of our "accessibility solutions" under an ARIA banner, we perpetuate a ghetto-ization of accessibility - a perpetuated "us and them" mentality, rather than just good practice that aids all, irrespective of their individual needs or how they identify (which is how *I* see personalization ultimately playing-out BTW).

What do you mean by more native? Mechanisms baked into HTML to alow
suitable modifications? Bring it on :)

> I remain of the opinion that we should be engaging now with other Working Groups within the W3C (for example, perhaps Web Annotations WG - http://www.w3.org/annotation/), sharing our needs and use-cases and working collaboratively with them for more native solutions. But that's just me.

+1 Given the concerns about adoption we'll need as many people as
possible singing from the same hymn sheet (as long as it is pro coga -
heh). Trouble is there will be resistance and delay. So on ballance, I
think the current approach of getting a clean initial position
together make sense.


Steve Lee
OpenDirective http://opendirective.com


On 6 November 2015 at 15:32, John Foliot <john.foliot@deque.com> wrote:
> Steve Lee [mailto:steve@opendirective.com] wrote:
>>
>> This older post by the mighty Steve Faulkner got me thinking about the proposals
>> for extending aria. I'm not criticising these extensions but wanted to raise some
>> thing that has be nagging at me.
>>
>> The underlying question in my mind is how do we get authors to use new ARIA
>> attributes for coga? It's proved not easy to get ARIA widely used.
>
> Hi Steve,
>
> Thanks for this observation. I too have similar concerns, and I was troubled that my surfacing of those concerns during TPAC last week was seen as an attack on the great work being done by this group.
>
> Author learning curves, and author fatigue in getting content marked-up correctly, is an on-going problem that is also impacted by scale: yes, large multi-national companies with dedicated accessibility teams and highly functioning engineers will likely get this right, but I fear how this will trickle down the author chain. Having spent over 15 years teaching uninitiated authors about accessibility concerns, I know it's hard enough to get them to understand how to write good alt-text, and I fear that expecting them to learn a raft of new aria-attributes, which as you note are mostly meta-data constructs (versus interaction constructs), sets the bar extremely high. The problem isn't one of computer engineering, it is one of social engineering.
>
> Coupling this concern with the thread (https://lists.w3.org/Archives/Public/w3c-wai-gl/2015OctDec/0117.html) going on over in the GLWAI Guidelines WG over the need for testable statements / creation of Success Criteria (which leads me to conclude that trying to get the new COGA requirements set as SC will prove extremely difficult, if not impossible), and I am growing increasingly concerned that while I understand what is being proposed, I fear we will be setting ourselves up for poor adoption.
>
> Finally, during last week's TPAC Face-to-Face meetings (http://www.w3.org/2015/10/27-aria-minutes.html#item04), Rich Schwerdtfeger stated: "most of what we have done w/aria is interoperability. What we are doing here is new semantics to drive the UI". Yet, in my previous discussions with representatives of the various browser vendors in the past, they are all adamant that ARIA is for exposing role, state and property to the Accessibility APIs, AND NOTHING MORE, and that they are quite insistent that ARIA *NOT* have an impact on the UI. If nothing else, this raises a very serious red flag for me going forward.
>
> Moving from minting new aria-* attributes to proposing new coga-* attributes may be one possible solution, and it seemed that many (including myself) were supportive of that direction, at least for now, although it was also noted that relying on a prefixed attribute solution is sub-optimal (that we were "forced" to accept that for ARIA):
>
>         MC: Was not proposing that coga- would be used in the real world.
>         We should oppose that. We got forced there with aria-.
>         coga- is an experimental space.
>         (http://www.w3.org/2015/10/27-aria-minutes.html#item04)
>
> Personally, I still hope to look to more native methods to address many of these issues, resorting to coga-* attributes as a last resort solution, rather than a first-pass one. My other fear is that by collecting all of our "accessibility solutions" under an ARIA banner, we perpetuate a ghetto-ization of accessibility - a perpetuated "us and them" mentality, rather than just good practice that aids all, irrespective of their individual needs or how they identify (which is how *I* see personalization ultimately playing-out BTW).
>
> I remain of the opinion that we should be engaging now with other Working Groups within the W3C (for example, perhaps Web Annotations WG - http://www.w3.org/annotation/), sharing our needs and use-cases and working collaboratively with them for more native solutions. But that's just me.
>
> JF
>
>
>
>> -----Original Message-----
>> From: Steve Lee [mailto:steve@opendirective.com]
>> Sent: Friday, November 6, 2015 5:33 AM
>> To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
>> Subject: HTML5 default implicit semantics
>>
>> This older post by the mighty Steve Faulkner got me thinking about the proposals
>> for extending aria. I'm not criticising these extensions but wanted to raise some
>> thing that has be nagging at me.
>>
>> The underlying question in my mind is how do we get authors to use new ARIA
>> attributes for coga? It's proved not easy to get ARIA widely used.
>>
>> http://html5doctor.com/on-html-belts-and-aria-braces/
>>
>> In this article Steve points out that the belt a braces approach of adding ARIA to
>> built in controls is not needed with newer browsers.
>> The reason is the browser assigns default semantics and exposes those via the
>> a11y APIS. This is exactly how it should be and leaves ARIA markup to be most
>> useful when defining custom controls and structure.
>>
>> In contrast, if I correctly understand the suggestions, we are proposing an
>> extension to this model of ARIA articulating predefined semantics. The new
>> attributes are unlikely to ever be useful for a default semantic for controls or
>> structure. Rather they are for authors to add semantics to their content and
>> structure which clarify intent and as such they can be no default semantics.
>>
>> Content and structure may operate at a higher level of semantics, rather like
>> custom controls and so always need to be described. I still worry we'll have a job
>> getting authors to actually use the new attributes.
>>
>> Perhaps this doesn't matter much as the ARIA provides semantics in both cases.
>> However, the proposed coga_ prefix may be useful as it helps keep this potential
>> difference in mind
>>
>> Thoughts?
>>
>> Steve Lee
>> OpenDirective http://opendirective.com
>
>

Received on Friday, 6 November 2015 16:37:34 UTC