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

Why do you say role has to be reverse engineered?

W3C docs:
http://www.w3.org/TR/aria-role/

Firefox docs:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications

Also, role can be used in HTML in Firefox. It doesn't validate, if you 
use a validator, but we decided it was not worth the extra code to check 
the namespace, since role is in the XHTML role attribute module. That 
means it's legal with XHTML 1.1 so we just allow it in HTML as well.

- Aaron


Simon Pieters wrote:
>
> 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.
>

Received on Wednesday, 27 June 2007 12:55:23 UTC