Do screen readers just read content without paying attention to CSS?

My reason for asking is that I would like to use LESS.js for some of my CSS (so not all of it). As far as I'm concerned, users with JS disabled will get a basic experience anyway so they won't miss some of my presentational CSS.

However, what about Screen Readers... will they miss my extra CSS that's served via Javascript?

P.S. no piler suggestions please, I'm not interested - they slow down my workflow.

Thanks

Do screen readers just read content without paying attention to CSS?

My reason for asking is that I would like to use LESS.js for some of my CSS (so not all of it). As far as I'm concerned, users with JS disabled will get a basic experience anyway so they won't miss some of my presentational CSS.

However, what about Screen Readers... will they miss my extra CSS that's served via Javascript?

P.S. no piler suggestions please, I'm not interested - they slow down my workflow.

Thanks

• javascript
• css
• accessibility
• less

• Depends on what kind of CSS, I guess. If it's just rounded edges and gradients, you probably won't have to worry – Pekka Commented Nov 22, 2011 at 21:41
• 2 If you're doing something like div:before { content: "It was the best of times, it was the best of times yada yada yada aydaa " } and the reader doesn't parse css, then it's going to be "A Tale of NO Cities" instead. – Marc B Commented Nov 22, 2011 at 21:42
• 1 I can't think of any existing screen reader that understands even aural stylesheets... not even JAWS, no. So much for standardizing aural styles in CSS2.1. – BoltClock Commented Nov 22, 2011 at 21:43
• 2 456bereastreet./archive/201111/screen_readers_and_css – user470489 Commented Nov 22, 2011 at 21:50
• @BoltClock: the issue here is that the screenreader is not actually a user-agent/browser; it's just reading out what the underlying browser does, and the browser is rendering for a screen. A true speech-based browser might use an aural stylesheet, but currently none of the existing screenreaders follow that model. – BrendanMcK Commented Nov 22, 2011 at 23:52

3 Answers 3

The most important issue to understand here is that a screenreader is not a browser: it is an app that reads out the UI of other apps, either via speech, braille, some bination or the two - or possibly even some other means.

When reading the web, the screenreader doesn't actually load or parse HTML or CSS: the browser does that, and the screenreader reads out what gets displayed by the browser, typically by either accessing the underlying DOM directly (eg. on Win32 with IE, via the various IHTML* interfaces) or via an accessibility-related API.

(Note that this means that support can vary depending on the screenreader and browser bination; JAWS can work against IE or Firefox, but not currently Chrome, Opera or Safari; and might in some cases actually read things out differently against IE vs Firefox.)

Usually this means that screenreaders ignore most CSS - they pretty much ignore most formatting and layout and concentrate on content; but all modern screenreaders do take at least display: and visibility: into account, so they will not read out content that a sighted user would not see. For example, a screenreader would not want to read out "collapsed" text - until it was appropriate to do so. The key issue here is that these two CSS attributes actually have semantic meaning, so it's important for the screenreaders to convey that.

Since the screenreaders get these values typically from the DOM (either directly or indirectly), it doesn't matter whether they were set via inline styles, an external stylesheet, or at runtime via javascript.

--

A quick note on aural stylesheets: right now, they are simply not relevant at all to the screenreader scenario.

First, there's the issue that a screenreader user might not be using speech output in the first place.

Secondly, most screenreader users have their voice set to a very specific voice - typically a neutral one that the user can understand well at high speeds - and then they'll pump up the speed to a very fast speed that most folks won't be able to understand at all. The last thing a screenreader user wants is for some page to start overriding their voice settings.

This makes the screenreader experience fundamentally different from a speech-based UI (where an aural sheet might be appropriate). The UI is really still display-based; it just happens to be accessed by the user in an indirect manner; and that indirection might be via speech, or braille, or some bination. But you shouldn't have to care about that, so long as you have good semantic markup in your page in the first place.

They're supposed to take cues from the CSS properties defined in the voice module when figuring out how read CSS styled text.

The aural rendering of a document bines speech synthesis (also known as "TTS", the acronym for "Text to Speech") and auditory icons (which we refer to as "audio cues" in this specification). The aural presentation of information is mon amongst munities of users who are blind or visually-impaired. For instance, "screen readers" enable control of visual user-interfaces that would otherwise be inaccessible. There are other cases whereby listening to textual information (as opposed to reading it) is a necessity. Typical examples include in-car use of an e-book reader, industrial and medical documentation systems, home entertainment, helping users to learn reading, or supporting users who have reading difficulties (print disabilities).

When it es to documents, the quality of the speech rendition depends on the structure and semantics authored within the content itself. The CSS Speech module provides properties that enable authors to declaratively control presentational aspects of the aural dimension (e.g. TTS voice, pitch, rate, and volume levels). These style sheet properties can be used together with visual properties (mixed media), or as a plete aural alternative to a visual presentation.

Content creators can conditionally include CSS properties dedicated to user-agents with text to speech synthesis capabilities, by specifying the "speech" media type via the media attribute of the link element, or with the @media at-rule, or within an @import statement. When doing so, the styles authored within the scope of such conditional statements are ignored by user-agents that do not support this module.

Yes and no. CSS needs to be parsed for the screen reader to know whether or not to read an item. Items with display: none wont get read by a screen reader, however there are still other means of hiding content that can only be observed with a screen reader.

I highly remend downloading a development copy of JAWS or Window Eyes and performing an actual usability test of your site.