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

I agree with James. There are a LOT of issues around this. In particular,
there is a huge impact on accessibility test tools - in effect this would
break all the accessibility test tools for rich web available today.

As I said to Dominic we have:

   Finish ARIA 1.0
   SVG2 accessibility
   Canvas accessibility wrap up. It looks like the new Shape object will
   meet our needs for magnification and touch.
   ARIA 1.1
   Wrap up of HTML5 accessibility features
   Indie UI 1.0 events and user context

that need to get done in the next 2 years. Doing a CSS solution correctly
also requires education, tooling, and AT support. To achieve those items on
the list requires all the accessibility resources we have, and then some,
and frankly those items above are far more important than the CSS approach.
Other vendors have expressed the need to address more in the way of the
interaction model in ARIA 2.0 as well. Finally, to me a top, top, top,
priority is Indie UI events as we must have them for mobile. It is was a
known deficiency in the ARIA 1.0 spec. that we need to fill ASAP. I will
also point out that now that we have some accessibility support in canvas
that I am seeing an uptick in the use of canvas. At CSUN there were
multiple sessions discussing canvas accessibility.

I am not suggesting that we dismiss the discussion but rather we should
table the discussion to ARIA 2.0. Taking all the issues in their entirety
for ARIA 2.0 we need to look at all the issues around extensibility, SVG 2
taxonomies, CSS, etc. holistically. That takes some time and heads down
engineering for which we are already committed.

Rich


Rich Schwerdtfeger



From:	James Craig <jcraig@apple.com>
To:	Dominic Mazzoni <dmazzoni@google.com>, "wai-xtech@w3.org
            WAI-XTECH" <wai-xtech@w3.org>,
Cc:	Richard Schwerdtfeger/Austin/IBM@IBMUS, Janina Sajka
            <janina@rednote.net>
Date:	02/04/2013 07:14 PM
Subject:	ARIA in CSS (Was: [user-context] What are the use cases for
            exposing screen reader or magnifier version info?)



(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
>>