ARIA as stop-gap (was Re: Next steps for the ARIA syntax discussion)

On Thu, 22 May 2008 11:36:25 +0200, Aaron M Leventhal  
<aleventh@us.ibm.com> wrote:

> It would be quite risky to assume ARIA is stop-gap. How do you see the
> need for ARIA going away?  Do you really think people will suddenly stop
> using or developing JavaScript UI toolkits at some point? Or is some
> better extensibility mechanism going to take over, which allows for a11y
> semantics to be added? If ARIA is to go away, we'll need standards and
> consistent implementations for HTML widgets. We'll need a widget
> extensibility layer which provides some other means of exposing a11y
> semantics will need to be added, and all browsers will need to have some
> way of supporting that. There is no guarantee we will get there -- that
> all vendors will be willing or that 3rd party solutions will find
> traction.
>
> The need for a11y APIs has never gone away on the desktop -- developers
> are always creating new widget sets even when there is a built-in one.
> That is why a11y APIs are so important. Developers will always want to
> create their own widgets and those should be made accessible.

Let me just say upfront that I think ARIA is needed, and will be needed  
for some time yet. But let me also answer your question about why we  
should strive for it to be a stop-gap in the long term in order to get  
even better accessibility.

Widgets are a black box. All their semantics are hidden away in a mass of  
code. In that sense, widgets are just the <font> tag writ large: they  
represent some semantics, but you can only see what by looking at the  
result. We need ARIA to be able to layer a level of meaning onto them to  
help expose their meaning. But frankly such post-hoc accessibility is a  
Bad Thing in the big picture. You really want the markup to be accessible  
out-of-the-box.

That is why (for instance) XForms controls are designed as they are. They  
say what they are required to do, not how they should do it, nor how they  
should look. A separate layer, be that CSS, or XBL, or anything else, can  
bind an actual control to the markup. This is why it is possible to  
deliver the same XForm without change to a browser, a mobile phone, a  
voice browser or via an IM buddy: you have late binding of interface to  
markup.

Mark Birbeck has been doing some great work in this area, with widgets  
like clocks, and even Google maps, being bound at the last minute to the  
(XForms) markup, just like stylesheets are. It means you can bind  
device-dependent interfaces at the last minute to the markup, or  
accessible interfaces: the markup doesn't commit itself. When we reach  
that level of maturity in markup languages we shouldn't need ARIA style  
bandaids any more.

Best wishes,

Steven Pemberton

Received on Wednesday, 28 May 2008 13:24:14 UTC