An Accessibility Audit of WebCT

Dey Alexander [HREF1], Usability Analyst, Information Technology Services [HREF2]
PO Box 28C, Monash University [HREF3], Victoria, 3800. Dey.Alexander@its.monash.edu.au

Abstract

WebCT is a learning management system that provides an integrated environment for online teaching and learning. Many Australian universities are already using WebCT or similar systems, and others are considering doing so in order to meet the growing demand for online course delivery and support.

Decisions on purchasing learning management systems are generally based on a range of criteria including pedagogical issues, flexibility and ease of use, and licensing and running costs, but often without explicitly considering the need for the system to be accessible to disabled students. As a result, universities may be providing materials and resources that students with certain types of disabilities may not be able to access, thereby exposing themselves to the possibility of litigation.

This paper summarises the results of an accessibility audit of WebCT. It outlines a range of accessibility problems that have been identified with the product and suggests strategies to ensure that universities understand and are able to meet their legal obligations.

1. Introduction

WebCT is a learning management system that provides an integrated environment for online teaching and learning. It enables academic staff with basic computer skills to provide and manage web-based learning materials and utilise a range of online communication tools in order to supplement, or as an alternative to, face-to-face teaching.

Many Australian universities have purchased WebCT or systems like it in order to meet the growing demand for online course delivery and support. Decisions about the selection of a learning management system are likely to be made on a range of criteria including pedagogical issues, flexibility and ease of use, and licensing and running costs. The requirement for course delivery systems, or indeed any online information, to be accessible to disabled students is generally poorly understood. At Monash University, for instance, the issue of accessibility was not considered until after WebCT had been purchased, installed, and rolled out for use in the teaching environment.

As a result of this lack of awareness, universities may be providing materials and resources that students with certain types of disabilities may not be able to access. In the eyes of the Australia legal system, this is a discriminatory practice and opens the door to the possibility of litigation.

This paper seeks to do three things. First, it outlines the legal requirements for accessibility for online resources in Australia and then compares them to those in the United States. Given that many vendors of courseware products are either located in the US or have their most significant customer base located there, it is important to recognise that products are likely to be developed to meet US standards which are significantly different to those in Australia. Second, it details an accessibility audit of WebCT and outlines aspects of the system which fail to meet accessibility standards. Finally, it outlines a strategy that universities could adopt to assist in understanding and meeting their legal obligations.

2. Legal Issues

2.1 Web accessibility and Australian law

In Australia, the Disability Discrimination Act 1992 (DDA) [HREF4] makes it unlawful to design web pages that fail to be accessible to the disabled. The relevant provision of the Act is Section 24 which states:

(1) It is unlawful for a person who, whether for payment or not, provides goods or services, or makes facilities available, to discriminate against another person on the ground of the other person's disability or a disability of any of that other person's associates:

(a) by refusing to provide the other person with those goods or services or to make those facilities available to the other person; or

(b) in the terms or conditions on which the first-mentioned person provides the other person with those goods or services or makes those facilities available to the other person; or

(c) in the manner in which the first-mentioned person provides the other person with those goods or services or makes those facilities available to the other person.

(2) This section does not render it unlawful to discriminate against a person on the ground of the person's disability if the provision of the goods or services, or making facilities available, would impose unjustifiable hardship on the person who provides the goods or services or makes the facilities available.

The legislation was tested in the case of Bruce Lindsay Maguire v Sydney Organising Committee for the Olympic Games (SOCOG) [HREF 5]. Bruce Maguire who is blind and uses a speech reader to access online information, made a complaint to the Human Rights and Equal Opportunity Commission (HREOC) that various aspects of the Sydney Olympics web site were inaccessible to him. Attempts to conciliate the issue failed and when the matter proceeded to formal hearing, SOCOG argued that the defence of unjustifiable hardship should apply because "SOCOG would have to retrain many of its staff and redraw its entire development methodology...Such expense would be an unjustifiable financial imposition" [HREF 6]. The defence was unsuccessful and in August 2000 SOCOG was ordered to make the site accessible and pay $20,000 in damages to Maguire.

2.2 Australian standards for accessibility

Australian legislation does not specify standards for accessibility. However, HREOC has issued guidelines under the DDA to assist organisations to avoid discrimination and meet their legal obligations. The guidelines, generally referred to as "Advisory Notes", have no direct legal force. HREOC indicates though, that compliance with the guidelines will make it "far less likely that a Web publisher would be subject to complaints" [HREF 7].

The Web Content Accessibility Guidelines 1.0 (WCAG) [HREF8], developed by the World Wide Web Consortium (W3C) are the guidelines recommended by HREOC. They are a set of internationally developed and recognised standards based on fourteen guidelines or general principles of accessible design. Sixty-five checkpoints are derived from these guidelines, with each being assigned one of three priority levels. [HREF9]

Priority one checkpoints provide the most basic level of accessibility. According to the W3C:

A web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. Web sites that meet all priority one checkpoints can claim compliance level A.

Priority two checkpoints detail requirements for a more desirable level of accessibility. The W3C says:

A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. Web sites that meet all priority two checkpoints can claim compliance level Double-A.

Priority three checkpoints are those that would be met by an organisation attempting to provide the greatest level of accessibility of its online materials. The W3C says of priority three checkpoints:

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. Web sites that meet all priority three checkpoints can claim compliance level Triple-A.

HREOC does not specify which level of compliance should be attained, but the greater the level of compliance, the more likely an organisation is to meet its legal obligations.

2.3 Legislation in the United States relating to web accessibility

A number of other countries now have legislation and/or policies related to web accessibility [HREF10], most notably the United States, where a recent amendment to the Rehabilitation Act—commonly referred to as Section 508—has resulted in many software vendors making changes to their products in order to comply with the legislation.

Section 508 differs significantly from the Australian legislation [HREF11]. It specifies 16 standards for web-based intranet and Internet information and applications. These are:

§ 1194.22 Web-based intranet and internet information and applications.

(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with colour is also available without colour, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with 1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

The authors of the US legislation have interpreted the web-related standards as being consistent with a number of WCAG 1.0 priority one checkpoints (see table below).

Note to §1194.22:

1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:

Section 1194.22 Paragraph WCAG 1.0 Checkpoint
(a) 1.1
(b) 1.4
(c) 2.1
(d) 6.1
(e) 1.2
(f) 9.1
(g) 5.1
(h) 5.2
(i) 12.1
(j) 7.1
(k) 11.4

2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0 1.0. Web pages that conform to WCAG 1.0 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section.

It is important to note that some priority one checkpoints, and most priority two and three checkpoints, are not covered by the Section 508 requirements. Therefore even those vendor products that are entitled to claim compliance with Section 508 may not provide adequate levels of accessibility for use in an Australian context.

While the vendors of WebCT make claims about the product's Section 508 compliance, they do not mention its compliance with the more demanding standards of WCAG 1.0 [HREF12]. There are some promising statements about the company's commitment to accessibility, but they have not yet indicated a timeline for the delivery of accessibility enhancements, what the nature of those enhancements will be, and whether their development strategy will widen to focus on the internationally recognised standards of WCAG.[Note 1] It is clear that in the development of WebCT, as with many other software and web-based systems, accessibility has been an afterthought rather than a consideration in the initial design of the product.[Note 2]

3. Accessibility audit of WebCT

3.1 Audit methodology and scope

An evaluation of WebCT was undertaken in order to assess the level of its compliance with WCAG 1.0 checkpoints, and to see what the practical barriers to access might be for users with disabilities.

While there are standard methods for evaluating usability, web accessibility evaluations are not yet well established.[Note 3] This evaluation was based on a method outlined by the W3C's Web Accessibility Initiative. [HREF13]

The first part of the evaluation involved a WCAG 1.0 conformance evaluation. The requirement to log into the system ruled out the use of some tools that might otherwise have been employed in this type of evaluation.[Note 4] The extensive use of javascript to dynamically build pages excluded the use of other tools.[Note 5] Instead, the evaluation was limited to the following:

To get an understanding of some of the practical barriers to access, limited user testing was also undertaken. Three disabled users participated.

A limited number of WebCT components were tested. These included:

It is important to note that this accessibility evaluation addresses the issues from a student point of view. Accessibility for course designers was not evaluated.

As a result of the limitations of this investigation, there may be further accessibility problems and instances of checkpoint failure than those that have been identified here.

3.2 Audit results

WebCT suffers from a number of accessibility problems and does not meet the requirements necessary for level A compliance with WCAG.

User testing revealed significant barriers to access including:

Screenshot showing the Frames List that JAWS presents to users
Figure 1: Frames List generated by JAWS 4

Screenshot showing the Links List that JAWS presents to users
Figure 2: Links List generated by JAWS 4

3.2.1 WCAG checkpoint failures

Numerous WCAG checkpoint failures were observed at each of the three priority levels. The ability for course designers to create their own HTML pages and add their own multimedia content to WebCT opens up the possibility for even further checkpoint failures to occur. Course designers can allow students to upload home pages and attachments to messages posted in discussion forums. These may also fail accessibility checkpoints.

To summarise, WebCT 3.6.3 fails on six priority one accessibility checkpoints (WebCT 3.7 fails on five), and leaves open the possibility for failures on a total of eleven checkpoints for content created or added by course designers.

WebCT also fails on ten priority two accessibility checkpoints, and leaves open the possibility for failures on twenty-seven checkpoints for content created or added by course designers.

WebCT fails on nine priority three accessibility checkpoints, and leaves open the possibility for failures on sixteen checkpoints for content created or added by course designers.

The table below outlines the audit findings as they relate to checkpoint compliance. The WCAG 1.0 checkpoints are shown in the left column, grouped into the three priority areas. Any observed or potential failures of these are indicated in the right column.

3.2.2 Priority One Checkpoints

Checkpoint Observed or potential failure (s)

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content).

While most images do have a text alternative, those used in the self-test tool to indicate a correct or incorrect answer do not have text alternatives (WebCT V3.6.3 only; corrected in 3.7)

Content added by course designers may fail this checkpoint.

2.1 Ensure that all information conveyed with colour is also available without colour, for example from context or markup.

Content added by course designers may fail this checkpoint.

4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).

Content added by course designers may fail this checkpoint.

6.1 Organise documents so they may be read without style sheets.

Content added by course designers may fail this checkpoint.

6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.

The contents of the main frame change, but the frame title does not.

The default image used as the navigation icon for the discussion group tool changes to indicate when new messages have been posted to discussion groups. The text alternative, however, does not change.

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.

Content added by course designers may fail this checkpoint.

14.1 Use the clearest and simplest language appropriate for a site's content.

Content added by course designers may fail this checkpoint.

1.2 Provide redundant text links for each active region of a server-side image map.

Server-side image maps are not used in WebCT and cannot be introduced by course designers.

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

See above.

5.1 For data tables, identify row and column headers.

Content added by course designers may fail this checkpoint.

5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

Content added by course designers may fail this checkpoint.

12.1 Title each frame to facilitate frame identification and navigation.

WebCT frames are given titles, but as the framesets used to display pages are nested, it is not clear whether the nested frame titles are accessible to all screen readers or make sense to users. For instance, JAWS reads out two frame titles together: "WebCT Course Navigation Frame, WebCT Tool Location Frame"

Frame titles could more meaningfully identify the content of the frame.

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

Logging on to WebCT requires a javascript enabled or capable user agent. No alternative accessible page is provided nor is any error message—the user sees only a blank screen.

Internal WebCT pages are also inaccessible to user agents with javascript turned off or not supported. No equivalent alternative is provided.

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.

Content added by course designers may fail this checkpoint.

1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

Content added by course designers may fail this checkpoint.

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

No link is provided to alternate pages that are accessible.

Course designers may not have the technical skills required to provide accessible alternatives to pages that comprise their content module.

8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

The chat and whiteboard tools utilise java technology that may not be accessible to screen readers. Difficulties were encountered with both JAWS and Home Page Reader.

If these tools are used as primary teaching tools, then this is a priority one checklist failure.

3.2.3 Priority Two Checkpoints

Checkpoint Observed or potential failure(s)

2.2 Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].

Content added by course designers may fail this checkpoint.

3.1 When an appropriate markup language exists, use markup rather than images to convey information.

Images are used as bullet points on the main course options page (accessed immediately after login) where list items would be more appropriate. Images are also used to mark selection options in the self-test tool. Radio buttons should be used instead.

Content added by course designers may fail this checkpoint.

3.2 Create documents that validate to published formal grammars.

WebCT pages do not validate to formal grammars.

Content added by course designers may fail this checkpoint.

3.3 Use style sheets to control layout and presentation.

WebCT uses some stylesheets for presentation and layout, but there is extensive use of HTML attributes for text and table presentation.

Content added by course designers may fail this checkpoint.

3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.

Content added by course designers may fail this checkpoint.

3.5 Use header elements to convey document structure and use them according to specification.

Header elements are not used to convey document structure.

Content added by course designers may fail this checkpoint

3.6 Mark up lists and list items properly.

List items are not always properly marked up. For example: indenting topics and sub-topics in the Content Module is done by means of non-breaking spaces. On the main course selection page (accessed immediately after login), images are used for bullet points.

Content added by course designers may fail this checkpoint.

3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.

Content added by course designers may fail this checkpoint.

6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.

WebCT is not accessible to browsers that are not capable of handling frames. No alternative presentation is provided.

As students proceed through the self-test tool, dynamic content is generated in a frame to indicate whether the student's answer was correct. This may not be accessible to screen readers.

Content added by course designers may fail this checkpoint.

7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).

Content added by course designers may fail this checkpoint.

7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.

Content added by course designers may fail this checkpoint.

7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.

Content added by course designers may fail this checkpoint.

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

Several tools within WebCT cause pop-up windows to open. These include the Quiz, Discussion, Whiteboard and Chat tools.

Content added by course designers may fail this checkpoint.

11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.

WebCT does not use the latest versions of W3C technologies.

Content added by course designers may fail this checkpoint.

11.2 Avoid deprecated features of W3C technologies.

WebCT uses deprecated features of W3C technologies. These include the formatting of text with HTML attributes instead of stylesheets, the use of deprecated HTML tags (e.g. <center>).

Content added by course designers may fail this checkpoint.

12.3 Divide large blocks of information into more manageable groups where natural and appropriate.

Content added by course designers may fail this checkpoint.

13.1 Clearly identify the target of each link.

Content added by course designers may fail this checkpoint.

13.2 Provide metadata to add semantic information to pages and sites.

Content added by course designers may fail this checkpoint.

13.3 Provide information about the general layout of a site.

A site map is provided, but calling it a 'course map' may not be intuitive. It might be mistaken for an overview of the course.

Students using screen readers capable of displaying links alphabetically may go to "S" and therefore miss the site map.

13.4 Use navigation mechanisms in a consistent manner.

Content added by course designers may fail this checkpoint.

5.3 Do not use tables for layout unless the table makes sense when linearised.

Content added by course designers may fail this checkpoint.

5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.

Content added by course designers may fail this checkpoint.

12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.

The relationship between the frames in the quiz tool and in the self-test tool require explanation as the frame titles are insufficient.

Content added by course designers may fail this checkpoint.

10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.

Content added by course designers may fail this checkpoint.

12.4 Associate (form) labels explicitly with their controls.

Content added by course designers may fail this checkpoint.

6.4 For scripts and applets, ensure that event handlers are input device-independent.

Content added by course designers may fail this checkpoint.

7.3 Until user agents allow users to freeze moving content, avoid movement in pages.

Content added by course designers may fail this checkpoint.

9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.

The chat and whiteboard tool interfaces appear to be only partially navigable without a mouse.

9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.

WebCT uses numerous 'onmouseover' events and so technically fails this checkpoint. Further user testing would be required to determine whether this has any real effect on accessibility.

Content added by course designers may fail this checkpoint.

3.2.4 Priority Three Checkpoints

Checkpoint Observed or potential failure (s)

2.2 Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].

The colour contrasts between text and background colour are weak in some places. For example see the course navigation frame and the last item on the breadcrumb navigation bar.

Course designers have the ability to customise the colour settings for the course environment. This may result in a failure to meet this checkpoint.

Content added by course designers may fail this checkpoint.

4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.

Content added by course designers may fail this checkpoint.

4.3 Identify the primary natural language of a document.

WebCT provides no identification of the primary natural language of documents and so fails this checkpoint.

Content added by course designers may fail this checkpoint.

9.4 Create a logical tab order through links, form controls, and objects.

There is no logical tab order created to assist effective use of the keyboard to navigate through links, form controls or objects.

9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.

No keyboard shortcuts are provided by default and there is no provision to facilitate this when course designers add elements to course pages.

10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.

No problems observed.

11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

WebCT fails this checkpoint.

Content added by course designers may fail this checkpoint.

13.5 Provide navigation bars to highlight and give access to the navigation mechanism.

No problems observed.

13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

WebCT provides a 'hide navigation' option, but this only allows for the course navigation frame to be bypassed. The top navigation frame cannot be bypassed.

13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.

Searches can be restricted to specific content areas of a course, but do not cater to skill levels or preferences.

13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

Content added by course designers may fail this checkpoint.

13.9 Provide information about document collections (i.e., documents comprising multiple pages).

Content added by course designers may fail this checkpoint.

13.10 Provide a means to skip over multi-line ASCII art.

Content added by course designers may fail this checkpoint.

14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.

Content added by course designers may fail this checkpoint.

14.3 Create a style of presentation that is consistent across pages.

Content added by course designers may fail this checkpoint.

1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.

Content added by course designers may fail this checkpoint.

5.5 Provide summaries for tables.

No table summaries are provided.

Content added by course designers may fail this checkpoint.

5.6 Provide abbreviations for header labels.

No abbreviations for header labels are provided, but no long labels that may require them were observed.

Content added by course designers may fail this checkpoint.

10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.

The table layout on the course selection/bookmarks page (that appears immediately after log-in) would not render side-by-side text correctly in some user agents.

Content added by course designers may fail this checkpoint.

10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.

No place-holding characters are included in edit boxes and text areas though these were only observed on the login page where this is probably not desirable.

4. Recommendations

Four broad, interrelated strategies are recommended. While these relate specifically to WebCT, a similar approach could be taken with other learning management systems.

1. A strategy involving active liaison with disabled students would substantially reduce the risk of litigation and ensure that universities meet their legal obligations. This strategy should involve:

2. WebCT training programs for academic staff should include an accessibility component to ensure that staff are aware of the ways in which course materials can be made more-or less-accessible to students with disabilities. Attention should also be drawn to WebCT tools that are likely to cause problems for disabled students. Where academics wish to use these tools in the delivery of subjects, they will need to be encouraged to provide equivalent accessible alternatives for students who cannot access them.

3. Representations should be made to the vendors of WebCT to ensure that their development of the product focuses on improved compliance with the international standards set out in WCAG. With a significant US-based market, commercial imperatives are likely to be tied to US legislation which may leave Australian institutions in a position where we will continue to have to use stop-gap measures to meet our legal obligations.

Some recommendations that should be made immediately, and which could be readily addressed by the vendors include:

Additional recommendations that may require more development effort on the part of the vendor include:

4. Australian institutions should consider working together as a group to lobby the vendor for accessibility improvements that meet Australian requirements.

Notes

Note 1: At the time of writing, I am waiting on the company's response to these issues. They have indicated that their current focus is on meeting the standards required by US legislation.

Note 2: In Lila F Laux, Peter R McNally, Michael G Paciello & Gregg C Vanderheiden, "Designing the World Wide Web for People with Disabilities: A User-Centred Approach", Proceedings of the Second Annual ACM Conference on Assistive Technologies, April 1996, pp. 97-8, Michael Paciello argues that accessibility will always remain problematic unless the needs of disabled users are considered before a product is developed. He advocates a user-centred design approach that extends human factors engineering methods to include the disabled.

Note 3: For traditional usability evaluation methods, see Jakob Nielsen and Mack (eds.), Usability Inspection Methods, John Wiley & Sons, 1994; Jeffrey Rubin, Handbook of Usability Testing, John Wiley & Sons, 1994; Joseph S Dumas & Janice C Redish, A Practical Guide to Usability Testing, revised ed., Intellect, 1999. These methods have come from the field of software engineering but have been adapted for use in evaluating web site usability. See, for example, Mark Pearrow, Web Site Usability Handbook, Charles River Media, 2000; Jonathan Lazar, User-Centred Web Development, Jones & Bartlett, 2001; Tom Brinck, Darren Gergle, & Scott D Wood, Usability for the Web, Academic Press, 2002.

Note 4: Tools commonly used for accessibility evaluation include Bobby, developed by the Centre for Applied Special Technology [HREF14] and The Wave, developed at Temple University [HREF15].

Note 5: For example, it was not possible to use a HTML validator to check whether the markup validated to formal grammars. [HREF16]

References

Brinck, Tom, Gergle, Darren & Wood, Scott D (2002). Usability for the Web, Academic Press.

Decision No. H99/115 (2000). Bruce Lindsay Maguire v Sydney Organising Committee for the Olympic Games, [HREF 5]

Disability Discrimination Act 1992, http://www.austlii.edu.au/au/legis/cth/consol_act/dda1992264/

Dumas, Joseph S & Redish, Janice C (1991). A Practical Guide to Usability Testing, revised edition, Intellect.

Human Rights and Equal Opportunity Commission (1999). "World Wide Web Access: Disability Discrimination Act Advisory Notes", [HREF 6]

Laux, Lila F , McNally, Peter R, Paciello, Michael G & Vanderheiden, Gregg C (1996). "Designing the World Wide Web for People with Disabilities: A User-Centred Approach", Proceedings of the Second Annual ACM Conference on Assistive Technologies, April, pp. 94-101.

Lazar, Jonathan (2001). User-Centred Web Development, Jones & Bartlett.

Nielsen, Jakob and Mack, eds. (1994). Usability Inspection Methods, John Wiley & Sons.

Pearrow, Mark (2000). Web Site Usability Handbook, Charles River Media.

Rubin, Jeffrey (1994). Handbook of Usability Testing, John Wiley & Sons.

Section 508.gov, "Section 508 Standards" [HREF11]

W3C, "Checklist of Checkpoints for Web Content Accessibility Guidelines, [HREF9]

W3C, "Evaluating Web Sites for Accessibility" [HREF12]

W3C, "Policies Relating to Web Accessibility" [HREF10]

W3C, "Web Content Accessibility Guidelines 1.0," http://www.w3.org/TR/WCAG10/

WebCT, "WebCT Accessibility" [HREF12]

Worthington, Tom (2001). Olympic Failure: A Case for Making the World Wide Web Accessible [HREF5]

Hypertext References

HREF1
http://deyalexander.com/
HREF2
http://www.its.monash.edu.au/
HREF3
http://www.monash.edu.au/
HREF4
http://www.austlii.edu.au/au/legis/cth/consol_act/dda1992264/
HREF5
http://www.tomw.net.au/2001/bat2001.html
HREF6
http://scaleplus.law.gov.au/html/ddadec/0/2000/0/DD000120.htm
HREF7
http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html
HREF8
http://www.w3.org/TR/WCAG10/
HREF9
http://www.w3.org/TR/WCAG10/full-checklist.html
HREF10
http://www.w3.org/WAI/Policy/
HREF11
http://www.section508.gov/index.cfm?FuseAction=Content&ID=12
HREF12
http://www.webct.com/products/viewpage?name=products_accessibility
HREF13
http://www.w3.org/WAI/eval/
HREF14
http://www.cast.org/bobby/
HREF15
http://www.temple.edu/inst_disabilities/piat/wave/
HREF16
http://validator.w3.org/

Copyright

Dey Alexander, © 2002. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.