Increasing use of the web by universities
Teaching uses
- Some subjects wholly online
- Many others supported online through learning management systems such as WebCT, Blackboard, etc.
- lecture notes
- taped lectures (audio)
- study resources
- discussion groups and mailing lists
Research uses
- Information about funding sources, ethics requirements
- Applications for funding
- Research reporting and documentation
- Research collaboration
- Research resources
Administrative uses
- Course, subject, tutorial enrolment online
- Timetables online
- Helpdesk and student services functions online
- University corporate applications with web front-ends
- Human resources information and forms online
- Finance information and forms online
- Training and training resources online
Increased use necessitates improved accessibility
- Business imperatives
- Loss of business if prospective students (their parents, or careers teachers) cannot access course guides
- Potential for productivity enhancements is lost if content is not accessible
- Legal imperatives
- Disability Discrimination Act 1992 prohibits discimination against
those with disabilities
- Web sites must be accessible - Section 24
- Universities have obligations not to discriminate against disabled students - Section 22
- As employers, universities have obligations not to discriminate against disabled staff - Section 15
- Disability Discrimination Act 1992 prohibits discimination against
those with disabilities
References
- Disability Discrimination Act 1992 - Section 24
- Disability Discrimination Act 1992 - Section 22
- Disability Discrimination Act 1992 - Section 15
Telephone survey regarding web accessibility in Australian Universities
Background
- Conducted in November 2002
- Provided background research for a workshop at the OzeWAI web accessibility conference 2002
- 18 respondents - University "webmasters" who responded to an email invitation to participate
Aims of survey
- See where Universities were at in terms of web accessibility
- how many have policies on web accessibility?
- what is the webmaster's estimation of the sites current accessibility?
- what were the goals for accessibility in the current or any forthcoming redesigns?
- at what level is the knowledge of web accessibility within each university's web authoring community
Results of survey
- 56% said web accessibility policies were in place (half said this was a recent initiative)
- 67% believed their sites to be at least WCAG level A compliant
- 72% said they aimed for at least WCAG level A compliance in the current redesign (or were aiming for it in a web redesign in progress)
- 72% said their web site had been audited for compliance with WCAG
level A
- of these, only 11% (2 sites) had been externally audited
- 78% were of the view that their central or corporate web team's knowledge of web accessibility was good
- 89% said that administrative staff, who maintain content for university sites, had a poor knowledge of web accessibility
- 94% said academics, who produce online course materials, have a poor knowledge of web accessibility
References
Accessibility audit of Australian university web sites
Background
- Paper will be presented at AusWeb 03 conference (a link to the paper will eventually be added to this presentation)
- Conducted between January 27 and February 15, 2003
- Some sites/pages have been updated since
Aims of audit
- Do Australian university web sites meet the basic standards for web accessibility?
- Are there any areas in which the basic requirements for web accessibility are poorly understood and/or implemented?
Scope of audit
- All 45 Australian university web sites as listed on the Department of Education, Science and Training (DEST) web site
- 4 pages from each site were selected (180 pages in total)
- home page
- prospective students page (or courses page, or similar)
- orientation page (or alternative)
- student accommodation page (or alternative)
Methodology
- Pages were measured against priority 1 checkpoints (basic standards) in W3C's Web Content Accessibility Guidelines (WCAG) - 16 checkpoints in total
- Six-step method
- Page viewed in Internet Explorer (version 6, on Windows XP Professional)
Screen capture was taken - Page viewed in Internet Explorer with accessibility options turned
off
This effectively turns stylesheets off - Page viewed twice using the Web Page Backward Compatibility Viewer
from delorie.com
First, stylesheet support was turned off
Second, support for scripts was turned off - Page viewed with Lynx (version 2.8.4 running on Windows XP Professional)
- A screen capture was taken using Lynx Viewer from delorie.com
- Page analysed by The Wave
Screen capture was taken
- Page viewed in Internet Explorer (version 6, on Windows XP Professional)
- Where text-only pages were provided, they were analysed in place of the original page
References
- List of Australian universities on the DEST web site
- Web Content Accessibility Guidelines 1.0
- Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
- Web Page Backward Compatibility Viewer
- Lynx Viewer
Results - 98% of sites failed the test for basic accessibility
Overview of results
- 98% of sites (44 of 45) failed to comply with all priority 1 checkpoints
- 85% of pages (153 of 180) failed to comply with all priority 1 checkpoints
Checkpoint failures recorded
- Failures were recorded against 8 of the 16 priority one checkpoints
- Most failures were recorded against checkpoint 1.1
- No failures were recorded against checkpoints 1.2, 1.3, 1.4, 4.1, 7.1, 9.1,14.1
References
- How accessible are Australian university web sites? Detailed results of an accessibility audit
- Excel spreadsheet summary of results
Text equivalents for non-text elements
Checkpoint 1.1 says:
Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Overview of results
- 98% sites failed to comply with checkpoint 1.1
- 138 pages failed to comply with checkpoint 1.1
Discussion - images
Users who are blind or who suffer significant loss of vision are not able to utilise 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% sites failed to provide text equivalents for images (using "img" and "longdesc" attributes)
- 133 pages failed
- 7 types of problems were found (note: problem types 2 and 6 were not
counted as checkpoint failures)
- Image "alt" attributes were not equivalent to the information conveyed by the image (41 pages)
- Image "alt" attributes included unnecessary data (21 pages)
- Image "alt" attributes were left blank (11 pages)
- Images without an "alt" attribute (65 pages)
- Background images that conveyed content that was not repeated elsewhere on the page (1 page)
- Decorative or spacer images with "alt" attributes that included unnecessary data (53 pages)
- Decorative or spacer images without an "alt" attribute (89 pages)
One thing is apparent: many university web authors do not understand the role of text alternatives.
For examples of each of these image-related errors, see the presentation "How should we provide text equivalents for non-text elements on the web?"
Discussion - frames
Designers are required to provide an equivalent alternative to pages where content is presented via a set of frames--either by providing equivalent content within a "noframes" element or by providing a link within that element to an equivalent accessible page. This ensures access to content and functionality for those with user agents that do not support frames.
- Frames were used on 26 of the pages analysed as part of this study
- 22 of these failed to provide text equivalents for frames (using "noframes" element) - many had only an error message (see screenshot below)
- 6 attempted to provide a text alternative, but it was not equivalent
![]()
Discussion - PDF content
The Portable Document Format (PDF) is widely used on the web. Reasons for its popularity include:
- it is easy to convert documents to PDF format
- free PDF readers are available for most platforms
- belief that PDF protects intellectual property (copy, edit, print restrictions can be applied)
However, despite recent improvements to the accessibility of the PDF format, the Human Rights and Equal Opportunity Commission cautions web content providers on its use:
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.
- 24% sites failed to provide accessible equivalents for PDF content
- 13 pages had links to information provided in PDF format only

Discussion - script-generated content
Some user agents do not support the use of client-side scripting such as javascript or java applets. 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. One way of doing this is by using the "noscript" element to provide a text alternative of script-generated content. Another, is by providing a link to an alternative accessible rendering of the content.
- 11% sites failed to provide text equivalents for script-generated content (within "object" or "applet" element, including "alt" attributes for applets)
- 6 pages failed
- The content generated by scripts was mainly news sections or news headlines (see screenshot below)

Discussion - Flash content
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 leveraged through the use of plain or dynamic HTML.
However, despite recent improvements to the accessibility of Flash-generated content, the Human Rights and Equal Opportunity Commission cautions web content providers on its use:
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.
- 9% sites failed to provide text equivalents for Flash content (within "noembed" element)
- 4 pages failed
References
- How should we provide text equivalents for non-text elements on the web?
- World Wide Web Access: Disability Discrimination Act Advisory Notes
Use of stylesheets
Checkpoint 6.1 says:
Organise documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
Overview of results
- 56% sites failed to comply with checkpoint 6.1
- 59 pages failed to comply with checkpoint 6.1
Discussion
Users with low vision or colour blindness may override the author's stylesheets in order to increase font size or provide better colour contrasts. Alternatively--and this is becoming increasingly less likely--users may be using older browsers with partial or no stylesheet support.
Checkpoint 6.1 was written to cover problems that may occur when
- content is generated by stylesheets (using pseudo-elements and the "content" property). In these cases, the generated content would be missing if the user turns stylesheets off
- content is positioned by stylesheets. With stylesheets turned off, content may not be rendered in the correct reading order
Three additional problems were found in this study
- in older browsers (those without proper stylesheet support), lack of contrast between text and background colours on some pages hampered readability. This occurred where text colour, say white, was controlled by stylesheets and background colour, say dark blue, was marked up in HTML. Turning off stylesheets resulted in the default text link colour of dark blue being rendered on a dark blue background
- in more recent browsers, turning off stylesheets produced a related problem. Where images had transparent backgrounds, the stylesheet-controlled background colour was turned off, any text on the image became difficult to read
- a third problem occurred where drop down menus lost their background colour and became difficult to read as text displayed on top of body text



Frame titles
Checkpoint 12.1says:
Title each frame to facilitate frame identification and navigation.
Overview of results
- 24% sites failed to comply with checkpoint 12.1
- 26 pages (all of those that used frames) failed to comply with checkpoint 12.1
Discussion
When using a screenreader or text browser, frames do not appear as a single page as they do to users of graphical browsers. Users of screenreaders and text browsers are reliant on frame titles for orientation around the separate zones on the page.
When frame titles are absent, user agents compensate by including the frame "name" or "src" attribute. These are not usually written to be displayed to screen and read by humans. As a result, they are often less than useful. Some frame name sets found in this study included:
- "left" and "right
- "homepage", "homepage", "links", "nav"
(see the screenshot below which shows this frameset when viewed with Lynx, a text browser)

Use of scripts
Checkpoint 6.3 says:
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.
Overview of results
- 20% sites failed to comply with checkpoint 6.3
- 23 pages failed to comply with checkpoint 6.3
Discussion
The rationale behind this checkpoint is to cover the following situations:
- some user agents do not support client-side scripting
- some users turn client-side scripting off for a variety of reasons including concerns about security
In this study, most of the problems related to javascript-generated navigation. Some problems with java applets were also noted (as shown in the screenshots below).


Text-only alternative pages
Checkpoint 11.4 says:
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.
Overview of results
- 13% sites failed to comply with checkpoint 11.4
- 9 pages failed to comply with checkpoint 11.4
Discussion
Text-only alternative pages can be provided where efforts at making the original page accessible have proven too difficult.
- 15 pages included in the study offered a text-only alternative
- it is likely that the original pages could have been made accessible
- problems with keeping manually maintained text-only page up to date and in synch with the original page were observed
Data tables
Checkpoints 5.1 and 5.2 say:
For data tables, identify row and column headers.
For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
Overview of results
- 4% sites failed to comply with checkpoint 5.1
- 2 pages failed to comply with checkpoint 5.1
Discussion
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.
Few data tables were encountered in this study. Only two failures were recorded against this checkpoint (see screenshot below).

Use of colour
Checkpoint 2.1 says:
Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
Overview of results
- 2% sites failed to comply with checkpoint 2.1
- 1 page failed to comply with checkpoint 2.1
Discussion
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.
In the only checkpoint 2.1 failure noted in this study, required fields on a form were indicated solely through the use of the colour red (see screenshot below).
Dynamic content
Checkpoint 6.2 says:
Ensure that equivalents for dynamic content are updated when the dynamic content changes.
Overview of results
- 2% sites failed to comply with checkpoint 6.2
- 1 page failed to comply with checkpoint 6.2
Discussion
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 miss out on that content.
Only 1 example of the use of dynamically-generated content was noted. On the University of Queensland Orientation page, an image that acted as a link to a story about a particular student's orientation experience was randomly generated each time the orientation page loaded. Students accessing the page with a screenreader or text browser would not have been aware that different stories were linked each time the page was viewed (see screenshot below).

Conclusions
- University web sites are likely to present significant barriers to access for disabled users
- Policies governing web accessibility appear to be ineffective - at least to date
- The role of text equivalents is poorly understood
- There appears to be insufficient knowledge of accessible design practices within web teams in Australian universities
- Web publishing quality assurance procedures either do not exist or are not followed
