Testing the accessibility of the CSS generated content

This article is about how screen readers speak the content added with CSS pseudo-elements :before and :after (in CSS3 they are ::before and ::after).

I am trying to learn to use AT when developing websites and recently I saw that no matter how W3C wants us to use a certain CSS element, there will always be developers/designers who will try to push the limits of the specification.

While I do advise you to NOT use pseudo-elements to generate useful content (limit yourself to generating quotes or design elements), just in case somebody thinks that the cool resides in generating content with CSS because everything else is already old, let’s see how people using screen readers will “benefit” from the idea.

A piece of code…OK, maybe two…

The HTML is really simple, an innocent paragraph of text:

<h1>Example of content added with CSS pseudo-elements</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit..and so on.</p>

and the CSS is also quite simple:

#content p:before {
content:"This is before the text, you can style it";
}
 
#content p:after{
content:"This is after the text";
}

Let’s hear voices

The video will show how NVDA, Jaws and Window Eyes read the page – I set NVDA to read at a lower rate in order for you to follow, but the other 2 are a bit faster.

The conclusion

There’s no need for me to tell you how bad the idea is, DON’T use these pseudo-elements for generating useful content, limit its use to generating quotes, breadcrumb icons, fluffy snowflakes or whatever. But keep it presentational in order for other people to have access to the useful stuff.

Check the Spanish version of this post:
Probando la accesibilidad del contenido generado por CSS

9 thoughts on “Testing the accessibility of the CSS generated content”

  1. I’ve heard that VoiceOver on the Mac does read generated content, but I don’t have it myself to check. Would you mind posting the link to your simple test page so we can get someone to check it on VoiceOver? (BTW, even if VoiceOver does read the generated content, I agree with you that generated content shouldn’t be used for anything essential. I’m just curious!)

  2. VoiceOver will read generated content. However, it does not read dynamic generated content. So, you can a string, such as {content: “Step”}
    but it won’t read something generated in the css, such as {counter(fieldsets)}

  3. Obviously it is not good practice to generate content in this way because of the way screenreaders handle it, but I would be interested to know if this is in fact amounts to a bug within screenreader software becuase the specification defines this as content so they should be made able to read it.

  4. “Obviously it is not good practice to generate content in this way because of the way screenreaders handle it, but I would be interested to know if this is in fact amounts to a bug within screenreader software becuase the specification defines this as content so they should be made able to read it.”

    I totally agree. As much as I see actual content as belonging to the DOM of the page and anything generated by CSS as presentational (screen readers don’t and shouldn’t read out the entire markup of a page just because it is there in the source) I can totally see uses for it for the purposes of allowing users to override stylesheets on a website to add notes etc. But being that I personally think this should be handled by the browser directly or by a third party utility, I would like CSS content to be treated like padding and positioning … consistence in browsers in one things, but to not have consistence in screen readers is also not helping.

  5. Doh! I’m actually using generated content for some presentation, and actually don’t want it to be read by VoiceOver on iOS in my case. I would ideally be using an background image instead, but I wanted to cut down on bytesize by using text character in :after content. I can’t use role=”presentation” on the element itself, because only the generated content is for presentation!

    Generated content seems to be a tricky thing in general, regardless of whether screen readers read the content or not. :/

Comments are closed.