RE: XTECH: ARIA in CSS for generated content (Was: CSSWG: Need fallback alternatives for CSS generated *text* content containing unicode glyphs)

So, the general idea seems to add extra ARIA info into CSS to control better the screen reader output.
And this will have probably performance impacts, if I understand that right.

Another valid alternative would be IMHO to sit together with the screen reader guys and give them a general interpretation speech pattern
what they have to announce in the use cases described. For Apple, this should be a home run. Others may follow or may not.

Anyway, the effort on screen reader side to implement these may be comparable to the effort implementing the proposed extensions for ARIA 2.0. In addition, who grants that even after implementation, speech output will not differ again from what you intend?

- Stefan



-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Freitag, 1. März 2013 02:59
To: Alexander Surkov
Cc: wai-xtech@w3.org WAI-XTECH; Dominic Mazzoni; James Teh
Subject: Re: XTECH: ARIA in CSS for generated content (Was: CSSWG: Need fallback alternatives for CSS generated *text* content containing unicode glyphs)

On Feb 28, 2013, at 5:49 PM, Alexander Surkov <surkov.alexander@gmail.com> wrote:

> As long as ARIA allows to generate content ARIA in CSS looks
> reasonable. However I expect this can be a performance hit since
> browsers need to watch both DOM and CSS, especially because a single
> change in CSS can cause the thousands of accessibility events. If the
> author is not cautious enough then ARIA in CSS can become a bottleneck
> easily. Are there other alternatives to control accessibility mappings
> of CSS generated content?


The only way I know of is using the reader media type I mentioned below. This could allow basic functionality like hiding and labeling, but to my knowledge, no browser implements that media type, and the draft has been stagnant for nearly a decade (2004).


>>> Since, to my knowledge, there is no way to define modality-specific
>>> alternatives to unicode glyphs, we could potentially implement the "reader"
>>> media type.
>>> 
>>> .expandable:before { content: "\25BA"; /* a.k.a. ► */ }
>>> @media reader { .expandable:before { content: ""; } }
>>> 
>>> .new:before { content: "\2730";  /* a.k.a. ✰ */ }
>>> @media reader { .new:before { content: "New!"; } }
>>> 
>>> However, the CSS 3 Reader draft [3] has made no progress since 2004, and
>>> appears to be stagnant.



> On Fri, Mar 1, 2013 at 6:50 AM, James Craig <jcraig@apple.com> wrote:
>> Not seeing much traction on this thread in the www-style group [1], so I'm
>> moving to wai-xtech to discuss this in the context of an ARIA solution. This
>> represents an accessibility and usability problem for Apple in several
>> production environments, so we need to find a web standard solution to make
>> this work. I'm leaving the www-style list in the BCC for this one message,
>> so that any interested parties know to follow the thread on wai-xtech.
>> 
>> Background:
>> 
>> The issue of allowing ARIA in CSS has been raised and soundly rejected
>> several times, as the general consensus (of both PFWG and CSSWG) is that
>> functional information like ARIA should be available in the DOM. I generally
>> agree with this consensus. However, it's recently come to my attention that
>> sometimes this is not possible, particularly with regards to generated
>> content and pseudo-elements that have no DOM node on which to hang ARIA
>> attributes. For example:
>> 
>> On Tuesday, 13 November 2012 22:42:29 GMT, James Craig wrote [1]:
>> 
>>> With the following markup:
>>> 
>>> <li role="treeitem" aria-expanded="false" class="expandable">Vegetables</li>
>>> 
>>> And this CSS:
>>> 
>>> .expandable:before { content: "\25BA"; /* a.k.a. ► */ }
>>> 
>>> The text character is exposed to accessibility trees according to the rules
>>> in the ARIA text alternative computation [2]. This character is spoken by
>>> some screen readers or text-to-speech engines as "Black right-pointing
>>> pointer" according to the unicode description for the character.
>>> 
>>> So the expandable tree item is spoken like this:
>>> 
>>> "Black right-pointing pointer, Vegetables, collapsed"
>>> 
>>> This is obviously not ideal, as the glyph is intended as a style that is
>>> already conveyed semantically via the attributes, and should be spoken as
>>> this:
>>> 
>>> "Vegetables, collapsed" (the 'collapsed' string varies by screen reader, but
>>> is generated based on aria-expanded="false")
>>> 
>>> CSS allows for text alternative fallback content to CSS-generated images,
>>> like so:
>>> 
>>> /* empty fallback text string, because the semantics are defined in the DOM
>>> */
>>> .expandable:before { content: url(./img/collapsed.png), ""; }
>>> 
>>> /* similarly */
>>> .new:before { content: url(./img/star.png), "New!"; }
>>> 
>>> /* or even better */
>>> .new:before { content: url(./img/star.png), attr(data-new); } /* allows DOM
>>> localized values for @data-new="New!" */
>>> 
>>> However, there is no way to do the same thing with unicode characters
>>> exposed as text content.
>>> 
>>> .new:before { content: "\2730", "New!"; } /* both are text, so no way to
>>> declare modality in fallback order */
>>> /* this character is ✰ which would be spoken as "black shadowed white star"
>>> instead of the intended "New!" */
>>> 
>>> If this were an element (as opposed to a pseudo-element) we could override
>>> the label with @aria-label or hide the element entirely with @aria-hidden.
>>> Since, to my knowledge, there is no way to define modality-specific
>>> alternatives to unicode glyphs, we could potentially implement the "reader"
>>> media type.
>>> 
>>> .expandable:before { content: "\25BA"; /* a.k.a. ► */ }
>>> @media reader { .expandable:before { content: ""; } }
>>> 
>>> .new:before { content: "\2730";  /* a.k.a. ✰ */ }
>>> @media reader { .new:before { content: "New!"; } }
>>> 
>>> However, the CSS 3 Reader draft [3] has made no progress since 2004, and
>>> appears to be stagnant.
>> 
>> 
>> Also, as Dominic Mazzoni (Google), Jamie Teh (NVDA), and others have pointed
>> out [4], even when it's possible to use the DOM for ARIA, it can represent a
>> large number of DOM manipulations in certain circumstances which has
>> potential performance implications.
>> 
>> Proposal:
>> 
>> It is for the above reasons that I am proposing allowing a limited set of
>> ARIA properties into CSS interpreters as part of ARIA 2.0.
>> 
>> .new:before { content: "\2730"; aria-label: "New!"; }
>> .new:before { content: "\2730"; aria-label: attr(data-pseudo-alt); } /*
>> would allow pseudo-element attrs to be defined on the parent node */
>> 
>> In the case of true style information that is already adequately represented
>> in the DOM, this would allow an author to explicitly prevent the generated
>> content from being exposed to screen readers.
>> 
>> .expandable:before { content: "\25BA"; /* a.k.a. ► */ aria-hidden: true; }
>> 
>> In cases where alternatives or properties could be conveyed using existing
>> CSS, don't use ARIA properties in CSS. This is more or less equivalent to
>> what we recommend for HTML, too. E. g. if you can use @alt (as on an <img>)
>> , there is no need to use @aria-label.
>> 
>> /* No need to override with aria-label, b/c CSS supports image fallback
>> text. */
>> .new:before { content: url(./img/star.png), "New!"; }
>> 
>> Thoughts? I'll raise the ARIA 2.0 issue in the PFWG tracker once any
>> discussion settles.
>> 
>> Thanks,
>> James Craig
>> 
>> 
>> 1. http://lists.w3.org/Archives/Public/www-style/2012Nov/0233.html

>> 
>> 2. http://www.w3.org/WAI/PF/aria/complete#tac_gencss

>> 3. http://www.w3.org/TR/css3-reader/

>> 4. http://lists.w3.org/Archives/Public/public-indie-ui/2013Feb/0010.html

>>

Received on Friday, 1 March 2013 07:52:44 UTC