- From: Aaron Leventhal <aaronlev@moonset.net>
- Date: Tue, 26 Jun 2007 12:05:41 +0200
- 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:56 UTC