Accessibility is an important part of the development of any new site. Your content should be viewable by your entire audience, and it is a mistake to think that everyone will be using the same technologies and software that you use.

Conformance is mandated by the Commonwealth Disability Discrimination Act (DDA) 1992.

Provision of information and other material through the Web is a service covered by the DDA. Equal access for people with a disability in this area is required by the DDA where it can reasonably be provided.

This requirement applies to any individual or organisation developing a World Wide Web page in Australia, or placing or maintaining a Web page on an Australian server.

This includes pages developed or maintained for purposes relating to employment; education; provision of services including professional services, banking, insurance or financial services, entertainment or recreation, telecommunications services, public transport services, or government services; sale or rental of real estate; sport; activities of voluntary associations; or administration of Commonwealth laws or programs. All these are areas specifically covered by the DDA.

In addition to these specific areas, provision of any other information or other services or facilities through the Internet is in itself a service and as such, discrimination in the provision of this service is covered by the DDA. The DDA applies to services whether provided for payment or not.

From "World Wide Web Access: Disability Discrimination Act Advisory Notes (Version 3.1 May 1999)". Human Rights and Equal Opportunity Commission. http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html.

In the course of developing a new website, or testing an old site, at least some representative pages should be evaluated for conformance to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines Version 1.0 (WCAG 1.0).

Creating accessible sites

Rather than repairing pages, it is a much better proposition to create accessible content in the first place.

For this, I use Macromedia's Dreamweaver (http://www.macromedia.com/dreamweaver). I use this editor primarily because of the ability to enhance the application through the use of "Extensions".

"508 Accessibility Suite", "Check Page for Accessibility", "Insert HTML Doctypes", and "Accessible Image Object" are just some of the extensions I use as part of my day to day development work. These extensions are all available through Macromedia's Dreamweaver Exchange (http://www.macromedia.com/exchange/dreamweaver).

By using web creation tools that generate accessible content, and incorporating regular accessibility testing into your workflow you will become much more familiar with the guidelines and will develop styles and techniques that adhere to them.

Testing for conformance should take place while the site is being developed. Ideally, the pages that will be used as templates for the rest of the site should be tested and made to conform to the desired level before any other pages are created.

Multimedia Tools

Audio and Video can also be made much more accessible, through the use of SMIL (Synchronized Multimedia Integration Language) or SAMI (Synchronized Accessible Media Interchange).

SMIL is a World Wide Web Consortium markup language for authoring accessible multimedia presentations that integrate streaming audio and video with images, text, or any other media type. SMIL is commonly used for delivering captioned text and/or audio description, synchronized with an accompanying video file. Current versions of the Quicktime Player and the Real Player, as well as some other applications, support SMIL.

SAMI is similar to SMIL, but was developed by Microsoft and is supported by Microsoft products.

Creating SMIL and SAMI

You can create SMIL and SAMI presentations using a simple text-editor, but tools like Magpie, from the National Center on Accessible Media (http://ncam.wgbh.org/webaccess/magpie/), can help automate the process and can produce SMIL and SAMI output.

See http://www.webaim.org/howto/captions/real/real for a quick introduction to creating SMIL captioning and http://service.real.com/help/library/guides/production8/htmfiles/smilref.htm for a more detailed reference.


Testing for Conformance

Choosing a conformance level for the evaluation

There are 3 conformance levels available within WCAG 1.0:

  • Conformance Level A: all Priority 1 (mandatory) checkpoints are satisfied;
  • Conformance Level Double-A: all Priority 1 and 2 checkpoints are satisfied. These additional checkpoints should be satisfied in order to remove significant access barriers for one or more groups; and
  • Conformance Level Triple-A: all Priority 1, 2, and 3 checkpoints are satisfied. These additional checkpoints will make it easier for some groups to access web content.

Ideally, the selected pages should be assessed for conformance to WCAG 1.0 Conformance Level Triple-A.

In order to obtain a representative evaluation of the new website, representative pages should be selected from various sections of the site. The intention is to ensure that a good sample of the technologies used in the site, and pages that represented the "look and feel" of the site, are assessed for conformance.

Evaluation Process

There is no single tool available that will adequately cover all aspects of accessibility testing.

Many of the conformance goals within WCAG 1.0 cannot be assessed automatically, and will rely on the informed judgement of the assessor.

Expertise in using the testing applications is very important, and if your budget can afford it, you should consider employing users of specific adaptive technologies to test your pages.

The process listed below is how I test pages for conformance. There are many other tools available and this should not be considered anything more than a description of my apporach, using the tools I have at hand.

All pages should be tested using a combination of automated, semi-automated and manual processes.

Automated and semi-automated processes

The Syntax of each page should be examined

Pages should be examined for general accessibility issues

 

Manual evaluation

Once the automated and semi-automated checks have been carried out, each page should be subjected to a series of manual checks to determine conformance. This is where familiarity with the guidelines is most important

Each page should be manually checked against all checkpoints from the Checklist of the for Web Content Accessibility Guidelines 1.0. (http://www.w3.org/TR/WCAG10/full-checklist.html).

Browsers and Operating Systems

Examine each page using the a variety of Graphical User Interface (GUI) Browsers and Operating Systems, such as:

  • Internet Explorer Version 6.0 / Windows 98
  • Netscape Communicator 4.72 / Windows 98
  • Internet Explorer 5.0 / Mac OS 9.1

(Consider also testing using a Linux OS, and additional browsers such as Opera, Mozilla, Galeon, Skipstone, and Konqueror).

Pages are checked to determine the following:

  • When images are turned off, is the information presented in an appropriate sequence relative to the visual presentation on the GUI site?
  • When sound is turned off, is audio content is still available through text equivalents?
  • Is the page is still readable when the font size is increased and decreased?
  • Are pages forced into horizontal scrolling when the screen resolution is set to 640 x 480 pixels?
  • Is the colour contrast adequate when displayed in black and white?
  • Is it possible to tab through and access all of the links and form controls on a page, and do the links clearly indicate what they lead to?

Pages should also be checked with scripts and style sheets not loaded to determine if all information is still accessible.

Alternate Access

Each page should be examined using alternate browsers, including tools such as:

Other devices, such as braille readers, should also be used if you have access to appropriately experienced users.

Pages should be checked to determine the following:

  • Is equivalent information available through the voice or text browser as is available through the GUI browser?
  • Is the information presented in a similar logical order as when viewed through the GUI browser?

Reporting

Results on all of the above are collated and added to a report for each page tested, based on the WCAG 1.0 Priority 1, 2 and 3 checkpoints. This can highlight common problems and is an important part of the iterative process of ensuring that your site is accessible.