W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2015

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

From: James Craig <jcraig@apple.com>
Date: Fri, 18 Sep 2015 16:49:58 -0700
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
Message-Id: <63E8050E-1E48-44D8-BA0A-2F89EDAEA52A@apple.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>

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

Received on Friday, 18 September 2015 23:50:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:58 UTC