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

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