- 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