Disability Rights: Australian National Audit Office Better Practice Guide: Internet Delivery Decisions

Australian National Audit Office Better Practice Guide: Internet Delivery Decisions

Note: The official version of this guide is on the ANAO site www.anao.gov.au . It is posted here for convenience.

Component No 9: How to Make Government Internet Sites More Accessible

This component of the ANAO Better Practice Guide provides advice on how government managers can make government internet sites more accessible. It explains the reasons for making sites more accessible and describes the meaning of accessibility.

It also sets out how program managers can confirm that their program's sites are accessible. Some better practice sites are also identified.

Why do Commonwealth internet pages need to be accessible?

because that's what often best suits the clients (or 'service users')

For anyone who uses the online services, accessibility means better service at times and places which suit them. This is most important for clients with a disability, but more accessible services make access easier for everyone.

Remember, disability is not always a physical limitation. A client with agoraphobia (a fear of crowds or open spaces) may find a trip to a shopfront office an impossible challenge.

because it is efficient and effective to make internet based services accessible

Internet based information products and services, when properly set up, can significantly reduce the expense and time spent using products such as Braille and audiotape to reach Australians with disabilities. It can reduce the need for inefficient paper products.

Accessible design makes it easier for everyone in the community to get better and faster access whether they have a disability, including:

  • most home users, who do not have cable or ISDN internet access speeds;
  • lower income, rural or older users with even slower connections, slower modems or less than state of the art equipment; and
  • increasing numbers of users of non-PC internet devices, including hand-helds (Web Application Protocol devices, or WAPs) and mobile phones.

because the Government has decided that Commonwealth internet services must be accessible

On 21 March 2000, the Government adopted accessibility requirements for Commonwealth sites. This is part of the Government online strategy, requiring:

  • all Commonwealth departments and agencies to see their sites meet the World Wide Web Consortium's (W3C) accessibility standards from 1 June 2000;
  • all new/contracted site work to include accessibility benchmarks from 1 June 2000; and
  • all Commonwealth sites to meet W3C standards by 1 December 2000.

because the Disability Discrimination Act requires accessibility

The Disability Discrimination Act 1992 requires government bodies to provide equitable access to people with disabilities.
Commonwealth websites (and others, including commercial sites) risk exposure under the Act to complaints from anyone claiming disadvantage by lack of access. The Act requires equal access for disabled people, where it can reasonably be provided.

While other service providers may argue that providing access would 'involve unjustifiable hardship', this defence is not acceptable when administering Commonwealth laws and programs.

For anyone who uses the online services, accessibility means better service at times and places which suit them. This is most important for clients with a disability, but more accessible services make access easier for everyone.

What does accessible mean anyway?

In terms of government programs and services, accessible means available to clients in formats which are easily available, easy to use and appropriately targeted at the potential audience. For example, it might include providing:

  • audio links for blind clients;
  • pop-up screens and TTY (teletype) access for deaf clients; and
  • translations for key languages for non-English speaking background clients.

Users who cannot see, or cannot easily read print (e.g. those suffering retinal pigmentosa, or RP), or cannot distinguish colours, or hear, can receive and exchange information through the internet as readily as other users if sites and services are designed to be accessible.

In particular, blind or vision impaired people can use screen reader software and a range of programs and devices to receive web page content in speech or Braille. People who cannot read written English -due to learning or literacy difficulties or language differences-can also benefit from this ability of the internet to deliver material in different formats.

But what does accessible really mean?

The W3C standards have been government's benchmark for accessibility for Commonwealth Government sites: (see also the Australian Human Rights Commission's [the Commission] advisory note on Disability Discrimination Act compliance at www.hreoc.gov.au/disability_rights/standards/www_3.html). Government has set the W3C's Priority 1 'checkpoints' as a first stage and required Commonwealth bodies to comply.

The selected priority one checkpoints within the W3C guidelines are:

In General (Priority 1)

  • 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.
  • 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 (e.g. 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 internet products 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 (Priority 1)

  • 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 (Priority 1)

  • 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 (Priority 1)

  • title each frame to facilitate frame identification and navigation.

And if you use applets and scripts (Priority 1)

  • 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.

And if you use multimedia (Priority 1)

  • until internet delivery products 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 (e.g., a movie or animation), synchronise equivalent alternatives (e.g. captions or auditory descriptions of the visual track) with the presentation.

And if all else fails (Priority 1)

  • 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 less accessible (original) page.

Where do I get more information?

Refer to the W3C Web Content Accessibility Guidelines and accompanying Techniques for Web Content Accessibility Guidelines 1.0. The full checkpoint list including Priority 2 and 3 Guidelines is also available.

In addition to its World Wide Web Access, see the Disability Discrimination Act Advisory Notes the Commission published in December 1999.

DOFA's Guidelines for Commonwealth Information in Electronic Formats also include discussion of accessibility issues.

That's too much information—can you put it more simply?

A useful easy reference guide to some major issues is provided in the W3C Web Access Initiative's Quick Tips for Accessible Websites:

  • Images and animations. Use the alt attribute to describe the function of each visual.
  • Image maps. Use client-side MAP and text for hotspots.
  • Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
  • Hypertext links. Use text that makes sense when read out of context. For example, avoid 'click here'.
  • Page organisation. Use headings, lists, and consistent structure. Use a cascading style sheet for layout and style where possible.
  • Graphs and charts. Summarise or use the longdesc attribute.
  • Scripts, applets, and plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
  • Frames. Use NOFRAMES and meaningful titles.
  • Tables. Make line by line reading sensible. Summarise.
  • Check your work. Validate. Use tools, checklist, and guidelines at www.w3.org/TR/WAI-WEBCONTENT

How do I check if my pages are accessible?

The Bobby program (available free at www.cast.org) can give an automatic check. This should highlight major access problems. However, automated checking is not a full substitute for human judgment and human user experience in any thorough assessment of effective accessibility, and broader issues of 'useability'.

  • In all cases, and as early and extensively as possible, you should invite and act on user feedback.
  • Consider more formal testing of accessibility and useability using consumer test groups (research has indicated that effective tests can involve as few as five users).
  • Consider using consultant or employee internet experts with disabilities during site design and testing.

Users who cannot see, or cannot easily read print (e.g. those suffering retinal pigmentosa, or RP), or cannot distinguish colours, or hear, can receive and exchange information through the internet as readily as other users if sites and services are designed to be accessible.

Frequently asked questions (FAQ)

Does accessibility mean I can't use innovative or attractive design?

No. There is obviously a role for attractive visual design in ensuring that sites reach and serve their intended audience. Many people (including some people with disabilities) receive some information more effectively through graphic forms than through words. Accessibility does mean that, as far as possible, users can choose how they get the information from your page.

Does accessibility mean I need to maintain several versions of my site?

Some Commonwealth sites appear to have effectively managed several accessibility issues (as well as long download times for graphic-heavy pages) by implementing text only equivalent sites. A smaller number have implemented the W3C preferred approach, with one accessible version (but different versions of particular elements or pages where necessary). There are several reasons to adopt the single accessible site approach. A single accessible version will benefit all users. Work on 'accessibility' issues can provide a simpler, clearer, better site. Also, parallel ('text') versions may not cover all your site's accessibility issues because:

  • a text only version may still be inaccessible (for example because of errors in using frames); and
  • scripts to create a text version will not automatically render accessible versions of graphics, multimedia or formats such as Portable Document Format (PDF).

Is PDF accessible?

PDF does not, in itself, accord with accessibility guidelines. It is, however, widely used by the Commonwealth and other Australian governments. This is only acceptable if sites either:

  • test each PDF file to ensure it converts effectively to accessible formats (text or HTML) and provide links to conversion options developed by Adobe Inc (see http://access.adobe.com) to address accessibility issues with this format; or
  • provide accessible alternative versions directly on site (preferred).

PDF is, at least in its origins, essentially a graphical format, which presents access problems for people who cannot see and who are relying on screen reader software to convert text into speech or Braille.

The W3C Web Content Accessibility Guidelines recommend:

When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided...Converting documents (from PDF, PostScript, RTF, etc.) to W3C markup languages (HTML, XML) does not always create an accessible document. Therefore, validate each page for accessibility and useability after the conversion process... If a page does not readily convert, either revise the page until its original representation converts appropriately or provide an HTML or plain text version.

The proprietors of PDF have recently published a White Paper on PDF accessibility which includes guidelines for PDF accessibility. These emphasise the need for providers of documents to check that their work converts effectively.

If document providers check their documents convert effectively, by converting them to accessible formats, then such text or HTML alternatives are little extra effort to put online alongside the 'authentic' PDF version. Consequently, users aren't required (from their viewpoint, 'penalised') to do the conversion and undergo additional effort, expense or delay, together with the uncertainty of whether conversion will in fact be effective (rather than jumbled text and junk symbols, as seen on converted PDF files from a number of Commonwealth sites).

Can I use frames?

Several Commonwealth Government sites use frames as a convenient way to navigate. An example is using side bar menus in a constant screen position while the user scrolls through document content in another frame.

However, not everyone uses or can use browsers which support frames. Frames can present particular barriers for screen readers - who, for example, may not be able to find their way out of the first frame encountered to view the rest of the site.
The Web Content Accessibility Guidelines does not disbar frames. They require that frames should not prevent navigation by users who cannot see the whole page or use frames, and that a 'no frames' option should be provided. Frames are, after all, intended to improve navigability and presentation, rather than to make it difficult or impossible.

The Guidelines provide detailed advice on techniques to ensure that frames do not disable accessibility. Many of the Commonwealth sites which use frames do not comply with these requirements.

Can I use video, pictures, music and sound bytes?

Yes, but ensure that you provide a text description of the picture, video or sound track, and provide transcript and/or captioning of dialogue wherever possible.

Can I use animation and moving elements?

Yes, but you must provide an accessible alternative. Shockwave, flash animation and moving text
are not accessible to all users. Also consider why you need to use these formats on a Commonwealth site.

Fixing the whole site will take time - where do I start?

Sites must comply with the priority one guidelines as soon as possible, thereby complying with government policy. This should not prove as hard as it looks once a start is made.

The following suggested order of priority for achieving compliance with at least the Priority 1 guidelines is based on advice from a leading commentator on web page useability:

  • home page;
  • all new pages;
  • any pages required for completing important transactions on line;
  • highest traffic pages;
  • pages particularly relevant to users with disabilities; and
  • other pages.

Can you give some examples of better practice sites?

Several Commonwealth agencies have achieved significant progress in accessibility (although
further accessibility or useability improvements may be possible). These include:

Can you give examples of current problem areas?

Here are some problems identified in the Commission's December 1999 audit of Commonwealth sites, in addition to the problems with frames and PDF already discussed:

  • a page providing important information on a major government initiative used Shockwave animation. It was invisible (black) to users without the Shockwave program. An alternative (text) version was prominent on the front page, but not accessed from all pages within the site. For example, no text informed users who came directly to these pages that Shockwave was needed to read this otherwise 'black page', or that a text alternative existed and how to find it.
  • on one Commonwealth department's homepage tested, alternative text was missing for image map hot spot links and for several images serving as links, including the image link given to the Prime Ministers' home page.
  • on one Commonwealth department home page the image link for the department's contact details had alternative text saying only 'image'. Many links on the same page had alternative text saying 'click to go' – but go where, was not specified.
  • on one major agency site most pages passed automatic checking with the Bobby program, but on checking manually (as recommended by Bobby and by the World Wide Web Consortium Guidelines) for whether the alternative text gave sufficiently meaningful information, 'click here' was found as the alternative text given for numerous links. Click here for what?
  • on another department's site the alternative text for the main menu map read 'picture'.
  • a number of tested Commonwealth sites provided audio files but appear to have overlooked providing text equivalents.
  • several pages tested had dynamic content (such as a number of different headlines popping up or running across the page in turn) which was not reflected, or only partially reflected, in the static alternative text provided.
  • in some cases a text home page had been provided which passed Bobby testing for accessibility, but most pages linked from there on failed for the common reasons of lack of alternative text for images and image map hot spots. Accessibility means more than access to the home page.
  • a number of sites had text only versions, but provided links to these only from the bottom of the front page. For users of screen readers and speech output, this may involve sitting through (and perhaps paying for) minutes of listening to, and being puzzled or annoyed by, a synthesised voice intoning statements such as 'clearpixel.gif', 'spacer.gif', 'transspacer.gif', and so on as the system reads the names of decorative image files.