RE: Proposal: ARIA-ROLE & CSS definition integration

James -

Even in my post, I believe that I said it violated the separation
principles. :) Yeah, it violates them, but so do any HTML tags other than
<div>, <span>, and a few other "generic" tags. So the question isn't, "does
this violate separation", but, "is this violation reasonable and healthy?"

Regarding your other suggestion, I like it as an option, but not as a
replacement. Remember, the systems/UA that need the semantic Web *the most*
are the ones not running JavaScript! Search engines, textual analysis, etc.

I think that most HTML authors typically intend for a presentational class
to only be used in one semantic role, unless it is generic (like someone
using a class with red, large text to mean "important" and "header" at the
same time). I think it would be fairly safe to allow the CSS to indicate the
semantic role of a definition for that reason, so long as we allow it to be
accessed via the DOM *and* specified in the HTML itself.

J.Ja

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, June 06, 2008 4:45 PM
To: Justin James
Cc: Anne van Kesteren; Leif Halvard Silli; elharo@metalab.unc.edu;
public-html@w3.org; W3C WAI-XTECH; www-tag@w3.org
Subject: Re: Proposal: ARIA-ROLE & CSS definition integration

Justin James wrote:

> div.checkbox {aria-role: checkbox;} <div class="checkbox">Blah blah  
> blah</div> The div would be treated as if @aria-role="checkbox" had  
> been specified. [...]

Hi Justin, it's an elegant idea, not unlike XBL or HTC behaviors.  
Unfortunately, as expressed by most of the responses to your original  
post, this idea violates the principle of separation of content from  
presentation. Roles, states, and properties are semantic information  
about the content, so they belong in the data model (DOM) with that  
content, and not in a style sheet.

And later, Justin James wrote:

> I still think that it would be extraordinarily helpful to figure out  
> a mechanism to allow a link between CSS class and ARIA "role".

I think your issue may be that you are associating the class attribute  
only with CSS, when it can be used with many other technologies.

I share your desire for minimal markup, and I think I have a solution  
that may appease you, if only in simple cases. As mentioned, roles  
should be specified in the DOM. However, how the role information is  
inserted into the DOM is up to you. It could be in the source code  
markup, or you could insert it into the DOM via JavaScript.

In theory, you could choose to use the same markup you mentioned  
earlier (<div class="checkbox">foo</div>) then have JavaScript check  
for all elements with any of your reserved classes and insert the role/ 
state/property information as needed. For example:

for (/* each elm with a 'checkbox' class */) {
	elm.setAttribute('role', 'checkbox');
	/* note: example uses the Prototype.js hasClassname shorthand */
	if (elm.hasClassname('checked')) elm.setAttribute('aria-checked',  
'true');
	else elm.setAttribute('aria-checked', 'false');
}

Your markup stays minimal, but the semantic information implied is  
inserted into the DOM where it can be accessed by the user agent,  
assistive technology, and author-defined JavaScript. I hope it's  
apparent from the example, though, that you could open a can of worms  
with all the class variations and combinations you'd need to represent  
the roles, states, and properties in all but the simplest of web  
applications.

Both your original idea and my potential workaround listed here would  
fall short when trying to develop class representations of arbitrary  
data like aria-valuetext or aria-posinset. The Microformats community  
ran into this same issue with datetime information, and ended up shoe- 
horning it into an attribute anyway.

Hopefully this clears up why CSS-defined roles/states/properties won't  
work for ARIA. However, you're welcome to implement Class-defined role  
information in any way you see fit. Using XBL or HTC might work, but  
only in certain browsers. JavaScript is a more cross-browser solution,  
but may have performance costs on the more complex web applications.

Cheers,
James Craig

Received on Sunday, 8 June 2008 03:36:48 UTC