Introduction

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.

It is depressing to see so many Web sites being produced to such poor quality. 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.

Many older browsers still exist. Many are still used. Also many people deliberately use browsers with limited capability in order to increase browsing speed and reduce vulnerability to exploits or viruses. 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 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 sites functionality reamins 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 1024 x 768, but I know many people who use 800 x 600 and above, often because they are unable to see with anything larger - telling them 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 not well supported in desktop browsers, but they are available in Opera and Safari, two of 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. 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 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 looks good without CSS too, because a lot of 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 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. 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 56k modem (about 1 minute over a 28k modem), you should consider cutting the size down. 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. What you can do when making menus from images is use just one image behind every link and write the text over the top. That way, they only have to load one 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 several mobile proxies also do this). If your images are needed do convey 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. Use it if at all possible. 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

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 browsers such as Netscape 4 and anything older, as well as 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.

Never use browser specific scripting languages like Microsoft's VBscript. If you can't do it so 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 56 K modem (currently about half of the Internet users I know personally still use these), 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 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. The only one that is available for all operating systems is Real Media (Real player format). Not QuickTime or MS Media Player format. They may 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.

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: 4 September 2008

Site design

Navigation

Site search

Site navigation