- From: Aaron Leventhal <aaronlev@moonset.net>
- Date: Tue, 26 Jun 2007 13:53:10 +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
This is good -- I agree with almost everything you're saying. The only small quibble I have is that I think the short term solution will actually increase the motivation to get the long term solution right. But I especially agree that WGs shouldn't just take what some random a11y experts say, no matter how assertive or inflexible they are. Thinking about better long term solutions is a great thing. Any "experts" out there should know that a discussion is good and be sure to listen to the concerns of any WGs. - Aaron Henri Sivonen wrote: > On Jun 26, 2007, at 13:05, Aaron Leventhal wrote: > >> 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. > > I don't want to throw tomatoes at anyone. I'd much prefer the WG > exploring different ways of addressing use cases without tomato throwing. > >> 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. > > As I see it, the main danger of short-term add-on solutions are that > they decrease the motivation for UA and AT vendors to implement > long-term solutions and they may decrease the motivation for members > of the HTML WG to think hard about developing long-term solutions. I > also think that making existing short-term add-on solutions > non-conforming is too drastic a measure to address this danger. > Unfortunately, it seems that these discussions that appear > confrontational are necessary in order to get the WG think hard about > long-term solutions that scale to the Web of non-expert authors. > >> 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. > > I guess the new HTML5 features need a lot more marketing as > accessibility features. It is kind of sad that the accessibility > interest part of the blogosphere has focused on the HTML 5 draft not > having certain attributes (yet) and not noticing how many new features > have accessibility-friendly semantics without needing annotations > specifically for accessibility. > >> Here are some of the advantages of using ARIA properties such as >> @role, as an accessibility solution for today. > ... >> Some disadvantages of ARIA > ... >> Realistically, most authors will either not make use of @role/ARIA. > > I totally agree with your analysis, BTW. > > However, for the custom widget case, ultimately native elements for > all available roles and XBL for custom widgets would be a more elegant > long-term solution. I do realize, though, that the main advantage of > role='' over XBL is that role='' doesn't require the deployed > installed base of browsers to participate as a whole in order for > expert authors to target the browsers that do participate. > >> 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. > > I agree that HTML5 will need to have role='' and headers='' as > short-term measures and as overrides for handling corner cases when > easier-to-author methods fail. It is rather pointless to make > non-conforming something that Firefox and JAWS already support. > > However, I think they should be presented as short-term measures and > as overrides when other ways fail instead of being presented as > primary way of making HTML accessible on the long term. And the HTML > WG should seriously consider the long term. > > That is, I still think that <progress> is the curb-cut installed as > part of the routine paving process in the front of the building and > role='wairole:progressbar' is the retrofitted ramp leading to a side > door. A retrofitted ramp is better than no ramp, but surely we should > make something better for new construction. >
Received on Tuesday, 26 June 2007 11:54:41 UTC