Re: ARIA BPG Issue: we should not be decreeing complex keyboard interactions

wai-xtech-request@w3.org wrote on 09/08/2008 08:47:53 PM:
> 
> Aaron M Leventhal wrote:
> 
> > Sadly, that's not where the web went.
> 
> Until ARIA, it did not have any other option.

Well, yes it could and did. They just didn't work with ATs. 
For example, GMail was just fine with the keyboard and mouse and worked 
across browsers.
As far as GMail developers are concerned, they can come in and pepper ARIA 
markup in without changing GMail behavior (at least that's how it's 
intended).

> 
> > In order to make web widgets that work everywhere people had to 
> > implement the widget code in JS. ARIA widget markup is just about 
> > describing what the widgets are and what state they're in.
> 
> And AT is able to affect that state directly, as defined in the 
> "states and properties expected to change" section that Rich is 
> working on. Theoretically, JavaScript control of ARIA widgets should 
> most often be triggered by DOM mutation events, no?

I think most often by keydown or click events that the JS handles itself. 
Based on what the group has said so far, handling the DOM mutations is 
going to be optional for those who wish to support alternative input ATs 
fully (onscreen keyboards and voice input etc.)

> > What most people hope is that most of the ARIA widget technology 
> > becomes less necessary over time, as proper next gen widgets become 
> > implemented consistently across the web.  This could take many years 
> > -- no one knows what will happen or when.
> 
> All I'm saying is that we shouldn't be decreeing long term keyboard 
> controls without a plan for how browsers transition to those proper 
> next gen widgets. Since ARIA is intended as a stop-gap measure, it 
> should be setting a precedent for how its obsolescence can be 
> achieved, even expedited, by the browser vendors.

Ok. The style guide probably has an opportunity to influence consistency 
of future keyboard nav decisions made by browser developers for HTML 5, 
etc. I don't think it's a decree, but it's advice on how to improve 
consistency with the majority of implementations.

Just to be clear I don't expect ARIA to become obsolete -- but that the 
most common use cases get consumed by things like HTML 5+, and that the 
uses for ARIA become more for live regions and innovative types of 
interactions (defined by authors without needing to sit in a commitee 
somewhere).

> This is just one hypothesis. The browser's level of support could be 
> declared in navigator.aria.* (Is this proposed for ARIA 2.0?) For 
> example, if the browser declares 
> navigator.aria.widgets.tree.nativeSupport to be true, then the author 
> scripts don't define the keyboard controls and only checks for DOM 
> Mutation events; otherwise the script author uses the keys defined in 
> the DHTML style guide and maintains the DOM itself.

That will break lots of apps that exist today. The web is too big for us 
to go chase down on all the places that keyboard nav was implemented the 
way GMail did pre-ARIA.

> > In the meantime ARIA provides a way for JS widget libraries to be 
> > accessible. In the long run ARIA should be necessary for fewer of 
> > the obvious widgets, and more for really interesting cases where 
> > people are inventing new complex interactions.
> 
> Agreed. That's what I am hoping we plan for.
> 
> James
> 
>