- From: Chris Blouch <cblouch@aol.com>
- Date: Wed, 25 Feb 2009 10:30:11 -0500
- To: James Craig <jcraig@apple.com>
- CC: Chris Blouch <chris.blouch@corp.aol.com>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>
I need to make a retraction in that the actual author is Stuart Langridge who came up with the solution in response to a presentation by Matt Machell. That said, Stuart has posted some clarity on what his solution is and is not. I believe he argues for himself more clearly than I did: http://www.kryogenix.org/days/2009/02/25/updates-on-the-aria-stylesheet-hack CB James Craig wrote: > 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 Wednesday, 25 February 2009 15:30:58 UTC