Re: ARIA in CSS (Was: [user-context] What are the use cases for exposing screen reader or magnifier version info?)

James,

Have you seen Tab's Cascading Attribute Sheets 
<http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html> proposal 
[1] which would solve a lot of these issues albeit creating another in 
that they would only be applied when elements were inserted into the DOM.

Regards,
James
[1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html



On 2/4/2013 5:14 PM, James Craig wrote:
> (Since this thread has moved off of the IndieUI topic, I've moved it to the ARIA (wai-xtech) list, and put IndieUI in the BCC for this message.)
>
> FWIW, am not opposed to doing some of ARIA 2 in a more CSS-like way, but the role and other aspects of ARIA would need to be programmatically determinable from the element, and so far that's the main reason why it's been easiest to hang things off the DOM node.
>
> I proposed a related issue for ARIA 2.0 a while back.
> ISSUE-119 (XBL for ARIA2): Consider use of a technology like XBL or BECSS to assign ARIA semantics (roles/state/props) and event handlers
> http://www.w3.org/WAI/PF/Group/track/issues/119
>
> Lisa Seeman mentioned this a couple times.
> https://lists.w3.org/Archives/Member/w3c-wai-pf/2010JulSep/0146.html
>
> Jamie Teh (NVDA) and others have raised the topic of potential ARIA in CSS, too.
>
> Also, role extensibility and other programmatic determinations would need to precede any change in the way we specify ARIA features. In other words, if you say role="switch checkbox", the web author needs to be able to determine which role was applied for the element. Likewise this would be needed if the role was applied via a linked document like an XBL or CSS file.
>
> ISSUE-9: Role Extensibility https://www.w3.org/WAI/PF/Group/track/issues/9
>
>
>
> On Feb 4, 2013, at 4:38 PM, James Craig <jcraig@apple.com> wrote:
>
>> set-size and posinset are only necessary if the DOM does not reflect the full tree, so while your CSS counter example appears very clean in the small example:
>>
>>>   aria-setsize: 16;
>>>   aria-posinset: calc(index + 1);
>> It would become more unwieldy when using larger data sets
>>
>> <ul role="listbox" aria-labelledby="label_fruit">
>>    <li role="option" aria-setsize="247" aria-posinset="163"> apples </li>
>>    <li role="option" aria-setsize="247" aria-posinset="164"> bananas </li>
>>    <li role="option" aria-setsize="247" aria-posinset="165"> cantaloupes </li>
>>    <li role="option" aria-setsize="247" aria-posinset="166"> dates </li>
>> </ul>
>>
>> Every time the table scrolled, you'd have to update your CSS rule offset.
>>
>>>   aria-posinset: calc(index + 163);
>> Why bury functional information specific to one control inside a CSS rule? IMO, it's much better to store this on a DOM attr, even if it is more verbose.
>>
>> James
>>
>>
>> On Feb 4, 2013, at 2:44 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:
>>
>>> Rich,
>>>
>>> To clarify, I'm not proposing that the media type would replace any screen reader or magnifier features. The web app would still use ARIA to expose accessible information about the page and Indie UI to get accessible events. The difference would be that the author would have the option of specifying this ARIA markup using CSS in addition to DOM attributes, which could be a lot more efficient.
>>>
>>> Here's a specific example of where this would help, taken straight from the ARIA spec:
>>>
>>> <ul role="listbox" aria-labelledby="label_fruit">
>>>    <li role="option" aria-setsize="16" aria-posinset="1"> apples </li>
>>>    <li role="option" aria-setsize="16" aria-posinset="2"> bananas </li>
>>>    <li role="option" aria-setsize="16" aria-posinset="3"> cantaloupes </li>
>>>    <li role="option" aria-setsize="16" aria-posinset="4"> dates </li>
>>> </ul>
>>>
>>> Instead, I propose the page could be marked up more like this:
>>>
>>> <style>
>>> ul#fruit li {
>>>    aria-setsize: 16;
>>>    aria-posinset: calc(index + 1);
>>> }
>>> </style>
>>> <ul id="fruit" role="listbox" aria-labelledby="label_fruit">
>>>    <li role="option"> apples </li>
>>>    <li role="option"> bananas </li>
>>>    <li role="option"> cantaloupes </li>
>>>    <li role="option"> dates </li>
>>> </ul>
>>>
>>> There are several potential advantages of this approach:
>>>
>>> * Many web pages already have CSS styles for certain properties that need ARIA markup. This allows them to be tied together rather than requiring duplicate code.
>>> * When the accessible media type is not loaded, the browser wouldn't need to bother keeping track of these attributes.
>>> * Even when loaded, DOM operations would be faster in many cases because there'd be fewer attributes per element.
>>> * Finally, it'd add an additional tool for web developers to inject accessibility fixes into shipping products without refactoring third-party code.
>>> * It'd be purely optional and wouldn't add any new ARIA attributes or capabilities, it'd just provide alternative syntax.
>>>
>>> - Dominic
>>>
>>> On Mon, Feb 4, 2013 at 2:06 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>>> Dominic,
>>>
>>> Although the page load may increase if authors were to bind CSS to ARIA attributes the amount of JavaScript would drop considerably. Also, the really big overhead for ARIA is the keyboard support which should drop considerably with Indie UI both from a device independence perspective and from a content adaptation, based on user preferences, perspective.
>>>
>>> So, this looks like a longer term strategy. If this approach were taken how do you address some of the added functionality that is provided for by screen readers and magnifiers like detailed review mode, etc. that you would not (at least it is not readily apparent to me) get form a media adaptation?
>>>
>>> Rich
>>>
>