Below are given a brief set of guidelines, to
assist those who wish to ensure that their sites are as widely accessible as
possible. You can also check our pages if you like. This will let you get a
feel for what is involved.

These guidelines aren't for a moment meant to cramp web pages into a
dismal black-and-grey text format with no images. On the contrary, many
attractive web pages exist that conform to these guidelines and are a
pleasure to access when an appropriate browsing situation is available: the
key factor is that the enhancements are handled in such a way as not to
impair access to the information from other web browsing situations.

Since HTML was designed from the start with this principle of "graceful
fallback" in mind, this isn't the complex task that it might seem - more a
matter of exploiting the strengths of the medium, and knowing where its
weaknesses are.

All web pages must be validated to the HTML3.2 DTD, the W3C
Recommendation, widely accepted internationally as the current interworking
specification. Selecting the links provided will take you to
authoritative sources of further information.

Ideally, web pages will use only
standard HTML
constructs; the use of vendor-specific extensions isn't ruled out in
principle, but they can only be tolerated if it can be proven that their
addition does not impair accessibility, i.e they must be proven to "fallback
gracefully" in browsing situations that don't support them. Tags such as FONT cause
particular problems, for example.

All the information should be accessible from a text-mode situation.
Where an image is used for good reason (e.g a clickable network map), there needs to be an
appropriate alternative text-mode means of access to the underlying
information.

The use of TABLE can present particular pitfalls in terms of "graceful
fallback", especially in view of the use of the Lynx browser as a
component of disability access (speaking browser etc.) systems. Although
current versions of Lynx have some awareness of TABLEs, they do not "render"
them in the way envisaged by authors. In the interests of accessibility,
authors should be aware of what happens when TABLEs are used on such
browsers; various hints and tips
are available to ensure usable results for all readers - without
needing to give up these useful techniques for those who can benefit from
them.

Taking into account their deleterious effect on accessibility, the fact
that they are disliked by many users, and the shortcomings of actual browser
implementations, quite apart from the fact that they are not included in
HTML3.2, the use of FRAMEs
is strongly deprecated.

We have prepared an example which shows the use of a 'Client Side Imagemap' and a 'Gracefully Degrading Table'. Note also the
liberal use of links, and how use of the ALT text retains the meaning of the
images, or helps the non-visual browser, where this is felt to be necessary.

In our example, based on a fictional
transport website, we have placed everything in a single web document. In a
real life situation, this information would preferably be split into several
pages, in order to speed loading online. However, in the offline situation,
use of the internal links gives much faster navigation within the page. In
some cases it may be useful to offer this single page version as an
alternative, to be downloaded in a ZIP archive and used offline, such as has
been done with some of the web resources we have linked to.

We have both validated and thoroughly checked these
pages in a number of browsers, including Lynx, Netscape, MSIE, Opera, and on
several different computer platforms. They were also presented to some of
the online utilities such as the 'Web Page Purifier' and 'Bobby'. Some of
these give warning messages about potential problems, which the page design
has taken due account of.

If you would like to test these pages yourself, please use the links
below: