Re: 'role' should be property

Henri Sivonen wrote:
> On Jun 1, 2007, at 03:33, Jon Barnett wrote:
>> - if a use case for "role" is very common, may that role should  
>> warrant its own element
> 
> A very superficial glance through http://www.w3.org/WAI/PF/GUI/ 
> roleTaxonomy-20060508.html suggests that almost all roles already  
> have markup that corresponds to them in HTML5.
> 
> Are the particular roles that you find inadequately covered by the  
> semantics of HTML 5 markup features?

   Most of the roles in the Role Taxonomy for Accessible Adaptable
Applications Working Draft are for assistive purposes. They all authors
to identify a specific DHTML widget or block of code as being a
particular type of widget, such as a radio group or a tree. I was told
that this was needed because aural browsers and other assistive user
agents couldn't make heads or tails of complex DHTML composite controls.

   My suggestion on the WHATWG mailing list was that we have a |wairole|
attribute that specifically communicates "accessibility roles", as
opposed to having a |role| attribute that can declare roles with a broad
range of semantics and can potentially interact with the underlying
markup and other roles.

   At this point, I'm leaning toward just having enhanced support for
microformats and converting the Role Taxonomy into an assistive
microformat that uses |class|. I could be persuaded to allow a |role|
attribute if it were limited to microformat use, but at this point I
think it's possible to solve the problem of non-semantic class names
with some sort of microformat class matching and cascade system:

| <meta name="microformat"
| content="http://microformats.org/wiki/hcalendar-profile" name="hcal">
| [...]
| <div class="vevent" mf="hcal">[...]</div>

Received on Thursday, 7 June 2007 11:27:33 UTC