[Skip navigation]

DEMOS Project

Online Materials for Staff Disability Awareness
: Techniques

Validation and Testing

People view websites in a variety of settings:

Advanced techniques like JavaScript or CSS Positioning might not work in all browsers or carefully laid out design might display unexpectedly even in different versions of the same browser or on different computers.

For example, the default font size on the Macintosh is smaller than on the PC. One way around this problem is to give users control over the display of fonts by specifying relative rather than absolute font sizes or by not specifying font sizes at all and leaving it to the default settings of the browser.

For these reasons is it important to test websites in as many environments as possible.

Test your website

Test criteria

A detailed list of test criteria can be found here:
Criteria for Web Site Evaluation: Points to consider when performing a site critique. [External link: Open in new browser window]

User testing

It is a good idea to test usability and accessibility with members of the target group.

Log files can also be analysed for information on how people access the site, which browsers or operating systems are used.

Validation of code

The validation of HTML syntax and of style sheets ensures standard compliance, which is an important contributor to accessibility and to a positive user experience. Validation also discovers coding errors, such as wrongly nested tags, missing closing tags, etc.

There are a number of software tools and online checkers available that will validate code and examine pages for accessibility problems. A list of these tools can be found on the resources page.

In order to check a page for code syntax and grammar errors it is necessary to know which version of HTML was used to write the page. Please refer to the information about DOCTYPE to learn more about this.

Checking for accessibility errors

Accessibility has become an important issue. Developers of web authoring software are beginning to include tools to address these issues. Dreamweaver MX, as an example, now includes an accessibility checker. But these tools are not perfect yet and require a good amount of manual checking and correcting.

Bobby [External link: Open in new browser window] is probably the best known accessibility checker but it also has its limitations. Bobby checks a page against the WAI priorities and returns a report listing all possible problems it has found. Bobby cannot declare a page accessible or inaccessible. It clearly states that manual checks are still required. For example, Bobby will recognise that tables are used in the HTML code, but it cannot determine whether they are used for layout or whether they are data tables. It then gives instructions on what to do in either case to make these tables accessible.

[You can find links to Accessibility checkers in the resources section.]

[Previous] | Previous || Table of Contents || Next | [Next]