WebWatch: How Accessible Are Australian University Web Sites?

This article reports on a recent study of the accessibility of Australian university Web sites. A selection of key pages from all 45 Australian tertiary education Web sites were analysed to assess their compliance with basic accessibility standards, as required by Australian anti-discrimination legislation. The results--98% of sites failed to comply--suggest that Australian university Web sites are likely to present significant barriers to access for people with disabilities. Web accessibility is poorly understood by university Web publishers, and procedures are not in place to ensure that university Web sites provide equitable access to important online resources.

Today, it is difficult to imagine university life without the Web. Like many organisations, universities have gradually moved business operations online and significant aspects of student recruitment, teaching, research and support functions are now operating on the Web.

The delivery of services, resources and information online is becoming the norm, and many of us appreciate the convenience and time-saving opportunities associated with this trend. For some people with disabilities, the Web is not just a convenient means of access to information but allows them to do things that may have been impossible, or at least extremely difficult, in the past. For instance, blind persons can read the newspaper online whenever they choose, rather than having to wait for someone to read it to them. And a person confined to a wheelchair can reach all the grocery items on the virtual supermarket shelf, where those on the upper shelves in the physical supermarket proved inaccessible.

However, while the technology that supports the Web offers this opportunity for increased independence, many Web sites obstruct access to disabled users through poor design. This is despite the fact that international standards for Web accessibility have been codified since 1999, and that policy and legislation now exists in many countries to protect the rights of those with disabilities [1].

With the increasing emphasis placed on the delivery of core university services via the Web, it is important to ensure that equitable access is provided. Many universities have, or are in the process of developing, policies concerning Web accessibility. Many believe they are close to achieving the goals set out in those policies [2]. But is that belief well-founded?

So I will discuss the findings from a recent study of Australian university Web sites. The study aimed to identify: whether basic accessibility standards are being met; if there are any areas in which accessibility standards are poorly understood; and what measures might be needed to ensure or improve equitable access.

What is Web accessibility?

In its broadest definition, "Web accessibility" is an approach to Web design that aims for maximal inclusion, both in terms of people who use Web sites, and the technologies that are utilised in the process.

This notion of Web accessibility was Tim Berners-Lee's vision when he created the Web:

The concept of the Web is of universal readership. If you publish a document on the Web, it is important that anyone who has access to it can read it and link to it.

These days Web accessibility generally refers to accessibility for disabled user groups. This is an important aspect of the original goal for the Web, and the push for Web accessibility for disabled users has largely come from within the World Wide Web Consortium (W3C), of which Berners-Lee is the Director.

Legal requirements for Web accessibility

The W3C has overseen the development of a set of international standards for the design of Web content: the Web Content Accessibility Guidelines 1.0 (WCAG) [3]. Published in May 1999, these guidelines have influenced the development of policy and legislation around the world, including in Australia.

In this country, the Disability Discrimination Act 1992 (DDA) makes it unlawful to design Web pages that create barriers to access for disabled users. The relevant provision of the Act is Section 24:

24 Goods, services and facilities
(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.

The DDA does not specify standards for Web accessibility. Instead, it empowers the Australian Human Rights and Equal Opportunity Commission (HREOC) to issue "Advisory Notes", or guidelines, in order to assist organisations to discharge their responsibilities under the Act. HREOC's advisory note concerning Section 24 of the DDA endorses the W3C's WCAG as the standard for Web accessibility in Australia [4].

Disabilities that affect use of the Web

The definition of disability in the DDA is very broad. In Section 4, the Act states that:

disability, in relation to a person, means:

(a) total or partial loss of the person's bodily or mental functions; or
(b) total or partial loss of a part of the body; or
(c) the presence in the body of organisms causing disease or illness; or
(d) the presence in the body of organisms capable of causing disease or illness; or
(e) the malfunction, malformation or disfigurement of a part of the person's body; or
(f) a disorder or malfunction that results in the person learning differently from a person without the disorder or malfunction; or
(g) a disorder, illness or disease that affects a person's thought processes, perception of reality, emotions or judgment or that results in disturbed behaviour;

and includes a disability that:

(h) presently exists; or
(i) previously existed but no longer exists; or
(j) may exist in the future; or
(k) is imputed to a person.

Given this definition, almost one in five Australians has a disability [4]. However, not all disabilities affect people's use of the Web. Those that do include visual, hearing and cognitive impairments, some mobility impairments and seizure disorders [5].

The effects of visual impairments such as blindness, low vision and colour blindness are probably best understood. This group of users may have difficulty with visual media including graphical representations of text, photos, animations and movies. Small text sizes may cause problems for those with low vision, and the use of certain colours and in some combinations may cause difficulties for those with low vision and colour blindness.

Mobility impairments, on the other hand, are not as well understood. These can include complete or partial loss of hand or arm movements, muscle weakness or involuntary movement, tremor or loss of fine motor control. Mobility impairments can make the use of a mouse impossible or extremely difficult. Navigating a Web site with only the use of a keyboard can be challenging. Selecting and activating small controls--for example radio buttons and checkboxes or small navigation images--are also highly problematic.

The impact of hearing impairments is often overlooked since much of the Web is visual. However, it is important to note that for some in the deaf community, English is a second language: Auslan or another sign language may be their primary linguistic orientation. While the use of audio without captioning poses an obvious barrier to access, so too may the use of overly complex language.

For those with cognitive impairments, issues which may present barriers to access are also poorly understood. Many people have reading or learning disorders, and these are often unrecognised or undiagnosed. Writing in plain language and breaking text into manageable-sized chunks is recommended. Clear labelling and organisation of content, consistent use of navigation, and supplementing text with images and audio will also greatly assist access for this group.

Seizure disorders may be triggered by page elements that flicker in the range of 2-55 Hz. In the early days of JavaScript, there was a tendency to cause page flickering through rapid loading of different page background colours. Currently the greatest threat to those with seizure disorders are animated banner ads and other moving or blinking elements that flicker within this frequency.

It is worth noting that many of the design techniques that improve accessibility for disabled users, also improve usability for other users. For instance, research shows that few people read text closely on the Web [6] . Breaking text into small chunks and using plain language improves readability for everyone. Likewise, clear and consistent layout and navigation structures benefit all users of the Web.

Methodology

Nature and goals of the research

This study of Web accessibility sought to address two primary questions. Do Australian university Web sites meet the basic standards for Web accessibility? And, are there any areas in which the basic requirements for Web accessibility are poorly understood and/or implemented?

Sites included in the study were measured against the standards set out in the W3C's Web Content Accessibility Guidelines (WCAG). Efforts to comply with the Australian Disability Discrimination Act 1992 are judged against these standards [4]. WCAG is also an international standard, developed with input from amongst the 300 W3C member organisations around the world [7].

WCAG specifies 14 guidelines or "general principles of accessible design" [7]. Each guideline has an associated set of one or more checkpoints, with 65 checkpoints in total. The checkpoints are categorised into three priority levels, each level providing greater access [3]:

Priority 1 checkpoints
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.

Priority 2 checkpoints
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.

Priority 3 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.

Associated with these three sets of prioritised checkpoints is a WCAG conformance level. If a site satisfies all priority one checkpoints it can claim level-A conformance. Where all priority one and two checkpoints are met, the site can be said to have reached conformance level-AA. Conformance level-AAA can be claimed when the requirements of all priority one, two and three checkpoints have been fulfilled.

In this study, Australian university Web sites were assessed against only the priority one checkpoints. These are the minimum requirements for accessibility that all sites must meet. However, even if a site is found to be level-A compliant it might still present accessibility problems for some disabled users.

It is important to point out that this study does not directly measure the degree to which disabled people can access Web content provided by university Web sites. Instead, compliance with the WCAG guidelines is used as an indicator of accessibility. To determine more precisely the extent to which university Web sites facilitate access, the experience of users with various disabilities would need to be studied.

Research scope

All 45 Australian university Web sites listed on the Department of Education, Science and Training Web site were included in the research [8]. See Appendix A for the complete list. From each site, a selection of four key pages was chosen for analysis. These were:

• the home page
• the prospective students page (or an equivalent)
• the orientation page (or an alternative)
• a student accommodation page (or an alternative)

These pages were chosen for several reasons. First, it is important to compare pages that are of similar significance to the core business of the institution. The comparison should be made across pages that provide a similar function for similar target audience groups.

Second, each of the four pages is likely to have had the benefit of significant development and maintenance attention. Two are key entry points for each Web site. The other two--the orientation and student accommodation pages--are likely to be of most interest at the time of year in which the analysis was undertaken (in the month prior to the commencement of first semester).

Finally, it was necessary to examine pages which did not require authenticated access.

An examination of only four pages is of course not sufficient to declare that any site positively conforms to WCAG level A--the data set is appreciably incomplete. However, given the significance of the pages chosen for the analysis, a negative result for any institution is a strong sign that there are insufficient procedures in place to ensure that accessibility standards are being met.

Evaluation method and tools

The evaluation method used for this analysis was based loosely on that suggested by the W3C [5]. A six-step method was used.

1. Each page was viewed in Internet Explorer (version 6, running on Windows XP Professional). A screen capture was taken of each page.
2. Each page was viewed in Internet Explorer (version 6, running on Windows XP Professional) with the accessibility options (ignore colours, font styles and sizes) turned on. These options override the styles defined by the site's author and show how a page would appear when rendered without stylesheets.
3. Pages were viewed twice using Delorie's Web Page Backward Compatibility Viewer [9], a Web-based utility that simulates the behaviour of browsers with variable functionality. First, the support for stylesheets was turned off, simulating how a page would appear when rendered by a browser that does not fully support stylesheets. Browsers such as Netscape versions 1, 2 and 3 fall into this category, along with Internet Explorer versions 1, 2 and 3. The second page view was done with support for scripting turned off. This allowed a simulation of how a page would function when client-side scripting was not supported or turned off.
4. Lynx (version 2.8.4, running in a DOS window on Windows XP Professional) was then used to view each page. Lynx is a text-only browser available for a number of operating system platforms.
5. A screen capture of a text-only view of each page was taken using Delorie's Lynx Viewer [10], a Web-based Lynx emulation utility that facilitates an environment in which screen captures of long pages can be achieved.
6. Pages were then checked using Webaim's The Wave [11] (alpha versions 2.02 to 3.0 and beta version 3.0). The Wave provides a visual analysis of compliance with several WCAG checkpoints. It is particularly practical for evaluating the use of text alternatives for non-text elements on a page. A screen capture of the output from the Wave was saved. Development on The Wave occurred during the month in which the analysis took place. As a result, some of the pages were checked with alpha version 2.02, others with alpha version 3.0, and those analysed in the later stages of the project were checked with beta version 3.0.

Where a text-only alternative to a page was provided, it was analysed in place of the original page. Text-only pages are generally provided as part of an accessibility effort by site owners, and may be selected in preference to the original page by users with certain types of disabilities.

All pages were viewed between 27 January and 15 February, 2003. Some pages may have been redesigned or updated since.

Analysis of results

An analysis of the results shows 98 per cent of Australian university Web sites failed to meet the most basic standards for Web accessibility. Only one Australian university Web site's set of four key pages was found to be WCAG level-A compliant.

Of the 180 pages included in the analysis, 153 pages failed on at least one checkpoint [12]. Most errors were recorded against checkpoint 1.1 with 138 pages, across 44 sites, failing to comply.

No failures were recorded against eight of the 16 priority one checkpoints: checkpoints 1.2, 1.3, 1.4, 4.1, 7.1, 9.1 and 14.1. As a result, they will not be discussed. Instead, the rationale behind the requirements of the eight remaining checkpoints will be considered along with the failures recorded against them and some examples of the problems encountered.

Provide equivalent text alternatives for non-text elements on a page
(checkpoint 1.1 - 138 page failures, 98% site failures)

One of the most fundamental requirements for accessibility is the provision of text equivalents for non-text elements. As the W3C points out "both words in 'text equivalent' are important" [3]:

• Text is considered accessible because it can be rendered by the widest range of user agents--from graphical browsers to text and voice browsers, including screen and braille readers--making content accessible to people from various disability groups [13].
• Text alternatives are considered equivalent to other content "when both fulfill essentially the same function or purpose upon presentation to the user" [14].

WCAG checkpoint 1.1 requires the use of text equivalents for a range of Web content elements that might otherwise not be accessible, including:

• Images (photos and graphic content, animations, text rendered as images, images used for decorative purposes and layout, image maps and their clickable regions)
• Media such as video and audio
• Applets and scripts
• Frames

Of the 180 pages analysed, 138 failed to comply with the requirements of this important checkpoint. This indicates a serious lack of understanding of the role of text equivalents, and should be of great concern to university Web site administrators. The nature of these page failures is discussed below.

Text equivalents for images (133 page failures, 95.5% of sites)

Those who are blind or who suffer significant loss of vision are not able to make use of graphical content provided on Web pages. Therefore Web designers are required to include a text equivalent for all graphical elements by using the "alt" attribute of the "img" element and, where necessary, the "longdesc" attribute.

95.5% of Australian university Web sites failed to meet this checkpoint. A number of problems relating to the use of text equivalents for images were found. These have been categorised into seven sub-groups. Five relate to images that convey content, and two concern images used solely for layout or decorative purposes. They are discussed below.

While some of the errors that were found may be attributed to limitations of the particular markup tool being used, the data strongly suggests that university Web authors do not understand why they must provide text alternatives for images. This lack of understanding is not confined to university Web sites:

Many authors haven't figured out exactly what they are trying to present; they don't know what it is about the image that's important to the page's intended audience. The reason you can't figure out why their alt [texts] aren't working is that they don't know why the images are there. Every graphic has a reason for being on that page: because it either enhances the theme/mood/atmosphere or it is critical to what the page is trying to explain. Knowing what the image is for - makes the labels easier to write [15].

In addition, it is clear that either an inadequate quality assurance procedure is in place or it is being ignored.

Image "alt" attributes were not equivalent to the information conveyed by the image (41 pages)

On 41 pages, text alternatives for images did not provide equivalent information or functionality. For example, on the Murdoch University home page, an image drew attention to the University's Orientation Week activities and provided the date on which these would occur. For non-sighted users or those relying on the text alternative for the image, the date of Orientation Week was not included. On the James Cook University's student accommodation page, an image linking to an online application for on-campus accommodation was given the text alternative of "Apply online" without indicating what the application was for. Given that both on and off-campus accommodation options were discussed on the page, this ambiguity may lead to a user error. On LaTrobe University's orientation page, the text alternative for an image linking to the staff telephone directory failed to include the information that the directory was for internal use only. And on the University of Technology Sydney's home page, a news item was given the text alternative of "news", omitting the substantive content.

Commonly, text alternatives were treated as though the author believed they should provide meta data or information about the image, rather than the information the image was conveying [15]. For instance, on the Australian Catholic University Web site, an image that contained the name of the university and each of its campus locations was given the text alternative "ACU locations". On the Bond University site, an image showing a map of Australia with Bond's location relative to Brisbane and some photographs of the campus and the Gold Coast area was given the text alternative "Location guide and Bond scenes".

On ten further pages, less critical differences between the text alternative and the information provided by the image were found. These were not recorded as checkpoint failures in this study, although some may think they ought to have been. In any case, they represent a less than ideal approach to writing text alternatives. On the Deakin University home page an image containing a welcome message as well as the University logo was given the text alternative "Deakin logo". While this signalled to the user that they were on the Deakin site, it did not provide the same sort of experience that a sighted user would have. A different example was found on the Curtin University home page. There, an image at the bottom of the page presented the University's tagline or slogan: 'Look ever forward'. While the visual presentation indicated to sighted users that this was a slogan or tagline, the text presentation did not, leaving open the possibility that users may be confused about what the text was intending to convey.

Image "alt" attributes included unnecessary data (21 pages)

Unnecessary information was included in the text alternative provided for images on 21 pages. The most common example involved the repetition of a text alternative for an image that had been sliced to allow greater control over layout. The logo on the University of Western Australia's orientation page was sliced in three and each segment given a text alternative. In similar fashion, the University of Newcastle's logo that appears on the home page has been sliced in two, and both slices have the same text alternative. And "University of Ballarat - Welcome to orientation week" was repeated four times on the University's orientation page.

Unnecessary data was also included by some page authors when they added the words "link to" or "click here to go - " at the beginning of text alternatives for images that acted as links to another page. This approach was found on many pages on the Charles Sturt University site.

User agents provide their own mechanisms for identifying links. JAWS, for instance, will say aloud "link graphic" prior to reading the text alternative provided by the page author. Adding text such as "link to" means that those accessing the Web with screenreaders or speech synthesisers will be forced to listen to text that is, in fact, redundant. A further annoyance might result for skilled users of screenreading software. The software provides a feature that allows users to access a list of all the links on a page, rather than having to read through the page in order to locate a link. The list of links can be sorted and browsed alphabetically. Users can skip to a particular part of the list, say to section H, to quickly locate the link to the home page. Adding "Link to" to every text alternative for a link renders this feature useless.

(Note: the errors mentioned in this section were not recorded as checkpoint failures. They are included here as they indicate the extent to which the function of text alternatives is misunderstood).

Image "alt" attributes were left blank (11 pages)

On 11 pages empty "alt" attributes for images that conveyed important information, or acted as links to other pages, were found. E.g.

An image with the words "Click - enrolment info", found on the University of Adelaide's home page, had an empty "alt" attribute. On the Flinders University home page, an image link to the orientation Web page had no "alt" attribute. Images providing key navigation options on the Notre Dame University home page had no "alt" attribute. In each of these cases, users would have no idea of the target of the link.

On a further 2 pages, empty "alt" attributes were also found for images conveying text of less than critical importance. These were not counted as checkpoint failures. An example, from the James Cook University Web site, was a blank "alt" attribute for a graphical tagline or slogan, "Always Thinking Ahead". While this omission may not be serious from the user's point of view, its use on the home page was presumably part of the University's marketing strategy. One would assume the intention of the University is to apply that strategy to all parts of its prospective student market--not just to those who can see.

Images without an "alt" attribute (65 pages)

The second most common error concerning text alternatives for images was the failure to include the "alt" attribute on "img" elements where the images conveyed content. E.g.

In some cases, the error would have been frustrating for users reliant on text alternatives for orientation. For instance, on the Australian Defence Force Academy Web site, the logo and crest that acted as the site identification on each page had no "alt" attribute. In other cases, the failure to provide an "alt" attribute would have had more dire consequences. Consider the Avondale College Web site where none of the navigation images used on the site had an "alt" attribute, or the Deakin University accommodation page, where global navigation images were treated similarly.

Background images convey content that is not repeated in text elsewhere on the page (1 page)

When an image is used as a background for a page, it is not possible to include an "alt" attribute. As a result, it is recommended that background images should not be used to convey content. Where they are, the content must be repeated in an accessible format elsewhere on the page.

The background image used on the University of Canberra prospective students page shows the location of Canberra on the east coast in relation to Sydney and Brisbane. This information is not provided elsewhere on the page.

Decorative or spacer images with "alt" attributes that included unnecessary data (53 pages)

The use of "alt" attributes on images used for layout or decorative purposes was also highly problematic. Unnecessary text alternatives were found on 53 pages. Common examples included images bearing the text alternative "banner" or "curve" and photographs with the text alternative "pic1" or "library image", as were found on the Macquarie University, Northern Territory University, and University of Southern Queensland pages.

Many sites use images to act as bullet points or horizontal lines, and use text alternatives of "asterisk" or "bullet" for the former, and "line" for the latter. The Australian Maritime College, Australian Catholic University and James Cook University sites provide examples of this. There is a degree of disagreement about appropriate text alternatives for images used in these ways, but the situation only arises because of the failure to use structural markup [15][16][17]. Lists should be indicated by the use of the unordered list element, 'ul' and items within it by its child element "li". This indicates to screenreaders that the data is a list, and saves users from having to listen to several instances of "Asterisk [item name], asterisk [item name].." or "Bullet [item name], bullet [item name] - ". Similarly, structural markup can solve the problem of indicating the end of a page section. Here, the use of heading elements, 'h1' through to 'h6' would be appropriate. "H1" indicates the page title, and each instance of "h2" indicates a new section. Using "h3", "h4", "h5" and "h6" within a section marked by "h2" provides as much flexibility and meaning as could be indicated by horizontal lines or image bars. Use of heading styles can then optionally be supplemented for sighted users by using horizontal lines or image bars--bearing blank "alt" attributes to prevent interfering with readability for non-sighted users [13].

As with section 4.1.1.2, the errors discussed here were not recorded as checkpoint failures but are included as areas in which Web authoring practices could be improved.

Decorative or spacer images without an "alt" attribute (89 pages)

Finally, the most common error concerning the use of text alternatives was the failure to include an 'alt' attribute on decorative images and those used for page layout purposes, such as the single-pixel gif image. This error was found on 89 pages across 37 of the 45 sites evaluated in this study.

The "alt" attribute is not optional. It must be included on all "img" elements. Where it is not, the user agent will attempt to compensate, by including the filename or another text string such as "[inline]", or by giving some sort of auditory signal to the user that an image is present--just in case the image is important. This kind of compensation will unnecessarily interfere with the reading of the page and cause the user to wonder whether they are missing important content.

Text equivalents for frames (22 page failures, 22% of sites)

Designers are required to provide an equivalent alternative to pages where content is presented via a set of frames. This ensures access to content and functionality for those with user agents that do not support frames. Accessible alternatives for frames can be achieved by providing equivalent content within a "noframes" element or by providing a link within that element to an equivalent accessible page.

Frames were used on 26 of the pages analysed in this study. Of those, 22 failed to provide an accessible equivalent. Sixteen had either no "noframes" element, or no useful content within it. These included the prospective students page at Murdoch University, three of the four Open Learning Australia pages and all four pages from the National Institute of Dramatic Art Web site. Six provided some content, but it was not equivalent to the content provided on the original framed page. The Marcus Oldham College Web site was an example.

Text equivalents for PDF content (13 page failures, 24% of sites)

The Portable Document Format (PDF) is widely used on the Web. There are at least two main reasons for its popularity as a content format. First, it is very easy to produce content in this format: with little more than a click of a button a document can be converted to the PDF format. Second, the availability of a free PDF reader for multiple platforms has given many the impression that PDF is as appropriate for publishing on the Web as HTML--or at the very least, that it is preferable to publishing content in Microsoft Word DOC format.

Within universities, PDF is often seen as a solution for protecting intellectual property when publishing to the Web. This belief arises because PDF documents can be created with copy, edit or print functionality disabled. But of course anyone who is sufficiently determined can copy or reproduce "secure" PDF content without a great deal of effort using screen capture and OCR scanning software.

A recent development that may have added to the impetus for publishing Web content in PDF format involves accessibility enhancements to PDF documents. By leveraging Microsoft's Active Accessibility (MSAA) technology, Adobe Acrobat version 5 now facilitates the creation of PDF documents that can be accessed by the latest screen reading technology [18].

While this development is to be applauded, PDF can not be considered an accessible format--at least not at this point in time. Only recent versions of screenreading software can utilise this technology, and only when running on a Windows platform with Adobe PDF reader version 5.0.5 (or higher) installed. Screenreading software is expensive--the latest version of one of the more popular screenreaders, JAWS, retails at around $US900 and has an upgrade price of between $US120 to $US550, depending on the user's existing version. The purchase price is therefore prohibitive for many users. And of course, not all blind users own Windows machines. Unix or Macintosh users are still locked out of content provided only in PDF format.

An additional limitation is that only documents created using Adobe Acrobat version 5 (or paper documents scanned and captured with Acrobat Capture version 3) and authored in Microsoft Word 2000 (or higher) can be made accessible. Even then, authors must understand and use appropriate authoring techniques, such as structural formatting, before the document can be made accessible [19].

And there is a further catch--particularly relevant to the use of PDF within universities. None of the accessibility features in Acrobat version 5 will work if the PDF document is secured to prevent copying or editing.

As a result of these limitations, the Australian Human Rights and Equal Opportunity Commission (HREOC) have issued the following advice:

The Commission's view is that organisations who distribute content only in PDF format, and who do not also make this content available in another format such as RTF, HTML, or plain text, are liable for complaints under the DDA (HREOC 2002).

Despite HREOC's advice, 13 pages of those analysed, had links to information that appeared to be provided in PDF format only. These included the Curtin University of Technology's course prospectus, news items linked from the home page of the Edith Cowan University Web site, orientation information at Griffith University, information about pathways from TAFE to university provided on the University of South Australia Web site, and information about scholarships linked from the University of Queensland prospective students page.

In this study, the provision of content in PDF format only has been recorded as a failure against checkpoint 1.1, but others reference it against checkpoint 11.4 (see for instance documentation related to use of the accessibility diagnostic tool, The Wave). However, failures against checkpoint 11.4 occur when the content is an alternative rendering of inaccessible content, and it is not equivalent to the original provided. In each of the cases recorded here, PDF format was not used as an alternative content format.

Text equivalents for scripts (6 page failures, 11% of sites)

Some user agents do not support the use of client-side scripting such as JavaScript or Java applets. In addition, some users turn JavaScript off for a variety of reasons including security concerns. Designers must then ensure that an accessible equivalent is provided for content generated by scripts and applets.

One way of doing this is by using the "noscript" element. This allows a text alternative of script-generated content to be delivered to those users browsing a page without JavaScript enabled. If the "object" element is used, then a text equivalent should be provided within the object. And where the "applet" element is used, a text equivalent must be provided with the "alt" attribute and in the content of the "applet" element. This enables the content to transform gracefully for those user agents that only support one of the two mechanisms ("alt" or content). Another method that can be used is to provide a link to an alternative accessible rendering of the content.

In this study, 6 failures to provide a text alternative for script-generated content were found. These included Java applets and JavaScript used primarily to generate news sections on pages and were found on the Marcus Oldham College home and prospective students pages and the Charles Sturt orientation page.

Text equivalents for Flash content (4 page failures, 9% of sites)

Flash provides a visually rich environment for the presentation of Web content and is widely used on commercial Web sites as a result. Ongoing enhancements to its capabilities have seen it adopted as a Web application environment as it provides a more functional user interface than can be provided through the use of plain or dynamic HTML.

There have also been improvements to the accessibility of Flash. However, as with the caveats that apply to PDF content, the improvements to Flash accessibility do not mean that Flash is universally accessible. Flash content needs to be authored specifically to meet the needs of disabled users. And users must have the technology that allows them to take advantage of this.

As a result, the Human Rights and Equal Opportunity Commission have also issued a caution about the use of Flash as a presentation format for the Web:

While some positive progress has been made, it will be a considerable time before most users will benefit, and even then, Flash may be accessible only in certain specific circumstances. It is certainly wrong for Web designers to assume that improvements in the accessibility of a technology mean that it can be used indiscriminately without regard for the principles of accessible Web design [4].

Four pages included in the study contained Flash content. These were the Avondale College and National Institute of Dramatic Art home pages, and the accommodation pages on the Murdoch and Central Queensland University Web sites. All failed to provide an accessible equivalent.

Ensure documents can be read without stylesheets (checkpoint 6.1 - 59 page failures, 56% of sites)

Users with colour blindness or low vision may choose to override the styles used on Web pages in order to avoid colours that they cannot distinguish, increase the contrast between text and background colours, or make font sizes larger. In addition, some user agents--such as text browsers and older graphical browsers--do not utilise stylesheets, or do so poorly. As a result, it is important to ensure that documents are readable when stylesheets are either not fully supported, or overridden by user preferences.

Several problems can occur when a page is viewed without stylesheet support. First, there are several mechanisms for including stylesheet-generated content in a page using pseudo-elements and the content property [20]. Any content generated in this way will be missing.

Second, where content has been positioned on the page through the use of styles and the HTML "div" element, it may not display in the correct order when stylesheets are not in use. Content needs to be positioned in a logical order within the HTML document to overcome this problem.

Neither of these problems were observed on the pages analysed. However, three additional issues were, all related to legibility. The most common of these was found when checking page readability via graphical browsers with little or no support for stylesheets. Many pages were difficult to read because of insufficient contrast between text and background colours. In each case the page author had used HTML coding to handle the background colour--making it, say, dark blue--and stylesheets for controlling the text colour--for example, white. The result was that the styled text reverted to its default colour, black, and was rendered on the HTML-controlled dark blue background. Some examples of this problem were found on the Flinders University, University of Adelaide and Northern Territory University Web sites.

This is an area in which design practices could easily be improved. Designers ought to take a consistent approach to presentation, ensuring that all colour--rather than only text and hyperlink colour--is handled by stylesheets. All version 4 browsers are capable of handling stylesheet-generated colours. For users accessing the Web with older browsers, the pages will degrade to use the default browser colours or those chosen by the user.

The second problem was found on pages where images with transparent background colours were used, most notably when images contained text. In many cases, the image presented white text on a dark background. The background colour was made transparent in the image creation process, and was intended to be replaced by a dark background controlled by stylesheets. Once the stylesheets were overridden, trying to read white text on a white background--save for the few pixels of dark colour that are left behind in the process of making the image background transparent--becomes very difficult. Some examples of this problem were found on the prospective students pages at the University of New England and the University of Canberra.

This appears to be a difficult issue to resolve as it is considered good design practice to make the image background transparent when it is displayed on top of a coloured background generated by a stylesheet or HTML. The reason designers use this approach is because of colour shifts that can occur between colours generated by stylesheets or HTML and those that are part of an image [21]. However, this problem only arises on displays where the colour depth is set to 256 colours or less, and this is becoming less and less frequent. Designers should therefore check for the image transparency problem and use solid rather than transparent backgrounds where problems with readability occur.

Finally, where stylesheets were used to provide solid background colours for dynamically generated drop down or flyout menus, these became impossible to read without stylesheet support. The text of the menu items was displayed on top of body text and other elements. Some sites where this occurred include the Avondale College site, and the University of Western Australia home page.

Provide frame titles to facilitate identification and navigation (checkpoint 12.1 - 26 page failures, 24% of sites)

Framesets are a collection of two or more HTML documents loaded into individual frames to create the appearance of a single page. The use of frames is generally not recommended as they give rise to a series of potential usability issues, particularly when they are not skilfully implemented [22]. The potential problems exist for all users, not just those with disabilities. They include:

• being unable to bookmark a page within a site that uses frames
• unpredictable behaviour of the browser back button in some frameset implementations
• difficulty printing framed pages
• pages from a linked site "accidentally" loading inside the frameset of a the page providing the link
• frames in which the content does not quite fit, requiring horizontal scrolling of multiple parts of the page or simply preventing the user from seeing all of the content

Moving around within a frameset adds a layer of complexity to navigation for those unable to use graphical browsers. Frames appear as a series of separate zones on a page when read by some screenreaders, and users can then jump between frames--as long as they know what each contains--to access the content in each zone. In text browsers and some screen readers, frames do not appear as a single page with separate zones, but as links to separate pages.

In both cases, frame titles are important to user orientation. They should be descriptive enough to enable users to identify the contents of a particular frame, understand how one frame relates to another, and navigate between the frames that comprise a page.

In this study, frames were used on 26 pages. Unfortunately, none of those pages complied with the requirement to provide descriptive frame titles.

When frame titles are missing, user agents may display the "name" or "src" attribute of the frame element instead. Given that these are markup attributes rather than content intended to be displayed to users, the results may be far from optimal. Some examples found in this study included a frameset with frames named "left" and "right" as used on the Australian Defence Force Academy home page, and the home page of the University of the Sunshine Coast with four frames: "homepage", "homepage", "links" and "nav".

Ensure that pages are usable when scripts are turned off or not supported (checkpoint 6.3 - 23 page failures, 20% of sites)

As mentioned in section 4.1.4 above, some user agents do not support client-side scripting and some users turn it off. Where this is the case, developers must ensure that pages are still functional despite the limitations of the user agent or the preferences of the user.

One of the key areas in which scripting can create problems is when it is used to control site navigation elements or generate links [23]. In these situations, disabled users may be denied access to some parts of the site, or may not be able to navigate at all.

Twenty-three pages in this study failed this checkpoint. Most failures related to the use of JavaScript-generated navigation--either as flyout menus, where no accessible default options existed, or as drop-down quicklink-style menus. The worst of these was found on the Avondale College Web site where navigation on every page would be severely limited. On the Monash University accommodation page, java applet-controlled navigation would result in some users being unable to move around within the accommodation site. And on the Open Learning Australia site, users may not be able to proceed beyond the site's splash page as JavaScript is used to generate the entry link.

Ensure that text-only page alternatives provide equivalent content (checkpoint 11.4 - 9 page failures, 13% of sites)

Some organisations choose to approach designing for accessibility by providing a text-only page as an alternative to the main content page. WCAG allows for this approach, but indicates it should only be adopted when "best efforts" at attempting to make content directly accessible have failed [12].

Of the pages analysed in this study, 15 offered a text-only version (four of these were alternatives to pages using framesets). In each case, the original page could have been made directly accessible.

A difficulty with opting for the creation of text-only pages is that maintenance requires greater effort unless the process can be automated in some way. When it can not, maintenance of text-only alternatives may fall behind that of the original page, with the result that disabled users are not given access to the same information or resources as other users. The pages surveyed as part of this research illustrate that problem: 60 percent of the text-only pages did not provide content or functionality equivalent to the original page. Some example include the accommodation page provided by the University of Sydney, the University of Ballarat's home page, several text-only pages on the University of South Australia Web site, and the home and prospective students pages at the Australian National University.

Ensure that data tables are properly marked up (checkpoints 5.1 and 5.2 - 2 page failures, 4% of sites)

An important principle in accessible Web design is the separation of content from presentation. The ideal approach is to use structural elements that have meaning independent of their presentation style, and to handle presentation through the use of stylesheets. Using structural markup ensures that meaning can be conveyed regardless of the user agent rendering the page. For instance, using the 'strong' element to indicate a passage of text that the author wishes to draw the user's attention to is preferable to using 'bold'. The latter will only be rendered by graphical browsers, whereas the former will be given emphasis by any user agent, even a screenreader.

Data tables present data in a matrix or grid. To be accessible to those who cannot see them, data tables must include structural information such as row and/or column header elements. In complex tables, further structural elements must be provided, and associating headers with data cells is recommended [24]. Using structural table markup provides context to users of screenreaders as they negotiate the content in a data table. Without this, an unacceptable cognitive load is likely to result. Blind users would need to remember table header labels in the correct order and do a mental association between them and the data, on the fly.

Few data tables were encountered in this study. Only two failures were recorded against this checkpoint. One of these was found on the University of Western Sydney orientation page. The other occurred on the Queensland University of Technology accommodation page.

Do not convey meaning by colour alone (checkpoint 2.1 - 1 page failure, 2% of sites)

Structural markup is also the principle that motivates checkpoint 2.1, which requires that meaning be conveyed by more than just colour [13]. The checkpoint aims to ensure that those who are colourblind, or not able to use a graphical browser, can make sense of content even when they cannot see or distinguish between colours used on the page.

Only one page included in this study was found to have failed this checkpoint. Required fields on a form on the Avondale College Web site were indicated solely through the use of the colour red.

Ensure that equivalents for dynamic content are updated as dynamic content updates (checkpoint 6.2 - 1 page failure, 2% of sites)

The aim of this checkpoint is to ensure that page authors are aware of the need to dynamically update accessible equivalents for dynamically-generated content, otherwise some disabled groups will be denied access to that content.

Using images as the source files for frames was an early concern related to this checkpoint because it is not possible to include an accessible equivalent for an image if it is the source file for a frame [24] [25] [26]. More recently, the use of scripting to dynamically generate Web content requires monitoring for compliance and equity of access.

Only one failure related to dynamically-generated content was noted in this study. This occurred on the University of Queensland orientation page. An image provided a link to a student's testimonial about their orientation experience at the University. The image and associated link were randomly generated each time the page loaded, however, the text alternative for the image failed to change. Anyone using a screenreader, or Braille or text browser would not be aware that the link changed each time they revisited the page and that a series of testimonials were available.

Concluding remarks

The results of this research suggest that Australian university Web sites are likely to present significant barriers to access for some disabled user groups. Although many universities have policies governing Web accessibility, the policies are apparently ineffective. This may be due to any one or more of the following:

• The role of text equivalents for non-text elements, particularly images, is poorly understood amongst university Web designers.
• There is insufficient knowledge of accessible Web design practices amongst those who are charged with design, development or maintenance of university Web sites.
• Web publishing quality assurance procedures either do not exist, do not address issues related to Web accessibility, or are not adhered to.

In order to discharge their obligations under the DDA, universities need to take immediate steps to improve the accessibility of their Web sites. The implementation of Web accessibility policies needs to be supported by a broad educative process. All those involved in the design of university Web sites or the markup of Web content need to be given thorough training in accessible Web design techniques. In addition, quality assurance processes need to be strengthened: sign-off authorisation should include not just the acceptance of responsibility for the accuracy of page content, but for the accessibility of that content as well.

References

1. W3C, 2003, "Policies Relating to Web Accessiblity" http://www.w3.org/WAI/Policy/
2. Alexander, D. 2002, "Web Accessibility in Australian Universities: A Telephone Survey" http://deyalexander.com/papers/accessibility-survey.html
3. W3C, 1999, "Web Content Accessibility Guidelines 1.0" http://www.w3.org/TR/WCAG10/
4. Human Rights and Equal Opportunity Commission, 2002, " World Wide Web Access: Disability Discrimination Act Advisory Notes", Version 3.2 http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html
5. W3C, 2001, "How People with Disabilities Use the Web"
   http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/
6. Morkes, J. & Nielsen, J., 1997, "Concise, Scannable, and Objective: How to Write for the Web" http://www.useit.com/papers/webwriting/writing.html
7. W3C, 1999, "Fact sheet for 'Web Content Accessibility Guidelines 1.0'"
   http://www.w3.org/1999/05/WCAG-REC-fact
8. Department of Education, Science and Training Web site, 2002 http://www.detya.gov.au/tenfields/detya/which_uni.html
9. Delorie, Web Page Compatibility Viewer http://www.delorie.com/web/wpbcv.html
10. Delorie, Lynx Viewer http://www.delorie.com/web/lynxview.html
11. Webaim, The Wave http://wave.webaim.org/
12. W3C, 1999, "Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0" http://www.w3.org/TR/WCAG10/full-checklist.html
13. W3C, 2000, "Core Techniques for Web Content Accessibility Guidelines 1.0" http://www.w3.org/TR/WCAG10-CORE-TECHS
14. W3C, 1999, "Techniques for Web Content Accessibility Guidelines 1.0"
    http://www.w3.org/TR/WCAG10-TECHS/
15. Flavell, A., 2003, "Use of ALT texts in IMGS" http://ppewww.ph.gla.ac.uk/~eflavell/alt/alt-text.html
16. Korpela, J., 2002, "Guidelines on alt texts in img elements" http://www.cs.tut.fi/~jkorpela/html/alt.html
17. Bohman, P., 2002, "How to create accessible graphics" http://www.webaim.org/howto/graphics/index.php
18. Adobe, 2003, "Acrobat Accessibility" http://www.adobe.com/products/acrobat/solutionsacc.html
19. Adobe, 2003, "How to Create Accessible Adobe PDF files" http://www.adobe.com/products/acrobat/access_booklet.html
20. W3C, 2000, "CSS Techniques for Web Content Accessibility Guidelines 1.0" http://www.w3.org/TR/WCAG10-CSS-TECHS/
21. Lehn, D. & Stern, H., 2000, "Death of the Websafe Color Palette?" http://hotwired.lycos.com/webmonkey/00/37/index2a.html?tw=design
22. Nielsen, J., 1996, "Why Frames Suck (Most of the Time)" http://www.useit.com/alertbox/9612.html
23. W3C, 2000, "Example for Checkpoint 6.3: WAI Web Content Accessibility Curriculum" http://www.w3.org/WAI/wcag-curric/sam56-0.htm
24. W3C, 2000, "HTML Techniques for Web Content Accessibility Guidelines 1.0" http://www.w3.org/TR/WCAG10-HTML-TECHS/
25. W3C, 2000, "Example for Checkpoint 6.2: WAI Web Content Accessibility Curriculum" http://www.w3.org/WAI/wcag-curric/sam54-0.htm
26. McMullin, B., 2002, "WARP: Web Accessibility Reporting Project - Ireland 2002 Baseline Study" http://eacess.rince.ie/white-papers/2002/warp-2002-00/

Further Reading

• W3C, 2002, "Evaluating Web Sites for Accessibility" http://www.w3.org/WAI/eval/
• Watchfire Corporation, 2002, "Bobby: Report Help Files" http://bobby.watchfire.com/bobby/html/en/browsereport.jsp

Appendices

• Appendix A: List of sites included in the study:
  http://deyalexander.com/papers/ausweb03/sites-list.html
• Appendix B: An Excel spreadsheet showing the results of study: http://deyalexander.com/papers/ausweb03/results.xls
• Appendix C: Results and screenshots for each site included in the study: http://deyalexander.com/articles/ausweb03/

Author Details

Dey Alexander
Usability Specialist,
Information Technology Services
Building 3A, Monash University
Victoria, 3800 Australia

Email:Dey.Alexander@its.monash.edu.au
Web site: http://www.monash.edu.au/

Return to top

Article Title: "How Accessible Are Australian University Web Sites?"
Author: Dey Alexander
Publication Date: 30-January-2004
Publication: Ariadne Issue 38
Originating URL: http://www.ariadne.ac.uk/issue38/alexander/