Comment details

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?

Answered question

The :before and :after CSS textual content rules are handled by requiring the UA to include the 'before' and/or 'after' text when computing the text alternative. This reflects a general rule, namely, that the UA "knows" what the relevant text is.

The new CSS content rules provide additional ways to alter how text content is rendered. These include:
- image replaces text.
- text replaces image.
- (new) text replaces (old) text.

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

We agree.
- when an image replaces text, then the UA should use the original text, since that text is presumably the equivalent.
- when text replaces an image, then the UA should provide that text.
- when new text replaces old, then the UA should include the new text, since that is what is rendered on screen.

Aside: There is a potential problem with an image replacing text where the original text is the meaningless "put image #1 here". In this case, we would recommend using more descriptive text. Compare this situation with the recommendation that an author not use something like "image #1" for @alt text.

> 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?

Yes, but the wording should be done with care. These new CSS content rules are part of a working draft, and are not standard. The ARIA specification ought to reference other specifications that are settled, or nearly so. In addition, future versions of CSS might include even more content rules that ARIA cannot anticipate. It is ultimately up to a group working on CSS to define the accessibility API mapping of that information when applied to a host language.

With that mind, we propose to add a general statement about CSS content rules to the text computation algorithm.