The Australian Government Information Management Office Archive
The content on this page and other AGIMO archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.
Guide to Minimum Website Standards - Accessibility
|
This guidance has been superseded by the Australian Government Web Publishing Guide and should be used for reference purposes only. |
April 2003 edition. Contact details updated July 2004.
Chapter headings:
What is the standard, and which agency issued the standard? - Implementation requirements - Background - Key things you should know - Further Assistance - FAQ
Web Content Accessibility
What is the standard, and which agency issued the standard?
The standard for web content accessibility is the Web Content Accessibility Guidelines, which were devised by the World Wide Web Consortium (W3C). The guidelines are available at: www.w3.org/tr/wai-webcontent
The Human Rights and Equal Opportunity Commission (HREOC) has responsibility for promoting the objectives of the Disability Discrimination Act (DDA) and provides advice about the implications of the Act for website operators. Agencies should also be familiar with the following document from HREOC: World Wide Web Access: Disability Discrimination Act Advisory Notes, www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html
Implementation Requirements
From 1 June 2000, all websites were to be tested by agencies for accessibility, and all new website contracts were to include accessibility as a key performance measure. From 1 December 2000, all websites were to follow the W3C guidelines to a sufficient extent that they pass recognised tests of accessibility.
Background
The W3C guidelines explain how to make web content accessible to people with disabilities. However, following them will also make web content more available to all users, whatever hardware and software they are using to access the Internet or constraints they may be operating under. Utilising these guidelines will also help people find information on the web more quickly. These standards do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.
Key things you should know
The W3C guidelines provide a series of checkpoints that can be used to ensure that websites are accessible. Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.
Priority 1
W3C states that 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.
Level of Compliance: The Human Rights and Equal Opportunity Commission's view is that compliance with the W3C WCAG 1.0 guidelines to the Single-A level is a minimum rather than a desirable outcome. Websites that demonstrate such compliance may still be difficult or impossible to access for many users with a disability.
Priority 2
- W3C states that 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
- W3C states that 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.
Priority 1 checkpoints
These are available at: www.w3.org/TR/WAI-WEBCONTENT/checkpoint-list.html
In General -
- Provide a text equivalent for every non-text element (eg. via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations, 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.
- Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
- Clearly identify changes in the natural language of a document's text and any text equivalents (eg. captions).
- 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.
- Ensure that equivalents for dynamic content are updated when the dynamic content changes.
- Until user agents allow users to control flickering, avoid causing the screen to flicker.
- Use the clearest and simplest language appropriate for a site's content.
And if you use images and image maps ...
- Provide redundant text links for each active region of a server-side image map.
- Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
And if you use tables ...
- 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.
And if you use frames ...
- Title each frame to facilitate frame identification and navigation.
And if you use applets and scripts ...
- Ensure that pages are useable 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.
And if you use multimedia ...
- 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.
- For any time-based multimedia presentation (eg. a movie or animation), synchronise equivalent alternatives (eg. captions or auditory descriptions of the visual track) with the presentation.
And if all else fails ...
- 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.
Other documents that will assist with ensuring that websites are accessible are Core Techniques for Web Content Accessibility Guidelines 1.0, available at: www.w3.org/TR/WCAG10-CORE-TECHS/
Testing websites for accessibility
Tools such as 'Bobby' can be used to help Web authors check their web pages, and identify changes needed so users with disabilities can more easily use their pages. The 'Bobby' software is available from: http://bobby.watchfire.com/bobby/html/en/index.jsp. Ideally, users should be involved in website testing and government departments should develop appropriate strategies to ensure that their sites are tested for accessibility/usability by users with disabilities. This may involve working with companies that enlist groups of users as part of the website testing services that they offer. The Commission can provide contact details for a number of web accessibility consultants.
A range of evaluation, repair and transformation tools for web content accessibility are available at the Web Accessibility Initiative website at www.w3.org/WAI/.
In addition, some organisations may provide a website testing service and advisory service.
Further Assistance
Contact Person - David Mason, HREOC
Telephone - (02) 9284 9724
E-mail - david.mason@humanrights.gov.au
Address - Level 8, Piccadilly Tower, 133 Castlereagh Street, Sydney NSW 2000; GPO Box 5218, Sydney NSW 1042
FAQ
Q. We have placed a lot of our documents on our website in PDF format, which is not readily accessible to people with sight disabilities. Apart from converting these documents to alternative formats, which we can't afford, what can we do?
A. It is generally not desirable to convert a PDF file to HTML, since the results are likely to have formatting and other navigational information removed. Wherever possible, the original file from which the PDF is created should be used as the basis for conversion, not the PDF file itself. If an original non-PDF file is not available, organisations may need to consider options such as using OCR software to scan and edit the PDF file to produce an accessible version. The preferred format is HTML, followed by Word/RTF, and text. It is important to note that where a document is presented in HTML format, an option should be provided for the user to download the document as a single file rather than as a (sometimes large) sequence of individual pages.
Some content, such as graphs and maps, cannot be made accessible online to people who are blind or vision-impaired. In some cases it may be possible to use the HTML "Longdesc" tag to provide a verbal interpretation of pictorial content, while in other cases it may be necessary to have such content produced in accessible formats by external contractors. Departments should develop strategies for responding to requests for making content available in accessible formats, and contact information should be provided on websites so that users will be able to direct their requests to the appropriate person within the department.
Q. I'm trying to make my organisation's forms available on our website, as required by the OISO's. The only technology I've discovered for formatting complex forms for fill and print is PDF. This is not an accessible format, and means that we are not compliant with the accessibility guidelines. What do I do?
A. Although there has been some progress in making it possible for people who are blind or vision-impaired to use online PDF forms, this option is considered inaccessible for most users. It is often possible to design online forms using non-PDF techniques. See, for example, http://www.mandoforms.com, which provides guides and tools for making online forms accessible.
PDF Forms can be made more accessible if authors provide enough information from the form itself for people with disabilities to gauge the relevance of the form to them. Clients can also be given the option of submitting information the form was designed to collect back via alternative means, such as email. So for example, the boxes on the form itself should have enough information annotated to them to make it clear what the form is trying to collect, and every form should have an email contact provided on the form page itself, for free text replies from people who have accessibility issues, or who simply cant get the form to work normally.