In part 2 of my introduction to accessible web text, I explore the issues surrounding text size; explain what all the fuss is about; and suggest some useful approaches you can adopt to ensure the text on your web pages will be readable to your visitors.
Did you miss part 1? Read it here: http://www.devwebpro.com/articles/0214a.html.
‘The bigger the better. You can use any typeface on your screen if you use it large enough.’ writes Daniel Will-Harris, in The best faces for the screen. ’14-point fonts were found to be more legible, promote faster reading, and were preferred to the 12-point fonts.’, concludes Michael Bernard, Corrina Liao, & Melissa Mills in their research aimed at determining the best online font for older adults.
The above comments indicate that size is a significant factor when it comes to the ‘readability’ of text on the web. Indeed in a related piece of research, So, What Size and Type of Font Should I Use on My Website? Michael Bernard & Melissa Mills conclude that using a larger font has a positive effect on reading speed.
So, is it your duty as a designer, concerned with usability and accessibility, to ‘hard-wire-in’ text that is bigger than the default? Is it ‘common sense’ to assert that most visually impaired people prefer to bump-up the size of the text on their screens – so you might as well give them big text to start with? And, if, as we can see from the research mentioned above, big text will mean visitors to our sites with ‘normal’ vision will be able to read the content quicker – does that just add more fuel to the argument? Surely it cannot be that simple? Consider the following quote from The Royal National Institute for the Blind (RNIB) Web site:
“Some people prefer large text, while others can only read smaller text. Most people need a highly contrasting colour scheme, while others can only read yellow text on a black background. To cater for everyone, Web sites should be flexible in design, enabling the individual to adjust the text and colour settings to suit their needs.” (RNIB http://www.rnib.org.uk/wedo/research/hints.htm)
Hmm, the RNIB don’t seem to agree with our earlier hypothesis; despite the best of intentions – setting big text may actually exclude some people. It turns out that there are people who would find small text more accessible. Small text is not good, big text is not good; seems like we are running out of options. What should we be doing if we want to ensure that the text on our pages is accessible to the widest possible audience?
Well there is an answer; the RNIB ‘hit the nail on the head’ when they say that designing for flexibility is the key. It is not about creating big text, or small text, it’s about creating ‘any size’ text’, i.e. its about ensuring that the user can set the text to whatever size they need. In other words accessible web design in relation to text is about getting out of the way of the user’s ability to set their own browser preferences.
How do we get out of the way of the user?
There are two approaches you can take to putting the user in control of text sizes:
- Don’t attempt to set the size of your text at all.
- Or, set the size of text in your web pages using a relative unit of measurement.
By choosing the first option, i.e. abandoning any attempt to control the size of text on the pages you design, you are also removing any barriers to access – at least those related to text size – you might inadvertently put in the way of your visitors. However it also means that if your pages may not look as nice as you would like; as they will adopt the users browser preferences and the ‘default’ HTML style sheet, with, for example, headings that look too big for the surrounding text.
With the use of relative units, you get the best of both worlds; you give the user control of relative text size, and you get to set text sizes that won’t offend your aesthetic sensibilities. With this approach, when a user changes the text size in their browser, all of the text on the page gets bigger or smaller, but the relative sizes of the text structures remain the same. For example, if you think of the main paragraph text as being 100% or the browser default size, a top level heading may be 130%, a sub-heading 120%, text for navigation 95% and so on. (Please note that: these are not recommendations, just examples.)
By using relative units to set the size of text in your Web pages you are recognising that you can’t predict the needs of the end user, or the type of output device used. If the visitor your website wants, or needs the text to be big – they should be able to make it big, just by changing the preferences in their browser. Below are some example of relative units you could use to give your users that ability:
- em units
- percentages
- relative keywords such as smaller or bigger
I will look at how these relative units work in practice shortly, but, first there are a couple of important issues that I feel need to be addressed before we proceed to that discussion.
First there is the argument put forward by Joe Clark, that text size is not a particularly important issue for accessible web designers to concern themselves with, and as long as the text is not set so small it’s unreadable, it doesn’t matter what unit of measurement you use.
Secondly, it is important that we explore the case against using absolute units (e.g. points) for setting the size of text on web pages – as it is one of the most common accessibility problems that I come accross when auditing pages for accessibility.
Are you sure the unit of measurement used is that important?
Joe Clark in his book Building Accessible Websites, argues that web designers should not get overly concerned with the issue of whether text is resizable on the pages they design. His argument stems from his definition of ‘visually-impaired people’, as only those who need to use assistive technology on their computers to access the web. Having defined visually impaired people thus, he considers that the units a designer uses to set text on a web page ‘are essentially irrelevant to the actual visually-impaired people’ (page 223), because “. Accessibility is handled exclusively by the visitor’s adaptive technology’.
In other words, it doesn’t matter what unit of measurement you use, because visually-impaired users will use whatever bit of technology they already have installed on their computer, to magnify, read out, or convert to braille the text on the screen. The only people, who will be affected by the choice of unit, therefore, will be ‘normal-vision people who find the task of reading that specific page difficult.'(223). And these people should not be our concern because they are not visually impaired people – and therefore outwith the remit of accessible web design.
The argument has an attractive logic to it, however, I see some problems with this approach:
- It assumes that accessible web design is only about making pages accessible to people with physical or cognitive impairments – and this is not a definition that I agree with. Although we want to design pages that will be flexible enough to be used by people with many different impairments – defining accessible web design only in those terms does not help us address the wider issues of site management, content re-use and making sure our pages will work on the widest range of web-enabled devices. I would group assistive technologies in with all the other bits of client technology used to access the web – and I want to have web pages that work on them all.
In What is an accessible website?, I have discussed the implications for web designers and website managers, of defining accessible web design in particular ways – and suggest a definition that leads to the development of some practical guidelines.
As someone with good eyesight I come across many websites where I need to increase the size of the text to read the page comfortably. An approach that assumes that as a user, if I want to make the text bigger I will be using screen magnfication software to do it, seems to a unnecessarily restrictive in the access problems that it seeks to address.
- It doesn’t take into account the well worn argument, that it is the barrier to access that makes a person disabled, not their particular impairment. For example, I’m disabled by the fact that the text on the screen is too small for me to read and I can’t change it, not by the fact that my eyesight is not as good as it once was. Remove the barrier, i.e. allow me to resize the text and, in this particular situation, I’m no longer disabled – even though my eyesight is the same as it was when I couldn’t read the text.
The issue that needs to be addressed here is whether or not it is easy for me to resize the text – and that is related the choice of unit used to set text sizes on the page.
- If true, the points Joe Clark makes, undermine my argument that we should use relative rather than absolute units when setting text size in our pages; legitimating the use of, for example, points and pixels for setting text sizes on web pages. The case against using points is fairly straighforward and we will explore the arguments shortly. The case against using pixels is less clear cut, as pixels can be defined both as a relative or absolute unit depending on the capability of the device and web browser being used to view the page.
I don’t recommend using pixels to set the size of text on web pages, because for many users pixels effectively ‘acts like’ an absolute unit – i.e. many users will not be able to resize the text easily.
Although, I disagree with Joe Clark’s approach on this point, I agree largely with his general approach to accessible web design; and I would recommend Building Accessible Websites to you.
The other issue that we need to address – and one that can be killed off with less resistance – is that you should use absolute units of measurements to set the size of text on your page. This practice seems to stem from the misguided idea that it is the only way a designer can take complete control over how their webpages will look.
Why can’t I use points to set text size?
A major accessibility problem related to using absolute text sizes came to light when web designers started using Cascading Style Sheets to format the text on their web pages.
The use of style sheets brought with it a new phenomenon; websites with unreadably small text, which can’t be resized using normal browser text size preferences. This is a direct result of designers using absolute units such as points to set the text size on their pages – and being unaware that their text may be unreadable on the screens of some users.
In short:
- Using absolute sizes makes it difficult or impossible for many visitors to change the size of the fonts to suit their own preferences
- Depending on the hardware platform they are using to view the page, the text may be so small it is unreadable.
Why using points to set sizes on a computer screen is bad
The following explanation is only for ‘web text fetishist’ – or those people who aren’t happy with anything less than a full and detailed analysis of what I call ‘the tiny text’ problem. It is a problem that most Apple Mac users in particular will be aware of.
Below is an example of how 9pt, 8pt, 7pt and 6pt text will look on a PC with a resolution of 96dpi (dots per inch).
The above screenshot shows that it is only really when you get to 6pt text that the quality of the text drops below the threshold of readability. However, the same text sizes on a Mac with the default resolution of 72dpi looks a little different, as illustrated in the screen-shot below.
The screenshot illustrates that there are clearly readability problems on the Mac with text set to anything below 9 point. The most common example of this problem can be found on Web pages that have been designed on a PC but are unreadable when viewed on a Mac. Let’s have a brief look at why this is the case.
Most importantly, it takes at least nine pixels to form normal text with upper and lower case characacters (There are fonts that can be rendered clearly with fewer pixels but they are not generally available on most Web users’ computers). Text set to 8pt on a Mac is rendered using only 8 pixels and that is too small to be legible – no matter how good your vision is.
The details:
- The default resolution of a Mac is 72dpi.
- 1 point is an absolute unit of measurement; it is 1/72 of an inch.
- On a Mac therefore, 1 pixel maps to 1 point on a Mac monitor; so for every inch on the Mac monitor there are 72 pixels.
- At least 9 pixels are needed to render a normal font because of their ascenders and descenders.
- Setting type to 8pt means that only 8 pixels will be used to render the type.
- 8 pixels is not enough to render type clearly on a monitor set to 72dpi (see point 4 above).
The result, as we have seen in our earlier example, is that any text set using absolute units smaller than 9point (or 9pixels) will be unreadable on a Mac set to the default resolution.
Should you be concerned about making your Web page unreadable to Mac users? You should of course because there are 25 million people in the world who use Macs, but what you should be more concerned with is the principle that your pages should work on all Web enabled devices, irrespective of the screen resolution. Many ‘alternative’ browsing devices, such as Personl Digital Assistants (PDAs), will ignore your style sheet recommendations – so it is not guaranteed that the text size will be a problem – but I don’t consider that a strong enough counter argument to justify the use of points as a measurement for use on computer screens.
A bigger inch for your money: why is 8pt type readable on a PC?
A PC has a default resolution of 96dpi; dpi stands for ‘dots per inch’ – so ‘right off the bat’ you have more pixels per inch to render your text. But on a PC screen, this apparent fact is a bit of a red herring; there is no match up between a physical off-line inch and an on-screen inch. Measurements in the world of the PC screen world have been untethered from measurement in the physical word – a PC inch is bigger than both a real world inch and a Mac inch;1.3 times bigger.
What it boils down to is that everything on a PC screen is about 1.3 times bigger than it is on the Mac, and this translates to a difference of 2 to 3 points between font sizes on PCs and font sizes on Mac. The irony is, that there is nothing absolute about absolute units on the Web; text that looks fine on one computer can be unreadable on another, even for people with perfect vision.
Fixing text that is too small to be readable
Internet Explorer 5 for the Mac and Netscape 6 gets around the size inconsistencies by adding a default resolution preference that is set to 96dpi, to mimic that of the PC. Additionally, screen magnification options are being added to the latest browser to get around problems caused by using absolute units in pages. These changes are a great idea – but only solve the problem for users who have the latest browser; even if all new browsers adopt these techniques – there will still be a fair proportion of users with old web browsers – the principle of using relative units rather than absolute units is still a good one.
Apart from the facilities which may, or may not be built into some newer browsers, turning off style sheets is the only way that text can be made readable for many users who are faced with pages that have used small absolute units to set text size. I suspect that most people will not know that style sheets are the problem, or that they can be turned off. They are more likely just to leave the site and look for another source for the information they are after.
Alternative absolute units of measurement
Other absolute units that I have not mentioned – but which are equally unsuitable for on-screen display, include picas(pc), inches(in), centimeters(cm) and millimeters. I am not going to spend time attempting to make a case against each of these units in turn; suffice to say that I don’t recommend them, and unless you have absolute knowledge of all clients machines that your web pages will appear on – they are likely to lead to unpredictable results.
So why does CSS give me the ability to use points if they are no good for the web?
Points are provided as part of the CSS specification so that you can set up an alternative stylesheet for those who would like to print out your page rather than read it on screen. In the context of physical print, using points to set text sizes makes sense and is the correct unit of measurement to use. We know that an A4 (UK) document measures 8.27inches by 11.69inches (8-1/2″ x 11″ in United States, Canada and Mexico) – therefore it makes sense to set margins, indents, font sizes and so on in inches or points (a point being 1/72 of an inch) or some other absolute unit, with predictable results.
Controlling text size with relative units
Ok, if you are ready to adopt the strategy of using relative rather than absolute units to set the size of text on your web pages, let’s look at the techniques that are at our disposal. Below are the main techniques you can use to set the size of the text on the Web,
- Use Cascading Style Sheets (CSS).
- Use the FONT tag.
- Use the HTML tags and
Of the above the most standards compliant choice would be to use Cascading Style Sheets.
Using Cascading Style Sheets
Using style sheets to set the text size is my preferred approach as it has advantages over the other methods; document structure can be divorced from presentation, page size can be reduced, leading to pages that are faster to download (particularly by avoiding having to use hundreds of FONT tags) – and redesigns at least in theory should be quicker. With CSS text size can be set using the font-size property and one of the following relative units of measurement:
- Em, en or ex units
- Percentages
- Relative keywords
- x-height
- Absolute keywords
- Pixels (see below for my discussion of pixels and why I don’t recommend their use)
For the body selector we could write the following:
body
{
font-size: 1em;
}
In the above example I have used a unit of measurement which will be familiar to traditional typographers, the em unit.I will use the em unit to outline the main techniques for using relative units and to alert you to potential problems. On the Web 1em unit is equivalent to 100% of the text size set by the parent element. (Notice I said ‘set by the parent element’ and not ‘set by the browser default’. This is an important idea to remember – and we will look at how this works shortly.)
Even when using relative units, there are still quite a few pitfalls to avoid if you are to ensure that your pages are accessible to everyone. The first possible problem is related to inheritance works in CSS. Knowledge of the ‘hierarchical’ nature of HTML and how CSS uses that hierarchy will be your first defence against ending up with inaccessible pages. A few examples should make the reasons apparent.
Em units in practice
Example 1
body
{
font-size: 1em;
}
If the default size in the browser is set to 16pt, and text-size in the body selector is 1em, assuming no other element uses the font-size value, the size of the bodytext in the browser will be 16pts, i.e. %100 of the browser default.
Example 2
body
{
font-size: .9em;
}
Using the same browser defaults, if the body element has a font size set to .9em, paragraph text on the page will be 90% of 16pts.
Example 3
body
{
font-size: .9em;
}
p
{
font-size: .9em;
}
Again assuming the same browser defaults, the text-size in the body selector has been set to .9em, and the p selector has also be set to .9em. What will be the size of paragraph text? 90% of the browser default (i.e. 90% of 16pt) or 90% of the text size set in the body element?
The answer is 90% of the size set in the body element – 90% of 90% of 16pts. Because a paragraph element is the child of the body element – the value set in the body selector is inherited before the text size instructions in the p element are applied.
Ok, let’s look at an example of how this works in practice, and the possible accessibility pitfalls of ignoring the hierarchical nature of HTML.
Understanding inheritance
Here is an example that illustrates inheritance – the way a child element inherits property values from its parent element.
First the the inline styles:
<div style="font-size: 1em;">
<p>This paragraph is set within a div with font-size set to 1em, so it should be the same size as the browser default.</p>
</div>
<div style="font-size: .9em;">
<p>This text is contained within a div element that has the font-size set to .9em.</p>
<p style="font-size: .9em;">This paragraph is contained with a dive element that has the font-size set to .9em. It is smaller because the font-size of the paragraph tag is also set to .9em. </p>
</div>
And how those styles are interpreted by a browser that understands style sheets:
This paragraph is set within a div with font-size set to 1em, so it should be the same size as the browser default.
This text is contained within a div element that has the font-size set to .9em.
This paragraph is contained with a div element that has the font-size set to .9em. It is smaller because the font-size of the paragraph tag is also set to .9em.
If your browser does not understand style sheets, here is the CSS inheritance example as a graphic.
The above example reminds us of the importance of understanding inheritance when applying property values to style sheets. This in turn reminds us that well coded Web pages are not just collections of HTML tags, but documents that have been marked up according to a predetermined set of rules designed to expose their logical structures.
A quick look at alternative relative units
Relative keywords:
Relative sizing of text can also be achieved by using the keywords larger and smaller. If you can put up with the feeling that you never quite know how much smaller or bigger the resulting text will be, this seems like a relatively safe option to use. However, as reports on the website Oo Kingdom by Charlie, Wendi and Joe Petitt in Janesville indicate: ‘Weirdness may result when text is resized in IE’ and that Netscape 4 (Mac) and IE 3 will ignore these relative keywords (probably no bad thing).
Smaller – means one size smaller than the parent element, so in the example above the body text is set to 1em – 100% of the default font size. If the default font size in the web browser is 12pt, paragraphs are set one step smaller, perhaps 10pt . The exact size of ‘one step’ is difficult to say because it varies with the browser. here is an example of using the smaller keyword:
BODY
{
font-size: 1em;
}
P
{
font-size: smaller;
}
Eric A. Meyer author of Cascading Style Sheets: The Definitive Guide by O’Reilly & Associates points to problems with using larger and smaller keywords.. These essentially are the same problems you will get when using any relative unit if you don’t take into account the the hierarchical nature of HTML – and the cascading nature of Cascading stylesheets.
Eric Mayer illustrates his point with examples of the font-size set for text within a table, e.g.
TD
{
font-size: smaller;
}
If tables are nesting, as they are on many Websites, the text will become smaller and smaller, until it is unreadable.
“If there is any nesting of tables, the text inside those tables will very quickly become illegible. Given the prevalence of table-layout pages, rules such as these must be used with the utmost caution, and you’ll need to do a lot of testing before making your design public. “
The keyword ‘Larger’ works in the same way as ‘smaller’ but makes text progressively larger. The same cautions apply when using the larger keyword; text can become so large that it takes up too much of the screen.
“If there is any nesting of tables, the text inside those tables will very quickly become illegible. Given the prevalence of table-layout pages, rules such as these must be used with the utmost caution, and you’ll need to do a lot of testing before making your design public. “
The keyword ‘Larger’ works in the same way as ‘smaller’ but makes text progressively larger. The same cautions apply when using the larger keyword; text can become so large that it takes up too much of the screen.
X-height
Another relative unit that you can consider using is x-height, which is the height of lowercase letter x. I don’t recommend the use of x-height, unless you are an expert typographer and will understand how text set with a particular x-height is likely to be interepreted by users who do not have the font you have specified installed on their machines. The use of a font other than the intended could result in difficult to read text.
It’s relative but not as we know it Jim: using absolute size keywords
Absolute size keywords are advocated by many web savvy designers as the ulitimate answer to the ‘how to set the size of text’ problem. Despite the name ‘absolute size’, keywords are actually a relative measurement; text size is calculated relative to the default font size set in the user’s browser. The idea is that they replace the sizes previously provided by the font tag – the following absolute size keywords are available for your stylesheet:
- xx-small
- x-small
- small
- medium
- large
- x-large
- xx-large
The idea of absolute size keywords is a good one, and in theory I would recommend them. Unfortunately, in use there are some serious problem; the main problem is the inconsistent support in current and past browsers.
Jeffrey Zeldman writes,
“If implemented correctly and uniformly, these seven keywords would allow designers to specify approximate sizes without running into either of the accessibility problems associated with pixels…. For that reason, the W3C recommends their use.” (Fear of stylesheets 4: http://www.alistapart.com/stories/fear4/4.html)
Great, I’m thinking, I should really start using these keywords instead of em units in my Website. But in the next paragraph I read,
“Unfortunately, absolute size keywords are unusable in current browsers, since in our estimation only IE5/Mac (and possibly Opera 4) renders them correctly.”
Inconsistent browser support is the major drawback of adopting absoluted keywords on your Web pages . If you are prepared to spend the time understanding the issues and implementing the workarounds they are certainly worth investigating. To get you started, Jeffrey Zeldman, Eric A. Meyer and Todd Fahrner discuss the issues at length. Perhaps at some later date absolute keywords will be ‘the way to go’ – but not today.
Why not use pixels?
Pixels as a units of measurement is in a kind of half-way-house between being a absolute unit and a relative unit of measurement. It is an absolute unit of measurement in the sense that if you set your text to 12px it will always be 12px, no matter what changes you make in your browser preferences. The physical size of that 12px character will however vary according to the resolution of the screen; on a low resolution screen the 12px character will look bigger than it does on a high resolution screen of the same physical dimensions. This is because, the higher the screen resolution the more pixels there are crammed into each bit of screen real estate – with the 12 pixels, used to make up a character,crammed in to a smaller physical space. In this sense, it could be argued that pixels are a relative unit of measurement – relative to the screen resolution.
So should you be using pixels to set the size of your text? ‘Give me pixels or give me death’ said Jeffrey Zeldman in his article exploring the pros and cost of specifying text sizes on the web. He advocates the use of pixels as the best solution, on the grounds that it is the most consistent performer – from a designers point of view – across the main hardware platforms and browsers. He does concede that setting text sizes in pixels will make it impossible to resize text on many current and past web browsers; specifically IE5 and below on Windows and prior to IE5 on Mac. And he also notes that on Linux, unless the end user has the font installed on their machines that is specified in the style sheet, the text may be very poorly displayed and may be illegible. But he considers these disadvantages against those of using other units, and settles upon pixels as the best of a bad bunch.
Em units he dismisses because they are ignored by Netscape 4 and because IE 3 treats em units as pixels (i.e. 2em headings will be rendered as 2 pixels high) – a star performer among CSS browser bugs.
From the point of view of accessibility, the problems associated with using pixels outweigh those encountered by using the relative em unit. Netscape, ignoring the CSS declaration, is not an accessibility problem, and as for the IE3 problem, there are workarounds related to how the style sheet is referenced from within the page. Even if we approach the options open to us from a purely Utilitarian point of view – less people will be disadvantaged if you use em units than if you used pixels, because less people are using IE3 than are using IE 4, IE 5 for Windows, and Netscape 4 on both Mac and PC.
What relative unit is best?
To all intents and purposes en and percentages work the same way as ems, but I am more comfortable using em units rather than percentages for the following reasons:
- Typographers have traditionally used em units rather than percentages to express the size of type.
- It is easier to calculate text sizes using em units than en or ex units.
- Em units and percentages are not interchangable when creating page layouts, e.g. you can’t use em units to set a margin that is equivalent to 10% of the page width.
For the above reasons, I consistently use em units to set text size, and use percentages for page layout. There are some problems with this approach; some have been demonstrated and some I mention below – but there are likely to be problems no matter what unit of measurement you decide to use. Despite the knowledge of some drawbacks, going with a relative unit and sticking to HTML standards on your page, is the best strategy for cross-platform compatibility.
Problems with the use of relative units
Cascading Style Sheets give Web designers many more options when specifying their type: now you can say exactly the size, colour, position on the page, margins, line height and style. But it is not all good news when it comes to using style sheets.
Ironically the introduction of Cascading Style Sheets makes it easy to design pages that contain inaccessible text. As demonstrated earlier, it is now possible to specify fonts that are smaller than the readable threshold on many systems – or text that is so big it is unusable. It is also possible to take away the ability of the end user to resize text according to their needs.
There are additional problems – none of which are appropriate to discuss in this article. Potential problems are likely to come from any of the following areas.
Problems can occur from several areas:
- Browser bugs: see browser bugs and workarounds, and Jeffrey Zeldman’s article outlining what he sees as the main problems with using em units (http://www.zeldman.com/daily/0502c.html#emz).
- Incorrect HTML markup: use the W3c’s HTML validation tool at http://validator.w3.org/ to validate your pages and avoid problems related to incorrect HTML.
- Incorrect CSS implementation: use the W3c’s CSS validation tool at http://jigsaw.w3.org/css-validator/ to validate your style sheets.
BIG and SMALL tags
Todd Fahrner notes that using the HTML tags BIG and SMALL gives the most consistent and robust results when setting font sizes in Web pages for version 3 browsers and above. (Beyond the FONT tag: Practical HTML text styling http://style.cleverchimp.com/font_size/livetext.html). The BIG and SMALL tags are extremely easy to implement.The following example sets the text one step larger than the default:
<big>some text</big>
Similarly, the following sets the text one step smaller:
<small>some text</small> set the text one step smaller than the default.
Visit Todd Fahrner websitefor further examples.
The only problem I have with this technique is that the tags BIG and SMALL have little meaning beyone visual presentation – and therefor it doesn’t look like a ‘forward-compatible’ solution. If we are interested in moving towards the goal of divorcing content from presntation, these tags would more usefully be replaced with attributes declared in a separate style sheet. Having said that, BIG and SMALL are perfectly legal HTML elements.
Setting the size of text with the Font tag
The font element is no longer part of the HTML 4 standard – but ironically it is harder to create unreadable small, or large text, using the font element than it is using style sheets. Even if a designer decides to set the entire contents of a page to size one , i.e. 40% smaller than the default size – the user still has the option to reset the text to a bigger size – by adjusting the text size in their browser preferences.
The font tag can be used to adjust the size of text by setting the value of the size attribute to an integer between 1 and 7; e.g.
<font size="1">
Or by setting a value as being a certain number less than or greater than the default size of 3, e.g.,
<font size="-2">
A change of 1 in the value of the size attribute represents a change in size of 20%.
Accessibility problems with using the font tag arise from their use to set text colour, and/or font choices. When text colour or font choice are set usign the font tag, it may be impossible for the user to change from their browser preferences to suit their own needs.
The main argument against using the font tag, apart from the fact that it is a deprecated elements, is that they make it harder to divorce the presentation of documents from the content – and this makes the code less portable, more costly to maintain and more expensive in terms of download times for users.
Accessibility is also affected when presentation tags are used to mimic the effects of proper markup, e.g. using font tags to make headings bold and big, rather than using the proper header tags.
Say goodbye to pixel perfect layouts, and embrace flexible design principles
Using relative units to set text size presents problems for designers who would like to produce ‘pixel-perfect’ layouts on their Web pages. Absolute control of page layouts is impossible when using relative units; the resulting page will change according to the needs of the end user and the phyisical attributes of the display device.
The size of Web pages is never predictable; different sized monitors, different screen resolutions, resized browser windows, devices with small, large or medium screens. Unpredictability is the only constant. Therefore, unless you are designing for a closed environment like an intranet and you can control screen size, resolution, and the habits and cababilities of your users, the stress free solution is to give up the idea that you can completely control how the Web page looks to your users.
A major plus-point of the web is that it is available, and works on a huge variety of client devices; that was a reason for its growth in the first place. Play to the strengths of the medium; design web pages that are flexible enough to adapt to the needs of both the client device and the end user. And apply this general principle when setting the size of the text on the pages you design.
Jim Byrne is the Director of accessible web design consultancy ‘The Making Connections Unit'(MCU) he co-founded in 1996. He is the author of ‘Making Websites Accessible’ published by SAIF in 2003. The MCU can help web publishers attract more visitors, reduce support costs, and avoid accessibility related legal problems. Accessible web design training is provided in partnership with ScotConnect (http://www.scotconnect.com). Web: http://www.mcu.org.uk
