The Accessibility of ::before and ::after
I was recently reading a tutorial on how to use CSS counters. They look great! CSS counters are a new feature of CSS that allow us as developers to enumerate elements in the DOM and then do something with that information. There are plenty of practical uses for this - from numbering highlighted blocks in the text to creating complex nested ordered list bullets. (I mean, we’ve all read government documents that include bullet point 184.108.40.206. Right?)
All of these implementations involve using the
::after CSS pseudo-selectors in order to display the counter information on the page, before a particular block. With all of my work with accessibility this year, it begged the question: Is CSS-generated content accessible?
Is this even supported?
We should probably start with asking, are CSS counters universally supported by browsers. The answer is yes. Really, with 98.16% support according to CanIUse.com, this is barely a question.
Alrighty then. What about screen readers?
Screen readers are another story and one that, frankly, I was skeptical about. I did a bit of Google research and came across an article that showed mixed results in terms of whether the readers read this generated content. The biggest offender was in IE, where neither JAWS nor NVDA read the content. This is presumably because the content does not reside in the DOM and these readers are reading the DOM, as opposed to the visible content on the screen.
However, because this article is almost 3 years old, I decided to conduct my own experiment.
I created a simple example to use in testing that included content using both the
I tested in as many screen readers and browsers that I have access to. I have access to two operating systems (Mac OS X and Windows 10) and three screen readers (VoiceOver, JAWS, and NVDA). I used the latest versions of all browsers tested.
I came across a couple of issues that made testing… adventurous.
Why I did not test in Firefox
I tried! Firefox does not play well with screen readers. At all. When the browser sees that you are using a screen reader, it disables the the display of tab content because of “incompatibility”. This incompatibility appears to be universally true since I had this issue with every screen reader on both my Mac and PC.
The “solution” is to download the Firefox Extended Support browser. Because, you know, making your base browser compatible with accessibility software is too hard.
Except, that did not work. Even with the Extended Support version of the browser, both NVDA and JAWS refused to read anything on any web page. (I did not try to install this on my Mac because now I’m really angry at Mozilla.)
JAWS and Edge
JAWS does not support Microsoft Edge by default. Actually, any sort of Edge support in JAWS is relatively new, as it was introduced in the JAWS 18.0.4321 release in September 2017. In order to get JAWS to read content in Edge, you must both have a recent version of JAWS (always a good idea anyway) and turn the Edge browser support feature on in the Settings Center.
Specific results of my testing are in the table below:
|Chrome||Safari||Edge||Internet Explorer 11|
The good news is that all screen readers read the CSS generated content in Chrome, Safari, and Microsoft Edge. That is actually great news, since these 3 browsers combined account for over 73% of the global browser market share in November 2017 according to W3Counter Stats.
However, the bad news is that no screen reader was able to read the CSS generated content in Internet Explorer 11. (The study linked above from 2 years ago found the same results.) While IE 11 only accounts for 3.33% of the global market share (again, for November 2017), 3.33% of the entire world accounts to a fair amount of people.
You can very likely use CSS generated content without worrying too much about accessibility concerns. I don’t want to give you a full pass since, in addition to your IE 11 users (just upgrade to Edge already!), I did not even try to test on real mobile devices. However it did seem to work when I emulated mobile devices in Chrome using dev tools and tested with VoiceOver as a “quickie” test.