Re: ARIA style sheet

Chris Blouch wrote:

> I think Matt Machell wasn't saying so much that role:slider was a  
> style but that we should embrace using something like CSS selectors  
> to map one or more DOM nodes to one or more sets of ARIA attributes.  
> Call it a shorthand way to add semantics.

For roles, states, and properties that JavaScript will not need to  
control, this makes sense, and is the intended purpose of mapping ARIA  
to an implementing host language like HTML 5. For example, if a user  
agent mapped @required in HTML 5 directly to the same API as @aria- 
required, then the need to do this via a shorthand is irrelevant.  
Likewise, there is no need to use role="heading" on a heading element  
like html:h2.

For widgets that JavaScript does need to control, I'd be wary of  
assigning them via a technology other than JavaScript, because if  
JavaScript is unavailable, the author won't be able to comply with  
their end of the ARIA contract for managed widgets. Assigning ARIA  
semantics through a technology like XBL [1] or Behavioral Extensions  
to CSS [2] is a good topic to discuss for ARIA 2.0. I added it as an  
ARIA2 issue [3].

ISSUE-119: Consider use of a technology like XBL or BECSS to assign  
ARIA semantics (roles/state/props) and event handlers

1. http://www.w3.org/TR/xbl/
2. http://www.w3.org/TR/becss/
3. http://www.w3.org/WAI/PF/Group/track/issues/119

> If I have 20 sliders and each one is a constructed by a <div  
> class="slider"></div> it seems systemically wrong to have to put in  
> all the ARIA attributes inline repeatedly whether by hand or via a  
> dom walking script.

I agree with you that you shouldn't have to do it by hand, but I don't  
think I agree with you about not using the DOM walking script,  
especially for widgets that the JavaScript will need to control.

The example I listed in the thread uses checkbox as an example, but  
you could also use a similar method for complex managed widgets like a  
tree control. For example, this script would assign the 'treeitem'  
role to any html:li elements within a node using a 'tree' className.  
You'd need some additional code for the tree role itself, as well as  
for any sub-level group nodes and appropriate even handlers, but the  
idea is the same, and can be accomplished using standard JavaScript or  
a technology like XBL.

for (/* each li elm within a node with a 'tree' class, using $$('.tree  
li') */) {
   elm.setAttribute('role', 'treeitem');
   /* note: example uses the Prototype.js hasClassName shorthand */
   if (Element.hasClassName(elm,'expanded')) elm.setAttribute('aria- 
expanded','true');
   else elm.setAttribute('aria-expanded', 'false');
}

<ul class="tree">
   <li>One</li>
   <li>Two
     <ul>
       <li>A</li>
       <li>B</li>
     </ul>
   </li>
   <li>Three</li>
<//ul>

> We should have a means to infer the applicable ARIA semantic  
> attributes from the already stated class or other other fingerprints  
> defined by the selector. Maybe the problem is folks call them CSS  
> selectors when really they could be used for broader purposes.  
> Imagine all the handy stuff the selector cascade process could do to  
> auto-generate appropriate ARIA markup for the same generalized chunk  
> of HTML based on the context of its location in the DOM. All those  
> joys and challenges of specificity could be made to work for ARIA as  
> well.

Selectors can be made to work for ARIA today. Most JavaScript  
libraries have a "get elements by selector" method like the example  
used above. $$('.tree li')

Received on Tuesday, 24 February 2009 00:22:17 UTC