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

+Tab (who may not be subscribed to the xtech list)

James N, Tab's proposal [1] looks somewhat promising, but this part could be a deal-breaker for use with general aria-* attributes. The ARIA case Dominic was trying to solve [2] would require dynamic updatability (e.g. aria-posinset), and the case I was trying to solve (ARIA in CSS for generated content [3]) would not really apply, unless CAS were somehow able to apply attributes to CSS pseudo-elements.

Tab Atkins Jr. wrote:

> CAS files are *not* as dynamic as CSS.  They do not respond to
> arbitrary document changes.  (They *can't*, otherwise you have
> dependency cycles with an attribute selector rule removing the
> attribute, etc.) My thought right now is that your CAS is only
> applied to elements when they are inserted into the DOM (this also
> applies to any parser-created elements in the page).  This allows us
> to keep information tracking to a bare minimum - we don't need to
> track what attributes came from CAS vs the markup or setAttribute()
> calls, we don't need to define precedence between CAS and other
> sources, and we don't need to do any of the fancy coalescing and
> whatnot that CSS changes require.  Semantically, a CAS file should be
> exactly equivalent to a <script> that does
> "document.querySelectorAll(<selector>).forEach(<do attribute
> mutations>);", plus a mutation observer that reruns the mutations on
> any nodes added to the document.  It's just a much more convenient way
> to express these.

[1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html
[2] http://lists.w3.org/Archives/Public/wai-xtech/2013Feb/0009.html
[3] http://lists.w3.org/Archives/Public/wai-xtech/2013Feb/0027.html


On Mar 4, 2013, at 3:56 PM, James Nurthen <james.nurthen@oracle.com> wrote:

> James,
> 
> Have you seen Tab's Cascading Attribute Sheets 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
>>>> 
>>>> 
>> 
>

Received on Tuesday, 5 March 2013 01:32:02 UTC