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

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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 26 June 2007 11:42:30 UTC