Re: ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect)

Two clarifications inline.

> On Sep 21, 2015, at 10:28 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> 
> Hi Mike, 
> 
> Thank you for weighing in. 
> 
> ARIA defines how we map the ARIA semantics to platform accessibility APIs. We do not define default UI behavior. We don't tell the browser how it should render the user experience based on those semantics. That is where James and I agree. 
> 
> However, if a host language were to then use that information define the user agent behavior then that should be fine as long as it does not impact the API mappings. All the API mappings for ARIA are worked on behind our working group and the host languages. 
> 
> Since ARIA, intentionally, defines nothing about browser UI behavior I don't see how that if a browser who wants to define new behavior it should be restricted from doing so.
> 

One of the distinctions I'm trying to make is that UAs should be restricted from doing adding behavior based on ARIA when that behavior *conflicts* with behavior defined in a host language spec. For example, role="button" should not change the implicit tabindex value or keyboard behavior of an element, because those behaviors are already defined in the host language. A UA's implementation of ARIA should not *break* the UA's implementation of the host language behavior.

The second point I'm trying to make is that changing *any* default behavior based on ARIA is a slippery slope, with a lot of potential to conflict with future behavior. It also increases the likelihood developers will be mistrustful or ARIA-based retrofits, due to concern that they might negatively affect the primary interface of their web applications.

James

> The problem you get into is that the user experience may not be consistent across browsers. This was the point I was making about the use of the "title" attribute or <title> element in SVG. It leaves it up to browser interpretation of how that impact the UI. Consequently, you could get a tooltip in one browser and not in another. 
> 
> Does that help?
> 
> Rich 
> 
> 
> Rich Schwerdtfeger
> 
> Mike Elledge ---09/21/2015 12:07:18 PM---Hi Rich (all)-- I'm a newcomer to this conversation, and, though I've read most of the preceding ema
> 
> From: Mike Elledge <melledge@yahoo.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Chaals McCathie Nevile <chaals@yandex-team.ru>, Joanmarie Diggs <jdiggs@igalia.com>, John Foliot <john.foliot@deque.com>, "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, WAI Protocols & Formats <public-pfwg@w3.org>, Sailesh Panchang <sailesh.panchang@deque.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>, James Craig <jcraig@apple.com>
> Date: 09/21/2015 12:07 PM
> Subject: Re: ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect)
> 
> 
> 
> Hi Rich (all)--
> 
> I'm a newcomer to this conversation, and, though I've read most of the preceding emails, it may be that I've missed something. 
> 
> I am confused, however, by your last post. If you are saying that the ARIA spec is intended to describe mainstream browser behavior, aren't you also leaving open the possibility that browsers can interpret the ARIA specs in a way that enhances accessibility, if it becomes generally accepted (i.e. "mainstream")? This would seem to support John and Sailesh's point-of-view. 
> 
> Or were you thinking of "default" browser behavior, which would, for example, preclude an on/off setting in the browser that would provide additional accessibility should the user want it? That would seem to be James' point-of-view.
> 
> If the latter is the case, don't we run the risk of unnecessarily restricting creative browser approaches that could enhance accessibility? 
> 
> Mike
> 
> 
> 
> On Monday, September 21, 2015 11:56 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> 
> 
> I don't think anyone who has worked in the ARIA working group would disagree with you that we should be defining mainstream behavior in the UI in the ARIA WG. So, if John and others are saying otherwise then we are on the same page. 
> 
> Regarding Host languages there are instances where the host language is not clear about the behavior (like the use of "title" for tooltips). I these instances browsers have made their own determinations on how to handle those features. SVG is not very clear about this for example. 
> 
> I would prefer that host languages be more prescriptive but that has not always been the case. 
> 
> Rich
> 
> 
> Rich Schwerdtfeger
> 
> James Craig ---09/18/2015 06:50:06 PM---> On Sep 18, 2015, at 9:01 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: >
> 
> From: James Craig <jcraig@apple.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Sailesh Panchang <sailesh.panchang@deque.com>, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Chaals McCathie Nevile <chaals@yandex-team.ru>, Joanmarie Diggs <jdiggs@igalia.com>, John Foliot <john.foliot@deque.com>, lwatson@paciellogroup.com, WAI Protocols & Formats <public-pfwg@w3.org>, w3c-wai-ig@w3.org
> Date: 09/18/2015 06:50 PM
> Subject: Re: ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect)
> 
> 
> 
> 
> > On Sep 18, 2015, at 9:01 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> > 
> > However, should a host language or browser decide to leverage ARIA (which I think would be wise in some cases) to provide a better user experience then that is where the UI should be decided. 
> 
> Caveats below, but I don't have any objection to this. SVG is an example of where this may happen, thanks to efforts by Rich and others.
> 
> > This is why ARIA neither requires or forbids user agents from enhancing native presentation and interaction behaviors.  
> 
> I disagree. This statement is unambiguous. User Agents should not change the default behavior unless the behavioral change is specified in a host language.
> 
> Quoting the ARIA spec:
> "Aside from using WAI-ARIA markup to improve what is exposed to
> accessibility APIs, user agents behave as they would natively."
> 
> If a host language like SVG imports and extends the mainstream behavior based on an ARIA attribute, then a browser should incorporate the behavior defined by the host language. I don't see any objection to this.
> 
> However, that's a far stretch from what I think John and Sailesh may be proposing. I may have misunderstood, but my reading of their emails is that browsers could make some behavioral change based on ARIA attributes, even if it is not defined in host language spec. That's a slippery slope and a very risky proposal which I doubt many implementors — if any — would agree to support.
> 
> One example: A few years ago, someone proposed that adding role="button" should implicitly cause an element to become focusable and start intercepting certain key events. Not only is that proposal contrary to both the ARIA and HTML specs, it would actively *break* several DOM APIs, causing mainstream web applications to stop functioning based on the presence of an innocuous accessibility attribute. The backlash for this could be that engineers become distrustful of ARIA, and become less likely to allow accessibility retrofits in their code repositories, thereby making it more difficult for engineering teams to get accessibility bugs resolved.
> 
> For these and other other reasons, I consider any suggestion of mainstream behavioral changes in ARIA to be a harmful anti-pattern.
> 
> James
> 
> 
> 
> 
> 
>