- From: White, Jason J <jjwhite@ets.org>
- Date: Mon, 21 Sep 2015 19:23:48 +0000
- To: James Craig <jcraig@apple.com>
- CC: Richard Schwerdtfeger <schwer@us.ibm.com>, Mike Elledge <melledge@yahoo.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" <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>
> On Sep 21, 2015, at 13:53, James Craig <jcraig@apple.com> wrote: > 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. Thank you for clarifying the point, James. There are essentially two ways of creating new interactive elements today: (1) by extending a host language and implementing the new features, and (2) by creating custom interactions, e.g., with HTML or SVG, CSS and JavaScript. The second method is soon to be further facilitated by Web Components. This, I think, is as it should remain. Specifically, the right way to extend user agent behavior is by doing the work to enhance host languages themselves, especially HTML and SVG. I find the “invisible metadata” argument in support of using host language features, where possible, and for avoiding the unnecessary use or creation of accessibility-specific features, highly persuasive. New features intended for general use should be made available for everybody, including users with disabilities, in the host languages. There’s an important role for ARIA in making Web Components accessible, but this is entirely compatible with the purpose of ARIA as it has historically been understood. ________________________________ 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. ________________________________
Received on Monday, 21 September 2015 19:24:27 UTC