Skip to main content

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

Australian National Audit Office Better Practice Guide: Internet Delivery

Note: The official version of this guide is on the ANAO site . 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

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

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

How do I check if my pages are accessible?

The Bobby program (available free at 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

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