Typography and Accessibility

Typography has one plain duty before it and that is to convey information in writing. No argument or consideration can absolve typography from this duty. A printed work which cannot be read becomes a product without purpose.

Emil Ruder, Typography, A Manual of Design.

Accessibility standards demand that text is resizable by the user on
all browsers.

The challenge then for the designer is to meet the criteria of typography and design while creating user centered functionality i.e resizable text on demand. Is it possible to reconcile typographic criteria with accessibility requirements? Well almost. Let’s look at a solution I use frequently, though it’s not without compromise. (I do not include IE 5 in my considerations).

The first thing I do is set the body font size:

body {
font-size: 100%;
}

This sets the font-size to the browser default size which is 16px. This percentage unit is understood by all browsers. Remember we cannot use pixels for this value as both IE6 and 7 would not allow resizing.

Now the line-height. There are many approaches to this but the one that gets my vote is the unitless number. Rather than set the line-height to a unit value such as pixels or ems you can simply use a number:

body {
font-size: 100%;
line-height: 1.5;
font-family: Georgia, "Times New Roman", Times, serif;
}

So what is the difference between using a unitless value and a unit value? If we had stated a value of 1.5em, this line-height would cascade down through the entire document. No matter the text size the line-height would always be 1.5em, unless of course you explicitly stated a new line-height. With a unitless value, 1.5 translates into 1.5 x font-size. This means the leading on all text remains relative throughout the entire document. For instance if you had a font-size of 10px, the line height would be set at 1.5 x 10px. If somewhere else in the document you had a font-size of 24px the leading or line-height would be set at 1.5 x 24px. This would not be true of the em unit due to the variabilities introduced through div nesting.

It is important to understand that the unitless number has no equivalent unit value. 1.5 is not the same as 1.5em for instance. The unitless number simply acts as a multiple of the font-size. To calculate a specific starting value that corresponds to a pixel value use the following equation: For a value of 13/21 i.e 13px text size on 21px line-height (leading) = 21 ÷ 13 = 1.615. This would give us the following:

body {
font-size: 100%;
line-height: 1.615;
font-family: Georgia, "Times New Roman", Times, serif;
}

To set the remaining font-size elements I use em values:

p {
font-size: 0.8125em;
text-align: justify;
color: #333333;
word-spacing: -0.0625em;
}

I have set the p element font-size to 13px. To arrive at this as an em value you need to carry out the following calculation: (remember our default font-size is 100% or 16px) 13 ÷ 16 = 0.8125em. To work out the size of 1px it would be: 1 ÷ 16 = 0.0625em.

Lets add a blockquote element just to see the relative leading or line-height in action:

blockquote {
font-size: 0.6875em;
color: #666666;
text-align: justify;
font-style: italic;
word-spacing: -0.0625em;
}

If we put all of this together we get:

body {
font-size: 100%;
line-height: 1.5;
font-family: Georgia, "Times New Roman", Times, serif;
}
p {
font-size: 0.8125em;
text-align: justify;
color: #333333;
word-spacing: -0.0625em;
}
blockquote {
font-size: 0.6875em;
color: #666666;
text-align: justify;
font-family: Georgia, "Times New Roman", Times, serif;
font-style: italic;
word-spacing: -0.0625em;
}
#container {
width: 25em;
}

Here is the xhtml for the above:

<body>
<div id="container">
<p></p>
<blockquote></blockquote>
<p></p>
</div>
</body>
</html>

Just copy and paste into your html editor and fill the elements with text to see the example. The doctype is: XHTML 1.0 Strict.

This approach should work pefectly in :ie6/7, Firefox, Safari, Opera, SeaMonkey, Camino, iCab, Shiira, Flock, Mozilla and Netscape Navigator 9.

However

A problem arises in some browsers if you want to display code using the code element. Some browsers have a default monospace font-size of 13 pixels; Firefox and Safari instantly come to mind. Go ahead and look in your browser preferences.

If we want to set the font-size of the code element to 13px you may think this would be straightforward. 13 ÷ 16 = 0.8125em. However Firefox, Safari, Camino, Flock, iCab, SeaMonkey and Shiira all display the monospaced typeface smaller than specified. This occurs because the default font-size of the monospace typeface is smaller (typically 13px) than the default proportional typeface.

code {
font-size: 0.8125em;
}

To correct this we can set the code element to 1em which is the equivalent of 13px, the default monospace font-size:

code {
font-size: 1em;
}

There we go problem solved. Well yes until we view the mark up in Opera, which of course displays the code element at the 16px default font-size. What to do?

The most effective solution for this disparity is to to declare a font family in the code element which does not include a monospaced typeface. For example:

code {
font-size: 0.6875em;
font-family: Geneva, Arial, Helvetica, sans-serif;
}

If we collect our code we now have the following:

body {
font-size: 100%;
line-height: 1.5;
font-family: Georgia, "Times New Roman", Times, serif;
}
p {
font-size: 0.8125em;
text-align: justify;
color: #333333;
word-spacing: -0.0625em;
}
blockquote {
font-size: 0.6875em;
color: #666666;
text-align: justify;
font-family: Georgia, "Times New Roman", Times, serif;
font-style: italic;
word-spacing: -0.0625em;
}
#container {
width: 25em;
}
code {
font-size: 0.6875em;
font-family: Geneva, Arial, Helvetica, sans-serif;
}

This will now display perfectly in: IE6/7, Firefox, Safari, Opera, Camino, Shiira, iCab, Seamonkey, Flock and Netscape Navigator.