Accessible Web Typography An introduction for web designers
Jim Byrne, 2003
Welcome and thanks Publisher and copyright information About the author
Section One: Making good font choices
Increase accessibility by making informed font choices Why would you want to control the text on a Web page? Issues that can make it difficult to control how your text looks to your site visitors. The difference between screen fonts and printer fonts Readable on-screen fonts web fonts in practice Why not use images instead? Is it a good idea to use embedded fonts? What is the best font to use for accessibility? Summary of section one
Section Two: Text size
Accessible web text - sizing up the issues. How do we get out of the way of the user? Are you sure the unit of measurement used is that important? Why can't I use points to set text size? Controlling text size with relative units Using Cascading Style Sheets Em units in practice Increase accessibility and readability by making informed font choices 10/28/03 8:49 PM
Alternative relative units - relative keywords Should you use X-height? Using absolute size keywords Why not use pixels? What relative unit is best? Problems with the use of relative units What about using BIG and SMALL tags? Setting the size of text with the Font tag Say goodbye to pixel perfect layouts, and embrace flexible design principles
Section Three: Usability
Usability and readability issues
Useful links Links by chapter for printing
file:///Macintosh%20HD/Documents/Accessible%20Web%20Typography/PDF%20source/index.html Page 2 of 2 Welcome and thanks
Thanks for purchasing 'Accessible Web Typography - an introduction for web designers'. This book contains all the important 'stuff' I ever wanted to know about creating accessible text on my own web pages; and now that I have figured it out myself, I am happy to pass it on to you.
Don't hesitate to get in touch with your comments, or suggestion about how I could improve future editions of this book. Email me at, [email protected]. I look forward to hearing from you.
I'd also like to take this opportunity to thank my wife Pat for encouraging me to publish this book, and for reading it over and correcting all my grammer and spelling mistakes. :-) Pat would not forgive me if I did not tell you about the great local community website all about the West End of Glasgow which she spends much of her time updating. Please pay a visit to http://www.glasgowwestend.co.uk, and tell Pat I sent you.
I would like to thank Gez Lemon, and Dr Andrew Arch for their valuable feeback on the contents of this eBook. Gez runs the web developers information website Juicy Studio, and Andrew is the Manager of Online Accessibility Consulting, National Information & Library Service, and is a member of W3C Education & Outreach Working Group.
All the best, Jim Accessible Web Typography An introduction for web designers
Published by ScotConnect
Copyright © 2003 by ScotConnect
ScotConnect 2/L 23 Glasgow Street Hillhead Glasgow G12 8JW web: http://www.scotconnect.com email: [email protected]
ISBN: 0-9545375-1-3
Published by ScotConnect - the web accessibility training company. About the author
Jim Byrne has been programming computers and involved in the technical issues of computing since the late 1970s. He has been promoting the benefits of accessible web practices since 1996, when he founded the accessible web design consultancy 'The Making Connections Unit' with his colleague David Donald.
He has written and spoken widely on the subject of accessible Web design, including on national radio and television. He also develops and delivers accessible web design training programmes for the private, public, and voluntary sector.
Jim is a former Disability Information Officer and Trainer with The Wellbeing Initiative, and Lecturer at Glasgow Caledonian University.
In 2001 he was identified as one of Scotland's 'movers and shakers in e-commerce in Scotland' for his work in the area of Web accesssibility (NB Magazine, June, 2001).
Other publications
Standards for Disability Information and Advice Provision in Scotland: Making Websites Accessible (November 2002) published by The Scottish Accessible Information Forum. ISBN 0-9543408-0-9
Towards a Communications and Information Technology Intensive Learning Environment: Supplementing a Political Economy Module: (2000) David Donald, Alan Hutton and Jim Byrne in Innovative Approaches to Learning and Teaching in Economics and Business Higher Education. Stafford University Press ISBN 1 897898 82 7
Extracurricular activities
Photography (see Jim's West End Photo Diary at http:// www.glasgowwestend.co.uk/gallery/index.html). Writing songs and playing guitar. Assists his wife Pat run Pat's Guide to the West End of Glasgow; doing all the technical duties, including maintenance of a Linux Webserver.
Author of a number of Web applications:
QuicknEasyImage Pro - for making it easy to add photographs and other images to web pages in an accessible way. CommentIt - for adding comments to the bottom of web pages (now maintained by David Bayly as a plugin for Manila). FlathuntingPHP - for adding a flathunting service to a community website. BusinessListPHP - for adding a business listing service to a community website. PropertyListPHP - for adding a property sales service to a community website. EditIt - for simple forms based editing of web pages (for use with Frontier content management). AutoNews - for creating a simple news page (for use with Frontier content management). Accessible Web Typography Section One: Increase accessibility by making good font choices
Text is your flexible friend; it can be transformed into audio or braille; used to describe non-text elements; and be presented visually in an infinite number of sizes.
In the world of accessible design 'goodies' and 'baddies', text is a 'goodie'.
Unfortunately, text also has the potential to be very bad; bad text is:
unable to be changed to suit the preferences of the end user difficult to read due to font incompatibilites. so small it is unreadable inaccessible due to inadequate contrast between text and background or due to 'busy' backgrounds presented in inpenetrable blocks that make it difficult to read presented as an image - that can't be resized or read by people using screen readers. difficult to read because it is moving or blinking.
This eBook provides simple strategies to ensure that visitors to the web pages you create, will not be taking up your valuable time by complaining that they couldn't access the content on your web pages.
In sections two and three, we will explore the issues related to 'text size' and usability. In this first section, the emphasis will be on understanding how to choose fonts that are accessible, usable and appopriate to the aims of your site.
The two roads to accessible web text
As a Web designer committed to accessible Web design there are - in general - two approaches. You can take the easy route, summed up in the following phrase:
It is better not to set a font size or type at all - but instead leave this decision to the user.
Or the more difficult route - which involves learning about the vagaries of online typography and taking an active role in designing the text on your pages. For many designers control of web text is essential for reasons of branding, house style, subject appropriateness, or just plain old ego. Control of Web text can also realise usability gains; Cascading Style Sheets (CSS) provide limited control over margins, line width, line height, colour and font choice and size - all of which can help layout text in a way that makes it easier to read. And a Web page that is easier to read is a more accessible Web page.
If you are happy to follow the first route (i.e. do nothing), you can stop reading now. Assuming readability is not compromised by inaccessible colour schemes, you already know enough to create accessible text for the Web.
Visitors to your Website will be presented with the default font and font size they have set in their Web browser preferences - and they will be able to change these properties to suit their own needs. (There is one problem with this particular solution and that is that the majority of people probably do not know that they can change the default font in their browser preferences, or, indeed, how to do it.)
If you decide that you need to, or want to, have some control over the size, colour, layout and typeface of the text on your Web pages, then you also need to 'buy into' the idea that you will never be able to completely control how a user will see your text.
HTML was never designed to provide sophisticated typographic or layout capabilities. On the contrary its main job was to enforce the logical structure of documents; leaving the presentation of the page up to the individual capabilities of the computers and devices that would display the page.
Although you can, with the help of CSS or the deprecated FONT tag, provide your own set of 'suggestions' about how a Web page should look - and we will examine what those are later in this book - users can override practically all of your choices by setting their own browser preferences. And on an accessible Website, that is how it should be.
"you can't always get what you want, but if you try, sometimes you get what you need", Mick Jagger.
file:///Macintosh%20HD/Documents/Accessible%20Web%20Typography/PDF%20source/intro.html Page 2 of 2 Accessible Web Typography Why would you want to control the text on a Web page?
The typeface used on a Web page, or indeed any document, affects the way we feel about the content. Whereby one page looks formal and serious, another informal and friendly, yet another may be modern and cool.
Clearly the typography of a page designed to support a childrens TV program (http:// www.bbc.co.uk/cbbc/) should be different for one designed for a politics course in a university (http://www.ksg.harvard.edu/prg/). Similarly the text on the Financial Times Website (http://news.ft.com/home/uk/), if it is doing its job right, should be be different from that of the The Tate Modern (http://www.tate.org.uk/modern/ default.htm).
So typography, whether on the Web or otherwise has a job to do. This could be to support and re-enforce the message being presented by the content, or tell you something about the writer, or publication, that the the page is part of.
The font chosen should give the reader clues about the nature of an article or content they are about to read. For example, the text from an old manuscript might usefully be presented in a cursive style font that reflects its ancient content.
Having said that, it turns out that it is not that easy to find many examples on the Web that illustrate the points I make above. It can never be guaranteed that the font-face specified by the designer of a Web page will be the same as that seen by the reader.
A short introduction to the world of typography
Using fonts on the Web is problematic; there are many hidden dangers for the would-be Web typographer. However, before embarking on a discussion of potential problems, for those new to the world of typography, it would be useful to quickly summarise the following 'general knowledge' about fonts and design. If none of this is news to you, please skip the following section.
Serif versus Sans serif
Traditionally fonts have been categorised as either 'serif' or 'sans serif'. Serif fonts are characterised by the small decorative embellishements, called serifs, that are added to each character - Times is a good example:
Times
Sans serif (without serifs) fonts do not have these embellishments. An example of a sans serif font is
Helvetica The commonly held belief is that sans serif fonts are more difficult to read than serif fonts. This is based on the idea that the serifs help to lead the eye through the text, and the notion that our brains are quicker to recognise their more distinctive shapes.
For this reason most traditional documents use serif fonts when large chunks of text need to be presented, such as the main body of a story in a newspaper.
The cleaner, bolder, less busy shapes of sans serif fonts are used most often for 'display' type such as headlines and advertising slogans. You will recognise the implementation of these basic 'rules' in most newspapers and magazines.
What do serif and sans serif mean in the context of design
Sans serif fonts are arguably more 'modern' looking, more 'cool'. Although many consider them to be mechanical and lifeless; lacking the subtlety, character and warmth of serif fonts. When the first sans serif fonts were introduced some people had a strong negative reaction and labelled them 'grotesque' (see http://www.webreference.com/ dlab/9802/sansserif.html).
Serif fonts look more 'traditional', characterful, friendlier and more familiar, and as mentioned earlier, easier to read in dense passages. (see history of sans serif fonts: http://www.webreference.com/dlab/9802/sansserif.html)
These are very general observations - though hardly adequate for any meaningful introduction to the subject - they provide a basis for understanding how different styles of fonts are commonly used when designing online or off-line documents. As Dmitry Kirsanov notes in his article 'Matching Fonts' :
.. your single concern should be about a good match between the style, semantics, and intended impact of your text and corresponding properties of the typeface it uses. You can't set Shakespeare plays in a sans serif font (even of the "humanist" variety), and fragile Modern serifs are not appropriate for a pushy advertisement message. " http:// www.webreference.com/dlab/9802/
A note on the readability of serif fonts on the web
It should be noted that the general rule that serif fonts are easier to read cannot be relied upon when designing for the Web. The usability expert Jakob Neilson, notes that, particularly for small sizes, sans-serif fonts are more readable on low resolution screens.
This appears to be confirmed by Ralph F. Wilson who asked the readers of his HTML based emails what fonts they found to be the most readable. Sans-serif fonts were favoured over serif fonts, and Arial was preferred to Verdana for larger font sizes - see the full details at http://www.wilsonweb.com/wmt6/html-email-fonts.htm. Accessible Web Typography Issues that can make it difficult for you to control how your text looks to the user
Creating accessible, usable type for the Web, is not a straight-forward business. It is useful to be aware of the following issues:
The same fonts are not available on all operating systems. Some typefaces are designed to look good on screen, some designed to look good on paper. Those designed to look good on paper (particularly serif fonts) tend to look 'messy' on screen. Text size is dependent on screen resolution and operating system being used. The type of browser used can affect how the text looks. Users have their computers set up with different defaults and can change the preferences on their browsers.
Fonts and operating systems
In the 'designers' ideal world he/she would pick the font-face they think is most appropriate for the job in hand, specify it in their Cascading Style Sheet and publish their fabulous looking Web page for the world to gawp at. The user would see the fonts on the page exactly as specified and gain additional contextual information from their well chosen style.
However, the web is not an environment where such an 'ideal' is possible. For example, not all operating systems or even computers with the same operating systems, have the same set of fonts installed.
As a designer, unless you pick a font that is likely to be available on the majority of users' systems, the browser will display the page using the default font, usually Times or Times New Roman. Times in particular, is not easy to read on a computer monitor, so you could end up, despite thoughtful consideration of what is best for your page, with text that is difficult for users to read.
There are a limited number of fonts that you can depend on to be installed on most systems, designers are, therefore, forced to compromise; picking fonts that most closely meet the needs of their page design, while choosing from the relatively small list of fonts that are likely to be available.
The following table shows the most common fonts on PC, Mac and Unix systems. Win 95: Mac Unix Arial* Helvetica Helvetica Times New Roman* Times Times Courier New* Courier Courier Verdana* Verdana* Georgia* Georgia* Trebuchet* Trebuchet* Comic Sans MS* Comic Sans MS* MS Sans Serif Geneva MS Serif New York Chicago Palatino Charcoal (1999 onwards) Times New Roman* Arial*
* Fonts come with Internet Explorer on both Windows PC and Mac.
Update: Generic MacOS fonts include: Times, Times New Roman, Arial, Helvetica, Courier New and Courier.
On the excellent Rob Collins's web site you will find a more comprehensive list of Mac, PC and Internet Explorer fonts (http://www.angelfire.com/al4/ rcollins/style/fonts.html). A useful list of Linux/Unix fonts, and lots more font related information can be found at Browser News: http://www.upsdell.com/BrowserNews/ res_fonts.htm#a04d
Many fonts don't look good on computer screens
Although the above list gives you an indication of the fonts that are likely to be available on different hardware platforms - not all are equally good choices for using on the web. Some fonts are optimised for screen display and others optimised for print. Accessible Web Typography The difference between screen fonts and printer fonts
Fonts designed for print, are drawn (i.e. onto paper by a printer) on-the-fly from geometric descriptions of their outlines, and are thus scalable to any size. The first generation of fonts designed in this way didn't look good on low resolution monitors because there were not enough pixels available to display the subtlety and style inherent within the font descriptions.
An Apple Mac has a default resolution of 72dpi (dots per inch), and a Windows PC a default resolution of 96dpi, whereas printed material is likely to have a resolution of 1200dpi and upwards.
In an effort to try to overcome the problem, pioneering web font designers such as Chuck Bigelow (who designed the early screen font Pellucida as a screen equivalent of Lucida), developed a number of 'bitmapped' screen fonts.
Bitmapped fonts were designed in harmony with the square pixel grid of low resolution screens; in a bitmapped font, every character is represented by a particular arrangement of pixels on the screen and has been carefully tweaked by a designer for optimal readability and clearness.
Apple were quick to take advantage of bitmapped fonts to increase the readability of on-screen text. Looking back at our earlier list of included fonts for the Mac, you can tell which fonts are the bitmap screen fonts because they mostly have city names, e.g. Geneva (for Helvetica), New York (for Times) , Monaco (for Courier).
On MS Window bitmapped fonts can be recognised by their distinctive red and white icons found in the Windows/Fonts folder. Bitmapped fonts in MS Windows tend to be used for file and folder icon and windows labels.
However, one problem with bitmap fonts was that they where available in a limited number of sizes. If you chose a size that was not installed, 'you would get an attack of the on screen jaggies', i.e. the characters would look very roughtly drawn, and be difficult to read.
This was because the computer would try to create the characters based on what it knew about the shape of the font, or based on the outline printer version installed on a connected printer. Unfortunatly, most of the time it did not make a good job of drawing the characters on the screen.
In the past, scalable fonts didn't look good on screen, but similarly, bitmapped fonts didn't look good when printed (a 72dpi bitmap font would prints out at 72dpi, even on a high resolution printer). Commonly - your nerdy typographically aware computer user - would write in a screen font, but convert to a printer font before printing.
It is beyond the scope of this chapter to give you the full 'then and now' story of how things have changed (a useful summary can be found at: http:// www.dotprint.com/graphics/graphi26.htm), but it is safe to say that these days very few people designing for the Web - would know the difference between a screen font, a printer font, and a hole in the wall.
Many of the fonts commonly used on the Web today actually look good on the screen, come in every size, and don't look too shabby when printed. That is because the trend is now towards designing outline fonts (i.e. geometrically defined fonts) that have been designed with the constraints of low resolution monitors in mind.
Microsoft helped improve the readability of text on the web when they commissioned Matthew Carter to design fonts that worked well specifically on low resolution screens - and thus worked well on the web.
Matthew Carter, designer of the much used Verdana and Georgia, has this to say about screen fonts:
"In graphic design circles, people think of screen fonts as preview mode -- it's only when the toner hits the wood-pulp that we usually judge a typeface".
"But that's an increasingly short-sighted view of life. Larger numbers of computer users spend their entire time in front of a screen and never (or seldom) print anything. So it became obvious to us that this was a reversal of priorities -- we should not approach this as doing printer fonts adapted for the screen, we should design them as screen fonts from the outset. The printer fonts are secondary in this case." Matthew Carter, Designer of Verdana and Georgia. http://www.webreview.com/1997/11_07/webauthors/ 11_07_97_10.shtml Accessible Web Typography Readable on-screen fonts
Adobe with the introduction of PostScript Type 1 fonts and Apple with their Truetype technology led the way in readable outline fonts for screen use. Microsoft has continued the trend with their ESQ (Enhanced Screen Quality) Truetype fonts. Microsoft have to be thanked for making freely available an excellent set of scalable, screen display fonts that have become the staple of Web typography:
Verdana Trebuchet MS Georgia Arial Times New Roman Courier New
Verdana, and Georgia were conceived from the outset as outline fonts optimised for screen use. Designed by Mathew Carter and 'hinted' by Tom Rickner they are both readable and clear even at relatively small sizes.
Hinting means the manual modification of a font to make it look as good as possible on low resolution monitors, "A well-hinted font offers the quality only provided in the past by hand-tuned bitmaps - but with all the speed and reduced memory requirements which characterize outline font formats." (Introduction to hinting: http://www.microsoft.com/typography/hinting/hinting.htm).
A selection of 'safe to use' fonts
Both Arial and Times New Roman, have been especially hinted to work well on computer screens and as a result they are now considered by many to be good choices for Web use. Times New Roman is certainly a good compromise serif font for Web documents that are likely to printed to be read off-line, although, the design of Georgia makes it a better looking more readable serif font for documents designed exclusively for screen display. Arial is probably the most popular - and some would say overused - font to be found on Web pages, and is very clear unless used in small sizes. Verdana is a good alternative to Arial, and is more readable at small sizes on low resolution screens.
It is important to remember that even the fonts listed above will only be seen by the end user if they have them installed on their computers.
The above mentioned Microsoft fonts are built-in to Windows 95 (and PC operating systems later than Windows 95), many of them are bundled with Microsoft Word (the world's most popular word processor with over 90% market share on both PC and Mac ). They have also been bundled with Microsoft's Internet Explorer since version 3.
When considering what font to use the safest choices in terms of readability and availability on other platforms can be made from the fonts that come with Internet Explorer (and also installed with many Microsoft products). From those fonts the two 'cleanest' for web use are likely to be Verdana (sans-serif) and Georgia (serif) as they have been designed specifically to look good on low resolution screens. Accessible Web Typography Web fonts in practice
We can never be sure that users will have the fonts we specify available on their web connected clients; not everyone will be using Internet Explorer as their browser, or will have installed Microsoft products on their computers.
However, there are ways to 'get around' the missing fonts problem; both Cascading Style Sheets (CSS) and the FONT tag allow us to supply a list of fonts that we would like to be used, and a generic font style if all else fails.
Here is an example style sheet:
Body { font-family: Verdana, Arial, Helvetica, sans-serif; }
I have chosen Verdana as my prefered font for its readability even when users have set their default text size small. But this is a Microsoft font which comes with Windows 95 and above on PCs - It's likely to be available on the Mac, but it is not part of the basic fonts set that comes with it.
Also, it is a relatively new font and may not be built into earlier versions of the Windows operating systems.Therefore, I have specified Arial for those PC users, who do not have Verdana on their systems, and Helvetica (the Mac equivalent to Arial), for those who will be using Macs and don't have Arial or Verdana.
Finally, I have specified that, if all else fails, use the browsers default sans serif font.
Using the FONT tag
For those still using the FONT tag here is the equivalent instruction:
Some text
Although the font tag has been deprecated, meaning that browsers are no longer required to support it, it is still widely used by designers and still supported by all major browsers.
I don't recommend the use of the font tag for two reasons, firstly it is no longer included in the current HTML standard, and secondly, the use of FONT tag brings with it accessibility issues:
Setting the FONT tag 'color' and 'face' attributes should be avoided because users may not be able to override your preferrences with their own. This could cause problems for, among others, people who are colour blind. If using the font tag to set the size of text, use FONT size= +1 or FONT size= -1 rather than font size = 1. Setting the font size to 1 may make the text too small for many users (although if they know how to change their preferences they can increase the size of the font). Many web designers use the Font tag to format text to make it look like a heading, rather than using the appropriate heading element. This makes pages less accessible for people using text only browsers or speech based browsers; because valuable structural information will be lost. (The same goes for using CSS to replace appropriate HTML elements)
See What's wrong with the FONT element? for more information about why the font tag should not be your number one way of setting font style attributes.
For those with 'text only' browsers, using the Font tag to set styles, font size, and colours will not have any impact, because the formatting instructions will just be ignored.
Designers set the size of fonts on a page using the basefont and font element. These element are used to set the size of text on a page to one of 7 relative values, 1 being the smallest and 7 the largest, 3 is the equivalent to normal (default font size is set by the users browser). Each size is successsively 20% larger or smaller than the default. Accessible Web Typography Why not use images instead?
To get round the limitations outlined in the previous section, it is common to see web pages with headings created as images rather than text.
There are many occasions when using text as an image is the appropriate; not all fonts can be reproduced using HTML, and trying to reproduce a text based corporate logo using HTML is rarely a good idea. However, some sites use images of text when it is patently not appropriate, e.g., I have come across sites where every page, including all of the text, is one big image.
Using an image gives the designer complete control of the design of the text, but it also creates some problems of its own. Web pages created using this technique will be accessible to fewer people:
Images can't be enlarged easily via the browser preferences; the size of images remains the same no matter how large the text becomes. Colour or contrast can't be changed to increase readability. This could be an accessibility problem for a person who has colour-blindness. If no 'alt' attribute is added to the text the image will be lost when images are turned off in the client browser. Using images instead of real text decreases the amount of information related to page structure; a heading will be marked up as a heading with the
Using images rather than text has other disadvantages:
Maintenance issues: the presentation of text across an entire site can't be changed easily or quickly. Using style sheets to alter the presentation of text provides a more efficient method of site management. Alt attributes will need to be added to each graphic. Using images increases the size of each page; download times will be longer. Text in images is not available to be indexed by search engines.
Adding structural meaning to image based headings
It is possible to add structural meaning to image based headings; the following technique was suggested to me by Patrick H. Lauke as a comment on an article about how to make non-text elements accessible. When using a graphic as a heading, enclose the image tag in the appropriate structural markup, e.g.,
For users of screen readers such as Jaws, the text in the alt attribute will be recognised as a heading, and thus voiced appropriately.
The Fahrner Image Replacement technique has been developed to give designers the freedom to use image based text, while retaining valid structured markup for non-CSS aware browsers. The assumption is that screen reader users will get text, while those using modern browser will get appropriately styled images.
In practice the technique has proven to be problematic, e.g. the screen reader Jaws reads the screen after the CSS has been applied; Jaws users end up getting no text at all. Several developers have tried to modify the technique to overcome the problems; these techniques and related issues are discussed at length on the Accessify Forums.
Are Scalable Vector Graphics the future?
Some of the accessibility problems may be solved in the future with the introduction of scalable vector graphics (SVG), but for now using images of text rather than text itself is not always your best option. (See http://www.w3.org/ Graphics/SVG/Overview.htm8.) Accessible Web Typography Is it a good idea to use embedded fonts?
Another possible way to overcome the 'client machine might not have my preferred font' problem is to 'embed' fonts into web pages. The technology to do this has been in existence since Netscape 4.01 and Internet Explorer 4.
You can - in theory at least - now specify any font you wish; your chosen fonts are downloaded with the rest of the page.
However, this technology has not become popular with web designers, in fact it seems to disappearing with very few sites making use of the greater control it offers web typographers. There are a number of reasons why this seemingly attractive idea has not been adopted:
Internet Explorer and Netscape use different, incompatible technologies. Internet Explorer uses Embedded OpenType and Netscape uses TrueDoc. Embedded fonts don't work in older browsers (pre Internet Explorer 4 and pre Netscape 4.0). Embedding fonts into pages adds to download times. Security problems have been reported; it may be possible for users to steal fonts. There are still unresolved problems related to copyright and licensing of fonts.
Browser support for embedded fonts does not appear to be improving, with no support built into Netscape 6, it looks like Netscape has decided to abandon the technology. Detailed information about using embedded fonts can be found at http://builder.cnet.com/webbuilding/pages/Authoring/Typography/ss01.html
For now, sticking to fonts that you expect to find on your users' machines, and are optimised for web use, is the best approach. Accessible Web Typography What is the best font to use for accessibility?
Simply put, there is no best font for accessibility, but that is not to say that for any particular user there will not be a 'most accessible font', there will be; but it will not be the same font for every user.
Whereas, in the physical world of printed documents providing the most accessible font implies creating several different versions of every document; one to meet the presentation needs of each individual. On the web, with the help of style sheets, we can now provide one page capable of being presented in many different ways.
We can't predict what will be the most accessible font for any particular user - so we have to fall back on the assumption that the user knows what is best; the most accessible font, therefore, will be the one they pick themselves.
Your job as an accessible website designer is not to get in the way of the user's ability to set their own preferences - and in relation to typographical matters - that means the ability to choose a font that suits their own needs.
For the text on a website to be accessible, users should be able to do the following:
Turn off your style sheets - so that the page adopts the default settings in the user's browser (this is another good reason not to use the deprecated font tag; presentation attributes will still be present after the user turns off the style sheet). Substitute their own style sheet, assuming the browser has this facility. Override all of the preferences set in your style sheet with their own, including font choice, text size and colours. Some of the most critical issues here are related to the unit used to set font sizes, i.e. absolute units versus relative units (explored in greater detail in section 2). Accessible Web Typography Summary of section one
It turns out that it is not terribly difficult to pick fonts that are accessible and easy to read, once you have some knowledge of the possible pitfalls and how to get around them. Even if you restrict yourself to using style sheets and specifying Verdana, Arial, (sans-serif), Georgia, or Times New Roman (serif fonts) you won't go far wrong. However, it is useful to know why these are good choices and what you can do to realise extra accessibility, usability and readability gains for visitors to your site. The following list is summaries what we have learned so far,
Ensure that you don't do anything that stops users from replacing your chosen font with their own 'more accessible' one (in other words avoid the use of the tag). Use style sheets rather than the tag to set font preferences. Pick a font that you can be sure will be available on most operating systems, or provide alternatives in your font declaration including a generic font type. Choose a font appropriate to the message of your website. Use typefaces specifically designed for screen use. Attend to the usability and readability issues of the text on your pages including - as discussed - choosing a readable font. For the majority of your potential audience, many of whom will not be changing their browser preferences, paying attention to: line length; leading (line height); font size; primary font choice; and the balance between white space and text; will have an impact on how accessible your content is. The importance of concentrating on readabiltiy is heightened on the web by the twin factors of attention span and speed of reading and comprehenstion (10 - 20% slower on the web than on paper) It is these usability and readability issues that will be addressed in part 3 of Understanding Web Typography. Section Two: Accessible web text - sizing up the issues.
Accessible Web Typography Section Two: Accessible web text - sizing up the issues.
In part 2, I explore the issues surrounding text size; I will try to 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.
'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 .
Yes, size is important
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 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 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; should you just set the text bigger in the first place?
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 )
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. Accessible Web Typography 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. How do we get out of the way of the user? 10/21/03 6:10 PM
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. Accessible Web Typography 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' [because] ' Accessibility is handled exclusively by the visitor's adaptive technology'. (p 223).
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.'(p223). And these people should not be our concern because they are not visually impaired people - and, therefore, outside 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, regarding 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 so seems unnecessarily restrictive. It does not 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 to 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 units, 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 'act 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 largely support his general approach to accessible web design; and I would recommend Building Accessible Websites.
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. Accessible Web Typography 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 - 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.
The magic number is nine
Remember this: 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:
1. The default resolution of a Mac is 72dpi. 2. 1 point is an absolute unit of measurement; it is 1/72 of an inch. 3. 1 pixel maps to 1 point on a Mac monitor; so for every inch on the Mac monitor there are 72 pixels. 4. At least 9 pixels are needed to render a normal font because of their ascenders and descenders. 5. Setting type to 8pt means that only 8 pixels will be used to render the type. 6. 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. Accessible Web Typography 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. Accessible Web Typography 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)
Setting text size with the Em unit
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 how 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. Accessible Web Typography 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:
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 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.
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. Accessible Web Typography Alternative relative units - relative keywords
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 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 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 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 the page becomes unusable. Accessible Web Typography Should you use 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 specified installed on their machines.
Without undue care and attention, using the x-height to specify text size, could result in text that is difficult to read on some browsers. Accessible Web Typography Using absolute size keywords
Absolute size keywords are advocated by many web savvy designers as the ultimate 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 style sheet:
xx-small x-small small medium large x-large xx-large
Why absolute size keywords are a good idea
There are at least four very good reasons for adopting absolute size keywords as your relative unit of choice:
1. Absolute size keywords are a relative unit of measurement, allowing users to resize text to suit their own needs. 2. The size of absolute size keywords will be based on the default size set in the users browser. If the user has set a font size that they are comfortable with, their preferences will not be undermined by your use of absolute size keywords. 3. Absolute size keywords do not suffer from the 'inheritance' problems related to using em units, percentages, and the relative keywords, bigger and smaller. It is not possible for text to become unreadably small, or unusably large (in standard compliant browsers); e.g. a keyword used to set the size of a paragraph does not inherit the value of a keyword set in the body element (or any other parent element) - small is always small, xx-small is always xx-small. 4. In the most up-to-date Internet Explorer browsers, xx-small, the smallest size, will never be smaller than 9pt (the readability threshold on a Mac).
In relation to Absolute Size Keywords, 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 many current browsers, since in our estimation only IE5/Mac (and possibly Opera 4) renders them correctly."
The idea of absolute size keywords is a good one, and in theory I would recommend them. However, there are some problem; the main problem is inconsistent browser support.
In older browsers such as IE3 and Netscape 4.5, absolute size keywords are supported, but their implementation is so flawed that using them can make pages unreadable (e.g. xx-small sets text to 6pt, which is below the threshold of legibility).
In the more recent browsers, IE4, IE5 and IE6 for windows there is a problem in the way keywords are related to the default size set in the users browser. Logically you would think that the keyword 'medium' would mean 'use the browser default size' - but it doesn't. Medium actually sets the text size one size bigger than the browser default - and this makes the text look far too big to most users.
Most of the current browser versions including Netscape 6+ and IE5 for the Mac and the Mozilla browser implement absolute keywords correctly. The problem with deciding to use absolute keywords is the inconsistency between these new browsers and the older browsers, which many people are still using.
There are workarounds to these problems, most notably the work done by Todd Fahrner and Tantek Celik which you will find described the article called 'Size Matters' published on the website 'A List Apart', (http://www.alistapart.com/stories/ sizematters/).
Workarounds are required
I would not dismiss out of hand the use of absolute keywords; if you are prepared to spend the time understanding the issues and implementing the workarounds they are a good solution, and certainly worth investigating.
To get you started, Jeffrey Zeldman and Eric A. Meyer discuss the issues at length. The Happy Cog website at http://www.happycog.com/thinking/colophon.html also outlines a way to get around the problems. Accessible Web Typography 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. However as we are primarily concerned with accessibility, we cannot ignore these problems.
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.
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. The most important problem with em units - and which is definately an accessibility problem - is that for IE uses who have their default text size set to 'smallest' - text can be too small to be legible if specified at a size lower than 1em. However - 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; less people are using IE3 than are using IE 4, IE 5 for Windows, and Netscape 4 on both Mac and PC.
From the point of view of accessibility, the problems associated with using pixels are more serious than those encountered by using the relative em unit. Using em units does not - unlike pixels on the majority of web browsers - prevent the end user from resizing the text to suit their own needs. Accessible Web Typography What relative unit is best?
So far, in relation to CSS, we have discounted the use of absolute units for setting the size of the text on web pages. What then is the best relative unit to use?
Our candidates are:
em units en units percentages relative keywords absolute size keywords pixels
In reaching a conclusion about the best unit to use, it is worth reminding ourselves of the following points:
Pixels are a relative unit only in relation to screen resolution. For many users it will be very difficult or impossible to change the size of the screen text if pixels have been used. Typographers have traditionally used em units rather than percentages or relative size keywords, to express the size of type. Em units and percentages are not interchangeable 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. Luckily it doesn't work like that the other way around; you can safely use percentages to set the size of text. Inconsistencies in browser support create problems when using absolute size keywords. (However, I would not rule out the use of absolute size keywords, as there are workarounds for many of the problems.) Using en units to set text size is essentially the same as using em units, but it harder to calculate text sizes with en units.
The logical choice is to use em units - but there are problems.
The hierarchical nature of HTML, and the way CSS uses that hierarchy can make setting small text sizes a problem. Careful markup of your content, is all that is required to ensure that this is not a problem on your pages. Unfortunately there is a more important issue related to using em units; setting text sizes smaller than 1em can mean the text ends up too small for some users to read, i.e. peoplewho have their preferences for text size set to 'smaller' in their browsers. I will discuss this issue shortly and suggest possible workarounds.
Absolute size keywords are also a good choice - but workarounds are required
It is not possible for text to become unreadably small, or unusably large when absolute size keywords are used to set text size; this is the best reason for adopting them as your unit of choice. However, workarounds are required to overcome the problems caused by inconsistent browser support, and some up-front learning is needed before you start to use them.
Unfortunately there are likely to be problems no matter what unit of measurement you decide to use, em units and absolute size keywords are - in terms of accessibility - good choices as long as you are aware of the problems and can put into place the appropriate workarounds. Percentages are also a good choice for setting the size of text on your pages - but as they are not used much by web developers, there may be problems with using percentages - but they have not yet been discovered. Accessible Web Typography Problems with the use of CSS relative units
Cascading Style Sheets give Web designers many more options when specifying their type; now it is possible to set many presentation attributes with precision, including 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.
Potential problems are likely to come from any of the following 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.
Even when using the 'venerable' em unit, it is possible to end up with text that will be unreadable by some visitors to your site. As I demonstrated in an earlier section, problems can occur if developers are unaware of the hierarchical nature of HTML (and the way CSS uses that hierarchy) - but there is also a potentialy more serious problem related to a feature in a number of browsers that allows users to resize the text.
Problems with the use of em units.
Gez Lemon of Juicy Studio got in touch after reading an earlier edition of this eBook:
"I used to specify ems for font-sizes, but IE has a problem with the ratios when increasing and decreasing the text size. The ratios it uses between smallest, smaller, medium, larger, and largest are too big. If someone has his or her default text-size set to smallest in IE, the text is unreadable, which is obviously an accessibility issue."
Gez makes a very good point; if users have there browser preferences set to 'smallest' - text set below 1em can appear so small that it slips below the threshold of readability.
He goes on to say that he decided to use percentages instead of ems, as using percentages does not appear to lead to the same problems. I am not aware of any accessibility issues related to using percentages (although having said that - no doubt someone will now alert me to potential problems), so I would not argue against his choice - in fact, it's a good choice.
Percentages and ems do not act the same - even though logically they should; .8em should be the same as 80%, and .96em should be the same as 96%. However the reality seems to be that there are bugs when using em units do not exist when using percentages.
My favoured unit for sizing text has - to some extent - been based on the my in- built prejudice that ems are the most logical and appropriate unit for specifying text sizes (I blame the book The Mac is not a Typewriter by Robin Williams for my affliction). Unfortunately that is not a good enough reason, if they don't actually work in practice.
So I have a dilemma: - I would like to provide a simple message: ems are the way to set the size of the text on your pages.
But in reality I need to change my message to: in an ideal world I recommend the use of em units - but please be aware that work-arounds will be required due to current browser 'features' which can result in text being too small to read.
Luckily we do not need to abandon the use of em units entirely - there are workarounds.
Workarounds to the problem of using em units.
Set the base font size to 100%
Owen Briggs has discovered that setting the base font size to 100% cures many of the problems - and text remains at a readable size in most browsers - even when the user chooses the smallest size from their text re-size menu. Unfortunately this fix doesn't work consistency for Opera users (Rijk van Geijtenbeek provides information about the bug).
Use Javascript
Matt Round has provide a workaround based on the use of Javascript ; the script checks the text size after it is loaded into the browser, and resizes it if it is found to be too small (very smart). However, using Javascript does creates its own problems; not all browsers support javascript, and some people will have it turned off. The fix 'only works in modern, DOM-capable browsers' and does not work consistently in all modern browsers (e.g. there is a problem with text within tables when using IE for the Mac).
Use percentages to set a size in the body selector, and then use ems for everything else.
Owen Briggs has done a lot of work in relation to the text size problem - and has provided a workaround that appears to work well in all browsers:
"Anyhow, I played about and found you can make a nice ems stylesheet with P text at 1.0 em, and then downsize the whole thing by selecting size in BODY with %, like 76%. It's simple, easy to change, and works for everything. Score 1 for late nights and coffee. Enjoy. "Owen Briggs
Owen's article Sane CSS Sizes is worth reading, and you should also check out the 'generic text styles template' he provides as an example of how to implement the fix.
What units to use
Choose from any one of the following: em units (with workarounds), absolute keywords (with workarounds), or percentages; all are relateive units of measurements, and all, with the appropriate care and attention, will ensure the text on you pages is accessible to your visitors. Accessible Web Typography What about using 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:
some text
Similarly, the following sets the text one step smaller:
some text set the text one step smaller than the default.
Visit Todd Fahrner website for further examples.
The BIG and SMALL tags are user scalable, so there are no serious accessibility issues that I am aware of; I would not counsel you against using them. However there are a few issues you should consider:
BIG and SMALL have little meaning beyond visual presentation. It is an inefficient method for setting text sizes on large sites; to re-size text at a later date will require a lot of 'find-and-replace' work. It is less flexible than using CSS to set text sizes as presentation and structure are not clearly divorced.
If we are interested in moving towards the goal of divorcing content from the presentation of that content, these tags would more usefully be replaced with attributes declared in a separate style sheet.
However, BIG and SMALL are perfectly legal HTML elements, and they may be just what you want in terms of setting consistent cross-browser text sizes. Accessible Web Typography 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.
Or by setting a value as being a certain number less than or greater than the default size of 3, e.g.,
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 using 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, 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. Accessible Web Typography 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 physical 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.
And the technology people use to view web pages does not stand still. Reading Jeffrey Zeldman's excellent book, 'Designing with web standards' I was alerted to the fact that the first versions of the Safari browser for the Mac threw another variable into the mix - the default text size in Safari was not the same as the its competitors. Safari used 14 pixels as the default text size, rather than the 'standard' 16 pixels used by competing browsers (this has been addressed in later version of the browser).
Unless you are designing for a closed environment like an intranet and you can control screen size, resolution, and the habits and capabilities 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. Accessible Web Typography Usability issues
Readability is not just about the typeface used; in many cases this is not the most important factor. Rather, line length, contrast between text and background, balance of text and white space, the size of the text, and the interaction of all of these factors, will have a bigger impact.
The following is a list of some of the main readabilty and usability issues:
Text alignment:
Aligning text to the left, ragged on the right, increases reading speed because the straight left edge helps to anchor the eye when starting a new line (Designing Web Usability : The Practice of Simplicity by Jakob Nielsen).
Line length:
There seems to be little agreement on the best length length for optimum reading speeds. The most commonly advice is that limiting line length to 9 or 10 words can increases speed and comprehension (based on the assumption The eye can only focus on about 3 inches of a page at a time).
However reading speed and user preferences is not a simple matter, consider the following conclusions by by Melissa Youngman and Dr. Lauren Scharff (1998)
"Users read faster when line lengths are long, although they tend to prefer shorter line lengths. When designing, first determine if performance or preference is important. If user performance is critical, use longer line lengths to increase reading speed. However, if user preference is critical, use shorter line lengths. http:// usability.gov/guidelines/readscan.html#one
Leading (line-height)
Set the leading larger than the default - as a rough guide 1.3em of leading (130%) will make a big difference to the readability of a web page. Leading and line length however are related; the longer the line the bigger you need to make the leading.
Newspapers have very short line lengths and very little leading - so they can fit as much text into a small space as possible. However, given the variable nature of the devices people use to view web pages, we can never be sure what the line length will be for the user.
Choice of fonts: Choose a font that is suitable to your subject matter. If you use more than two fonts on a page and it can start to look like a ransom note - distracting the users attention from the content. Off-line, headings are commonly set in a sans-serif font, with body text set in serif. However, on-line, sans-serif are often used for both headings and body text; the cleaner outlines of the sans-serif fonts tends to make them easier to read on low resolution screens. Don't mix serif and sans-serif fonts in your body text, as it rarely looks good.
Italics:
Avoid using italics for small text sizes: the problems of screen display of outline fonts has not entirely disappeared. Italized fonts look particularly bad at small sizes - as italics do not easy to render using a square pixel grid. If you must use italics, avoid using them for large blocks of text.
Use of capitals
Don't use all caps for bodytype - or even capitalise all words in headings. The uniformally of size and shape of capitals make them harder to read than lower case letters.
Readability is increased if only the first letter in a heading is in capitals; each capital - being less recognizable - acts as an interruption to the flow, as the eye scans across the text.
Contrast
Ensure good contrast between the text colour and the background colour.
Underline links
Make it easy for visitors to understand what is a link and what is not a link. Don't rely exclusively on mouseovers to identify links, as this can be confusing and reduces usability. (From http://usability.gov/guidelines/links.html#six)
Users scan web pages
For Service based website in particular, arrange your text for 'scannability', i.e have lots of headings, provide the most important ideas at the start of paragraphs, and use lists rather than dense passages of text when appropriate. Accessible Web Typography Useful links and resources
Articles about typography listed by Lijst.net. Typography By Tomas Caspers. Fonts for the Macintosh have gone full circle writes ANDY BENEDEK. The World of Fonts by Dmitry Kirsanov . W3C access checkpoint 7: Text instead of images. Webmonkey embedded font tutorial. Tijs Teulings on embedded fonts. Microsoft Typography. Usability.gov: guidelines Beyond the FONT tag: Practical HTML text styling Browser bugs and workarounds Fear of stayle sheets 4 by Jeffrey Zeldman. Absolute Font Sizes: A Clarification by Eric A. Meyer. Size Matters: making font size keywords work by Todd Fahrner HTML - looking down at it from a very great height. by Jim Byrne. Building Accessible Websites a book by Joe Clark What is an accessible website? by Jim Byrne. Best faces for the screen Daniel Will-Harris Best online font for older adults Michael Bernard, Corrina Liao, & Melissa Mills So, What Size and Type of Font Should I Use on My Website? Michael Bernard, Corrina Liao, & Melissa Mills Sane CSS typography by Owen Briggs. Accessible Web Typography Help if you are printing this document: links from each chapter
Thanks and welcome
Pat's Guide to West End of Glasgow: http://www.glasgowwestend.co.uk
Publisher and copyright information
ScotConnect: http://www.scotconnect.com/
About the author
Jim's West End Photo Diary at http://www.glasgowwestend.co.uk/gallery/ index.html QuicknEasyImage Pro: http://www.quickneasyimage.com/ CommentIt: http://www.udena.ch:81/baylys/help/commentit FlathuntingPHP: http://www.glasgowwestend.co.uk/flathunting/index.php BusinessListPHP: http://www.glasgowwestend.co.uk/business/index.php PropertyListPHP: http://www.glasgowwestend.co.uk/property/index.php
Why would you want to control the text on a Web page?
childrens TV program: http://www.bbc.co.uk/cbbc/ politics course in a university: http://www.ksg.harvard.edu/prg/ Financial Times Website: http://news.ft.com/home/uk/ The Tate Modern: http://www.tate.org.uk/modern/default.htm Webreference.com Sans Serif History: http://www.webreference.com/ dlab/9802/sansserif.html Dmitry Kirsanov: Matching Fonts: http://www.webreference.com/dlab/ 9802/
Issues that can make it difficult for you to control how your text looks
Rob Collins's web site: http://www.angelfire.com/al4/rcollins/style/ fonts.html Browser News: http://www.upsdell.com/BrowserNews/ res_fonts.htm#a04d
The difference between screen fonts and printer fonts
Facing up to the future: http://www.dotprint.com/graphics/graphi26.htm Web Review: http://www.webreview.com/1997/11_07/webauthors/ 11_07_97_10.shtml TrueType hinting: http://www.microsoft.com/typography/hinting/ hinting.htm
Web fonts in practice
What's wrong with the FONT element?: http://www.mcsr.olemiss.edu/ ~mudws/font.html
Why not use images instead?
Scalable vector graphics: http://www.w3.org/Graphics/SVG/ how to make non-text elements accessible: http://www.mcu.org.uk/ articles/alttext.html The Fahrner Image Replacement technique: http://www.stopdesign.com/ also/articles/replace_text/ Accessify Forums: http://www.accessifyforum.com/viewtopic.php?t=28
Is it a good idea to use embedded fonts?
Using embedded fonts: http://builder.cnet.com/webbuilding/pages/ Authoring/Typography/ss01.html
Section Two: Accessible web text - sizing up the issues
Daniel Will-Harris, The best faces for the screen: http://www.will- harris.com/typoscrn.htm Best online font for older adults: http://psychology.wichita.edu/surl/ usabilitynews/3W/fontSR.htm So, What Size and Type of Font Should I Use on My Website?: http:// psychology.wichita.edu/surl/usabilitynews/2S/font.htm RNIB: http://www.rnib.org.uk/wedo/research/hints.htm
Are you sure the unit of measurement used is that important?
Building Accessible Websites: http://www.joeclark.org/book/ What is an accessible website?: http://www.mcu.org.uk/articles/ whatisaw.html
Using Cascading Style Sheets
Definition of em units: http://www.mcu.org.uk/article/ glossaryterms.html#em
Alternative relative units - relative keywords
Weirdness may result when text is resized in IE': http:// www.ookingdom.com/ Font Size Does Matter: http://www.meyerweb.com/eric/articles/webrev/ 199908a.html
Using absolute size keywords
Fear of stylesheets 4: http://www.alistapart.com/stories/fear4/4.html Size Matters: http://www.alistapart.com/stories/sizematters/ Absolute Font Sizes: A Clarification: http://www.meyerweb.com/eric/ articles/webrev/199912b.html The Happy Cog website: http://www.happycog.com/thinking/ colophon.html
Why not use pixels?
Give me pixels or give me death: http://www.alistapart.com/stories/fear4/
Problems with the use of relative units
Browser bugs and workarounds: http://css.nu/pointers/bugs.html Problems with em units: http://www.zeldman.com/daily/0502c.html#emz W3C HTML validation tool: http://validator.w3.org/ For printing: links from each chapter 10/26/03 12:14 PM
W3C CSS validation tool: http://jigsaw.w3.org/css-validator/ Juicy Studio: http://www.juicystudio.com/ The Mac is not a Typewriter by Robin Williams: http://www.peachpit.com/ features/article.asp?session_id={3C442FB2-5ECB-4F26-8699- 8D6F98C75DE3}&product_id={D59D0A20-FD87-4393-B80F- 840CBA7AAFE6} Rijk van Geijtenbeek: http://groups.google.com/groups?selm= u2009uofg6p8il05s7dq4dvqcvofg89r27%404ax.com
What about using BIG and SMALL tags?
FONT tag: Practical HTML text styling: http://style.cleverchimp.com/ font_size/livetext.html
Links
Articles about typography listed by Lijst.net: http://www.delijst.net/ delijst/Design/Typografie/Artikelen/index.php Typography By Tomas Caspers: http://www.wpdfd.com/wpdtypo5.htm Fonts for the Macintosh have gone full circle writes Andy Benedek: http:// www.dotprint.com/graphics/graphi26.htm The World of Fonts by Dmitry Kirsanov: http://www.webreference.com/ dlab/9802/ W3C access checkpoint 7: Text instead of images: http://www.w3.org/TR/ WCAG10-CSS-TECHS/#text-not-images Webmonkey embedded font tutorial: http://hotwired.lycos.com/ webmonkey/99/45/index1a.html?tw=design Tijs Teulings on embedded fonts: http://www.tijs.org/embed/ Microsoft Typography: http://www.microsoft.com/typography/ default.mspx Usability.gov: guidelines: http://usability.gov/guidelines/links.html Beyond the FONT tag: Practical HTML text styling: http:// style.cleverchimp.com/font_size/livetext.html Browser bugs and workarounds: http://css.nu/pointers/bugs.html Fear of style sheets 4 by Jeffrey Zeldman: http://www.alistapart.com/ stories/fear4/ Absolute Font Sizes: A Clarification by Eric A. Meyer: http:// www.meyerweb.com/eric/articles/webrev/199912b.html Size Matters: making font size keywords work by Todd Fahrner: http:// www.alistapart.com/stories/sizematters/ HTML - looking down at it from a very great height. by Jim Byrne: http:// www.mcu.org.uk/articles/htmlnotes.html Building Accessible Websites a book by Joe Clark: http:// www.joeclark.org/book/ What is an accessible website? by Jim Byrne: http://www.mcu.org.uk/ articles/whatisaw.html Best faces for the screen Daniel Will-Harris: http://www.will-harris.com/ typoscrn.htm Best online font for older adults Michael Bernard, Corrina Liao, & Melissa Mills: http://psychology.wichita.edu/surl/usabilitynews/3W/fontSR.htm So, What Size and Type of Font Should I Use on My Website? Michael Bernard, Corrina Liao, & Melissa Mills: http://psychology.wichita.edu/ surl/usabilitynews/2S/font.htm Sane CSS typography by Owen Briggs: http://www.thenoodleincident.com/ tutorials/typography/index.html