Developers often ask how various CSS declarations translate to the screen reader experience. Properties that are strictly visual—such as color, border, font, margin, padding—are transparent, but what about those that inject content, like ::before and ::after? What about properties that communicate meaning, like list-style and line-through? And then there are those that visually position or crop content, like clip, position, display, overflow, height, width, visibility… the list goes on. We all know that using CSS to generate content is bad, just as we all know that we should never ever exceed the speed limit. It happens.
Earlier this year, three colleagues and I tested and documented the behavior of some widely-used CSS declarations in screen readers, leaving the screen reader user settings at their defaults. We reported our findings at AccessU 2017 and will present again, with some new material added, at Accessing Higher Ground.
In addition to myself, our team included CB Averitt and Steve Sawczyn of Deque, and Birkir Gunnarsson. We tested the following screen reader-browser pairings:
- JAWS/IE 11
- JAWS/Chrome
- JAWS/Firefox
- NVDA/Firefox
- NVDA/Chrome
- VoiceOver/Safari
- VoiceOver/Mobile Safari
- Talkback/Mobile Chrome
Key Takeaways
Different screen reader/browser pairings behave differently.
It’s tempting to assert that if you do x, “the screen reader” will announce y. Sometimes it really is just that simple, but in a surprising number of situations, it just isn’t that absolute. For example:
- Across the pairings we tested,
counterwas announced three different ways. (CSS counters are “variables” maintained by CSS whose values can be incremented by CSS rules, to track how many times they are used.) - Using
vertical-align:superto communicate cents within a dollar amount worked in half of our pairings. In the other half, $1299 was announced as $1,299. - Applying a transition to
opacity:0; visibility:hiddenon a paragraph, we logged five slightly different behaviors across the eight pairings.
DOM order is everything.
One of the consistencies we found is that, regardless of CSS position, content is read in the order that it appears in the DOM. For example, appending a <div> to the end of the <body> and then using position:absolute to boost it to the top of the viewport will not change the reading order in the screen reader—it will still come last (and in this case, we can safely say “the” screen reader).
The same is true for floats. Applying float:right to an element typically positions it “after” (to the right of) the element that follows it in the DOM, making the visual reading order the opposite of the DOM order. Since the DOM order is what determines the screen reader reading order (and the tab order, in the case of active elements), the elements will be announced in the opposite order from the visual reading order.
Containers are only visual.
Many CSS properties are available to apply dimensions to containers—height, width, max-height, max-width, clip—and overflow and text-overflow determine whether and how content exceeding the bounds of the container are rendered. Across all of our test pairings, all of these are transparent to screen readers. Regardless of the content being clipped out visually, or obscured by overflow:hidden, the screen reader will announce all content in the container. Even opacity:0 has no effect in the screen reader environment; the content is announced nonetheless.
The moral of the story
All of this really highlighted the value of accessibility-minded development and pre-launch testing—in a wide variety of browser-screen reader combinations—to ensure that all website visitors enjoy a consistent, equivalent experience.
For more information
This is just a brief overview of our findings. For details, please check us out at Accessing Higher Ground in Westminster, Colorado on Friday, November 17, 2017 or contact [email protected].
Great original research, kudos to authors.
But still leaves the practical question unanswered: how much testing is too much, and how little testing is too little?
Beyond practical considerations, how much of this screen reader behavior variability is attributable to platform differences and how much to screen readers themselves?
Even though I find accessibility very important, I have issues with the general attitude of “devs should make sure behaviour is consistent for screen-readers”.
Don’t get me wrong, I totally believe devs should make their content accessible, but if screen readers X, Y, and Z all produce different results, then the issue is with the screen readers.
very much like browser rendering inconsistencies. There’s a spec to be followed and if a browser deviates from the spec, then it shouldn’t be up to the dev to “fix” that.
I know it’s not this black and white usually (we all have dealt with our ie.css files back in the day for example), but I think those who author screen readers should step up and make sure all readers adhere to the same spec.
Great work! One odd thing I’ve found is in using flexbox. While flexbox allows you to reorder the children, it should still be read in DOM order. Last time I checked, in FFOX, it was not (and for that reason, we don’t use the order property). Did you all do any flexbox testing? I’d be interested in the results.
Cheers!
Looking forward to hearing more at Accessing Higher Ground! See you there.