ARIA: Clarify whether how CSS replaced content would be included/excluded in accessible text determination

Re: http://www.w3.org/WAI.new/PF/aria/complete#namecalculation

ARIA's accessible text determination method includes CSS generated content:

"because it is possible to specify textual content using the CSS :before and :after pseudo-elements, it is necessary for user agents to combine such content with the text referenced by the text nodes to produce a complete text alternative."

Currently, web developers use hacks to replace text with CSS added content, such as moving text off-screen and putting a background image in its. While these hacks do have negative accessibility impacts, they do not affect the accessible text calculations.

CSS3 Working Drafts proposes new features for replacing content with CSS:

   * http://www.w3.org/TR/css3-content/#inserting3

   * http://www.w3.org/TR/css3-ui/#element

Here's some discussions of how web developers might want to use these features to replace their current hacks:

   * http://www.css3.info/image-replacement-in-css3/
   * http://my.opera.com/ODIN/blog/css-3-image-replacement
   * http://css-discuss.incutio.com/wiki/Image_Replacement
   * http://dev.opera.com/articles/view/css-generated-content-techniques/

These have some experimental implementations. Both Opera and WebKit will replace content with images, and Opera will also replace content with text.

So how does this affect accessible text determinations?

Currently, Opera exposes original text *and* new text when text is replaced with text, but exposes nothing when images are replaced. Likewise WebKit exposes nothing when text is replaced with an image.

It would be good for ARIA to take a stand on this.

Should new text added with such features be included in accessible text determinations? I'm guessing, by the current spec text by analogy with :before and :after, it should be?

But then should original text replaced with such features be included in accessible text determinations?

If original text is not included in accessible text determinations, then accessibility-aware developers will need to continue to use either "img" (with its costs to performance and skin-ability) or their existing hacks (with their costs to accessibility).

If original text and new text are both included which should go first when the accessible text is concatenated?

--
Benjamin Hawkes-Lewis

Received on Monday, 13 September 2010 06:46:14 UTC