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

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