Massive growth in the digital content over the last couple of years has led to a constant conjecture on how to make this content accessible to assistive technologies, and to screen readers in particular.
While striving for an optimal degree of accessibility, we often emphasize HTML semantics, ARIA attributes and/or scripts. While these are significant factors to improve content accessibility, we tend to ignore another important contributor: CSS.
Before we jump into the details, let us have a quick recap of what we understand by CSS and screen readers.
CSS or Cascading Style Sheets is a stylesheet language used to describe the presentation of a document written in HTML or XML (including XML dialects such as SVG, MathML or XHTML). CSS describes how elements should be rendered on screen, on paper, in speech, or on other media.
CSS is one of the core languages of the open Web and is standardized across browsers according to W3C specifications. The sole purpose of the CSS is to present data to users in an intuitive manner.
Screen readers (SR) are software applications that attempt to convey what is seen on a screen display in a non-visual way, usually as text to speech, but also into braille or sound icons. Screen readers are essential to people with partial or severe visual impairments, or having a learning disability. JAWS, NVDA, VoiceOver, TalkBack, etc. are some examples of screen readers.
In an ideal scenario, CSS should not impact SR reading behavior. However, after working extensively with various SRs and different types of data, we have come to the conclusion that certain CSS properties indeed alter the reading order. One of the interesting observations is that only a handful of the more popular SRs (as per the tests conducted) are affected by the CSS properties.
We need to first establish the SR and browser combinations tested to derive the results. They are as mentioned below:
- JAWS + IE (Internet Explorer)
- NVDA + FF (Firefox)
- VO (VoiceOver) + Safari
- TB (TalkBack) + Chrome
Though many other combinations are available, we kept our test suite limited to these pairs. Other blends might result in different outcomes.
Let’s look at some CSS styles and how SRs respond to them:
| CSS Style | JAWS + IE | NVDA + FF | VO + Safari | TB + Chrome |
| display: inline on block elements | No change in reading behavior. | Block elements are treated as inline elements and content is read in continuity without pause. | Block elements are treated as inline elements and content is read in continuity without pause. | Block elements are treated as inline elements and content is read in continuity without pause. |
| display: block on inline elements | No change in reading behavior. | Inline elements are treated as block elements and content is read with pause. | Inline elements are treated as block elements and content is read with a pause. | Inline elements are treated as block elements and content is read with pause. |
| ::before, ::after | Content is not read. | Content is read correctly. | Content is read correctly. | Content is read correctly. |
| display: table | No announcement of a table or any table elements. | No announcement of a table or any table elements. | No announcement of a table or any table elements. | No announcement of a table or any table elements. |
| counter | Content counter values are not read. | Counter values are read correctly. | Counter values are read correctly. | Counter values are not read. |
| UL with list-style: decimal. | Exposed as a three-item list; reads “bullet”. No mention of numbers. | Exposed as “list with 3 items”; announces number before each item. | Conveys “list start” and “list end”. Conveys “#” at the start of each list item. | Conveys “In list” at beginning and “#” at the start of each list item. Does not mention “list end”. |
The list is not exhaustive and results may vary based on SR–browser pairings. Here, we have highlighted the most frequently used CSS styles and the erratic behavior we observed in their reading order. This was surprising to us as well because while debugging the matter, our primary focus was on the semantics or the scripts, and verifying the styles was the last place to investigate the root cause of such behavior.
Through this information, we want to make our readers aware that our confidence in using CSS for its presentation or animation capabilities has been slightly tempered. When it comes to SR accessibility, CSS styles might throw up some unexpected consequences.
Author: Kalpeshkumar Jain, Lead Accessibility Expert, LearningMate Solutions