W3C home > Mailing lists > Public > www-tag@w3.org > June 2008

Re: Proposal: ARIA-ROLE & CSS definition integration

From: James Craig <jcraig@apple.com>
Date: Fri, 6 Jun 2008 13:44:36 -0700
Cc: Anne van Kesteren <annevk@opera.com>, Leif Halvard Silli <lhs@malform.no>, elharo@metalab.unc.edu, public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>, www-tag@w3.org
Message-Id: <A9930964-4167-42A6-83D0-5CE41334A466@apple.com>
To: Justin James <j_james@mindspring.com>

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 Friday, 6 June 2008 20:45:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:58 GMT