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 01:59:06 UTC