W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

From: Aaron Leventhal <aaronlev@moonset.net>
Date: Tue, 26 Jun 2007 12:05:41 +0200
Message-ID: <4680E4F5.6080903@moonset.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: John Foliot <foliot@wats.ca>, "'Gregory J.Rosmaita'" <oedipus@hicom.net>, "'HTML WG'" <public-html@w3.org>, wai-xtech@w3.org, w3c-wai-ig@w3.org

Henri Sivonen wrote:
> People aren't really disagreeing on the needs on the use case level. 
> For example, the need of blind users to query a table cell for its 
> headers has not been disputed. However, the accessibility expert 
> clique and the WHATWG clique have different views on what kind of 
> technical solutions best address the use cases. The general pattern is 
> that the accessibility expert clique goes for explicit accessibility 
> annotations that put the maximal burden on authors and the minimal 
> burden on UAs and the WHATWG clique goes for extracting accessibility 
> information from markup that has other purposes as well while trying 
> to shift the burden away from authors.
>
Okay, I'll represent myself as an "accessibility expert" so people can 
throw tomatoes at me. But, I don't think it helps the discussion to 
generally divide people into groups. It's no argument, and it's not 
totally an either-or situation. Support in HTML for @role does not mean 
HTML should not provide a better solution whenever it can. I also don't 
think we need to argue that allowing accessible web applications as soon 
as possible is important.

Yes, it is better to make things easier for web authors. Improving HTML 
to build all kinds of useful features together into new elements is a 
very important way to do this. Accessibility should just work, and be a 
side affect of correct usage. It's hard to disagree with that.

Here are some of the advantages of using ARIA properties such as @role, 
as an accessibility solution for today.
- Backwards compatible for browsers: it doesn't break web pages in 
today's web browser
- Practical: It can be added to current Web 2.0 applications without 
rewriting everything -- this makes it *easier* for the authors of 
today's apps
- Timely: We don't have to wait years for everything the entire 
technology chain to catch up -- making web applications accessible 
cannot wait that long. Do you really want to tell developers they need 
to wait possibly something like 7 years before they can start adding 
basic widgets like tree views to their web pages?
- Doesn't limit developers: it's unrealistic to expect web authors to 
always stick with the widgets made available in HTML, not matter what 
version it is. That battle has been fought and lost. Developers will 
always want to create custom widgets. This is the same reason Microsoft 
had to develop MSAA -- no widget set is ever complete. Developers and 
companies refuse to be limited by the widgets provided -- they want to 
provide something that sets them apart. It's unrealistic to believe that 
HTML 5 will have everything that's required. Iterating HTML to add new 
features will always be an extremely slow process, in comparison with 
web page and toolkit authors developing new widgets.

Some disadvantages of ARIA
- Hard to get right unless you're one of those "accessibility experts"-- 
it's unrealistic to expect most authors to manually add @role and other 
ARIA properties, or even to expect a large majority of authoring tools 
to support it
- Not as elegant as simply using natural elements with built-in 
functionality.
- Requires additional markup, increasing the download size of web pages

Realistically, most authors will either not make use of @role/ARIA. This 
is recognized by other WAI PF members I've spoke with, who agree that 
WAI-ARIA is not the ideal ultimate solution for common widgets.

Then why bother? I have not heard of another solution that will allow 
the large content providers to make their new Web 2.0 content accessible 
in any reasonable timeframe. And, authors need to be able to develop 
accessible custom widgets.

But how will it be useful if ordinary authors cannot use it? Toolkits 
are where most developers will get these new accessible widgets. The 
Dojo project already has at least 4 people working on ARIA support for 
it, so yes, it is in fact realistic that authors and users will benefit 
from this technology.

In the long term, it would be great if HTML 5 makes common things simple 
with new built-in elements, but still supports those ARIA properties 
that are useful.
I hope HTML will allow backwards compatibility for developers who need 
to use ARIA to make accessible web apps today.

- Aaron
Received on Tuesday, 26 June 2007 10:07:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC