RMIT Training puts emphasis on ensuring all its websites are
accessible to the broadest audience possible, including users with
disabilities.
1.0 What are Accessible Web Pages?
Web pages are accessible if they can be "navigated and read by
everyone, regardless of location, experience, or the type of computer
technology used" 1 .
2.0 Australian Legislation
The Australian Human Rights and Equal Opportunity Commission 1
explains that information or services provided through the Worldwide Web
fall under the jurisdiction of the Disability Discrimination Act 1992
(DDA):
"Equal access for people with a disability in this area
[Worldwide Web] is required by the DDA where it can reasonably be
provided. This requirement applies to any individual or organisation
developing a Worldwide Web page in Australia, or placing or maintaining a
Web page on an Australian Server."
3.0 Developing for accessible content
The W3C Web Content Accessibility Guidelines
outlines checkpoints for web development in three priorities. Each
priority level is based on the checkpoint's impact on accessibility:
3.1 Priority 1
RMIT Training websites must satisfy these
checkpoints. Satisfying Priority 1 of the guidelines is a minimum
criterion for some groups of users to be able to access information
successfully.
3.2 Priority 2
RMIT Training websites should satisfy this checkpoint. Satisfying Priority 2 of the guidelines will remove significant barriers to accessing web documents.
3.3 Priority 3
RMIT Training websites may address this checkpoint.
Satisfying Priority 3 of the guidelines will improve the usability of
the website for some groups of users.
4.0 Testing for Accessibility
Following steps can support the testing of a website for its accessibility:
- Using text-based browsers (e.g. Lynx) or text-only emulators (e.g.
Firefox, Opera) will ensure developers test their website in an
environment of lowest-common technology. Content of the website should
remain accessible to users of browsers or assistive technology that
cannot display images and style sheets or make use of dynamic HTML or
client-side scripts (e.g. Javascript).
- Automated tests such as "Bobby Watchfire" or "Cynthia Says" may
help to highlight key accessibility issues, yet they should be
approached with caution: many of the W3C checkpoints cannot be validated
in an automated test but require individual analysis with consideration
of the specific circumstances.
- Screenreaders such as JAWS (free demo available) or Windows'
built-in Narrator can provide the developer with an understanding of
accessibility issues for visually disabled users. Website content may be
technically accessible, yet taken out of context may provide little
information to the user. Due to different navigation patterns of
screenreaders and their users, content of a website might be delivered
in a different order than expected.