Cascading Style Sheets And Accessibility

This article is the first of a series that will discuss how Cascading Style Sheets (CSS) can be used to make Web sites more accessible. This introductory discussion is not meant to be exhaustive. Subsequent articles will delve deeper and cover more advanced topics.

What Is Accessibility

All users should be able to enjoy Web site content and services. This is a basic and widely recognized principle, but we sometimes forget that different users have different needs. People with visual impairments may need assistive technologies to surf the web; other users have physical impairments that make it hard, or impossible, to use standard pointing devices such as a mouse; many of us, at one time or another, may experience a temporary disability (such as a broken arm), and so on. Frequently, different levels of ability become barriers to accessing Web site content and services. To allow for different levels of ability, there are accessibility guidelines that a Web designer can follow when developing a Web site. The aim of these accessibility techniques is to make information and services available to everyone without discrimination. This, in short, is the meaning of Web accessibility.

Separating Structured Content From Presentation

There are many facets to Web accessibility, but the best place to start when trying to make Web sites more accessible is to separate structured content from presentation. This is one of the most important principles behind Web standards and accessibility.

Structured Content

Structured content is information organized into predefined constructs. A classic example is that of a book, in which content is logically organized into chapters, and arranged under headings, subheading, paragraphs and so on. Presentation would be the way in which the content appears in the book. This could include basic typographical considerations such as font choice and type, through to more complex visual layouts.

In the case of Web pages, content is structured using markup languages like (X)HTML. Using a predefined set of tags, (X)HTML gives structure to content by identifying content as headings, paragraphs, tables, lists and other common document constructs. In the example below, content inside the h1 tag represents a heading and content inside the p tag represent a paragraph.

  1. <h1>This is a heading</h1>
  2. <p>This is a paragraph.</p>

Web browsers, search engines and assistive technologies look out for these predefined set of tags and then process the content inside these tags accordingly.


Before widespread support for CSS, markup tags were used to apply formatting. The now outdated font tag was used to change font type, size and color. The blockquote tag, whose function is to represent a block of quoted text, was incorrectly used to increase margin width. The problem with using markup tags for formatting is that markup tags are embedded into the content which means that the visual significance of the content could only be processed in one way: the way determined by the designer. Inevitably, this limited the accessibility of the content for many users and devices.

The advent of CSS language changed the way content is formatted. Formatting rules no longer need to be embedded into the content. Instead, formatting rules can be created in separate files which makes it easier for designers to apply new formatting to content and for some devices to process content without the "noise" of formatting.

Writing CSS is easy. Below is an example of a simple CSS rule that changes the font size of text in paragraphs:

  1. p { font-size: small; }

CSS rules adhere to the following pattern:

  1. selector { property: value; }

The "selector" specifies to which markup tags the formatting properties will be applied. In our example the p selector indicates that the formatting properties will be applied to all paragraphs in the document.

"property" is an item from a list of predefined formatting characteristics like color, font, border, etc. In the example above, the font-size property is used to change the size of the font.

"value" is a number, a string, a percentage, a URI or a predefined keyword used to modify the "property". In the example above, font-size is set to the value of small (one of the CSS absolute-size keywords used to size characters).

The "property" and "value" in a CSS rule form the "declaration". A rule may contain many declarations, each followed by a semicolon. For example:

  1. selector { property: value; property: value; }

The part of the rule delimited by curly brackets is called the "declaration block".

Once CSS rules are written, they must be associated with one or more documents. For maximum flexibility, W3C recommends placing all CSS rules in a separate text file that is linked back to the (X)HTML document(s) using the link element (this type of CSS is called an "external stylesheet"). Using this method, a single external CSS file can control the formatting of an infinite number of (X)HTML documents, and is precisely how to ensure the separation of content from presentation that we described as being essential for accessibility.

Simple Suggestions For Using CSS With Accessibility In Mind

Length Units To Size Fonts

Everyone should be able to enlarge fonts in their favorite Web browser. This can make reading more comfortable for many people and is essential for those who have partial sight.

At the time of writing this article, the widely used Internet Explorer 6 browser is not able to enlarge text if the fonts are specified in pixels. The recently released IE 7 is able to do so, thanks to its new page zoom tool. However, to ensure backward compatibility, using pixel font sizes is still not a good method for sizing fonts.

Selecting the best font size units for accessibility has been rendered difficult due to a misunderstanding about "relative" units and accessibility. Checkpoint 3.4 of W3C's Techniques for Web Content Accessibility Guidelines 1.0 tells designers to "use relative rather than absolute units in markup language attribute values and style sheet property values". The following are examples of absolute units:

  • inches (in)
  • centimeters (cm)
  • millimeters (mm)
  • points (pt)
  • picas (pc)

It is not a good idea to use absolute units, because they are only useful when the physical properties of the output device are known, therefore the checkpoint suggests to always use "relative" length units instead. This is confusing since pixels are relative length units (they are relative to the viewing device resolution) and using pixels font sizes is not good for accessibility, at least for now.

We could say that the best relative units to size fonts are em or percentages (%). Indeed, designers should be able to use a unit of their choice, but on condition that it guarantees enlargement of text in every Web browser, which is a tough condition to satisfy. For that reason, it is preferable to talk about functions, rather than specific unit identifiers. Web browsers do evolve, and their support for length units and enlargement functions may change. So, instead of suggesting specific units, I suggest to always use scalable length units in order to size fonts. Also, don't forget that the interlinear space (the space between lines of text) must also be scalable. For this reason, it is preferable to use unit-less number values for the line-height property (e.g. 1.5), since unit-less number values are scalable and solve some additional problems too.

Finally, all Web browsers have a default font size for rendering text when no CSS is specified. This font size corresponds to a font-size value of 100%, 1em or medium keyword. You can adjust the default font size for the Web page via CSS like this:

  1. body { font-size: 0.7em; }

Web browsers will treat this value as the "Normal" or "Medium" font size for the given Web page. If the font size length units are scalable, then Web browsers can let users increase / decrease font size relative to the default font size for the given Web page.

But it is important to note that Web browsers have different abilities to let users increase the font size. Below is screen shot of text size controls in Firefox which lets users increase font size by multiple increments.

Screen shot of text size controls in Firefox.

Below is a screen shot of text size controls in IE, which has only two increments for enlarging text size.

Screen shot of text size controls in Internet Explorer.

Since IE only has two increments for increasing font size ("Larger" and "Largest"), the maximum text size IE can display may not be large enough for some users if the default font is set too low.

Interactive Elements

A person with physical disabilities that affect manual dexterity may use an alternative pointing device, or other assistive technology, to select interactive elements such as links or form buttons. Since the user's accuracy can be quite poor, placing links, buttons or form fields too close together can make their selection difficult. To facilitate easier selection:

  • Increase interlinear space values. Most browsers' default line-height value is set to 1.2. A value of at least 1.5 is often a better choice.
  • Increase the margin around items in vertical and horizontal lists of links. For example, in a vertical link list, write a rule such as the following: li { margin-top: 5px; margin-bottom: 5px; }. Spacing can also be enhanced using padding instead of margin.
  • Make sure there is adequate space between form buttons, and between form fields.

These are general suggestions, and suggested values are only examples.

Remember also that form button labels and form field content must, like regular text, be scalable. To make this work in Internet Explorer, you can write a CSS rule such as:

  1. input, button, textarea, select { font-size: 100%; }

Navigating Content

Blind users do not navigate web pages as other users do. This is not for the obvious reason (that they do not see) but because a screen reader reads site content exactly as it appears in (X)HTML markup. So you must keep this in mind when specifying CSS positioning properties.

CSS positioning allows designers to make any (X)HTML element appear (i.e. visually appear) anywhere on a Web page. For instance, absolute positioning literally removes the element from the normal document flow, so that the element's position on the screen is quite different from the position occupied by the element in the markup.

Since a screen reader will process the element in the position in which it appears in the markup, it is important to be aware if the position of the element is different when it is read visually. Failing to allow for this difference can result in confusion and loss of information for users who cannot see the visual rendering of the page. Therefore, to design accessible Web sites, we need to modify the conventional understanding of page navigation by better understanding what screen readers are used for and can do. For example, screen readers:

  • allow users to move through page elements such as words, lines, paragraphs
  • permit users to navigate at certain levels, such as heading elements (h1, h2, h3, and so on)
  • let users to skip through multi-page tables and forms
  • read (X)HTML lists pointing out the nesting levels
  • use information contained in (X)HTML attributes such as alt, summary, title
  • allow users to manage multiple bookmarks created ad hoc for a single page, etc.

Due to the way that screen readers process content, hearing page content read out loud can therefore be quite a different experience from seeing the same content laid out on the page. For example, as usability guru Jakob Nielsen wrote ten years ago: "People rarely read Web pages word by word; instead, they scan the page, picking out individual words and sentences". This type of random scanning technique is clearly impossible for a blind user.

In order to provide as many opportunities as possible for visually challenged users to process Web content on an equal footing, there are several things designers can do:

  • structure pages so that they can be read when stylesheets are disabled or not supported
  • ensure there is consistency between where content appears in the markup and where it appears visually
  • facilitate alternative ways of scanning content by:
    • understanding heading elements as microcontent, or "pearls of clarity" that explain and organize information found under headings. In this way, a blind user of a screen reader that render only the headings on a page will find it easier to build a mental map of the web page
    • splitting text into paragraphs (p elements) so that users can navigate easily among chunks of content.
    • using lists (ul, ol) to logically group informational elements, and using ordered lists (ol) when the sequence of those informational elements is important.
    • using the proper elements and attributes for tables, such as: summary, caption, headers, scope etc.

Nothing is new. Using web standards in the right way is the first, and, in my opinion, the most important contribution to accessibility.

Another serious consideration when it comes to managing the order of content in information blocks (such as menus) that are repeated from one Web page to the next. Screen readers need a way to skip such elements, in order to spare users the irritation of repetition. A simple (X)HTML link is sufficient to deal with the problem, though you will probably want to hide the link from other users. The CSS display property, with the value none, is sometimes used to hide code portions intended only for screen readers.

This example would be placed before a menu that the designer wishes to hide:

  1. <p class="hide"><a href="#main-content" title="jump to main content">Skip navigation</a></p>

We would associate this to the CSS rule .hide { display: none; } and would in theory expect the hidden information to be visible to screen readers, who would activate the link and jump to the main content.

Unfortunately, screen reader visibility is not assured, so that some screen readers are not able to read the hidden content. Bob Easton however developed a solution to the problem (called off-left), without the display property:

  1. .hide {
  2. position: absolute;
  3. left: -999px;
  4. width: 990px;
  5. }

Variations of this technique have been developed, but the common principle is to use absolute positioning to move the element out of the viewport, while continuing to make it visible to screen readers.

Hiding techniques can also provide contextual navigation assistance to blind users. For example they can be used to indicate which section of the page structure (usually marked up with div elements) is next in the document flow (e.g. main menu, main content, news etc.) and can provide links to jump from one section to another.

A final navigation tip relates to very long menus, with lots of nested levels. The first suggestion is to review how content is being managed, since a too long menu could be indicative of errors in the interface design. Blind users, for example, will find it challenging to remember a menu with a large number of items and numerous nesting levels. It is preferable therefore to make menus as short as possible and ensure they have a meaningful structure. Also, group menu items using headings and provide a way to skip from one heading to the next, instead of forcing users of screen readers to listen to every item and sub-item in the menu, before they reach the information they are looking for.


Separating structured content from presentation is a good first step towards making Web sites accessible. Once content is separated from formatting, applying CSS formatting correctly is the next step. Using external CSS, specifying scalable units for font sizes and interlinear space and adjusting space around interactive elements like form fields and hyperlinks can make your Web site more usable to everyone.


Marco Bertoni is an Italian Accessibility Specialist and IT consultant. He is also a W3C WCAG Working Group member for the International Webmasters Association.