RE: ARIA's role="" attribute (was Re: [Bug 7509] Consider <dl type="dialog"> instead of <dialog>)

For the record, I originally created the @role module for XHTML
because I  was frustrated with having to scrape content off of
sites like CNN by looking at class values such as storyText12pt
and more obscure names.

Well-designed classes can achieve the same end-result, but the
class attribute I felt had already been sufficiently abused to
make that goal hard. I have been repeatedly told by folks like
Tantek of microformats fame that that decision was a mistake ---
however, tying oneself to an over-used attr like class I felt
(and continue to remain convinced) 
is too fragile, especially given that the class attr often
contains multiple values in places. 
Also, it would be hard to go back and fix the large number of
HTML  pages that use  aclass value incorrectly --- e.g. say you
started assuming that class="nav" was the site navbar --- you
would get confused by other uses of class="nav" and likely think
them to be navbars. Better to rely in such cases on honestly
authored information --- rather than double-guessing.

Edward O'Connor wrote:
>
> Hi,
>
> Toby wrote:
> > Possibly @role could be re-used. (@role isn't just an ARIA attribute,
> it's
> > intended to be used in other ways too.)
>
> You may be confusing ARIA's role="" attribute with the XHTML Role
> Attribute Module. They are separate, distinct attributes. Insofar as the
> current HTML5 draft goes, role=""'s sole use within HTML is for
> specifying ARIA roles on elements.

Confusing or remembering? Despite the general disdain held by large swaths 
of the HTML unwashed, there were some very good ideas inside of XHTML2 that 
got dumped, just like the proverbial baby in the bath-water - @role being 
one of them.

ARIA's appropriation of the @role attribute was from XHTML2 for sure, but 
the *idea* that @role represents is a powerful one, and is exceedingly more 
powerful (and remember-able) than using the meaningless class attribute 
notation currently in vogue.  It *should* be considered more extensively, 
but we already can hear the moaning and growling from the peanut gallery 
(especially from the microformats camp).  Too bad really: consider the 
'issue' with accesskeys and mapping to keyless devices or international 
keyboards... if, instead of mapping a key to a function/feature you could 
instead state a Role, then the user agent could handle the binding on its 
own terms, rather than on terms forced by the content author.

JF

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 10 September 2009 20:48:03 UTC