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


Sadly, that's not where the web went.

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.

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.

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.

- Aaron

James Craig <>
David Bolter <>
09/08/2008 08:14 PM
Re: ARIA BPG Issue: we should not be decreeing complex keyboard 

David Bolter wrote:

> I share the view/hope that ARIA (at least ARIA 1.0) is about defining
> the semantics, and not the interaction. I would like to mention 
> however,
> that keyboard interaction in DHTML tends to be defined by the 
> JavaScript
> author, and not the Browser, or the AT.

I think that's because, prior to ARIA, there has never been a way for 
AT to gather application semantics out of the DOM.

> If Apple is going to base SproutCore interactions on native OSX
> interactions, I'd like to see Apple represented on the style guide 
> team.

The opinions I express here do not relate specifically to OS X or to 
any particular JavaScript library. I just think that web application 
controls should behave like desktop application controls, hence 
keyboard and mouse interaction should default to the browser and AT, 
as it does with form elements.


Received on Monday, 8 September 2008 18:22:06 UTC