Re: CSS issue: Need fallback alternatives for CSS generated *text* content containing unicode glyphs

On Nov 15, 2012, at 1:12 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:

> [James Craig:]
>> 
>> The text character is exposed to accessibility trees according to the
>> rules in the ARIA text alternative computation [1]. 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.
> 
> What screen readers are you using?

 VoiceOver on OS X and iOS both speak this character in generated content.

> Those I've tried limit themselves to DOM nodes and have no access to generated content. 

WebKit exposes CSS-generated text content. I believe other implementations are "working on it." If Internet Explorer does not support it yet, then the engine has a compliance bug with that portion of the normative ARIA name computation.

"3. Text nodes are often visited because they are children of an element that uses rule 2C to collect text from its children. However, because it is possible to specify or alter textual content using CSS rules, it is necessary for user agents to combine such content, as appropriate, with the text referenced by the text nodes to produce a complete text alternative. An example is the use of CSS :before and :after pseudo-elements, where the user agent combines the textual content specified in the style sheet with that given in the DOM." — http://www.w3.org/WAI/PF/aria/complete#tac_gencss

>>  /* similarly */
>>  .new:before { content: url(./img/star.png), "New!"; }
> 
> I assume you are referring to the GCPM version of the content property. I would 
> expect "New!" to be used in this case if start.png does not load i.e. it's not 
> really alt text fallback. (Also note that many implementations do not yet support 
> this content syntax and will reject the declarations above).
> 
>> What does the CSS working group recommend for this scenario?
> 
> I'm not sure the content property supports the notion of alternative content
> as you intend it yet.

When we specifically asked about this technique at the 2011 TPAC Joint Meeting between  PFWG and CSSWG, this recommendation was supported by Elika, and her feedback was generally acknowledged and approved by other members of the working group in the room.

 00:12:53 [fantasai]
 [href$=".pdf"]::after { content: url(PDF.png), "[PDF]"; }

http://www.w3.org/2011/10/31-css-irc

Repeating Sylvain:
> I would  expect "New!" to be used in this case if start.png does not load i.e. it's not  really alt text fallback.

It's modality-based fallback, and a screen reader is a mode that would not be expected to present images in the strict sense. Said another way, images never "load" for a user who is entirely blind, so I think using this for alternative text is an acceptable expectation despite the fact that it's not yet widely supported in implementations.

An alternate solution, that was proposed off-list, was for CSS to offer another property to indicate whether the value of the content property was considered decorative or not.

 .expandable:before {
  content: "\25BA"; /* a.k.a. ► */
  generated-content: decorative; /* something like this? like adding aria-hidden="true", but applied to the psuedo-element */
 }

James

Received on Thursday, 15 November 2012 22:18:11 UTC