Knowledge Base
Website Testing CheckList
Validation
Validate The HTML
The first stage of checking a web-site is to make sure that you have valid HTML (or XHTML). This can be done with a validator such as the W3C validator. Your own browser may ignore certain errors, but there is a significant risk that markup errors will result in display problems in some browser or other.
Validate The CSS
CSS can be validated with for example the W3C CSS validator.
Check For Broken Links
Obviously you do not want broken links on your site. There are various tools available to help find these, such as the Link Valet (which is convenient for checking a few pages) or Xenulink (convenient for checking a whole site).
Flexibility
Vary Window Sizes
A very important aspect of web design is coping with different window sizes. Window widths may vary from about 200 pixels on a web-enabled telephone to 2000+ pixels on a technical workstation in full-screen mode. While providing a readable site to the very smallest screens is something of a challenge, your site should at least be readable on a wide variety of sizes. As of mid 2006, nearly 20% of all readers are still using screens of 800x600 pixels or smaller, and if the reader wishes to compare the contents of your site with another document, it is entirely possible that he may want to use a window-width of around 400 pixels.
Fortunately, at least as far as the text goes, this is not very difficult – just refrain from specifying sizes in pixels or points and you are most of the way.
It is obviously easy to test window-sizes smaller than your own screen-size. Testing larger window-sizes might seem impossible, but you can do a rough simulation using the zoom facility of the Opera browser – zoom down to 50% and you get a screen twice the size. It may not be very readable, but any major layout errors should be obvious.
There is no need to worry too much about the very long lines of text that appear at large screen sizes when small fonts are used. If the reader does not use a large font, he can always reduce the window size to something comfortable – that is, after all, half the point of having windowing user interfaces in the first place. But if you wish to, you can also use the CSS2 'max-width' property to limit column width, just as this page does.
Vary Font Sizes
Some people use large screen fonts because they have a large screen with a very fine resolution; other people have to use large screen fonts because of declining eyesight. On the other hand, some people like to use microscopic fonts with their nose pressed against the screen.
So while doing the above activity, adjust the default text-size in your browser, and check that all the text scales appropriately.
Speed
Check Image Size Specifications
Check that the text of the page appears quickly enough. If it does not it is likely because you have forgotten to specify HEIGHT and WIDTH attributes on images. Specifying these attributes enables the browser to work out where the text needs to go, and to display it before images have finished downloading.
Accessibility
Test Accessibility
This is mainly important for handicapped users, but also relevant for e.g. people who use a text-only browser, or disable images, because of a slow connection. See the W3C Web Content Accessibility Guidelines for further information.
Many aspects of the guidelines require human judgement to say whether a page is accessible or not e.g. whether HTML Heading tags are used correctly. Even when the guidelines are unambiguous, you do not need to follow them slavishly. For example, the absence of a caption on a table is unimportant if the previous paragraph explained what the table is about. Nonetheless it is well worth running a few pages through a checker such as Accessibility Valet in order to familiarise yourself with the issues involved. You can then make the necessary improvements.
View In Text Browser
It is also worth running pages through a text-only browser or text-browser emulator to see what e.g. a blind person using a text-to-speech converter will encounter. It will help you pick up on badly-chosen or missing ALT texts for example. It also shows you the site pretty much as a search engine will see it.
Browser Independence
View on different browsers
Almost all web developers are aware of the need to check how a site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be:
- A Gecko-based browser – Netscape 7 (not 8!), Mozilla or Firefox as these seem to have the best standards compliance
- Internet Explorer – currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7 fixed quite a lot of bugs in 6 but introduced a new set of its own. (Microsoft is however still kicking developers in the teeth by not making it possible to install both versions on the same computer; you will either need two computers or one of the work-arounds available on the net.)
- Opera – growing in popularity due to its speed and pretty good standards compliance.
Check Printed Pages
Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably cannot achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page.
You should also consider using CSS to adjust the appearance of the page when printed. For example you could suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the "@media print" or "@import print" CSS features.
Some sites provide separate "printer friendly" versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and should not be needed.
Switch Off Javascript
There are quite a number of sites which abuse Javascript by e.g. generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off. Some organisations even block the usage of Javascript completely.
It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely on Javascript for navigation, with the result that the lack of Javascript renders the site unusable.
If you need it for essential content that functionality will be lost. But there is no reason why the basic text of the site should be unavailable.
Avoid nearly-meaningless messages like "Javascript needed to view this site". If you have something worth showing, tell the user what it is e.g. "enable Javascript to see animation of solar system".
Switch Off Plug-ins
The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript. Check the site with any plug-ins disabled. The basic text and navigation should still work.
Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a "You need Flash to read this site" message and he will probably go away, never to return.
Switch Off Images
If scanning a number of sites quickly for information, many readers switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This also means checking that ALT texts have been provided for images.
Additional Checks
Check Non-reliance On Mailto
In order to give readers a chance to contact them, web authors often include a link of the form "mailto:abc@xyz.org". However, this does not work for anything like all browser/e-mail client combinations. And people in e.g. an Internet cafe cannot use this type of link. Many readers prefer a form anyway.
Therefore the best thing is to provide a contact page which has both a mailto link and a contact form; the user can then choose which to use.
Check For Orphan Pages
An orphan page is one that contains no links back up to its ancestors i.e. to pages higher in the hierarchy of the site. Once one arrives at an orphan page, the only way to get to the rest of the site is via the "Back" button. Which is fine until people arrive at the page via a search engine, or via a link that someone else gave to them. They cannot then visit the rest of the site. So ensure all pages include a link back up the hierarchy.
Orphan pages are easy to overlook in sites with frames. When a page is accessed directly the other frames are absent.
Check Sensible Page Titles
Check that the page titles (i.e. the contents of the TITLE elements) are sensible. Page titles are important, as e.g. they show up prominently in search engine results, in bookmarks and also on the tabs of multi-tab browsers. Each page of a site should have a unique title.