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

Aaron M Leventhal wrote:

> Sadly, that's not where the web went.

Until ARIA, it did not have any other option.

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

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

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.

> 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

Received on Monday, 8 September 2008 18:48:34 UTC