Getting Started with Practical Web Accessibility

This document presents the practical basics of accessibility. It can be read as a standalone primer, or used as the basic material for a short course. After finishing it, you will know a useful set of rules, the reasons behind them, and how to apply them in authoring. You can then proceed to a wider and more detailed look at web accessibility, e.g. using the WebAIM cite.

Twelve simple rules

Why these rules?

We will begin with a few practical ways of making web pages more accessible. They are described as simple rules, which can be applied by anyone who knows how to create pages. The rules do not constitute any standard or recommendation, and they cover just a few aspects of accessibility. Yet, let us start from practicalities rather than theoretical foundations. This will help you to get an idea of what accessibility means at the level of actual work. Besides, following these rules you will easily make your pages far more accessible than most web pages are.

There is not much hi-tech involved in these rules. This makes it possible to present some basic principles in a manner that is widely understandable to authors (and other people, too). There is a deeper reason, too. Much of basic accessibility is technically simple. It is to some extent even matter of avoiding hi-tech in issues where it would cause accessibility problems.

The rules are here flagged with one, two, or three asterisks that indicate an estimate of the ease of implementation. This refers to satisfying the rules in a typical case where the rule is relevant. One asterisk means that the process is rather straightforward, two asterisks mean that a substantial effort and often some creativity is needed, and three asterisks mean that the process often requires conversion work or alternate content production and can thus be expensive.

  1. Check the language of the most important pieces of text, such as headings, summaries, first paragraph of each page, and navigation links. Use as simple and concrete language as possible, and check the spelling, too.**
  2. Use descriptive link texts, no “this” or “click here” links. Check that each link text is at least marginally meaningful when read in isolation.*
  3. Use adequate textual alternatives (alt texts) for all images. This means empty text (alt="") for decorative images.*
  4. For each image contributing content to the page, provide either a textual explanation of the essential content or a link to such an explanation.**
  5. Do not embed auto-starting audio, video, or animated images. Use links instead.*
  6. Provide text transcriptions or descriptions for all audio and video clips.***
  7. Provide alternative mechanisms for online forms, such as e-mail address or phone numbers.*
  8. Make all documents available in HTML format or, in some cases, plain text format. Other formats such as PDF, Microsoft Word, and Microsoft Excel can be offered as alternatives, not as the only format.***
  9. Organize pages so that they make sense and work when read linearly (by the HTML source order). In particular, if there is repetitive content such as a list of navigational links on every page, provide a simple link that lets the user to skip over it, to the content.**
  10. Do not set the copy text font size, or set it to 100% or, if deemed necessary, to a percentage value, in the range 85% to 100%.*
  11. Avoid any constructs that impose a large minimum width for rendering the document, such as width values for tables. A page should work without horizontal scrolling in a window that is 550 pixels wide.**
  12. If your site has serious accessibility problems, explain them and possible ways that people can use to cope with them. Use a separate page for this, and link to it with a prominent link (such as “accessibility info”) on the main page.**

Usually no special tools are needed to implement the rules. You can work with the program that you normally use to create and edit web pages. This can be anything from a simple editor like Notepad to a highly sophisticated authoring system that utilizes templates, data bases, preprocessing, and whatever. Perhaps you use a program like FrontPage or Nvu that lets you work with menus and buttons as in text processing but also gives you an optional access to HTML source code. In any case, you know your authoring tool and you will learn more about it if needed.

However, you may find some additional tools useful. For example, if your authoring tools has no spell checker built into it, you might use a separate program for the purpose. If you have many images on your page, you might use a markup validator that will check, among other things, that every image has an alt attribute. We will mention some of such tools in the subsequent sections that deal with each of the twelve rules separately in more detail.

Rule 1: Simple language

First, identify the most important pieces of text on the page. This includes

Then check these texts for

There are software tools for such checking. However, such tools cannot replace human judgement and analysis, by you or others. If possible, ask other people’s help to evaluate your texts and try to learn from their comments. If you think that your text is crystal clear and your friend says that it is confusing, the odds are that he is right. Other people’s comments help you make specific corrections, but more importantly, they can help you to see your typical mistakes and avoid them.

The general idea is to use as simple and concrete language as possible. Therefore, the goal depends on the purpose of the page. If it contains instructions on voting in a general election, it should be very simple and specific, even at the cost of looking nave to some. If it explains advanced quantum electrodynamics, it needs to use difficult and abstract concepts and special notations. As a rule of thumb, there is always room for improvement. Find, read, and apply some style guides for the language you are writing in. You will notice that there is always something new to learn in writing simply and understandably; the important thing is to get started.

In particular, watch out for the following expressions:

Experts always overestimate the need for using special terms and phrases. They are accustomed to using them when writing and speaking to colleagues, so they will keep using them when trying to address a wider audience. You may need to be less exact in order to be more understandable, but often it’s just a matter of choice between common words and jargon. You probably recognize this in texts that are outside your expertise. If you do not work in the area of medicine, you realize that “myocardial infarction” is unnecessarily complicated language; it means “heart attack.” The crucial thing is whether you can see how much you and your colleagues use jargon that creates serious accessibility problems.

Use simple sentences. On some pages, you may need many technical terms, and you may need to imply that readers have university level education. This does not mean that you should use difficult sentence structures. On the contrary, when the vocabulary and the ideas are complex, aim at simplicity of language to reduce the difficulty of understanding. As a rule of thumb, sentences longer than 20 words tend to be difficult to many just because of their length. Preferably, make most sentences 10 to 15 words long.

Avoid ambiguities and possibilities of misunderstanding. This is often even more important than being understandable! If your text is difficult, the reader can re-read it and seek help to find its meaning. If your text is superficially easy and simple but potentially misleading, it will be misunderstood. Ask yourself: could someone really get a completely wrong idea of what I mean, if he really tried? If the answer is yes, many people will misunderstand the text without even trying.

The ambiguity problem is especially important when checking navigational links. Their texts need to be rather short, and authors often make them too short and just vaguely suggestive rather than clear. If a set of navigation links contains the word “Index,” how is the reader supposed to know what index it refers to? “Site index” is better. The link texts should be understandable to a person with no prior information about the site. He should be able to classify his problem or question into one of the categories described by the links. The common problem is that the link texts reflect the author’s or the organization’s way of thinking rather than user view.

Of course, you can apply such checking to all text on a page. The formulation of rule 1 is just realism: you probably don’t have enough time for full checking. Moreover, some parts of the textual content are far more important than the rest. However, for a page that does not contain any substantial amount of special or rare words, it is usually quite feasible to run a complete spell check.

Rule 2: Descriptive link texts

There are two main types of links, from a practical standpoint:

Basic navigational links are very important elements. Therefore, they should be checked for simplicity and understandability. In addition to this, all links should be at least minimally explicit and descriptive about what they refer to. Optimally, link text is meaningful even when read in isolation.

When basic navigational links appear in two or more groups, it should be more or less evident at a glance what the idea in the grouping is. Quite often, the grouping is quite logical in the authors’ opinion but not to users. The more there are groups and links, the more difficult it becomes to satisfy a basic requirement: A user should be able to quickly select among the links to find what he is interested in.

A common problem is that navigational link texts are too short and just hints rather than descriptions. Some short links work quite well, such as “Staff” or “About us” or “Products.” On the other hand, “Info” and “History” are rather abstract. Information about what, history of what? “Site info” and “Company history” would be better. Make link texts as short as possible, but not shorter.

The following table illustrates examples of bad and good link texts.

Bad Good
this Price list
here Future events
click here Order form
more Meeting of the presidents (full text)
memo User satisfaction report
R/D unit Research and development unit
ISO 1234 Split pins standard (ISO 1234)

As a rule, link texts should be unique on a page. This means that no two link texts are the same or very similar. Links pointing to the same page might be an acceptable exception, but such duplication can be disturbing.

There are some tools that you might find useful for analyzing links. Browsers such as Firefox and Opera contain functions for getting a list of all links on a page. (On Firefox, select Tools/Page Info, then the “Links” pane.) This can be useful for an overview and for analyzing whether there are disturbingly similar-looking but different links. There are also online link extractors like Link Context Checker.

Rule 3: Alt texts

Check all images (<img> elements) on the page, and consider whether they have an alternate text (alt attribute) specified and whether that text is adequate. The alternate text is meant for use when the image is not displayed, for one reason or another.

The length of the alternate text should vary from zero to about twenty characters in typical cases. Anything longer is quite often a misguided and misguiding attempt at describing what there is in a picture, rather than proving a text equivalent to it. If an image would need a longer alt text, then the alt attribute is probably not a sufficient method for conveying the message of the image. In that case, you should present the longer text using a different technique.

Using a text-only browser is one way of checking that images have alt texts and that they work well. There is a free text-only browser, Lynx, available for different platforms. You might take an easier way by using an online simulator, “Lynx viewer;” such as Yellowpipe Lynx viewer You specify a page address to it, and it returns a page that corresponds to the page rendering on Lynx, i.e. a linearized view. You could alternatively use the Links browser.

Using a text-only browser or simulator is a good overall checking tool, since it also linearizes the page (see Rule 9) and ignores most formatting. It also gives a rough idea of how the page might behave when read aloud. Moreover, it is similar to the way that search engines “see” the page.

Alternatively, you could read the HTML source of a document and check the <img> elements. However, there is no simple way to detect images from the visual appearance of a page, since some images might actually be backgrounds and some texts might actually be images. Using a text-only browser as the only tool isn’t suitable either; you need to compare the presentation with the graphic appearance of the page.

If there are many images, it can be difficult to check the all the alt attributes. There are utilities that let you view the page graphically but with alt texts shown in a label-like manner. However, this isn’t as convenient as it may sound.

If you view a page on a graphic browser and move the pointer over an image, the browser may display the alt attribute as a “tooltip.” However, this isn’t universal, and the “tooltip” that is shown might actually reflect the value of another attribute (the title attribute). Moreover, how do you know how to identify all the images? Some of them may look like text or buttons or colored boxes—or be completely invisible.

Thus, it is much easier to write good alt texts originally, i.e. when creating a web page. That way, you will think about the textual alternative at the same time that you think about the image and its purpose. Many authoring tools let you write the alt text when you insert an image, but few of them encourage you to do so. Thus, if you use a wysiwyg editor, read its documentation in order to find out how to add alt texts

There is much to be said about alt texts (see e.g. the extensive document Guidelines on alt texts in img elements) but we will start from five basic cases:

There is no excuse for not specifying an alt text for an <img> element, but there are excuses for making such texts less than perfect. Things to be avoided include

There are many software tools for checking that every <img> element has an alt attribute. Even markup validators such as the WDG validator perform such checks, because the alt attribute is syntactically required in HTML. However, such tools cannot check that the attribute values are appropriate and useful. You need to understand the page and the purpose of images in order to evaluate what the alt texts should be.

Rule 4: Explain content images

In the previous rule, we suggested that parenthetic descriptions be used as alt texts for content images. This should be accompanied with some way of making the most essential part of information in the image available as text, naturally assuming that we cannot express that information conveniently in an alt text.

Explaining content images is often quite a challenge, perhaps too big a challenge. After all, we are referring to images that have rich graphic information. Quite often, it is not feasible to write a textual explanation. Content images often have more content that can reasonably be explained in text. For example, a news page contains news photos that are clearly content images, yet not necessary for understanding the text. You are not expected to do impossible or useless things. Yet, if some news photo contains essential information that is not expressed in the text, you should do something about it.

On the other hand, in many situations, textual explanations are both important and easy to write. For example, if the image presents an organization chart, you will usually need a lot of text to explain the organization with no reference to the image. However, it can be done, and it is rather straightforward. Imagine how you would explain the organization on the phone. On a web page, you are not limited to plain text, however. You can also use lists, tables, and other markup.

In a simple case, an organization chart would be explained in text as follows: “We have the board of executives on the top, with the managing director under it and overseeing all activities. The activities are:…”

Having written the textual explanation, choose between the following alternatives:

Rule 5: Avoid auto-start

There are different ways to embed audio or video data so that the presentation automatically starts when a user enters the page. Similar effects than be achieved by using so-called animated GIF images. Avoid such constructs. Also avoid blinking text (implemented using the <blink> element) and automatically scrolling text (usually implemented using the <marquee> element).

It is usually easy to see whether a page contains auto-starting content. You just visit the page using a normal graphic browser on a computer with sound presentation capabilities. If you hear something or if you see any moving content, even though you haven’t done anything on the page, you have a problem.

If the page uses the (nonstandard) HTML element <embed> for embedding something that auto-starts, then a quick fix could consist of the removal of an autostart attribute from the element. However, you need to consider the element as a whole: if it has been designed to auto-start, it may lack normal audio or video controls for starting it!

If the presentation is not relevant to the purpose of the page, just omit it. For example, an animated image of a mailbox with a hand reaching out from it is sometimes used as a link to the author’s E-mail address. Replace it by a static image, or, better still, by text like “E-mail” or simply your E-mail address.

If the presentation is relevant and useful, such as an animation that illustrates how a system works, it is often best to link to it instead of embedding. At the HTML level, this typically means replacing an <embed> or <object> element by an <a> element. You can use a link that consists of both a descriptive text and a static image that suggests the nature of the linked resource. In markup, this could mean something like the following (to complement a textual description, not as a replacement for it):

<div>There is a short (5 min) video presentation that
illustrates the installation process:<br>
<a href=”instructions.avi”>instruction video<br>
<img src=”video.jpg” alt=””

Rule 6: Text transcriptions

If a site contains audio or video clips, you should provide text transcriptions or descriptions of them. Exceptions include clips that merely visualize something already explained in the text and audio clips containing page content in spoken form.

For example, if you have a video clip containing an interview, you should try to create a textual alternative that contains the spoken content. You may need to add notes that describe what happens visually, if it is relevant to understanding.

This often means considerable work, perhaps comparable to the effort of creating the primary content. The cost may thus be too high. In that case, you should describe the situation to users. People should at least know that there is essential content that they cannot access, and there should be some note about the nature of the content. If a page contains a link to the clip, the text of the link could and should (cf. to rule 2) indicate what the clip is about.

Of course, there is content for which no adequate text transcription or description can be written. Instrumental music is a typical example.

Rule 7: Alternatives to forms

Forms are very important elements, especially to create accessible interaction. Yet, you should provide alternative mechanisms for forms. Although practically all browsers support forms, the support is often rather primitive. Despite all the measures we can and should take to make forms accessible, many people have problems with using forms.

In particular, if you have a form for sending feedback, requesting further information, joining an e-mail discussion list, or ordering something, consider specifying one or more of the following:

Make sure that the alternate contact methods really work and that the information on them is updated as needed.

Site search forms are different, since you don’t really expect to be able to have manpower for doing searches for users. In a sense, a good system of navigation is an alternative to using a search form. In addition, there should be a link to help with using the form, no matter how easy to use it might look. The help page or section can then contain contact information for problems with the form. The link could be, for example, visually an image consisting of “i” in a circle, with alt text like “info on using the search form.”

Rule 8: No “PDF only” or “Word only” content

Try to make all content available in HTML format or, in some cases, plain text format. Formats such as PDF, Microsoft Word, and Microsoft Excel have essential accessibility problems. They can (and often should) be offered as alternatives, but not as the only format and not as the primary format.

This is often hard to achieve. Content production in your organization might be oriented towards print media and therefore use mainly PDF or Word format. Converting from such formats to reasonably accessible HTML format takes time, effort, and skill. The amount of work often exceeds the possibilities. A major change in the production process would be needed to avoid this, and such things surely aren’t easy.

Yet, what you can often do in a reasonable amount of time is “HTML envelopes” for the other formats. Instead of directly linking to a PDF document, create a small HTML document and link to it. The HTML document should contain some basic facts about the PDF document (author, title, type, etc.) and a link to it, and preferably a short summary. The summary is typically just text without much formatting, so it should be easy to e.g. copy and paste an existing summary from the PDF file into the HTML document. (You can use e.g. Adobe Reader to copy text from a PDF file into the clipboard, unless the PDF file is copy protected.)

For a single document in, say, PDF or Word format, it can be reasonably easy to convert it into HTML. This is feasible if the content is important enough. Note that using the File/Save As Web Page function in Word will create a sort-of HTML format, which often has serious accessibility problems. It is, however, usually more accessible than Word format, so even such a simple conversion could be useful.

If your page contains links to non-HTML documents, you should warn about this, e.g. by putting the text “(PDF)” or “(PDF format)” after the link. If the linked document is larger than, say, one megabyte, mention the size as well, e.g. “(PDF, 4 megabytes)”.

There is no simple way to check whether there are links to PDF documents or other non-HTML documents on a page. The link appearance is normally the same. You might look for the addresses (URLs) in the links; an address that ends with “.pdf” usually points to a PDF file, and an address that ends with “.doc” usually points to a Word document. This not bulletproof though. The only way to really know the situation is to try to follow the links.

Rule 9: Linearizability

A page should make sense and work when read linearly, by the HTML source order. In particular, this means the following:

As an example of a construct that does not linearize well, consider a set of links organized as a two-column table, as in the following:


When read in a linear way, by rows, the links appear in a chaotic order: dog, birch, cat,… Although the structure might be obvious visually, it is confusing when linearized. Technically, you could make it linearize well by using two one-column tables, placed into a 1 by 2 table.

Thus, a division of the page content to two or more columns does not necessarily prevent linearizability. On the other hand, if it does, a fix usually requires a major redesign of the page structure. Therefore, it is important to avoid the problem by using appropriate design methods, if you use tables for layout. Similar issues arise when doing layout with CSS positioning.

There are two approaches to creating “skip navigation” links. The first is based on using a simple textual link: <a href="#start">skip navigation</a>. (Using “skip to content” or even “content” might be more logical as the link text, but “skip navigation” is widely used.) The other approach is based on the idea that the link should be invisible in normal graphic browsing, so one uses an invisible image (single-pixel transparent GIF image, say transp.gif): <a href="#start"><img src="transp.gif" width="1" height="1" alt="skip navigation" border="0"></a>. In both approaches, you would naturally need to define “start” as a destination anchor, e.g. in the main heading of the content: <h1 id="start">…</h1>.

If there is only a small number of navigational links at the start of a page, a “skip navigation” link is usually not needed. “Small” might be read as “less than six or seven” here.

Rule 10: Adjustable font size

The font size should ideally be left to the user to decide. There are schools of though that favor somewhat reduced font size, since (they claim) typical browser default font size is too large and most people don’t change it. If you decide to follow that school, you might set the copy text font size to a percentage somewhat smaller than 100%, but hardly below 85%.

Consider the simple case where a web page would set its own font size but only as an overall size, not with different sizes for different elements. This would mean something like body { font-size: 10pt; } in a style sheet. From the accessibility point of view, the basic alternatives are, starting from the best:

  1. Do not set the font size at all (i.e., leave it to the browser and the user). This is in practice equivalent to setting body { font-size: 100%; }. (There might some technical reasons, related to browser bugs, to use such settings, though they are logically redundant.)
  2. Set the font size to a percentage such as 90%, but not below 85%. If you do this, you should also set the font face to a sans serif-font, e.g. Arial.
  3. As above, but using the keyword small. Setting font-size: small sets the font size one step smaller than the default, with a browser-dependent step size. This is still readable to most people, and users can increase (on most browsers) the font size in a simple way if they need to.
  4. Set the font size in points, to a value between 10pt and 12pt. At least for 10pt, set the font face to a sans-serif font.
  5. Other settings. The px (pixel) unit may relate to points in slightly different ways, so that e.g. 10pt might correspond to 13px or 14px. Apart from such issues, there is no big difference in accessibility between using pixels and using points. Setting the font size smaller than 10pt tends to cause severe problem to many users.

Assuming you did not design a page yourself, how do you know what it does to the font size? The first test is to view the page on IE with default settings. If the page does not set font size, i.e. leaves it to the user, the font size is normally 16 pixels (16px), which typically means 12 typographic points (12pt). The following example shows 12pt text in some commonly used fonts (if your browser can display them). It can be seen that the actual sizes of letters depend both on the font size and on the font face.

This is sample text in 12pt size, in Times New Roman.
This is sample text in 12pt size, in Arial.
This is sample text in 12pt size, in Verdana.
This is sample text in 12pt size, in Courier New.

Second, using IE, select View > Text size and select the option Largest. If the font sizes on the page do not change, the reason is that the page sets font sizes in physical units, not percentages. This indicates a serious accessibility problem, though the seriousness depends on the actual font size used and the kind of disabilities that users have. Very small font sizes like 12 or even 9 pixels are problematic to many users.

Rule 11: Reasonable width

The common question .what screen resolution (or screen size) should I design for. is a wrong question, though it can be turned into a meaningful question. If you need to answer the question as posed, the correct answer is .any resolution.. This can be literally anything, starting from zero pixels; there are no pixels in a speech presentation of a page.

The simple test for page width is to open the page on a graphic browser and modify the browser window width. Is the content visible without horizontally scrolling if you make the browser window.s width half of the screen width?

The upper limit for the visible width without scrolling is dictated by the horizontal resolution of the screen, which is typically 1024 or 1280 pixels these days. A fairly common scenario of using two equal-wide windows side by side means that window width is 500–600 pixels, and this is often a convenient width for browsing: it roughly corresponds to typical page width in books.

You can find your monitor resolution in the system settings, e.g. via the Control Panel in Windows. You can also create a simple test page containing elements with known width, for comparison. A simple way to create such an element in HTML is <hr align="left" width="…">.

The graphic rendering of a page can “have a width” in several meanings:

A fixed-with page
has a specific width in pixels, typically set up by using a layout table with a width attribute. If you set, say, width="750" in a table tag, then the width is 750 pixels, causing some horizontal space to be unused if the browser window is wider, and forcing horizontal scroll bar if it is narrower. (To be exact, the page will be a bit wider, due to default margins.)
A free-width page
takes up the available horizontal space. This may cause very long text lines. On the other hand, it makes the page fit to even very small devices or windows without horizontal scrolling. In practice, there is some lower limit, typically the width of the widest image used or the length of the longest word.
A mixed-width page
is an in-between case that has a minimum width set, or a maximum width set, or both. This may mean, for example, that in a 1024 pixels wide window, the page content is 600 pixels wide (when the maximum width is set to that) but in window narrower than 600 pixels, the page takes the available width.

As a rule, a mixed-width page with a maximum width set to, say, 550 or 750 pixels is more accessible than the other alternatives. The value of 550 has no magic in it, but it allows the page to be viewed without horizontal scrolling on most devices, at least in full-screen mode; moreover, it probably makes the page fit on paper, for most commonly used paper sizes. A free-width page is suitable too, except for the fact that on a large screen, the user needs to know how to set the window width to something suitable. For a fixed-width page, smaller widths (down to something like 350–400 pixels) are better than larger widths.

However, the width issue is deeply entangled with the overall page design. If you have, say, a page with a layout table with <table width="900">, then the page surely has accessibility problems, but you cannot usually solve them simply by removing the width attribute or changing its value. There are probably several elements and features on the page that relate to the table width and should be adjusted too. However, on many pages that use layout tables in a rather simple way, removing all width attributes from the table and its cells can produce a considerable improvement.

Tables are not the only constructs that impose a specific a lower limit for page width. Quite often, a page is otherwise a free-width page but contains a wide logo image at the start (or elsewhere). In such situations, it is advisable to replace the image by another version that has width smaller than 550 pixels.

Rule 12: Honest about inaccessibility

If your site has serious accessibility problems, explain them. Typically, you would write a page about them and link to it on the main page. It might perhaps best be labeled “inaccessibility statement,” but in practice you probably want something like “accessibility issues of this site.” You might even use “accessibility info,” though this would be euphemistic.

In addition to describing essential problems, the page should help people to cope with them. Let us suppose that a large site lacks all alt attributes for images. This is serious indeed. However, it may take a long time to fix it, perhaps a year. Authors need to study each image and write the best alt attributes. Attempts to speed this up by using some bulk processing probably causes serious problems, perhaps even more serious than the one you are trying to solve. So what will you do? The proper way is to write and publish a description of the problem first. Here’s a suggestion, which might be somewhat too honest: “Unfortunately, most images on our site lack textual alternatives (alt attributes). This makes much of the content difficult to access or inaccessible to people who cannot see the images. We apologize for the situation. We are in the process of adding textual alternatives, and we expect this to be completed by April 1, 2009.”

Technologically oriented people are often inclined into looking for solutions rather than workarounds or explanations. Yet, when serious problems are detected on web pages (in accessibility or otherwise, e.g. in correctness of information), the first question should be: how do we minimize the damage? This typically means that you immediately add a note that mentions the problem and perhaps suggests a workaround, then start working on a solution. It may take a long time before a solution has been found and implemented.

Think about users and how to help them immediately, before considering how to solve the problem.

How the rules help disabled people

Following the twelve simple rules, you make pages more accessible to many people. This includes the following:

  1. Simple language helps people with cognitive disabilities or with dyslexia (difficulty of reading). It is also very important to people who do not know the language of the page well, e.g. because they are immigrants who are just learning it.
  2. Descriptive link texts also help people with cognitive disabilities. For example, difficulties in short-time memory make it essential that links are easy to understand and to distinguish from each other. Moreover, people with visual disabilities often use speech browsers in “link reading” mode to get an idea of what links there are.
  3. Alt texts are essential to all non-visual browsing (speech browsers and Braille browsers). They may also help people who can see images but have problems in understanding their meaning.
  4. Explaining content images, too, is crucial to people with visual disabilities.
  5. Avoiding auto-start helps people who easily get disoriented by moving content. Moreover, it helps to avoid conflicts with special software that disabled people may use. If you are using a speech synthesizer for browsing, you do not want any background music to start automatically.
  6. Text transcriptions of audio clips help people who cannot hear well enough or have difficulties in understanding the language as spoken. Text descriptions of video clips can be used to generate a speech presentation to people who cannot see well enough. They also help people who have difficulties in understanding speech, gestures, etc.
  7. Alternatives to forms help people who find it difficult to fill out forms e.g. due to motoric disabilities or lack of understanding of how forms work. For example, many people have great difficulties in presenting their question or feedback in writing but could easily present it by phone.
  8. Avoiding “PDF only” or “Word only” formats mean that the accessibility problems in these formats are avoided. Despite progress in improving their accessibility and despite software vendors’ claims, this is still a very important issue. When a user follows a link to a PDF file, there will usually be a delay, a possibility of software crash, disturbing messages about data format mismatch, etc., and the user interface of a PDF viewer (such as Acrobat Reader) is different from that of a browser. These are often just an inconvenience, but to people with disabilities, they may create serious barriers.
  9. Linearizability is essential in non-visual presentation. Visual presentation may also need to be linearized, e.g. in text-only browsers and graphic browsers working on a very small screen.
  10. A sufficiently large font size and the possibility of changing the font size easily are essential to people with reduced eyesight. People with considerable visual impairment are not affected, since they use non-visual browsing or a visual browser that uses a sufficiently large font size, irrespectively of settings on the page. But people with less serious problems will keep trying to read texts despite the difficulties. Thus, this problem is relevant to a very large group people. When a page sets font size to very small, e.g. to 9 pixels, the problem may affect the majority of users.
  11. Reasonable and adjustable width helps people with some eyesight problems (narrow scope of vision) and people using special devices to access web pages. It also makes it easier (often much easier) to get a good-quality printed copy of the page, and to many people, printed documents are easier to read than on-screen reading. Moreover, many people have cognitive problems when they have to work with a “wide scope.” They can physically see a wide area but they mentally get lost in the wilderness when trying to understand its structure and content.
  12. Explaining the inaccessibilities helps people to avoid frustration. When people know about the problems, they can try to find methods of overcoming the limitations (e.g., using a different browser or asking for someone’s help). They can also make rational choices between sites, e.g. between an accessible site and a more content-rich but less accessible site about the same topic. Besides, if you can make and keep promises about fixing the problems, the offence will be reduced and people will know that they can return to the site later.

Limitations of the rules

The twelve rules discussed here are a useful starting point. They demonstrate what work with accessibility means, and they deal with relevant problems and solutions. They are also useful in continued practice, should you decide to stick to such basic issues for the time being. It is not a bad idea to do so for some months before starting to study advanced accessibility. That way, you will have some routine with the basics, and you will probably have noticed some accessibility issues that are not covered by the rules.

Among other things, the rules do not discuss the following topics:

As you probably guess from this rather incomplete list, there is much more to be learned in accessibility. After learning more about accessibility, you might write your own additions or extensions to the twelve rules, or a different set of basic rules for yourself or your organization. On many sites, some additional rules might well be more important than the twelve rules.

Demonstration: an analysis of a page

We will here apply the rules to the FAQ (answers to Frequently Asked Questions) about a chemical compound, by the World Health Organization (WHO). Of course, by the time you read this, the page might be quite different; for your reference, I have created a a copy of the WHO page as analyzed here.

The analysis here will consider both specific issues on this very page and the general design of WHO pages reflected in it.

The page URL is We mention this because URLs are an accessibility issue, too. Although a URL is technically just a string that acts as an address of a resource, it will often be seen by users and perhaps copied, sometimes even by hand. Thus, it should be fairly understandable and short. In this case, the part /foodsafety/publications/chem in the path reflects the site’s technical organization, instead of the page content and purpose.

The page appearance, on Internet Explorer 7 (IE 7) in full screen mode, is the following:

(Image: screen shot of the page discussed)

Rule 1: Simple language

The external title (not shown in the image) is “WHO | Frequently asked questions - acrylamide in food”. This is not bad, but it is not optimal either. It would be more understandable if the most important word were placed at the start, e.g. “Acrylamide in food FAQ (answers to Frequently Asked Questions), by WHO”. The abbreviation “WHO” would remain unexplained, but for various practical reasons, the external title should be short, normally less than 60 characters. However, it might be a good idea to append the explanation “(World Health Organization).”

On similar grounds, the main heading would be better formulated e.g. as “Acrylamide in food,” with a subheading (in smaller font) like “Answers to Frequently Asked Questions (FAQ)”. This would remove the problem that the page uses the abbreviation “FAQ” with no explicit expansion. Many people know what FAQs are, but surely not all.

The word “acrylamide” is of course a difficult one, but it cannot be avoided, since the page is about acrylamide. It is important that it will be explained very early on the page. (Explaining it in the heading is probably not practical.)

The structure of the FAQ is not quite obvious from the page, but it consists of four pages, each containing a few questions in one category. Obviously, the category headings are important texts, even though only one of them appears as a heading and others are just links. They are fairly simple and easy language:

If you wanted to know about acrylamide, you could probably find the right category for your question easily. However, “Questions related to cancer” is somewhat abstract; “Cancer risks” would be more direct.

The specific questions appear in heading-like manner, and they are of course important due to their role. The first of them are rather simple, but then things get confusing:

  1. What is acrylamide?
  2. What is the problem?
  3. How/why does acrylamide form when food is cooked at high temperatures?
  4. What can be done to avoid acrylamide in food? Should I stop eating starchy foods including potato chips/potato crisps?
  5. Are home-cooked foods safer than pre-cooked, packaged or processed foods?

This is rather typical: when writing headings, you start well and concisely, but then they get too verbose and either too vague or too specific. Besides, the last heading is a question that is not answered in the text after it! (“Elevated levels of acrylamide have been found in home cooked foods, as well as pre-cooked, packaged and processed foods.”) The second heading is too abstract, and this may cause problems to people who have forgotten the context. In general, a heading that is understandable in any context is better than one that relies on contextual information. The third heading is too abstract: “cooking at high temperatures” means different things to different people, and what is meant here is really frying and comparable methods.

A better set of headings would be the following:

  1. What is acrylamide?
  2. Why is acrylamide a health problem?
  3. How is acrylamide formed when food is cooked?
  4. How can I avoid acrylamide in food?
  5. Do home-cooked foods contain acrylamide?

The page does not contain any general introductory or summary paragraph. Maybe it should. Anyway, we can still classify the first paragraph as very important, since it starts the answer to a question about the central term. The paragraph contains relatively simple text, with short sentences and not many difficult words (beyond necessity):

“Acrylamide is a chemical that is used to make polyacrylamide materials. Polyacrylamide is used in the treatment of drinking-water and waste water where it is used to remove particles and other impurities (see Question 15). It is also used to make glues, paper and cosmetics. Polyacrylamide materials contain very small amounts of acrylamide.”

Yet, is this relevant to understanding the topic of the page—acrylamide as a health problem? The paragraph looks like a part of a lecture in chemistry rather than a simple description for simple people. A better description might be: “Acrylamide is a chemical that causes health problems such as cancer risks. It appears in small amounts in our environment, including fried food and tap water.”

Rule 2: Descriptive link texts

Let us first consider the link to the main page of the site, since it is navigational too, though isolated. As so often, the organization symbol and logo appear in the upper left corner and it links to the main page. This is quite normal and acceptable. The symbol and the logo are represented as an image, with the text “World Health Organization,” which is simple and understandable. Yet, the textual alternative to the logo, and hence the alternative link text, is “WHO home.” It contains the abbreviation only; “World Health Organization (WHO) main page” would be better.

The navigational links on the page comprise several groups:

  1. Language links at the top of the page. Each link is a language name in the language itself, which is a good approach in many ways, yet alienating to people who do not even know the characters.
  2. The main navigation on the left, with links pointing to major parts of the WHO site: About WHO, Countries, Health topics, Publications, Research tools, WHO sites. These links are not very explicit in their meaning, but reasonably understandable except for the last one, which actually points to a site index! The problem here is that the WHO does not present itself as a single web site but as a collection of sites. This inevitably causes confusion.
  3. Second-level navigation on the left, below the main navigation, with subtopics of “Food safety” under it. The links there are partly rather enigmatic; most people don’t know words like “Zoonoses,” and “Capacity building” doesn’t say what is really being built.
  4. The menu “About | Contact us | Publications | Related links” under “Food safety.” On a closer look, it turns out to be a navigation menu for the food safety activity of WHO. This gets rather confusing, and there is even the link “Publications” with the same link text as another navigational link on the page, pointing to a different page.
  5. The “breadcrumb” links “WHO > WHO sites > Food safety > Publications related to food safety > Chemical risks publications.” This mostly duplicates links elsewhere on the page, but the links themselves are understandable, with the exception of “WHO sites.”
  6. “Acrylamide FAQ’s” links on the right and their duplication near the bottom of the page: “Frequently asked questions - acrylamide in food: 1,2,3,4 | Questions related to cancer.” The numbers are surely not very explanatory as links, and thus the duplication is potentially confusing.
  7. The contextual links at the bottom:
    “Employment | Other UN Sites | Search | Suggestions | RSS | Privacy
    World Health Organization 2006. All rights reserved”
    As such, these links are relatively understandable, though the last, long link text would be more understandable if rewritten as “Copyright statement.” The link “RSS” uses a technical abbreviation, so it is probably not understandable to people who don’t know the technology; “Newsfeed as RSS” would at least tell what it is about. Also note that “UN,” though a common abbreviation, is not known by everyone; “United Nations” would be clearer.

Thus, each of the seven sets of navigational links contains a rather small set of mostly understandable and simple link texts. As a whole, this is far too much navigation and causes confusion, even at the link text level. Hence, improving the link texts would be closely coupled with the issue of reducing the amount of navigational links.

Rule 3: Alt texts

The page contains a large number of images, mostly with adequate or tolerable alt texts:

Checking all those alt attributes is somewhat awkward. The extensive use of layout images makes it harder to find other images and check their alt attributes. The page would benefit from using a more modern approach to visual formatting, style sheets (CSS).

Rule 4: Explain content images

The page does not contain content images that need explanations. Adequate short alternate texts can be written for all images.

It is a rather common mistake to treat logos as content images. Someone might think that the WHO symbol in the upper left corner is essentially graphic, and it indeed is. Yet, there is normally no need to explain it to a person who does not see it. You might write an explanation of it for people who do see it, but this is hardly an accessibility issue. Such an explanation would best be included into a page that specifically discusses the WHO symbol (e.g., its origin, proper use, etc.).

Rule 5: Avoid auto-start

This rule is not relevant here. The page has no animations and no sounds.

Rule 6: Text transcriptions

This rule is not relevant here. There are no video or audio clips embedded or linked to the page.

Rule 7: Alternatives to forms

The page contains only one form, a site search form. Such a form normally does not need a particular alternative, but it should be accompanied with a link to help on the form and to contact information. There is no such link here. There is a link named “Search” but it is among the last set of navigational links and rather unnoticeable. Moreover, the link actually points to the “Advanced search” page. That page contains the link “Advanced search tips,” but it points to a page on the Google site; the search apparently uses Google technology. Thus, there is really no answer to a potential user’s question what to do if he fails in trying to use the search form.

Rule 8: No “PDF only” or “Word only” content

The page contains one link to a non-HTML document, namely “Full text in English [pdf 25kb].” It is not PDF-only content, since it duplicates the basic content of the HTML document. Therefore, it is not a problem as far as rule 8 is concerned. The link text is somewhat questionable, though, in the light of rule 2. The words “full text” might be read as suggesting that the linked resource is more comprehensive than the present page. The wording “All the FAQ answers as one PDF document (25 kB)” might be better, since that’s what the document really is.

Rule 9: Linearizability

If we test the page using the Yellowpipe Lynx viewer, we get a rendering that starts as follows:

Language options

   [1]Arabic [2]Chinese English [3]French [4]Russian [5]Spanish 
   [6]WHO home 
   ____________________ Search
   (_) All WHO (_) This site only

   [8]About WHO
   [10]Health topics
   [12]Research tools
   [13]WHO sites
   [14]Food Safety
   [16]Microbiological risks
   [17]Chemical risks
   [18]Biotechnology (GM foods)
   [19]Food standards (Codex Alimentarius)
   [20]Foodborne disease
   [21]Food production to consumption
   [22]Capacity building
   [23]Consumer education
     Food safety
     [24]About | [25]Contact us | [26]Publications | [27]Related links
     [28]WHO > [29]WHO sites > [30]Food safety > [31]Publications related
   to food safety > [32]Chemical risks publications
   [33]printable version

   Frequently asked questions - acrylamide in food

The numbers in brackets indicate links. Note that the links appear as a more chaotic collection than in the graphic rendering, since the visual formatting is lost.

We have reproduced the lengthy start to illustrate what many people have to go through every time they access a page of this site. When using a speech browser, they need to listen to this over and over again, unless there is some tool for skipping it.

Thus, there is a lot of repetitive content (navigation shared by other pages of the site) before the content proper, and no link for skipping it. This would be easy to fix by adding a skip navigation link. It should skip to the text “Frequently asked questions…” (or a reformulation of it).

The order inside the form is not quite optimal. When you use the tab key, you first enter the text input field, then the submit button, then the radio buttons. Therefore, if you wish to affect the search mode, you need to move to the radio buttons past the submit button, then backwards. This is mostly just a minor inconvenience, but it could be avoided by using a different form design.

In other respects, the page linearizes well. (It actually uses fairly complicated layout tables, but they do not affect the linearized browsing experience.)

Rule 10: Font size

Accessing the page, we can see that copy text appears in a font size considerably smaller than the expected 16 pixels. It is not necessary for the analysis to know the exact size, but it is 11 pixels. (This can be seen by looking at the page’s HTML source code, finding the reference to the style sheet, and viewing the style sheet.) This typically corresponds to about 8 points. Compare this with the fact that on paper, 10–12 points is often cited as required for good legibility. On screen, legibility is generally worse than on paper, since the screen has much lower resolution and stability

Almost all text on the page remains in the small font size even if the user sets the browser’s basic font size via the View > Text size. Thus, the font size issue is serious.

The font that the page’s style sheet suggests is Verdana. It is relatively readable even in small font sizes, so this somewhat alleviates the problem. However, in browsing situations where Verdana is not available, the problem becomes worse.

Rule 11: Reasonable width

Trying to view the page in a window that has half the width of a common 1280 pixels wide screen, we can see that the ends of text lines are cut off. They can be viewed by using horizontal scrolling, or by making the window somewhat wider. In a closer study, we can see that the window width needs to be almost 750 pixels to prevent horizontal scrolling.

This is not very accessible, but neither is it a particularly bad feature. There are web pages which much less reasonable width requirements. Changing this feature would probably require a major change to the page structure, which probably reflects the overall structure of the pages of the site. The width requirements stem from the use of a rather complicated layout table with many width attributes.

The page contains a link to “printable version.” In fact, this version is a “free-width” version except for the logo, which is (quite unnecessarily) 759 pixels wide! The version lacks most of the site navigation and most of the specific layout, so it could be more appropriately named “page content without navigation,” perhaps with the appended note “(suitable for printing)”.

Rule 12: Honest about inaccessibility

There are some serious accessibility problems on the page, though as a whole, it could be characterized as a typical page with no catastrophic inaccessibily. The problems, such as too small and fixed font size, should be fixed rather than explained. If they are not fixed, explanations would not help much. Thus, there is no special need for an “inaccessibility statement.”


If possible, work with an existing page that you have created or that you have worked with, and apply each of the rules to it. For each rule, process the page systematically by considering all elements for which the rule might be relevant. This will be easier and more thorough than trying to apply all rules in a single pass through the page.

Use a content page rather than a main page or an index page. Main pages are very important, but they have special issues of their own.

Alternatively, you may take just any web page and apply the rules to it, after making a copy of it. This is not very motivating, however, since you know that the results of your work will probably not be utilized in any way.

Keep a copy of the original page and the modified page. After the testing you normally do before publishing a new version of a page, upload the modified page. However, refrain from doing this if the modifications have made the page structure different from the general structure of your pages. Essential changes to things like navigational menus should of course be made for all pages at a time.

During the exercise, write down a very short description of the changes that you have made. For example, for rule (3), the description might read “added 4 empty alt attributes and 1 nonempty, for the site logo”. For rule (10), the description might be “changed font size from 10pt to 90%.” These notes will help you later when you work with the same sample page, performing additional accessibility improvements.

If you have friend who is also learning accessibility, it is a very good idea to cooperate by evaluating each other’s pages and exercises. This is particularly relevant to the difficult rules, marked with “**” or “***” in the presentation of the rules. Someone else’s evaluation of the simplicity of your language or the adequacy of your link texts often deviates a lot from your own evaluation. You will probably get some good ideas on improving your texts and page organization.

Work on accessibility should mainly consist of more accessible design of new or completely rewritten pages. It is generally not productive to do “accessibility repairs” of existing pages, but repairs are useful for learning the principles and methods. In daily work, the twelve simple rules are most useful as a checklist during design, implementation, and testing.