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

On Tue, 26 Jun 2007 13:42:01 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:

> 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.

Indeed.

> I also think that making existing short-term add-on solutions  
> non-conforming is too drastic a measure to address this danger.

Agreed.

> [...]
>
> 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.

Indeed. For simpler cases, CSS styling of form controls could suffice as  
well.

> 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.

It is also arguably easier to apply on existing Web apps. If an existing  
app uses styled and scripted divs as widgets, then adding tabindex="0" and  
role="..." can be done without changing anything else. Using the new  
elements with CSS/XBL however probably needs a remake of the front-end of  
the app.

> 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.

I agree. However, I'm not convinced that we should reverse engineer  
role="" as implemented in Firefox/JAWS and spec that, because doing so  
takes time, and it encourages other vendors to implement it instead of  
implementing the long-term solutions. I think it is more important for  
other vendors to implement WF2, XBL and CSS styling of form controls than  
implementing role="".

Moreover, namespaced roles are not trivial to use in HTML. Only IE  
supports namespaces in HTML, and its implementation is insane. AIUI, other  
vendors have tried long and hard to implement the same, but have failed.  
In Firefox, namespaced roles can only be used in XML and in the DOM. Not  
providing a way to use namespaced roles in HTML without resorting to  
scripting is unfortunate, but introducing namespaces in HTML has so far  
been unsuccessful.

That said, we can take the route to merely make role="" conforming without  
defining how it is to be processed. Pretty much like we can make RDF  
conforming without defining how that is to be processed. If a vendor is  
interested in implementing role="" then it has to reverse engineer  
Firefox/JAWS, and, if that happens, we can take the opportunity to spec it  
in the process.

-- 
Simon Pieters

Received on Wednesday, 27 June 2007 11:09:26 UTC