Making accessible pages

Navigation

Skip navigation.

Site search

Site navigation

Article links

Introduction

Most of us take it for granted that when we look at a page, we will be able to work out where the various sections start and finish by their position on the page. We assume that we will be able to identify section headings by the obvious fonts that are used. We assume that because of the way they are laid out that we will be able to identify a list of links as a list of links because of the dot or | between them, or because of the colours that are used. We assume that because we can see that the link we just clicked opened a new window, that everyone else can see that it was a new window.

What many of us forget is that we are not the only people in this world. Not everyone is able to see positions. Not everyone can identify colours. And not everyone can see different fonts, or bold text, or the | separator. For blind/visually impaired, or disabled users, they can use Braille or speech readers, but pages lose these visual effects, and they are left with just the sentences. Most speech or Braille readers can identify the differences between headers and lists, but all too often, people abuse HTML elements and use them for the wrong purpose.

CSS is a very powerful styling language, and it allows us to transform virtually any element so that it looks like any other element. So if you want to apply a pretty visual effect, it is far better to make your page work properly as a page without any styles, then apply the styles to make it look like it should. When a Braille or speech reader comes across the page, it will be able to see the page behind the CSS, and if your structure is good enough, it should be able to convey meaning in a non-visual environment. You can still style your page to suit your branding or taste, and people who are able to use a visual browsing environment will be able to see it as you want.

Also important is that search engines are fairly simplistic. They can read no more than a blind visitor. If your page is not accessible to blind users, then it is also inaccessible to search engines like Google. Without search engines, your site will not be indexed, no-one will find it, and you might as well have not created it in the first place.

New on the spoken interface field is Opera 7.6+ for Windows. Unlike the releases for other platforms, the Windows 2000/XP release is able to receive spoken commands and read normal web pages. But what makes it unique is that not only can it interact with VoiceXML pages, but it can also understand speech and aural CSS.

Unfortunately, because of this different focus, Opera does not immediately make use of the structure of HTML pages, but because of Opera's high level of CSS support, you can use CSS to allow it to make use of them. Since I am sure you probably don't want to have to go to all that work yourself, I have done all the work for you. This page is fitted with my speech enabled 'Spoken Page' stylesheet. Feel free to download it and use it on your own pages or as a user stylesheet, subject to my usual terms of use. Opera 7.6+ users, you can enable it right now using View - Style - Spoken Page.

Title

Sounds simple enough. Each page can have a title that helps to quickly identify what the contents of the page are. For people who are unable to quickly look over the page, it helps them to tell if they want to read the rest of the page. Yet surprisingly many people do not include it on their pages. Many who do simply include it because they see it used on the title-bar of the window, and they think that is cool. Title is not a decoration. It is there for a reason. Blind/visually impaired or disabled users, and even search engines use it to help make sense of the page, and it should always be included.

<title>Making accessible pages</title>

Lists

So many things should fit into the lists category. A list of links. A list of important points. A list of events. A list of products. A list of word meanings. A list of anything. As soon as you say the word 'list', chances are that you should be using a list.

HTML actually offers 3 different types of lists. A simple bullet point list, a numbered list and a definition list. Yet far too often, people make pages that use paragraphs, div elements, tables, or anything except a list, then position it all so that it appears to be a list.

This is simply ridiculous. Once the visual environment is unavailable, this pseudo-structure loses all meaning. CSS offers many ways to modify lists so that they can be aesthetically pleasing. Instead of making something else look like a list, why not make a list look like a list?

Yes, even the ever popular dropdown and collapsible menus can be done with netsted lists. After all, that is effectively what a menu is. It is a series of nested lists, subsectioned lists. If left in a list format, Scripts or CSS can easily be used to provide a visual effect, while leaving the list fully accessible to blind/visually impaired or disabled visitors, and the search engines. Google even has a special define: feature that works based on definition lists.

Unordered bullet lists

<ul>
  <li>Item 1</li>
  <li>Item 2
    <ul>
      <li>Item 2.1</li>
      <li>Item 2.2</li>
      <li>Item 2.3</li>
    </ul>
  </li>
  <li>Item 3</li>
</ul>

Styled lists

.bestyled {
  background-color: #257;
  width: 150px; }
.bestyled li {
  padding: 2px;
  margin-bottom: 2px;
  background-color: #bbd; }
.bestyled li li {
  background-color: #eef; }
.bestyled, .bestyled * {
  list-style-type: none;
  margin: 0px; padding: 0px; }
.bestyled {
  padding: 2px 2px 1px 2px; }
.bestyled ul {
  margin: 0px 0px 0px 10px; }

Ordered lists

<ol>
  <li>Item 1</li>
  <li>Item 2
    <ol>
      <li>Item 2.1</li>
      <li>Item 2.2</li>
      <li>Item 2.3</li>
    </ol>
  </li>
  <li>Item 3</li>
</ol>
  1. Item 1
  2. Item 2
    1. Item 2.1
    2. Item 2.2
    3. Item 2.3
  3. Item 3

Definition lists

<dl>
  <dt>Term 1</dt>
  <dd>Definition of term 1</dd>
  <dt>Term 2</dt>
  <dd>Definition of term 2</dd>
</dl>
Term 1
Definition of term 1
Term 2
Definition of term 2

Headings

Well structured headings. No, I am not going to demand that you use <h1> as the first tag on your page (although that is useful, not just for your users, but also for search engines that use this as a main search term). What I am saying is that if you properly break up the sections of your page, and separate them with an apropriate headed sections, it will help people who cannot immediately see the section to work out that it is a separate section.

CSS can hide this from visual user environments later. But the simple act of adding in a heading will allow non-visual based users to work out where the breaks are between the sections.

<h2>Lists</h2>

Links to bypass sections

With visual based browsing, it is usually easy to identify a non-important section, such as a long list of links. In these cases, it is usual to ignore the links and start reading the actual content of the page. With Braille/speech readers, there is no easy way to tell how long the non-important information is. To make it easier, either put non-important information last in the page source (you can position it later with CSS) or put a link to the main content at the top of the non-important content. If you put the non-important information last, it also helps to include a link to that section at the start of the main content.

<li><a href="#mainpart">Skip navigation</a></li>
<li><a href="somewhereElse.html">Some other link</a></li>
...
<h2 id="mainpart">Main Content</h2>

Page head link tags

For virtually every site, these provide an easy and acessible way to navigate the site. Good browsers will provide the users with a toolbar that shows all of these links. There are a standard set of links you can use that gives the user immediate access to any of; home page, index page, contents page, search page, glossary page, help page, first page (in sectioned pages), previous page, next page, last page, up a directory, copyright statement, author information page and newsfeed subscription.

For people who are not immediately able to see these links on your page, these provide an extremely easy way to find the link they are looking for. It is an easy way to help people and search engines make more sense of an otherwise complex page or site layout. See the webcoder page for a full list.

<link href="search.html" rel="Search">

Alternative text

Many elements specifically target the visual medium. Images are the obvious one, but others are video or animated plugins, applets, image maps and frames or iframes.

With images and image maps, and the areas that an image map uses, the alt attribute allows you to specify alternative text that can be used in a non visual environment, or if images are disabled. This attribute must always be specified, but with images it should be left blank unless the image actually represents some textual data (so spacer images [urgh] and decorative images should have an empty alt attribute specified).

<a href="next.html"><img src="nextSection.gif" alt="Continue to next section"></a>

Continue to next section

All too often I see menus made using Java or Flash with no consideration for the side effects this has. It is virtually impossible for either a blind/disabled user or a search engine to get past this. But the object tag allows us to put alternate text between its opening and closing tags that can be displayed if the browser does not understand the plugin or if the user has disabled it. A simple link to a sitemap page would suffice.

The same goes for the iframe tag (although search engines can usually get past these). Even the humble frameset offers an easy way to do this, using the <noframes> tag. And it is used. Badly. Usually with the words "Sorry, but you need to support frames to use this site". That is not an apology. That is an insult. It takes almost no effort at all to change this to a link to an index or sitemap page. Use it properly!

Although not the same thing, I will also mention background images. Not everyone can load images, due to slow connections or visual problems, and it is important to make sure that with background images disabled, the text can still be seen against the background colours.

Titles

Pretty much any element can accept the title attribute. This can be used to provide an explaination of the element content or an explaination of what it represents, such as abbreviations or summaries. In visual browsers, this is usually displayed as a tooltip, and in Braille or speech readers, it can be added to the normal content of the page.

In a non visual environment, this can prove incredibly useful, as it can help explain a structure that the visitor may not be familiar with, or may help to give instructions.

<li title="This section is the usual section that people want to visit">

Relative fonts

This is the 'be nice to IE users' section. IE is not the smartest browser in the world, and unlike all the other major browsers, it cannot resize pixel sized fonts. Unfortunately, it is also a very popular browser, used by many people with poor vision.

Old people in particular often need to have larger fonts than others, as they are unable to see clearly. So the fonts need to be resizable so that they can make IE resize them to a size they can see, without you having to serve large fonts to everyone.

p { font-size: 1.1em; }

Use em and strong tags

Most of us are familiar with word processors, and will probably have used the bold, italic or underlined text on numerous occasions. So the usual mistake when making web pages is to do the same thing. Unfortunately, bold, italics and underlined text has no meaning outside of a visual context. There are two tags that are specially designed for this purpose; <strong> and <em>. Using these ensures that your formatting has meaning in both visual and non-visual environments.

The strong tag means loud text (or text spoken with a more powerful voice), and is rendered in virtually all visual browsers as bold. The em tag means emphasised text, and is rendered in virtually all visual browsers as italic. There is no direct equivalent for underline text, but since this is effectively emphasised text, the correct thing to do is to use the em tag and style it to have an underline instead of italic. (Personally I feel this is a failing in the standard, as I believe they should simply specify a non-visual meaning for the underline tag.)

These are not the only examples. Another less common one is <strike> (which may also be written as <s>). In a visual environment, this puts a line through the middle of the text (strike-through), and as a result is often abused to represent text that has been deleted or crossed out. However, this also has no meaning outside of a visual context. What does have meaning is the <del> tag, as it actually means 'deleted text'. Using this tag instead has exactly the same effect in almost all visual based browsers, but actually means something in a non-visual environment as well, allowing a non-visual browser to announce it as deleted text. (A couple of old browsers do not render this as strike-through text, but you can use text-decoration:line-through; to force them to render it correctly, if you feel that you need to support them [you almost certainly don't].)

This is <strong>important</strong>.

Do not use tables for structure

Tables have been long abused. Ever since people realised that you could remove the borders, and make the cells certain sizes, they have used tables to position parts of the page. This practace is severely outdated, and has almost entirely been replaced with CSS positioning and floats, but unfortunately the bad practace continues.

Using tables as structure causes serious accessibility problems, in particular because the table structure changes the order of the contents in the source. Without the visual appearance of the table, it will make no sense at all. Wherever tables are used for structure try to avoid it, and use CSS positioning or floats to produce the arrangements, while leaving the unstyled structure intact and accessible.

That's not the only problem. There are many others relating to bandwidth, restructuring and rebranding. And there is also the problem that tables were actually invented to hold tabular data, and we still need to use them for that. This is such a large and important issue, that I have made a separate page describing how to use them.

Forms

On their own, these are reasonably accessible, since their structure is fairly simple. My stylesheet will attempt to describe these (using a different voice to make it obvious it is a form), but with a few known issues;

  1. Select boxes will not be announced.
  2. Form input values will be spoken twice. This is due to a generated content bug in the current Opera release (7.6P3). It is being worked on, and hopefully will be fixed soon.
  3. If a form input uses :focus :active or :hover pseudo-classes, the form input will not work. Either disable the page stylesheet (you will need to reload the page if you do this after it has loaded) or ensure it does not use these pseudo-classes on form inputs.

Using fieldsets and legends to group associated inputs, and using labels elements to correctly show which input label is associated with each input, will help to emphasise the form structure.

<fieldset>
  <legend>Login:</legend>
  <label for="username">User name</label>
  <input name="username" id="username" value="" type="text">
  <label for="password">Password</label>
  <input name="password" id="password" value="" type="text">
  <input value="Go" type="submit">
</fieldset>

To make truly accessible forms, use VoiceXML to make interactive forms, that can even be filled in using spoken words.

Example form inputs:
Login details

Site search

As soon as your site gets big enough to be called a 'site' and not just a 'page', it is time to add a search engine. This search engine should be easily available, and obvious, and should work in the simplest manner possible.

Site maps are good, but they are not that good. For people who cannot immediately see your site structure, it helps to provide them with a way to bypass the many tiers of structure, and find the information they were looking for. Using any form of Braille or speech reader makes navigating pages very slow, especially as it may not even be obvious where the navigation is. Do all your viewers a favour and provide a search engine, or if nothing else, a Google search using site:yourDomain.com to search your site.

Access keys

These provide a shortcut, allowing the user to press the access key and immediately focus a link, input, label or legend element. Simply include the accesskey attribute with an appropriate key, and the browser can allow the user to press the key to activate the element. Simple as that.

These are particularly useful for complex pages or large sites, especially those without an obvious structure or site layout.

<a href="#mainpart" accesskey="2">Skip navigation</a>

Although there is no standard governing this (or at least, none that I know of), there are a few conventions that are used. I found a nice blog that describes them.

Redirects

Yes, people may come across your site in a variety of ways. Often they find old links to your pages that are no longer relevant since you re-organised, so you add a page there that redirects them to the new one. Sounds simple. But there is a right way and a wrong way to do it. The wrong way is to use a Meta-Refresh tag to load the new URL, or to use script to redirect. These cause serious problems with the back button, because when you click 'Back', you are immediately forwarded again. This causes a serious accessibility problem for people who cannot immediately see what is happening.

Do it the right way. Use a 'Location' HTTP header. That way, the browser changes the history to reflect the change, so clicking 'Back' takes them to the page before the redirect. Much better, and completely seemless to the user. If that is not possible, set a large delay in the Meta-Refresh, so that when they go back, they will have time to realise what has happened, and go back again to the page before.

<?php
header( 'Location: http://new.location.com/new/page.html' ); 
?>

Scripts

A matter so close to my heart. Unlike many people (sorry Moose), I do believe that scripts have a place on the web. What I don't believe is that they should replace standard HTML functionality. Scripts should enhance the behaviour, not replace it.

Creating content with script is almost never the right thing to do. Content should be created with HTML. Script can change the way it interacts, as long as the important end results are still possible without script. Menus are the biggest culprit here. Using a javascript: protocol in a link href is another common accessibility nightmare. If you want a link to open in a new window, and target="_blank" is not enough for you, make a normal link, and use the onclick event to open the href in a new window, then return false to cancel the normal link.

Another common one that most people are unaware of is the use of onclick on elements other than links and buttons. The same effect can be achieved with abuse of onmousedown and onmouseup, or onmouseover and onmouseout. Anything like these that relies on a mouse is going to cause problems in an environment where the user does not have a mouse.

Once again, not only do these cause accessibility issues, they also prevent search engines from indexing. Search engines can't run scripts either.

Now to the nasty one. Overriding user actions. Many users have a set of keyboard shortcuts that they use. These are particularly popular with disabled users, but many other users rely heavily on them for their speed or convenience. Unfortunately, there are many scripts that hijack these keys, and use them for another purpose. So they press their key, and a script decides to do something completely unexpected.

Another similar idea is where scripts prevent the context menu appearing - usually as a pathetic form of copyright protection, but sometimes to provide a pretty context menu, or just to stop the user using back or forward or reload (typically with form based pages). Many users rely on these menus for other purposes, they add items to the menus to make them easier to access. By blocking the menu, you also block their access. Never a good idea, no matter how good your intentions

One major problem I often see is where people force their sites to be in a frameset (often losing track of the page that someone found using a search engine). Frames are a real problem for many disabled users, and forcing them to use one when they cannot use them properly is obviously not a good idea. If you think your page should be viewed within a frameset, don't use script to force it to appear. Offer them a link to load it in a frameset if they want to.

My stylesheet cannot help you here.

Site signature

A fairly new concept, but a very good idea. The majority of sites use the same template for most of their pages. If someone has a particular problem with your template, they can often use a user stylesheet to fix it. However, they would not want to have to enable a special stylesheet for your site, when they might also have to enable another stylesheet for another site etc.

If you use a site signature, they can easily target styles just to your site, but keep the styles in the same stylesheet as the styles for other sites. To use a site signature, simply give your body tag an ID that matches your site's domain name. The convention is to replace all . with a - since the . is not permitted in the id attribute.

This technique is only really applicable if you use the same template (or a similar or related template) for each of the pages where you use the signature.

<body id="www-howtocreate-co-uk">

To summarise ...

Pages are not just viewed in a visual environment. People who are unable to use a visual medium will need a few changes that will allow them to easily make sense of the page. You can use my 'Spoken Page' stylesheet to make it even easier for them to make sense of the page structure. If you are a user who has accessibility problems with pages, you can use my stylesheet as a user stylesheet in Opera 7.6. Enjoy, and let's help keep the web open to people who have different requirements to ourselves.

Links

This site was created by Mark "Tarquin" Wilton-Jones.
Don't click this link unless you want to be banned from our site.