Introduction

This tutorial is about the overall design of the site and its user interaction. It is not about graphic design.

There is no magic code to making good Web sites. The requirements of each site will vary, and so will the design. However, it is a mistake to think that it is impossible to make a site that is both accessible, and feature rich.

A large number of poor quality Web sites are produced that cause problems. I am not talking about sites that look bad, I am talking about sites that do not let all people view them. Not through password protection, and not through putting the site on a local-only network. I am talking about bad design.

A variety of browsers still exist. Some older browsers are still used. Many people deliberately use browsers with limited capability in order to increase browsing speed and reduce vulnerability to exploits or viruses. Many use browsers on devices with limited capabilities or significant restrictions (such as phones). Some people still use slow modems. Some still use their battered old computers. These badly designed sites prevent access to these people and browsers and in many cases do not have a good reason to do so. Some are even produced by so-called professional companies. See my list of computers and browsers for more details of what people use.

The Internet is sometimes called 'the information superhighway', and as we are told, it is all about communication. Communication of information. 'You can talk to people around the other side of the world'. But sometimes, Web site designers and creators exclude people who may be living next door, simply by failing to acknowledge the flaws in their design.

Simply think of it this way, if you have to put an "upgrade"-to-another-browser or download-plugin button on your page for people to view it, then you have not designed it properly. The solution is not for people to change browsers or modify browsers or download plugins or even enable scripts. The solution is for designers to design their sites properly so any browser can view them.

I have devoted much of my Web development to seeking out the best solution to incorporate downward compatibility into Web sites and, not to my surprise, I found the solution to be simple. You can still use fancy features. You can still make your sites look pretty. Downward compatibility is already built in.

The next few sections tell you how to design sites that everyone will be able to see.

This section was inspired by a fantastic article by Peter Seebach. It is mirrored here, just in case it ever goes offline.

Looking good

This is not about what is or is not a nice looking design. I would never claim to be an expert at that. This is about making sure that your site's functionality remains available, and easy to use, no matter what the vitual limitations of your visitors, or the browsers and devices they use.

Design your sites to work on any sized display

Not everyone uses the latest and greatest displays. My personal favourite resolution is 1280 x 800, but I know many people who use 800 x 600 and above, often because they are unable to see with anything larger. Mobile devices requently have very severe limitations which cannot be changed by the user, and even a good smartphone may still be stuck with 640 x 480. Telling visitors to use something larger will result in them quite rightly telling you where to put your Web site.

Devices and device browsers are becoming much more popular. Browsing on televisions is fairly common, and browsing on mobile phones is growing. The best approach is to have a design that is not restricted to specific widths, so that it remains fluid, and works at any size. If the design is restricted then use CSS media types to provide different layouts for different device types (such as 'tv' and 'handheld'). CSS 3 also offers media queries where you can provide different layouts for different resolutions. They are available in most desktop browsers, and they are available in the most popular browsers for devices, the place where this capability is really needed.

Don't rely browser specific features

Many browsers offer proprietary features (such as Microsoft page transitions - these in particular are annoying as they take time to display pages when it is totally unnecessary). You should never make pages that rely on these features. It is possible to use some features like these as long as you properly detect the capability (not the browser) and only use it if it is available, but in general, if you use these, you will asking to cause problems for your users.

Make your site easy to navigate

Don't overcrowd it with gimmicks or ugly colours, or plaster it with so many distracting adverts that the content becomes difficult to locate or follow. Provide sensible links, and only a few of them. Don't overcrowd your page with 200 links. Provide a search facility if your site is big, and make it an advanced search if your site is very big. Provide a site map just in case they get lost.

Carefully choose colours

Remember that colour blind people cannot see certain colour combinations. Always make sure that with and without images, the colours that text is written in are nothing like the background. Use a light colour for one and a dark colour for the other. Remember that the most common form of colour blindness is red-green indistinction. So colours that to you might look totally different, will to some people look identical. That is why I say to make one light and one dark, because colour blind people should always be able to see that.

For the same reason, never rely on colours to convey information. It is not a problem if you use colours to enhance it, as long as they are not the only way the information is provided.

View your page in a text browser

Try Lynx or Links (or try Opera, and disable the graphical and styling features). You should be able to find your way around without any problems. This is also the equivalent of what blind people would 'see' with text readouts.

When using CSS, ensure that your site remains functional without CSS too, because some browsers, especially browsers for people with visual disabilities, do not support it. Also, make note of the points I make in the section on browser problems in my CSS tutorial.

Include closing tags

Some older browsers will fail to display pages if tags like </table> are missing. Just because your browser copes with it does not mean that everyone else's will. Missing out these tags will make the page unusable in those browsers. You can use the W3C's validator service to check if you have forgotten to close tags.

Be careful with tables

Not all browsers can display tables in a way that is useful to their users. Text based browsers generally do not display them very well, and more importantly, they can be extremely confusing for users with certain disabilities. You should restrict their use to where they are really appropriate, such as displaying tabular data.

If you need more information about using tables, I have written an article about making accessible tables, which may be of use to you.

Make sure pages can be quickly identified

Search engines often display the first few lines of a page in their search results, When users search your pages, they will need to be able to identify which will be useful. With these pages, the main heading appears first, and will give the title for the individual page, so it can be identified. Users who use text or speech readouts will also benefit by being able to quickly identify if the page is useful to them.

Using images

Use sensible alt text

Alt text is the accessible version of an image, and is used by browsers that cannot display images (such as those for users with disabilities). Careful use of alt text is very important, and is fairly easy. See the images section of my HTML tutorial for more details.

Try to limit your use of images

If it takes over 30 seconds to load over a regular modem, you should consider cutting the size down. Mobile devices typically have very slow connections, and in several parts of the World, particularly in rural areas, users are stuck with modem connections. Remember that several small images take longer to load than one big one because they require more open connections.

If you are going to write using images, consider using text instead because text takes far less time to load, even if it doesn't look quite so nice. You can then use various CSS features (including Web fonts) to make the text look the way you wanted, while significantly reducing the bandwidth required. What you can do when making menus from images is use just one image behind every link, and then write the text over the top. That way, they only have to load one background image and a few words of text. CSS makes this easy.

If you insist on using images instead of text, restrict them to logos, and nothing more. Paragraphs and headings are always better as text, since they allow the browser to use its proper text handling and text based navigation, they are more accessible, and they allow proper integration with accessibility software.

If you want to use images so that things will change when you hang the mouse over them, try using the a:hover pseudo-class available with CSS. You can use this along with the background image.

Count your colours

Note that some Internet services limit images to 256 colours (AOL is one example, but some mobile proxies also do this). If your images are needed to convey essential information (hopefully they are not), you should consider using the colours optimised for 256 colour monitors. It is known as the Web optimised or standard palette, and you should find your image editor (if it is any good) will allow you to choose to use the standard palette. Note that an optimised palette is not the same thing.

Choose an appropriate background

If you are using images as a background, make the background colour similar to the colour of the image. The classic example of this is a white background with white text and a dark image as a backing. If you browse without images to increase browsing speed or have a browser that cannot use images as a background, you cannot see the text.

Using framesets

The best recommendation is to avoid using framesets altogether, as they have several severe limitations (such as being difficult or impossible to link to while retaining the correct pages in the frames, or failing to show the frames when located using a search engine). They have been disallowed in the latest versions of HTML, due to the problems that they cause.

If using framesets, always include a <noframes> section, which gives an index page from where no frames are required to view the site. This could quite easily be a site map.

If someone is viewing your site without frames, do not force their browser to use frames with script. They may not want to see the frameset, or may have problems using a frameset interface. If you want to offer them the ability to see the frameset, do just that, offer a link to it, instead of forcing it on them.

If you use the <iframe> element, you should include alternative content between the opening and closing tags. This could be a link. This is because some browsers are not capable of displaying inline frames. Most browsers for the blind or visually impaired cannot view iframes. The worst case I have seen of this was when a site has a search facility as the only means of navigation, and the search facility was held in an iframe. Try never to make this sort of mistake - that is not a good use for iframes

Using script

It is possible to make pages that use scripts extensively, but still remain accessible, and work on the maximum number of browsers. The main rule with scripts is to use them to enhance a page, not to produce content or functionality. If they do produce content, and that content is not available via other means, include <noscript> tags with alternative text or links.

If the script uses features where different browsers have different implementations, don't detect their browser, detect its capabilities and use the appropriate code for their browser. If their browser does not use any of the methods you know, then give them an alternative page, or alternative method of using the content.

When you use scripts, try not to make them unnecessarily large as that adds to the download time. If you are adding a number of MB of scripts to a page, you are probably doing something wrong, and should consider just how much of that script is really needed.

Never use browser specific scripting languages like Microsoft's VBscript. If you can't do it so that it works in every script supporting browser, then you shouldn't be doing it. Use the language they all understand; JavaScript.

If you use script to set the CSS, remember to make the default CSS look good too, just in case their browser does not fall into the categories you define.

If scripts are being used, it can help to use W3C DOM to modify the page after it has loaded instead of dynamically creating content. The page itself can be made accessible, and the script can then add extra interactivity, while leaving the page accessible in less capable browsers.

My JavaScript tutorial has more details.

Using plugins

Generally it is a bad idea to make a page based entirely on plugins such as Flash or Java. Many pages use an entirely Flash interface, with multiple animations (mainly a marketing thing, because they think it's cool). Flash does offer some advantages, since when it is available, it works reliably cross browser. However, Flash has many limitations:

Flash tries very hard to be accessible, but it is never as accessible as a normal HTML page. It cannot integrate well with accessibility software such as speech readers, and it gives no useful information about what is a heading or paragraph. Many Flash sites use scrolling sections of content - these scrolling sections do not hook into the normal scrolling mechanisms of the browser, meaning that they almost always demand the use of a mouse.
Flash sites are almost entirely inaccessible to search engines. They cannot read them, index them, point users at sub pages within them, and not to be blunt about it, but if you never get onto a search engine, you might as well not have written the site at all.
Flash sites rely on Flash (surprise). Not everyone has support for Flash. Some because it is usually used for distracting adverts, some because it is too slow, some because it takes far too much bandwidth to be comfortable on their connection, some because it is not available for the browser (or more often the device) that they are using, and some because they find it to difficult to use (because of disabilities etc.). They will not be able to see the site at all.
Generally it does not cope very well with different display sizes, often scaling to become unreadable, where normal HTML could reformat itself.
Displaying plugins in Internet Explorer requires ActiveX, which is disabled by many users or corporations because of security concerns associated with ActiveX.

If you want to use Flash or other plugins to display parts of your site, I suggest you do just that, use it to display only parts of the site, add decorations only, do not use it to display content or navigation. Leave that up to HTML, that is what it is there for. Try not to be so reliant on identical responses in all browsers, and instead, allow users to use what suits them.

Using it for cartoons, animations or games is ok, but if it is being used as part of a normal page, try not to make it too distracting or it will distract visitors from the main content - the reason they came to the site in the first place.

If you choose to make a splash page using Flash (although I fail to see why splash pages are needed - they serve no purpose except to say "I am not the page you came here to see"), provide a normal link to bypass the splash page.

Keep your flash movie small. In my personal opinion, if you have to display a progress bar to say when it has loaded, then it is too big. If it takes longer than 30 seconds to load on a standard modem, then it is too big.

Wherever you use Flash, or other plugins, make sure that you use the OBJECT tag, and use the TYPE attribute to specify the MIME type (not the classid) so that it works in the maximum number of browsers, then put alternative content inside the OBJECT tag's fallback. This is much more reliable than plugin detection scripts. You can do the same with the APPLET tag for Java. Generally it is a bad idea to use this to demand that they install Flash - you can be quite certain that they will have seen it before and if they do not have it yet, your site is unlikely to persuade them. Note that IE 7- does not display this content even if the plugin is not available. However, IE installs almost always have Flash and Java anyway, and if it is disabled, it is usually as a security precaution.

If you want to make an interactive page, try using JavaScript and DOM. It is able to take a normal accessible page and add interactivity to it, including animations. Generally it also loads faster as well.

If you want to use a streaming (audio/video) plugin, use a generic one. Preferably one that you can use on all operating systems. Flash is by far the most widely supported, and until enough browsers support the video and audio capabilities of HTML 5, it is probably thr best solution. Real Media (Real player format) is also available for most operating systems, but has become extremely unpopular. Do not rely on QuickTime or MS Media Player format. They may or may not be good, but again you are restricting your viewers.

If your site gives people documents in a different format, for example PDF, remember that not everyone can view them and some people cannot download them. They are confusing for disabled users, and deny the user's ability to use their normal browsing controls, as well as making it difficult or impossible to integrate with accessibility software. You should always include HTML alternatives whenever possible - they are using a Web browser, so give them a Web page. Almost no-one cares about printing or if the fonts look perfect - I know that is disheartening to a designer, but it is true. PDF should not be used to force your tastes onto your users.

Using cookies

Not all browsers can accept cookies and in many cases the users do not want to. Some will not accept cookies unless they are using Internet banking or online shopping because they feel that people leaving cookies on their computer and tracking them on the Internet is an invasion of their privacy. If at all possible, your sites should not rely on cookies. For login purposes, there is HTTP authentication, which is more appropriate than cookies in most cases. If you provide online shopping, your site can work without cookies too, by using a session ID that ends up in the URL. If you insist on using cookies, at least give a proper response saying why they cannot view your site.

Note also that European law requires sites to gain explicit permission before using cookies, unless those cookies are essential to the operation of the site (such as a shopping basket).

Try to minimise the number of cookies your site sends. If it tries to send over three, then you should find a different way. If you have cookies on prompt, it can be very annoying to have to accept or reject lots of cookies.

For the same reason, try not to resend cookies that have already been accepted. This is particularly noticeable on sites that use cookies as a session ID. It is usually unnecessary to send a cookie with each page that is viewed. If your cookies are set to expire quickly, say every 10 minutes, consider the following solution. Set the cookie on the first page that is viewed. At the same time, make a note of the time. If the person views any pages in the next 5 minutes, there is no need to resend the cookie. When they view a page after the 5 minutes, resend the cookie and again make a note of the time. Repeat as necessary. This way, the user will only have to accept one cookie every 5 minutes.

Examples

I have compiled a critical review of sites whose design fails to follow the good design points. The review includes mirrors of the sites and so uses protected material. For legal reasons you can only view these if you are a designer and the material is relevant to you.

The following are some examples of some annoying, some technically flawed and some just plain ugly sites. Unless otherwise stated, all of these are mirrors, not the originals.

By clicking the link below, you certify that you are a designer and the material is relevant to you and you will only use the material contained within for educational purposes, and will not reuse the copyright material for commercial gain.

View the examples.

Last modified: 11 May 2011

Site design

Navigation

Site search

Site navigation