DEMOS Project - Accessibility Guide: Validation

Validation and Testing

People view websites in a variety of settings:

on different platforms and operating systems,
with different monitor sizes, screen resolutions and colour depths,
in different browsers and browser versions,
using assistive technology from screen readers to braille printers,
on other devices, such as WebTV and Internet enabled phones.

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

on as many platforms and in as many browsers (old and new) as possible.
in a text-only browser or emulator.
in browsers for the blind, screen readers, using magnification software.
without loading images.
with frames, style sheets, JavaScript and applets disabled.
on small displays.
with a variety of input devices (e.g. keyboard rather than mouse).

Test criteria

load time,
structure,
navigation,
visual appearance,
clarity of content,
usability.

A detailed list of test criteria can be found here:
Criteria for Web Site Evaluation: Points to consider when performing a site critique.

User testing

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

encourage feedback.
ask people with disabilities to review the site.
test with expert and novice users.

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 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 || Table of Contents || Next |