Screen Readers and Cascading Style Sheets

Hiding Content with CSS

When more web developers started moving from tag soup and table-based design to standards-based design and CSS-based layouts, some developers looked for techniques to hide skip navigation links. Some developers used the CSS rule display: none to hide skip links, assuming that this would hide the skip links only in the visual modality but not in the aural modality.

Note that the CSS 1 specification does not make assumptions about the modality in its definition of display:none except where it mentions the “surrounding box”: A value of ‘none’ turns off the display of the element, including children elements and the surrounding box. The CSS 2 specification, however, may have confused developers by its emphasis on boxes: This value causes an element to generate no boxes in the formatting structure (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; this behavior cannot be overridden by setting the ‘display’ property on the descendants. The specification also points out that display:none is not the same as creating an invisible box.

(The sample stylesheet for HTML 4.0 contains the rule HEAD { display: none }; display: none is not used anywhere else in this stylesheet.)

The draft of CSS3 module: The box model finally solves the ambiguity by defining the effect of display:none as follows: The element is not rendered. The rendering is the same as if the element had been removed from the document tree, except for possible effects on counters (see [generated] or [paged]).

The next two sections reproduce test results from 2003 and 2005.

Survey results from testing in 2003

Note: More recent results, June 2005, are available on Bob Easton’s [Access Matters blog].

Notes:

1. Styles coded as embedded or inline in the html behave identical to having the styles within linked style sheets.
2. @import occurring within a linked style sheet produces results identical to having the @import directive in the <style> element of the html.
3. Jaws speaks these only because it does not heed imported style sheets. When Jaws does learn to import style sheets, it will not speak these either.
4. Sometimes used with screen readers.
5. Not a screen reader, but indicative in some ways.
6. I am guessing that these products do not read CSS.
7. Almost too good to believe! Aimed specifically at Internet users, maybe this Freedom Scientific product is paying attention to standards?

Source: Screenreader Visibility (css-discuss).

Visibility Test Results from 2005 (Access Matters)

Notes:

• Fangs is rated y/n if the hidden material is displayed in the Fangs’ Screen Reader Output text, but not displayed in the Firefox visual display.
• Test 10 in IE: text overprints next line. In Safari: VoiceOver cursor is visible.
• Test 11: Text is not displayed, but space is reserved for the text block.
• Test 12: IE and Safari display first letter of text, sometimes more.

Source: Screen Reader Visibility Test Results (Access Matters.

CSS Layout

A summary of tests is available at Screen Readers and CSS Layout (by Access Matters, 2005). The tests used four designs from CSS Zen Garden. The executive summary:

Current versions of the three leading screen readers speak page contents in the exact order the content is coded in the HTML source. CSS positioning is irrelevant.

Yes, other products and older versions of these same products might perform differently.

In the table below, reproduced from the above web site, a “-” means that content was hidden with display:none, and “X” means that content was spoken by the screen reader or user agent. The programs tested were Jaws 6.1 (J), Window Eyes 5.0 (W), IBM Home Page Reader 3.04 (H).

Recordings for VoiceOver Mac OS X 10.4 Tiger are available at the Webcrumbs blog. The results were different for the fourth design: the download links were read first.

Roger Johansson says he tested the pages with Apple VoiceOver with similar results as those available at Access Matters. Turning Full Keyboard Access on or off (which Joe Clark suggested) did not seem to make a difference.

Image Replacement

There are links to test cases at Quiz 1.1.4: Image Replacement Techniques (by Access Matters) but there are few test results in the comments, and the results are not always easy to interpret. The comments also contain links to other image replacement techniques.

Alastair Campbell also has a short article on Image replacement and Voiceover.

Generated Content

In the section on "Generated content, automatic numbering, and lists" of the current last call working draft of CSS 2.1, I found the following statement: Generated content does not alter the document tree. In particular, it is not fed back to the document language processor (e.g., for reparsing). (The ‘content’ property).

The current CSS 2 specification says the same thing (The ‘content’ property; just before section 12.3).

In CSS Accessibility, Jim Allan notes that: Current assistive technology relies on what the user's browser supports, that is what can the browser display on the screen). If the browser does not support a CSS rule, the user/AT will not “see” it.