- From: James Craig <jcraig@apple.com>
- Date: Fri, 01 Mar 2013 17:23:07 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Dominic Mazzoni <dmazzoni@google.com>, Janina Sajka <janina@rednote.net>, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>, David Todd <dltodd@us.ibm.com>
On Mar 1, 2013, at 8:25 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > I agree with James. There are a LOT of issues around this. In particular, there is a huge impact on accessibility test tools - in effect this would break all the accessibility test tools for rich web available today. As far as I know, this would not affect tools like Accessibility Inspector or AccProbe. Will you clarify? > As I said to Dominic we have: > • Finish ARIA 1.0 > • SVG2 accessibility > • Canvas accessibility wrap up. It looks like the new Shape object will meet our needs for magnification and touch. > • ARIA 1.1 > • Wrap up of HTML5 accessibility features > • Indie UI 1.0 events and user context > > that need to get done in the next 2 years. Doing a CSS solution correctly also requires education, tooling, and AT support. To achieve those items on the list requires all the accessibility resources we have, and then some, and frankly those items above are far more important than the CSS approach. Other vendors have expressed the need to address more in the way of the interaction model in ARIA 2.0 as well. Finally, to me a top, top, top, priority is Indie UI events as we must have them for mobile. It is was a known deficiency in the ARIA 1.0 spec. that we need to fill ASAP. I will also point out that now that we have some accessibility support in canvas that I am seeing an uptick in the use of canvas. At CSUN there were multiple sessions discussing canvas accessibility. > > I am not suggesting that we dismiss the discussion but rather we should table the discussion to ARIA 2.0. Taking all the issues in their entirety for ARIA 2.0 we need to look at all the issues around extensibility, SVG 2 taxonomies, CSS, etc. holistically. That takes some time and heads down engineering for which we are already committed. > > Rich > > > > From: James Craig > Date: 02/04/2013 07:14 PM > >> (Since this thread has moved off of the IndieUI topic, I've moved it to the ARIA (wai-xtech) list, and put IndieUI in the BCC for this message.) >> >> FWIW, am not opposed to doing some of ARIA 2 in a more CSS-like way, but the role and other aspects of ARIA would need to be programmatically determinable from the element, and so far that's the main reason why it's been easiest to hang things off the DOM node. >> >> I proposed a related issue for ARIA 2.0 a while back. >> ISSUE-119 (XBL for ARIA2): Consider use of a technology like XBL or BECSS to assign ARIA semantics (roles/state/props) and event handlers >> http://www.w3.org/WAI/PF/Group/track/issues/119 >> >> Lisa Seeman mentioned this a couple times. >> https://lists.w3.org/Archives/Member/w3c-wai-pf/2010JulSep/0146.html >> >> Jamie Teh (NVDA) and others have raised the topic of potential ARIA in CSS, too. >> >> Also, role extensibility and other programmatic determinations would need to precede any change in the way we specify ARIA features. In other words, if you say role="switch checkbox", the web author needs to be able to determine which role was applied for the element. Likewise this would be needed if the role was applied via a linked document like an XBL or CSS file. >> >> ISSUE-9: Role Extensibility https://www.w3.org/WAI/PF/Group/track/issues/9 >>
Received on Saturday, 2 March 2013 01:23:34 UTC