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

Henri Sivonen wrote:
<snip>
>> can expose the ability to enter the appropriate role perhaps from 
>> either a
>> dropdown list of standard roles, or with the added ability to "custom"
>> create.  We currently have *today* (on my cow path of life) WYSIWYG 
>> editors
>> that allow similar functionality with CSS.
> WYSIWYG editors then
>
> I still find it curious how accessibility experts have faith in 
> authoring software gaining all manner of features while at the same 
> time assuming explicitly or implicitly that AT will be more or less 
> frozen to its current state.
<snip>
I'm not exactly an expert, but I think that this "faith" you're 
referring to might have something to do with the fact that it's easier 
for an editor to add an "insert progressbar" button than it is for 
browsers to help ATs figure out that that <div> which has a bunch of 
event handlers attached to it (which is not necessarily visible in the 
DOM, so how would the AT know without the browser doing extra work?) is 
in fact simulating a progressbar.

On the general matter of this topic:
Ultimately, it is my belief that the semantics of the interactivity now 
possible in HTML, CSS, JavaScript and friends are too diverse and have 
too many degrees of freedom to hope that one would ever be able to 
capture those in a finite set of (new) elements in HTML proper, even if 
not considering the fact that it will take many years for such standards 
to be approved and (correctly) implemented in the majority of useragents 
and ATs. As Aaron already said, everyone agrees it would be great if we 
got authors "accessibility for free", but this is only possible if the 
functionality of these accessible elements is constrained. Authors will 
always move beyond the boundaries of such constraints, where 
accessibility isn't for free. They'll want a circular progressbar, or an 
animated SVG icon while the <video> is loading, or there'll be this one 
bug in this one large-amount-of-marketshare-browser which stops them 
from using the builtin element, or...

In this case, attributes which can be applied to versatile elements are 
a better solution than separate elements with limited functionality for 
every possible semantic the WG can think of (which I'm sure will be a 
lot). As Aaron also said, having builtin functionality will be good. Go 
for it. But don't stop authors from making their own creations (which 
are just a little more weird/pretty/versatile than the things the WG 
thought of) accessible.

~ Gijs

Received on Wednesday, 27 June 2007 18:07:11 UTC