Docstoc

accessibility-toolkit-v3.1.1-mar2011

Document Sample
accessibility-toolkit-v3.1.1-mar2011 Powered By Docstoc
					Victorian Government Accessibility Toolkit


eServices Unit, Information Victoria, Department of
Business and Innovation.

Version 3.1.1

March 2011
Enquiries should be addressed to –

eServices Unit
Information Victoria
Department of Business and Innovation
State Government of Victoria,
Level 20, 80 Collins Street,
Melbourne, Victoria, 3000

Email: mailto:administration@egov.vic.gov.au

September 2009

Version History
Version 1 of the Accessibility Toolkit was published by Multimedia Victoria in
July 2002. Version 2 of the Accessibility Toolkit was published by Multimedia
Victoria in June 2007. Version 3 was published by Information Victoria,
Department of Innovation, Industry and Regional Development in September
2009.
Version 3.1.1 - Links and content updated 29 March 2011



Copyright State Government of Victoria, 2009

The Accessibility Toolkit is subject to copyright. Except as otherwise permitted
under the Copyright Act 1968 you must not reproduce or transmit in any form or
by any means the Accessibility Toolkit without prior written permission of the
State Government of Victoria.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011           1
Copyright State of Victoria, 2009
                 Victorian Government Accessibility Toolkit

  Section One: Introduction to the Accessibility toolkit............................................... 7
  Section Two: Accessibility basics (business case)....................................................... 9
  What is accessibility?.................................................................................................... 9
  Why is it important to create accessible web sites? ................................................. 10
  Accessibility policy and guidelines ............................................................................ 21
  Common accessibility questions ................................................................................ 23
  Section Three: How to make a web site accessible................................................... 25
  How do you make a web site accessible? .................................................................. 25
  Building an accessible site .......................................................................................... 26
  Making an existing site accessible ............................................................................. 27
  Maintaining an accessible site.................................................................................... 30
  Incorporating accessibility into tenders.................................................................... 31
  Building an accessible site .......................................................................................... 33
  Evaluating a current site for accessibility (Evaluation phase) ............................... 38
  Fixing a current site to achieve accessibility (Implementation phase)................... 41
  Case Study 1 - Victoria Online (Department for Innovation, Industry and
  Regional Development)............................................................................................... 44
  Case Study 2 -Youthcentral (Department for Victorian Communities)................ 46
  Case Study 3 - Web Developer’s Resource Kit (Department of Education and
  Early Childhood Development) ................................................................................. 48
  Section Four: Understanding and testing Level A, AA and AAA checkpoints..... 50
  Introduction to the Level A and Level AA checkpoints .......................................... 50
  Level A, Level AA and non-essential Level AAA checkpoints ............................... 51
  General checkpoints.................................................................................................... 54
  Checkpoints on image maps....................................................................................... 67
  Checkpoints on tables ................................................................................................. 69
  Checkpoints on frames ............................................................................................... 71
  Checkpoints on applets and scripts ........................................................................... 72
  Checkpoints on multimedia ....................................................................................... 74
  If you can’t make it accessible ................................................................................... 76
  Level AA Checkpoints ................................................................................................ 77
  Checkpoint 2.2............................................................................................................. 77
  Checkpoint 3.1............................................................................................................. 78

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                        2
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
  Checkpoint 3.3............................................................................................................. 81
  Checkpoint 3.4............................................................................................................. 82
  Checkpoint 3.5............................................................................................................. 83
  Checkpoint 3.6............................................................................................................. 84
  Checkpoint 3.7............................................................................................................. 85
  Checkpoint 6.5............................................................................................................. 86
  Checkpoint 7.2............................................................................................................. 88
  Checkpoint 7.4............................................................................................................. 89
  Checkpoint 7.5............................................................................................................. 90
  Checkpoint 10.1........................................................................................................... 91
  Checkpoint 11.1........................................................................................................... 92
  Checkpoint 11.2........................................................................................................... 94
  Checkpoint 12.3........................................................................................................... 95
  Checkpoint 13.1........................................................................................................... 97
  Checkpoint 13.2........................................................................................................... 98
  Checkpoint 13.3........................................................................................................... 99
  Checkpoint 13.4......................................................................................................... 100
  Tables ......................................................................................................................... 102
  Checkpoint 5.3........................................................................................................... 102
  Checkpoint 5.4........................................................................................................... 102
  Frames........................................................................................................................ 103
  Checkpoint 12.2......................................................................................................... 103
  Forms ......................................................................................................................... 104
  Checkpoint 10.2......................................................................................................... 104
  Checkpoint 12.4......................................................................................................... 104
  Scripts and applets.................................................................................................... 105
  Checkpoint 6.4........................................................................................................... 105
  Checkpoint 7.3........................................................................................................... 105
  Checkpoint 8.1........................................................................................................... 107
  Checkpoint 9.2........................................................................................................... 109
  Checkpoint 9.3........................................................................................................... 110
  Checkpoint 4.3........................................................................................................... 111
  Checkpoint 9.4........................................................................................................... 112

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                              3
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
  Checkpoint 13.5......................................................................................................... 113
  Checkpoint 13.6......................................................................................................... 114
  Checkpoint 14.2......................................................................................................... 116
  Checkpoint 14.3......................................................................................................... 117
  Section Five: Top issues............................................................................................ 119
  Making images, image maps, maps and graphs accessible ................................... 120
  Making tables accessible........................................................................................... 122
  PDFs and accessibility .............................................................................................. 125
  Making a PDF accessible.......................................................................................... 128
  Creating accessible forms......................................................................................... 131
  JavaScript .................................................................................................................. 141
  Making splash pages accessible ............................................................................... 147
  Creating valid HTML pages .................................................................................... 149
  Creating valid CSS.................................................................................................... 154
  Page source order...................................................................................................... 159
  Page structure............................................................................................................ 162
  Ensuring sufficient colour contrast ......................................................................... 170
  Creating sites accessible to people with cognitive disabilities............................... 173
  Conducting Operating System and Browser testing.............................................. 179
  Additional accessibility features .............................................................................. 185
  Videos and accessibility ............................................................................................ 186
    What about YouTube videos?................................................................................. 186
    What about vodcasts? ............................................................................................. 186
    What about live streaming content?........................................................................ 187
    Relationship to WCAG1 checkpoints..................................................................... 187
    Complying with accessibility requirements when including video ........................ 187
    Example 1: Transcript of a video............................................................................ 188
    Further Information................................................................................................. 189
  Captioning downloadable videos ............................................................................. 190
    Relationship to WCAG1 checkpoints:.................................................................... 190
    Tools you will need................................................................................................. 190
    Using MAGpie to create captions........................................................................... 190
    Example 1: Koorie education with Learning Objects, Part 1 ................................. 192
    Further Information................................................................................................. 192
  Captioning YouTube videos..................................................................................... 193
    Relationship to WCAG1 checkpoints:.................................................................... 193
    Tools you will need................................................................................................. 193

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                           4
Copyright State of Victoria, 2009
                 Victorian Government Accessibility Toolkit
     Using MAGpie to create captions..............................Error! Bookmark not defined.
     Using Subtitle Workshop to convert the file..............Error! Bookmark not defined.
     Uploading captions to YouTube ................................Error! Bookmark not defined.
     Example 1: Koorie education with Learning Objects, Part 1 .. Error! Bookmark not
     defined.
     Further Information................................................................................................. 194
  Audio describing videos............................................................................................ 195
    Relationship to WCAG1 checkpoints:.................................................................... 195
    Tools you will need................................................................................................. 195
    Using MAGpie to create audio descriptions........................................................... 195
    Testing the audio descriptions ................................................................................ 196
    Putting the audio described video on a web site ..................................................... 196
    Example 1: Koorie education with Learning Objects, Part 1 ................................. 197
    Further information................................................................................................. 198
  Captioning vodcasts .................................................................................................. 199
    Relationship to WCAG1 checkpoints:.................................................................... 199
    Tools you will need................................................................................................. 199
    Using MAGpie to create captions........................................................................... 199
    Associate captions with the vodcast ....................................................................... 201
    Example 1: Test vodcast ......................................................................................... 202
    Example 2: Koorie education captioned vodcast.................................................... 203
    Further Information................................................................................................. 203
  Audio and podcasts ................................................................................................... 204
    Relationship to WCAG1 checkpoints:.................................................................... 204
    Tools you will need to create a podcast .................................................................. 204
    Complying with accessibility requirements when creating podcasts ..................... 204
    Example 1: A test podcast....................................................................................... 205
    Further Information................................................................................................. 205
  Flash and accessibility .............................................................................................. 206
    Relationship to WCAG1 checkpoints..................................................................... 206
    Complying with accessibility requirements when including Flash ........................ 206
    Example 1: Transcript of a Flash file...................................................................... 207
    Further Information................................................................................................. 209
  Mashups and accessibility ........................................................................................ 210
   Relationship to WCAG1 checkpoints..................................................................... 210
   Complying with accessibility requirements when including mashups ................... 210
   Example 1: Transcript of a mashup ........................................................................ 210
   Example 2: Doodle for Google Australia ............................................................... 213
   Further Information................................................................................................. 214
  Blogging and accessibility ........................................................................................ 215
    Relationship to WCAG1 checkpoints:.................................................................... 215
    Complying with accessibility requirements when creating blogs........................... 215
    Example 1: Gian Wild’s blog ................................................................................. 215
    Further Information................................................................................................. 215

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                     5
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
  Making maps and Google maps accessible............................................................. 217
   Relationship to checkpoints: ................................................................................... 217
   What about Google maps? ...................................................................................... 217
   Complying with accessibility requirements when creating maps........................... 217
   Example 1: An accessible bushfires map................................................................ 220
   Example 2: An accessible Google map .................................................................. 220
   Further Information................................................................................................. 220
  Frames and iFrames ................................................................................................. 221
    Relationship to WCAG1 checkpoints:.................................................................... 221
    What are iFrames? .................................................................................................. 221
    Creating accessible iFrames.................................................................................... 221
    Example 1: Accessible iFrame................................................................................ 222
    Further Information................................................................................................. 222
  Making Slideshare accessible................................................................................... 223
   Relationship to WCAG1 checkpoints:.................................................................... 223
   Can Slideshare presentations be embedded in a site?............................................. 223
   Creating accessible Slideshare presentations.......................................................... 223
   Example 1: Embedded Slideshare .......................................................................... 224
   Further Information................................................................................................. 224
  Facebook and accessibility ....................................................................................... 225
    Creating accessible Facebook ................................................................................. 225
    Example 1: Target 155............................................................................................ 225
    Further Information................................................................................................. 225
  Twitter and accessibility........................................................................................... 226
   Creating accessible Twitter..................................................................................... 226
   Example 1: John Brumby........................................................................................ 226
   Further Information................................................................................................. 226
  Section Six: Accessibility evaluation tools .............................................................. 227
  Page-by-page accessibility evaluation tools ............................................................ 227
  Specific accessibility evaluation tools ...................................................................... 230
  Entire site accessibility evaluation tools.................................................................. 232
  AccVerify ................................................................................................................... 233
  Cynthia Says .............................................................................................................. 238
  Firefox Web Developer Toolbar .............................................................................. 244
  The WAVE (version 4.0) .......................................................................................... 252
  Web Accessibility Toolbar ....................................................................................... 261
  Section Seven: Accessibility resources .................................................................... 269




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                           6
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Section One: Introduction to the
Accessibility toolkit
The Victorian Government Accessibility Toolkit
The Victorian Government’s Accessibility Standard 1 requires that:
    All websites must be Level AA compliant (W3C Web Content Accessibility Guidelines,
        Version 1.0)
    Where audience needs are specific, websites should become Level AAA .

This toolkit shows departments and agencies how to conform to this standard and the W3C Web
Content Accessibility Guidelines, Version 1.0. The toolkit is designed for Victorian Government
business managers and web site owners to enable them to effectively present the business case
for accessibility and manage the processes involved.

What about the Web Content Accessibility Guidelines, Version 2.0?
In December 2008, the W3C released the second version of the W3C Web Content Accessibility
Guidelines (WCAG2). According to the W3C these now supersede WCAG1. However, in Victoria,
we are still bound by the AHRC Disability Discrimination Act and the WOVG Accessibility
Standard. Both these standards still recommend the use of WCAG1 (correct as of 1st June
2009).

It is likely that, in the future, both the Disability Discrimination Act and the WOVG Accessibility
Standard will require compliance with WCAG2. However, it is not expected that sites will need to
be compliant until the end of 2011. The AHRC are working closely with Government to determine
the best strategy to introduce WCAG2.

            Should Victorian Government start using WCAG2 now?
            The short answer to this question is No. Both the AHRC and the WOVG web standards
            are still recommending compliance with WCAG1. Aspects of WCAG2, such as the
            concept of “accessibility supported” need to be defined in policy before web developers
            can begin using WCAG2. There are a number of technologies, such as PDF, Flash and
            JavaScript, which were deemed inaccessible in WCAG1. In WCAG2 the decision as to
            whether these technologies are accessible is left to policymakers such as the AHRC and
            Victorian Government.

            There will also need to be a policy decision regarding the accessibility level for which
            sites should aim. The WOVG Accessibility Standard recommends Level AA compliance
            (WCAG1). This was based on W3C information that compliance with just Level A would
            allow all people with disabilities to access the site. However, with WCAG2, the W3C is
            now stating that compliance with all levels (A, AA and AAA) is required in order for a site
            to be accessible to people with disabilities. A policy decision by the AHRC will need to be
            made as to the level of compliance that sites should attempt to meet.

            When will Victorian Government have to start using WCAG2?
            Unfortunately there is no specific answer to this question. However it can be assumed
            that once the AHRC has made the relevant policy decisions and endorsed WCAG2 that
            they will allow a period of overlap between WCAG1 and WCAG2.




1
    http://www.egov.vic.gov.au/index.php?env=-innews/detail:m1050-1-1-8-s:n-12-1-0--


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                7
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Conclusion
        Due to the policy decisions that surround WCAG2 it is not recommended that WCAG2
        be used until both the AHRC and the Victorian Government have endorsed it.

        The AHRC recommends testing with the first version of the W3C Web Content
        Accessibility Guidelines. This is still true, despite the fact that a second version of these
        guidelines has just been released as a W3C Candidate Recommendation. Once the
        AHRC have endorsed the guidelines it may be some time before sites that are compliant
        with the first version of WCAG will need to comply with WCAG 2.0.

About the author
Gian Wild has worked in the accessibility industry since 1998 when she was the accessibility
specialist on the first Australian Level AAA web site, Disability Information Victoria. Gian Wild
worked as the accessibility specialist for Melbourne 2006 Commonwealth Games, conducting
audits of the site and training Commonwealth Games staff including suppliers such as Microsoft
and Ticketmaster7. Gian wrote the original and updated Victorian Government Accessibility
Toolkit. More recently, Gian wrote a series of accessibility fact sheets for the Office for Disability.

Contents of the Toolkit
   Section One: Introduction

   Section Two: Accessibility basics (business case)
    This section covers some reasons why accessibility is important, including issues
    surrounding WCAG2.

   Section Three: How to make a web site accessible
    This section covers:
       Building an accessible site
       Making an existing site accessible
       Maintaining an accessible site

   Section Four: Understanding the W3C Accessibility Level A and Level AA checkpoints
    The W3C Accessibility Guidelines will ensure that your site contains many features that will
    assist people with disabilities. Level A and AA checkpoints cover some of the most difficult
    areas of web design and development that can make browsing a web site particularly difficult
    for people with disabilities.

   Section Five: Top issues
    When attempting accessibility conformance you may find it difficult to follow some
    accessibility guidelines. This section covers what to do in some of these situations, as well as
    addressing accessibility when using Web 2.0 technologies.

   Section Six: Accessibility evaluation tools
    Accessibility evaluation tools can be complex and often do not include adequate
    documentation or instructions. This section covers how to use the more popular accessibility
    evaluation tools.

   Section Seven: Accessibility resources
    A list of common accessibility resources.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    8
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit


Section Two: Accessibility basics
(business case)
This section introduces accessibility and describes the benefits of making web sites accessible.
The purpose is to give Victorian Government departments and agencies an understanding of how
accessible sites help people with disabilities, as well as the benefits to the wider community.

What is accessibility?
Accessibility means making web information available to all people, regardless of their ability.
Accessibility also assists people with varying means and technologies to access web information.

An accessible web site is one where the information is available:
 Without requiring a specific type of sensory input (vision, hearing etc)
 Without requiring a particular web browser
 Without requiring a particular browser plug-in or program, for example JavaScript or Flash
 In conjunction with software that people with disabilities might use
 Without relying on graphics or colour alone to provide information
 Without relying on a mouse to navigate through the site
 Without being unduly complex or using jargon

Victorian Government departments and agencies should create websites to be accessible to:
 People with disabilities
 People using older technology
 People with poor telecommunications infrastructure often in regional and remote areas
 The elderly
 People with temporary disabilities
 People with English as a Second Language




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         9
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Why is it important to create accessible web sites?

It is important to have an accessible web site for several reasons:

      Assists people with disabilities
       An accessible web site means people with disabilities can use and interact with your web
       site.

      Assists other groups that may have difficulty using the web
       An accessible web site assists other groups that may have difficulty using the web by
       reducing the complexity of the site or providing alternatives.

      Increases the usability of a site
       An accessible web site is often a more usable site by including features that make finding,
       using and interacting with a site easier.

      Accessibility is cost-effective
       An accessible web site is cost-effective because it can reduce the need to provide
       information in alternative (hard copy) formats, as well as reduce help desk queries, or
       equipment requirements.

      Accessibility increases search engine optimization
       An accessible web site allows more of its content to be crawled and available to search
       engines such as Google.

      Provides best practice examples to other Australian web sites
       An accessible Government web site provides an example that other Australian web sites can
       emulate.

      Improves public perception of Government
       An accessible web site provides good service to a larger number of people, creating a better
       return on your investment. In turn, this creates a favorable perception of Government.

      State Government has a duty to its citizens
       An accessible web site is part of our Government’s duty to the people. This duty includes
       facilitating communication to all members of the public.

      It is the law
       An accessible site complies with the Australian Human Rights Commission Disability
       Discrimination Act 2 . This Act requires that information be provided to all people without
       discriminating on the basis of disability.




2
    http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               10
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Assists people with disabilities
Approximately 20% of people in Australia 3 in 2003 had at least one type of disability that affects
their daily activities.

People with disabilities have as much right to access the information available in a web site as
any other member of the public.

The Internet gives people with disabilities the:
 Opportunity to access information and services
 Ability to access information easily
 Ability to participate in community life without fear of discrimination

When a site is accessible the following groups of people find it easier to use a site:

      People with vision impairments
       Accessible sites can be manipulated, so alternative presentations can be provided when the
       user cannot see the screen clearly, if at all.

      People with hearing impairments
       Accessible sites are written in clear and simple English and provide text equivalents for audio
       files, so people with hearing difficulties or impairments can still access all the information.

      People who have English as a Second Language (ESL)
       Accessible sites are clear and simple, and able to be understood by people whose first
       language is not English.

      People with physical impairments
       Accessible sites can be used without solely relying on one device. This means that a site can
       be navigated by keyboard, mouse or other tracking mechanism.

      People with cognitive impairments
       Accessible sites are cleanly designed using both images and text. This makes the site
       simpler and easier to use for people with cognitive impairments such as dyslexia or learning
       disabilities.

           Types of assistive technologies
           There are many programs that people with disabilities use in addition to the browser to
           access your site. These are either hardware or software tools.

           When testing with these tools it is important that you employ someone with experience
           using them. Ideally these people should use these tools for regular browsing. Able-bodied
           people tend to use assistive technologies quite differently to people with disabilities.

           The Guild of Accessible Web Designers (GAWDs) has a detailed section on assistive
           technologies:
            Keyboards and other input devices 4
            Braille and Low Vision aids 5
            Alternative pointing devices 6



3
    http://www.abs.gov.au/ausstats/abs@.nsf/0/c258c88a7aa5a87eca2568a9001393e8?OpenDocument
    http://www.gawds.org/show.php?contentid=96
4


    http://www.gawds.org/show.php?contentid=97
5




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               11
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Other aids 7

             Hardware
             These tools manipulate the keyboard or mouse; because the person with a disability
             cannot use them. Examples are:

                 Refreshable Braille display
                  A small Braille display that a blind person can use to read the screen line by line.

                 Joysticks / Trackballs
                  Pointers that manipulate the mouse onscreen for people with motor disabilities.
                  Joysticks 8
                  Trackballs 9 .

                 Alternative keyboards
                  Keyboards that have limited keys for people with motor disabilities.
                  Keyboards manipulated by fingers 10
                  Keyboards manipulated using a head-wand 11 .

             Software
             These tools change how a user interacts with the site. Examples are:

                 Screen readers
                  Programs that convert a web site to audio for people who are blind, visually impaired
                  or have dyslexia.
                  Video – Introduction to screen readers 12
                  JAWS screen-reader 13
                  Window Eyes 14

                 Screen Magnifiers
                  Programs that magnify sections of the screen for people with vision impairments.
                  Video – Screen magnification and the web 15
                  Windows Screen Magnifier 16

                 Oversized cursors
                  Large cursors for people with vision impairments.
                  “Biggy” cursors 17 .




    http://www.gawds.org/show.php?contentid=98
6


    http://www.gawds.org/show.php?contentid=99
7


8
    http://www.rjcooper.com/sam-joystick/index.html
9
    http://www.rjcooper.com/sam-trackball/index.html
10
     http://datahand.com/flashsite/home.html
11
     http://www.magicwandkeyboard.com/
12
     http://www.doit.wisc.edu/accessibility/video/intro.asp
13
     http://www.freedomscientific.com/fs_products/software_jaws.asp
14
     http://www.gwmicro.com/Window-Eyes/
15
     http://www.doit.wisc.edu/accessibility/video/screen_magnification.asp
16
     http://www.microsoft.com/windowsxp/using/accessibility/magnifierturnon.mspx
17
     http://www.rjcooper.com/biggy/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                   12
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Onscreen keyboards
                  Keyboards for people with motor disabilities used in combination with switching
                  devices.
                  On-screen keyboard 18 .

                 Programs that slow down applications for people with motor disabilities.
                  CPU Killer 19 (for Windows)

            More information

            Disability, Ageing and Carers, Australia: Summary of Findings, 2003 20
            This publication presents a summary of results from the Survey of Disability, Ageing and
            Carers (SDAC) conducted by the Australian Bureau of Statistics (ABS) throughout
            Australia, from June to November 2003. The primary objective of the survey was to
            collect information about three population groups:
                  people with a disability
                  older people (those aged 60 years and over)
                  people who provide assistance to older people and people with disabilities.

            Accessibility of electronic commerce and new service and information technologies for
            older Australians and people with a disability 21
            A report commissioned by the Australian Human Rights Commission on the ease with
            which older people and people with a disability use e-commerce.

            Beyond Accessibility: Treating Users with Disabilities as People 22
            This ‘Alertbox’ by Jakob Nielsen details how usability guidelines can substantially
            improve accessibility by making web sites and intranets support task performance for
            users with disabilities.

            How People With Disabilities Use the Web 23
            Draft summary by the W3C of how people with disabilities use web sites and web-based
            applications. Provides unique insight into the value and issues relating to web
            accessibility.

            Beyond ALT Text: Making the Web Easy to Use for Users With Disabilities 24
            This report investigates how people with disabilities use the Web. The NNGroup
            conducted usability tests of 19 web sites with people using a variety of different assistive
            technologies.

            Video Case Studies: Six Professionals with Disabilities Pursue Careers Enabled by
            Accessible Technology 25
            The video case studies feature six professionals with disabilities pursuing successful and
            satisfying careers in business and government using a wide range of accessible
            technology.

18
     http://www.rjcooper.com/onscreen/index.html
19
     http://www.cpukiller.com/
20
     http://www.abs.gov.au/ausstats/abs@.nsf/0/c258c88a7aa5a87eca2568a9001393e8?OpenDocument
21 http://www.hreoc.gov.au/disability_rights/inquiries/ecom/ecomrep.htm
22
     http://www.useit.com/alertbox/20011111.html
23
     http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/
24
     http://www.nngroup.com/reports/accessibility/
25
     http://www.microsoft.com/enable/casestudy/videos.aspx


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                13
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Assists other groups that may have difficulty using the web
Accessible sites are also easier to use for people who have difficulty browsing the web for
reasons not related to disability.

There are many groups that may have difficulty using the web. It is important not to alienate them
by presenting a confusing or overly complex site, or a site that is problematic for people with older
technology.

A growing group of people who are getting online are the elderly. It is this group of people who
are most likely to acquire disabilities, one of the most common being vision impairment. As the
population ages this will become a more pressing issue.

Some examples of groups of people who may benefit from an accessible site are:

   The elderly
    Accessible sites are easier to use for the aged who may have limited experience with the web
    and tend to have more vision impairments and other disabilities than the general population.


   People who have temporary disabilities
    Accessible sites will work better for people with temporary disabilities. For example, a person
    with a broken arm unable to use a mouse will be able to browse an accessible site using the
    keyboard.

   People who use old computers or browsers
    Accessible sites will display better on older machines such as those running Microsoft
    Windows 2000 and Internet Explorer 6.0.

   People who use a different operating system from Windows or a different browser from
    Internet Explorer
    Accessible sites will display better on Apple computers, Unix operating systems, Firefox,
    Opera and other browsers.

   People who have slow Internet connections or connect to the Internet through a phone line
    Accessible sites can be downloaded more quickly over slow modems, for instance, some
    rural areas don’t have access to ADSL and may still have a dial up connection with a
    download rate of 15kbps.

   People who do not have particular programs
    Accessible sites contain all information in the site as HTML, without relying on other
    programs. For example, a person wishing to read the Whole of Victorian Government Web
    Standards can read the standards as a web page and don’t need proprietary software such
    as Microsoft Word and Adobe Reader.

   People who use mobiles to access the web
    Accessible sites display better on new technologies such as PDAs, mobile phones etc.

   People in other countries
    Accessible sites are easier to use for people in other countries as content is separated from
    presentation and language is clear.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             14
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
            More information

            Agelight – Design Guidelines for Users of All Ages 26
            This is a set of guidelines for designing web sites to be senior-friendly and usable for
            people of all ages, especially by the elderly.

            Regional and rural issues 27
            The eGovernment Resource Centre archives all regional and rural issues highlighted in
            their eGovernment weekly newsletter.

            Usability for Senior Citizens 28
            This Alertbox discusses how the Internet enriches many seniors' lives, but most web sites
            violate usability guidelines, making sites difficult for the elderly to use.

            Web Usability for Senior Citizens 29
            This report investigates how the elderly use the Web. The NNGroup conducted three
            series of usability tests with 44 seniors. 46 design guidelines were developed based on
            the results. Please note that this report needs to be purchased ($US 125).

            Designing Web Sites for Older Users 30
            AARP has been conducting exploratory studies of its own web site to find out how well
            the site works for its intended audience. Thirty-four people participated in individual
            sessions: fifteen people in their 50s, nine in their 60s, and ten in their 70s.

            W3C Mobile Web Best Practices Guidelines 31
            This document contains specific guidelines for delivering web content to mobile devices.
            The principal objective is to improve the user experience of the Web when accessed from
            such devices.

            DEECD Mobile Web/PDA Guidelines 32
            The Department of Education and Early Childhood Development have developed their
            own set of mobile web and PDA guidelines in the form of a checklist.




26
     http://www.agelight.com/Resources/webdesign.htm
27
     http://www.egov.vic.gov.au/index.php?env=-innews/detail:m1509-1-1-8-s-0:n-455-0-0--
28
     http://www.useit.com/alertbox/20020428.html
29
     http://www.nngroup.com/reports/seniors/
30
     http://www.aarp.org/olderwiserwired/oww-features/Articles/a2004-03-03-comparison-studies.html
31
     http://www.w3.org/TR/mobile-bp/
32
     http://www.education.vic.gov.au/devreskit/webdev/mobile-pda.htm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 15
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Increases the usability of a site
Accessible web sites tend to be more usable, as many accessibility techniques have implications
for all users, not just people with disabilities.

The following are some examples of how particular accessibility techniques can assist the
general public in using your site:

      Providing a skip option to a splash screen allows users to access the content of a web site
       easily and quickly
       Splash screens can be very annoying to the veteran user; each time they attempt to access
       the site they need to watch the same animation. Allowing users to skip this splash screen can
       increase a user’s satisfaction with the site.

      Creating HTML versions of PDFs, Word documents and other download documents allow
       users to easily access information
       For users trying to access a very specific piece of content, PDFs and other download
       documents can be laborious because the user has to download the document before
       determining whether it contains the correct information. Offering HTML versions of these
       documents means the content is more easily available.

      Using style sheets to manipulate the layout and presentation of the content in a site reduces
       download requirements
       When style sheets are used for layout one style sheet usually has all the information
       necessary to style an entire site. This style sheet only needs to be downloaded by the user
       once; instead of in the markup of every page the user may visit. Fairfax Digital moved to a
       style sheet design and saved over a million dollars in download charges in the first six
       months.


             More information

             UseIt.com 33
             Jakob Nielsen’s web site on usability.

             Alertbox 34
             Jakob Nielsen provides a weekly alertbox columns on a variety of usability issues.

             Cooper.com 35
             Cooper also provides regular newsletters on usability issues

             Boxes and Arrows 36
             Journal dedicated to discussing, improving and promoting the work of the information
             architecture community.

             Gerry Gaffney UXPod 37
             Podcasts of interviews and on various different usability issues by Melbourne Usability
             Specialist, Gerry Gaffney.

33
     http://www.useit.com/
34
     http://www.useit.com/alertbox/
35
     http://www.cooper.com/content/insights/newsletters.asp
36
     http://www.boxesandarrows.com/
37
     http://uxpod.libsyn.com/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 16
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Accessibility is cost-effective
Considering accessibility during the development phase of a site ensures that the site is built to
best practice standards and maximizes efficiency. Although conforming to accessibility standards
is easier when creating a new web site, it can still be cost-effective to make a current site
accessible.

The following are some examples of how costs can be reduced by making your web site more
accessible:

      Reduces the need to provide alternative methods of information distribution
       If information is available on your web site in an accessible format then you can reduce the
       distribution of hard copy or other materials. For example, Melbourne 2006 Commonwealth
       Games had over 20,000 online volunteer applications and only 700 hard copy volunteer
       applications. The application form was a 13 page colour document and the completed hard
       copy forms needed to be entered into the database manually. The online, accessible form
       saved Melbourne 2006 Commonwealth Games a significant amount of money in printing,
       distribution and data entry costs.

      Reduces help desk queries
       If information is provided in an easy-to-understand format then help desk calls will be
       reduced. Monash University moved from a PDF form to an online form for subject
       evaluations. Help desk calls went down from approximately two hundred per semester (at
       half an hour per call) to none.

      Increases completion of information
       If information is provided in an easy-to-use format then users are more likely to complete or
       use the information. Monash University moved from a PDF form to an online form for subject
       evaluations. Completion of the form increased by X per cent.

      Can reduce the burden of site maintenance
       If a web site is built in an accessible way using templates (separating content from structure)
       then the site will be easier to maintain. Utilizing style sheets (which separate content from
       structure) instead of inline code also allows for easy maintenance.

            More information

            W3C - Financial Factors in Developing a Web Accessibility Business Case for Your
            Organization 38
            This document is one of several resources created to assist the preparation of a business
            case for the implementation of web accessibility. It describes the many business,
            technical and other benefits to the organization above and beyond the straightforward
            benefits to people with disabilities that can be achieved by applying the Web Content
            Accessibility Guidelines (WCAG 1.0) to web sites.




38
     http://www.w3.org/WAI/bcase/fin


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                17
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Increases search engine optimization
Accessible web sites contain a number of features known to improve search engine optimization.
For instance, the text in an ALT attribute is believed to be used in the Google search algorithm.
This algorithm also gives priority to text coded as headings. In addition, the title of the document
is very important to users when they view search results.

             More information

             High Accessibility Is Effective Search Engine Optimization 39
             An article on A List Apart about how complying with accessibility requirements can
             improve the search engine optimization of your site.

             Accessible Search Engine Optimization Techniques 40
             An article discussing why accessible content is more available to search engines.



Provides best practice examples to other Australian web sites
The Victorian Government acts as an example to other organizations and businesses.
Government web sites illustrate accessible solutions to problems faced by many organizations
and businesses. Conforming to W3C Accessibility Guidelines while maintaining an aesthetic and
functional web site demonstrates that it is possible to create an accessible site without
relinquishing good design.

             More information

             How Accessible Are Australian University Web Sites? 41
             This paper reports on a study of the accessibility of Australian university web sites. 98
             percent of sites failed to comply with accessibility requirements—suggesting that
             Australian university web sites are likely to present significant barriers to access for
             people with disabilities. An updated version of this study was conducted in 2007, entitled
             University website accessibility revisited 42 .

             Examples of accessible sites 43




39
     http://www.alistapart.com/articles/accessibilityseo/
40
     http://juicystudio.com/article/accessible-seo.php
41
     http://ausweb.scu.edu.au/aw03/papers/alexander3/
42
     http://ausweb.scu.edu.au/aw07/papers/refereed/alexander/paper.html
43
     Link to last page of Business Case


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               18
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Improves public perception of Government
Easy to use sites will be visited and used more often than difficult to use sites. Making your site
accessible will encourage use by everyone, irrespective of their abilities.

            More information

            Beyond Accessibility: Treating Users with Disabilities as People 44
            This ‘Alertbox’ by Jakob Nielsen details how usability guidelines can substantially
            improve accessibility by making web sites and intranets available to users with
            disabilities.

            W3C - Social Factors in Developing a Web Accessibility Business Case for Your
            Organization 45
            This document is one of several resources created to assist the preparation of a business
            case for the implementation of web accessibility. It describes the many business,
            technical and other benefits to the organization above and beyond the straightforward
            benefits to people with disabilities that can be achieved by applying the Web Content
            Accessibility Guidelines (WCAG 1.0) to web sites.

            Examples of accessible sites 46




Government has a duty to the people
Government has a duty to provide information to its constituency. A Government audience
consists of a cross-section of the general public, unlike businesses who can choose to be more
specific in their target market. Thus, it is important that Government web sites are as inclusive as
possible and are reflective of all their constituents.

Government has a duty of care to provide a long-term, sustainable public infrastructure (including
web) that is socially useful, available and non-discriminatory 47 .

Providing accessible web sites also raises the awareness in the general public of the needs of
people with disabilities.

            More information
            Whole of Victorian Government Web Standards 48




44
     http://www.useit.com/alertbox/20011111.html
45
     http://www.w3.org/WAI/bcase/soc
46
     Link to last page of Business Case
47
     Tom Worthington, Olympic Failure: A Case for making the Web Accessible - http://www.tomw.net.au/2001/bat2001.html
48
     http://www.egov.vic.gov.au/index.php?env=-categories:m390-1-1-8-s&reset=1


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                             19
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

It is the law

The following section is for information only; it should not be used as a substitute for legal advice.

The Australian Human Rights Commission (AHRC) investigates discrimination on the grounds of
race, colour, ethnic origin, racial vilification, sexual preference, gender, marital status, pregnancy,
or disability 49 . All web site owners have an obligation to make information available to all
members of the public without discrimination.

The Australian Human Rights Commission Disability Discrimination Act 50 requires that information
within web sites are available to all people regardless of disability:

            “Provision of information and other material through the Web is a service covered by the DDA. Equal access
            for people with a disability in this area is required by the DDA where it can reasonably be provided…This
            requirement applies to any individual or organisation developing a World Wide Web page in Australia, or placing
            or maintaining a web page on an Australian server…whether provided for payment or not.”
                                                                                                                 51
            HREOC. Version 3.1 May 1999. World Wide Web Access: Disability Discrimination Act Advisory Notes .

If your site does not conform to accessibility guidelines then necessary information may not be
available to certain people. If this is the case you may have breached the Disability Discrimination
Act and a case of discrimination could be brought against you. One occurrence of this was
Maguire vs. SOCOG (Sydney Organizing Committee for the Olympic Games).


            What happened in the SOCOG case?
            The case of Maguire vs. SOCOG is one example of a site owner being sued for having
            an inaccessible site.

            The Sydney Organizing Committee for the Olympic Games (SOCOG) was found to have
            acted in a discriminatory and unlawful manner by not presenting an accessible web site.
            It was argued that the Sydney Olympics web site was designed to give a wide-ranging
            user population, including people with disabilities, access to one of the world’s biggest
            sporting and cultural events.

            The original complaint was that the web site was not accessible to people with vision
            impairments. The result was that vision-impaired users could not access ticketing
            information, event schedules or postings of event results.

            The court determined that the complaint was correct and SOCOG was found guilty of
            breaching the Disability Discrimination Act and fined $20,000. Their legal fees were in
            excess of half a million dollars.

            For more information on the SOCOG case see the eGovernment Resource Centre -
            HREOC decision regarding Bruce Maguire versus SOCOG’s web site 52 .




49
     http://www.humanrights.gov.au/about/index.html
50
     http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html
51
     http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html
52
     http://www.egov.vic.gov.au/index.php?env=-innews/detail:m427-1-1-8-s:n-882-1-0&n_event=


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                 20
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
            More information

            Olympic Failure: A Case for Making the Web Accessible 53
            The details of the Maguire vs. SOCOG case and its global implications for government
            policy and commercial practice on the Internet are examined by one of the expert
            witnesses who gave evidence to the commission.

            World Wide Access: Disability Discrimination Act Advisory Notes 54
            Australian Human Rights Commission, Disability Discrimination Act web advisory notes.

            Government warned on Web site discrimination 55
            The man who sued SOCOG over web site accessibility has warned that rising complaints
            against Government web sites' use of PDF documents are being made under
            Commonwealth law.

Accessibility policy and guidelines


        The Accessibility Standard
The Whole of Victorian Government Accessibility Standard 56 was released in October 2004 and
superseded the WWW Accessibility (Disability) Policy released in September 2000. This standard
specifies that Victorian Government departments and agencies should design their web sites to
promote equal access for people with disabilities. It was recently updated to require:
 All websites must be Level AA compliant (W3C Web Content Accessibility Guidelines,
   Version 1.0)
 Where audience needs are specific, websites should become Level AAA as appropriate

       W3C Web Content Accessibility Guidelines
The Web Content Accessibility Guidelines were written by the World Wide Web Consortium
(W3C), which is an international organisation committed to making web sites more accessible.
The Victorian Government and the Australian Human Rights Commission recommend
compliance with the first version of these guidelines.

The W3C Web Content Accessibility Guidelines, Version 1.0 57 contain the following fourteen
guidelines:

1.     Provide equivalent alternatives to auditory and visual content. 58
2.     Don’t rely on colour alone. 59
3.     Use markup and style sheets and do so properly. 60
4.     Clarify natural language usage. 61
5.     Create tables that transform gracefully. 62


53
     http://www.tomw.net.au/2000/bat.html
54
     http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html
55
     http://www.computerworld.com.au/index.php?id=973165449&eid=-180
56
     http://www.egov.vic.gov.au/index.php?env=-innews/detail:m391-1-1-8-s:n-12-1-0&n_event=
57
     http://www.w3.org/TR/WCAG10/
58
     http://www.w3.org/TR/WCAG10/#gl-provide-equivalents
59
     http://www.w3.org/TR/WCAG10/#gl-color
60
     http://www.w3.org/TR/WCAG10/#gl-structure-presentation
61
     http://www.w3.org/TR/WCAG10/#gl-abbreviated-and-foreign
62
     http://www.w3.org/TR/WCAG10/#gl-table-markup


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             21
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
6.     Ensure that pages featuring new technologies transform gracefully. 63
7.     Ensure user control of time-sensitive changes. 64
8.     Ensure direct Accessibility of embedded user interfaces. 65
9.     Design for device-independence. 66
10.    Use interim solutions. 67
11.    Use W3C technologies and guidelines. 68
12.    Provide context and orientation information. 69
13.    Provide clear navigation mechanisms. 70
14.    Ensure that documents are clear and simple. 71

            Web Content Accessibility Guidelines accessibility levels
            The Web Content Accessibility Guidelines contain checkpoints that are given one of three
            priority rankings.

            The three levels are as follows:

                Level A
                 Some user groups will find accessing the site quite difficult.
                 Level A is a minimum requirement for State Government departments and agencies.
                 Requirement: all Level A checkpoints are met.

                Level AA
                 Some user groups will find accessing the site somewhat difficult.
                 Level AA is a minimum requirement for State Government departments and
                 agencies.
                 Requirement: all Level A and AA checkpoints are met.

                Level AAA
                 All user groups will be able to access site information easily.
                 Requirement: all Level A, AA and AAA checkpoints are met. Level AAA checkpoints
                 should be attempted when the audience is a specific group or groups of people with
                 disabilities.




63
     http://www.w3.org/TR/WCAG10/#gl-new-technologies
64
     http://www.w3.org/TR/WCAG10/#gl-movement
65
     http://www.w3.org/TR/WCAG10/#gl-own-interface
66
     http://www.w3.org/TR/WCAG10/#gl-device-independence
67
     http://www.w3.org/TR/WCAG10/#gl-interim-accessibility
68
     http://www.w3.org/TR/WCAG10/#gl-use-w3c
69
     http://www.w3.org/TR/WCAG10/#gl-complex-elements
70
     http://www.w3.org/TR/WCAG10/#gl-facilitate-navigation
71
     http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            22
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Common accessibility questions


        What about Web Content Accessibility Guidelines, Version 2.0
The Web Content Accessibility Guidelines, Version 2.0 are the most recent set of accessibility
guidelines released by the W3C. Released in December 2008, they – according to the W3C –
supersede WCAG1. However neither the Australian Human Rights Commission or the Victorian
Government have endorsed WCAG2 and both federal and state Government is still
recommending the use of WCAG1.

For up-to-date information on the current Australian policy decisions surrounding WCAG2 see:
 Australian Human Rights Commission Disability Discrimination Act Web Advisory Notes 72
 Whole of Victorian Government Accessibility Standard 73
          Does conforming to accessibility guidelines mean excluding Flash, JavaScript and
          other technologies?
No. Many technologies used in web sites include inbuilt accessible features. Some examples are:
 Images can include an ALT attribute to describe the image
 Macromedia Flash, JavaScript and Java have a number of accessibility features included in
     the products
 You can use JavaScript for navigation so long as you also provide a server-side fallback such
     as text links for navigational purposes. For example, you could use JavaScript so that a user
     can expand or collapse menus without refreshing the page, but if a user has JavaScript
     disabled then the menus could default as fully expanded. Therefore the user would still be
     able to navigate around the site. This toolkit provides more information on JavaScript on page
     141.
          Are PDFs accessible now?
No. In recent years Adobe has added a number of accessibility features to PDF, however it is still
necessary to provide a text, Word or HTML alternative. For more information see PDFs and
accessibility. Also, these accessibility features need to be specifically added to a PDF which
requires some skill and effort. For more information see how to create an accessible PDF.
However, remember that even if your PDF is accessible you will need to provide an
alternative.
          Are Word documents accessible now?
In some cases, yes. However, it is always preferable to provide an HTML or text version of the
content. If you have images in your Word document you should add ALT attributes and your
Word document should use proper Word specified headings. See the Australian Human Rights
Commission 2008 media release on accessible formats.
          Does an accessible site mean a text-only site?
No. Contrary to popular opinion, a text-only web site is not necessarily an accessible web site.
People with cognitive disabilities such as Acquired Brain Injury (ABI) or learning disabilities such
as dyslexia, often have difficulty with text-rich sites. For these people, a text-only web site is just
as inaccessible, as a graphics-only (without ALT attributes) web site is to someone who is blind.
This toolkit provides more information on making a site accessible to people with cognitive
disabilities..
          Are accessibility and usability the same thing?
Accessibility and usability both focus on ensuring that people can effectively and easily use a web
site. The difference is that accessibility's primary focus is on people with disabilities.

Usability is the effectiveness, efficiency and satisfaction with which users can achieve tasks in a
particular environment, in this case, on the web. High usability means a system is:


72
     http://www.hreoc.gov.au/disability_rights/standards/WWW_3/www_3.html
73
     http://www.egov.vic.gov.au/index.php?env=-innews/detail:m1050-1-1-8-s:n-12-1-0--


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              23
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
      easy to learn and remember;
      efficient,
      visually pleasing and fun to use; and
      quick to recover from errors.

For more information on usability, see Jakob Nielsen’s UseIt.com 74 .

Improving usability can make a site accessible. Enhancing accessibility will often also improve
usability.




74
     http://www.useit.com/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            24
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Section Three: How to make a web site
accessible
How do you make a web site accessible?
Accessibility is an issue that needs to be considered when:

      Building a site
       Accessibility should be considered from project conception and thoroughly tested throughout
       and prior to going live.

      Updating a site
       Accessibility problems can be addressed specifically or as part of broader site changes for an
       existing site.

      Maintaining a site
       Even static sites have constantly changing content which can inadvertently introduce
       accessibility problems. Accessibility should be built into the site maintenance quality
       assurance process and accessibility audits conducted on an annual basis.

To make a web site accessible you must follow version 1.0 of the W3C Web Content Accessibility
Guidelines (WCAG), 75 .




75
     http://www.w3.org/TR/WCAG10/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            25
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Building an accessible site

You need to address accessibility in a variety of ways; through design, written content and code.
This may marginally increase the time and cost of site development. Experience in the US
Government suggests that meeting accessibility guidelines adds less than 5% to the cost of site
development. Considering accessibility issues at the design stage delivers much better design
outcomes than fixing a pre-existing site and is likely to be a lot cheaper. This toolkit provides
information on developing a tender for building an accessible web site..

When building an accessible site there are issues that need to be addressed at three different
stages of the web development life cycle:

      Design
       This involves designing the look and feel of the site. This is the stage to consider accessibility
       issues relating to the layout of the navigation and content and the use of colours and
       graphics.

      Development
       This involves coding or building the site according to an agreed design specification. It is at
       this stage that the technical and coding requirements for accessible design are incorporated.

      Content
       This involves inserting the content (text and images) onto the site. Accessibility issues
       relating to content and its presentation are considered at this stage. Sometimes content and
       development are completed at the same time.

See Checklist – Building a site to achieve accessibility conformance for a list of accessibility
requirements organized by design, development and content.

The W3C has written a document called Selecting and Using Authoring Tools 76 which can assist
you in deciding what tools to use when building your site.




76
     http://www.w3.org/WAI/EO/Drafts/impl/software5.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                26
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Making an existing site accessible

There are several stages to making a site accessible:

   Site Evaluation
    This involves looking at the site in relation to each of the relevant accessibility checkpoints
    and identifying accessibility errors.

   Implementation
    This involves implementing specific changes to conform to W3C Web Content Accessibility
    Guidelines, Version 1.0.

   Conformance
    This involves testing the site to ensure accessibility conformance has been achieved.

These stages are detailed below.
       Site Evaluation

        Objective
        The Site Evaluation phase will determine how well your site currently conforms to the
        W3C Web Content Accessibility Guidelines (WCAG), version 1.0.

        Why do you do it?
        It is important to test all pages in a site to identify all accessibility failures. At the
        conclusion of the Site Evaluation phase you will know which checkpoints the site has
        failed. If you do not test all pages of your website, you may not have a true picture of your
        conformance to the guidelines. Do not assume a sample of pages is representative of
        your entire site, particularly if you operate a large, varied site.

        How do you do it?
        In some cases you will be able to identify a failure in the Site Evaluation phase and
        extrapolate the issue to the rest of the site; however in other cases you will need to test
        every single page for conformance to a particular checkpoint. This toolkit provides
        information on accessibility evaluation tools. You cannot claim site conformance without
        checking the entire site.

        Some guidelines need to be tested manually, whether this is by checking code or
        checking that the site displays as intended.

                 Which pages to test
                 Although you should test all pages in the site, sometimes this is not feasible. This
                 section takes you through which pages on the site to test.

                    Browse the site
                     Ensure you are thoroughly acquainted with the entire site and its contents.

                    Identify top level pages
                     You should test all top-level pages and the home page.

                    Identify all pages that utilize a different template
                     You should test a variety of pages from different templates.

                    Identify all pages that use alternative technologies
                     You should test all pages that use JavaScript, Flash, etc (if they are not used
                     throughout the site).

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                27
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

                          Identify forms and other interactive components
                           You should test all forms, search functions and any other interactive
                           components.

                          Sample of content pages
                           You should test a variety of pages from different contributors.

                          Popular pages
                           Identify these from your web statistics – they may be different from pages
                           you consider important.

            Example
            How your site is built determines how much testing will be required. For example, you
            might determine that an ALT attribute is missing on the header of a page. If the image is
            part of a template then you only need to note this once for pages of this template type. If
            the image is not part of a template and instead coded into each page of the website, then
            you will need to test each and every page.

            Deliverable
            At the conclusion of the Site Evaluation phase you will be able to determine exactly
            where on each page each checkpoint has failed.

            Implementation

            Objective
            The Implementation phase is where changes are made to ensure the website conforms
            to WCAG 1.0. The changes that are required were identified in the Site Evaluation phase.

            Why do you do it?
            Correcting accessibility issues on your site will help you conform to WCAG 1.0.

            How do you do it?
            See the Level A and AA Checkpoints 77 for more information on how to implement
            specific checkpoints. See the Checklist - Testing a current site for accessibility
            conformance (implementation) for information on which checkpoints should be
            implemented in which order.

            Example
            Your Site Evaluation phase might determine that an ALT attribute is missing from an
            image found on every page. If that image is not part of a template - and therefore coded
            separately into each page - you would need to add the appropriate ALT attributes to each
            page. In some instances this might be rectified easily through a global search and
            replace, but do not rely on this being the case or you may break your HTML code.

            Deliverable
            At the conclusion of the Implementation phase you will have created a fully or partially
            accessible website, depending on your accuracy in identifying the issues and
            implementing the fixes.

            Conformance

            Objective



77
     Level A Checkpoints section


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  28
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
           The Conformance phase will determine whether your site now conforms to the W3C Web
           Content Accessibility Guidelines.

           Why do you do it?
           Final testing is essential to ensure that all accessibility changes have been implemented
           as required.

           How do you do it?
           The conformance process is similar to the Site Evaluation process, however it is
           necessary only to test those areas of non-conformance identified in the testing phase
           (this is called regression testing). Where a change has been made through a template it
           is only necessary to test that change once for accessibility conformance. Remember that
           your site-wide conformance is only as good as the depth and quality of your Site
           Evaluation.

           Deliverable
           At the conclusion of the Conformance phase you will have an accessible site. Once you
           are sure that the site is Level AA accessible you can add the W3C logo or equivalent text
           to your site. You can add the logo to:
                 the home page of your site;
                 the ‘About the Site’ page (or equivalent); or
                 all pages on your site.

           W3C Conformance
           Information on conformance can be found on the W3C site: Conformance claims 78.




           Specifying conformance to the W3C Web Content Accessibility Guidelines

                           W3C AA Level logo                              W3C AA Level text

           Insert the following code into the site. For more    Insert the following text in the necessary
           information see adding the Level AA logo 79          place on the site.

           <a
           href="http://www.w3.org/WAI/WCAG1AA-                 “This site conforms to W3C's "Web
           Conformance" title="Explanation of                   Content Accessibility Guidelines 1.0",
           Level Double-A Conformance"> <img                    available at
           height="32" width="88"                               http://www.w3.org/TR/1999/WAI-
           src="http://www.w3.org/WAI/wcag1AA"                  WEBCONTENT-19990505, level AA.”
           alt="Level Double-A conformance
           icon, W3C-WAI Web Content
           Accessibility Guidelines 1.0"></a>




78
     http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#Conformance
79
     http://www.w3.org/WAI/WCAG1-Conformance.html#level-AA


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                   29
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Maintaining an accessible site


        When you are maintaining a site that meets WCAG 1.0 you need to consider the
        following:

           Content author training
            How your content authors are trained will depend on the type of website Content
            Management System (CMS) or authoring tool in use. Some accessibility
            requirements may be automated and others may require manual changes.

           Annual audits
            It is important to perform annual accessibility audits of the site to ensure all areas
            conform to accessibility standards.

        Content author training
        Once your site is accessible it is important that it remains so. Training content authors in
        maintaining accessibility standards should be conducted by someone who:
         is familiar with your site;
         has accessibility knowledge and experience; and
         is experienced in training methods.

        For information on what checkpoints should be covered in training see the Content
        Checklist.

        Annual audits
        The scope of your annual audit will depend on how much the site has changed since it
        was last audited for accessibility conformance. This is dependent on several factors:
         how many people create content for the site;
         how much information has been added to the site;
         the type of information added to the site; and
         any new functionality added to the site.

        Performing an annual audit is similar to conducting testing of a current site, however if
        content authors have been trained properly the number of accessibility errors identified
        should be minimized.

        It is important that at the conclusion of an annual audit that all content authors meet to
        discuss recurring issues within the site and share their collective knowledge. Issues
        identified in the current audit should be priority checkpoints for the following year.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               30
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Incorporating accessibility into tenders


Accessibility is a niche area and not all designers and developers have accessibility knowledge.
Accessibility is a requirement that needs to be incorporated into all tenders; you cannot assume
that the suppliers you have chosen will automatically have the accessibility experience required to
complete your project in compliance with WCAG 1.0.

        Building a new site to accessibility conformance

        When building a new website there are two ways to ensure that it is built in compliance
        with the W3C Web Content Accessibility Guidelines which are to:
         hire suppliers with accessibility experience; and
         have an accessibility specialist complete an audit of the site at the earliest stages of
            the project.

        Unless your supplier has specifically hired an accessibility specialist to consult on the
        project, it is always a good idea to get the website audited by an independent
        accessibility professional.

        Hire suppliers with accessibility experience

        When hiring designers or developers, or contracting a development company, you cannot
        assume that they have accessibility experience even if they profess to do so. Always ask
        for examples of previous work and conduct audits of these sites yourself checking for:
         the use of style sheets instead of tables for layout;
         valid HTML;
         heading tags;
         ALT attributes on images;
         reading order;
         field labels;
         headers on data tables;
         whether the site works with style sheets disabled; and
         whether the site works with Flash, JavaScript or Java disabled.

        The last two points of the above list are, in particular, a very fast way to check the
        accessibility of a website.

        For more information on how to conduct these tests using automated testing tools see
        the Accessibility Evaluation tools section

        Have an accessibility specialist complete an audit of the website

        When building a website there are particular stages in the web development lifecycle
        where accessibility measures must be included. Accessibility should never be an
        afterthought that is left to the end of a build. As a general rule, accessibility specialists
        should:
         complete an accessibility audit of the initial design;
         train developers in accessibility (where required);
         train content authors in accessibility (where required);
         complete an accessibility audit of the templates of the site;
         complete an accessibility audit of the finished site; and
         complete a final audit of errors found in the accessibility audit of the finished site.



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  31
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Using the suppliers’ accessibility specialist

        Some development companies have accessibility specialists on staff or contract
        accessibility advice to people specialized in the area. If this is the case most of the time
        you will not need to hire an independent accessibility specialist to complete an audit of
        the site. However, in this case, there are some things you should do to ensure that the
        accessibility specialist hired by the development company is giving you unbiased advice.
        Before accepting the specialist:
         request their credentials;
         request that they report directly to you;
         include specific accessibility deliverables (such as an accessibility audit on the
            design) as milestones in the project;
         request that you receive copies of all their reports; and
         clarify that it is the suppliers’ responsibility to fix all accessibility errors.

        There are sometimes instances where accessibility needs to be compromised in lieu of
        other business requirements, such as the use of a particular CMS or authoring tool. In
        these cases it is always important to liaise directly with the particular accessibility
        specialist to determine the best solution.

        Hiring an independent accessibility specialist

        When a supplier lacks accessibility experience, and has not hired an accessibility
        specialist to consult on your project, it is important to get your site audited by an
        independent expert. When briefing this accessibility specialist you should clarify with
        them:
         the accessibility level required;
         whether the site has any specific audience types e.g. migrants;
         the CMS or authoring tool being used;
         the supplier;
         the timeframe; and
         all complex areas of the site, such as forms, Flash files or PDFs.

        When deciding on a particular accessibility specialist you should consider:
         how much experience the accessibility specialist has and who exactly will be
           completing the work;
         how much the accessibility specialist relies on automated evaluation tools;
         how the results will be provided. Will a report of findings be presented, or will these
           also include recommendations? Will the report include all instances of a particular
           accessibility violation or only examples of particular violations;
         whether the accessibility specialist will work with the developers to come up with
           appropriate solutions; and
         whether the accessibility specialist will consider workarounds to particular violations
           that cannot be addressed (e.g. a CMS not producing valid code).




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            32
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Building an accessible site


        To build an accessible website efficiently and cost-effectively, it is important to consider
        particular accessibility measures at particular stages in the web development life cycle.
        The following explains how this can be achieved.

        Building an accessible site – design checklist
        During the design phase it is important to consider how the users will navigate through
        the site and whether there are any areas where add-ons are essential to the functionality.

        Design checklist                                              Yes              No
        Checkpoints 1.1, 1.2 and 1.3: Identify all non-text
        elements being incorporated in the design. Consider
        if they can be rendered as text: using style sheets
        instead of images to create the visual effect. Develop
        text equivalents for all remaining non-text elements.
        Checkpoint 2.1: Make sure you do not use colour as
        the only way in which information is conveyed
        Checkpoint 6.1: Make sure the site will be readable
        and usable if style sheets are turned off
        Checkpoint 6.2: Identify any content that will be
        presented dynamically and consider how a static
        equivalent will be provided.
        Checkpoint 6.3: Ensure the design has been
        developed to ensure the site still functions and that
        users can navigate through the site if JavaScript,
        Flash and other programs are turned off or not
        supported
        Checkpoint 6.3: Make sure that forms and Search
        options are still usable and can be submitted if
        JavaScript is turned off or not supported
        Checkpoint 6.3: Make sure all forms have visible
        Submit buttons
        Checkpoint 9.1: Ensure that any image maps can be
        delivered as client-side image maps not server-side
        image maps.
        Checkpoint 2.2 Ensure that colour contrast is
        sufficient for all content in images
        Checkpoint 3.5: Use headings and nest them
        appropriately
        Checkpoint 10.1: Include an icon (with appropriate
        ALT attribute) to warn users of links that open in a
        new window.
        Checkpoint 12.3:Divide large blocks of information
        into more manageable groups where natural and
        appropriate, by using headings, data tables and lists


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             33
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 13.1: Clearly identify the target of each
        link. Do not use ‘more’ or ‘click here’ as link text.
        Checkpoint 13.3: Include a site map, A- Z index or
        table of contents that is linked from every page
        Checkpoint 13.4 and 13.5: Create consistent
        navigation across all pages
        Checkpoint 10.2: Ensure all fields have descriptive,
        visible field labels
        Checkpoint 7.2: Do not use blinking
        Checkpoint 7.3: Do not use movement unless you
        have provided a means to stop the movement
        Checkpoint 13.6: Provide visible skip navigation links
        Checkpoint 14.2: Use graphics and audio to
        complement text
        Checkpoint 14.3: Ensure consistent presentation
        across the site




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   34
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Building an accessible site – coding checklist
        Many HTML tags have a number of accessibility features and it is important that these
        are utilized during this stage.

        Coding Checklist                                          Yes             No
        Checkpoint 1.1: Make sure all non-text elements
        have a text equivalent - e.g. ALT attributes for
        images, text transcripts for audio files etc.
        Checkpoint 1.1: Make sure that ornamental or spacer
        images have empty ALT attributes (eg. alt=””)
        Checkpoint 1.1: Make sure there are alternatives to
        information difficult to access (such as PDFs)
        Checkpoint 1.2: Make sure that all links in server-side
        image maps are replicated as text links elsewhere on
        the same page
        Checkpoint 1.3: Make sure audio descriptions are
        provided for visual content etc in a video, and ensure
        a text equivalent is provided
        Checkpoint 1.4: Make sure any time-specific
        presentation includes equivalent alternatives
        synchronized with the presentation
        Checkpoint 2.1: Identify where colour has been used
        to convey important information and find an
        alternative way to convey the information
        Checkpoint 5.1 and 5.2: Make sure all data tables
        have coded row and column headers using the TH ID
        and TD HEADER attributes.
        Checkpoint 6.1: Make sure the site will be readable
        and usable if style sheets are turned off
        Checkpoint 6.2: Make sure that where content is
        dynamically generated that a static version is
        provided that is updated at the same time
        Checkpoint 6.3: Make sure the site still functions and
        that users can navigate through the site and access
        all information and functionality if JavaScript, Flash
        and other programs are turned off or not supported
        Checkpoint 6.3: Make sure that forms and Search
        options are still usable and can be submitted if
        JavaScript is turned off or not supported
        Checkpoint 10.2: Make sure that all fields have
        appropriate labels and that they are positioned
        immediately to the left or immediately above the
        relevant field (or immediately to the right or
        immediately below a radio button or checkbox)
        Checkpoint 12.4: Make sure that all field labels are
        associated with the relevant field using the FOR and
        ID attributes.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          35
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 7.1: Make sure there are no flickering
        images in the site
        Checkpoint 9.1: Make sure client-side image maps
        are provided instead of server-side image maps
        wherever possible
        Checkpoint 12.1: Make sure frames are not used
        unless absolutely necessary. Make sure there is an
        alternative version of any content presented in a
        frame or iframe
        Checkpoint 3.1: Do not use images where text or
        code could be used instead. For example, avoid
        images of text, or image bullets (unless the image is
        coded in the style sheet)
        Checkpoint 3.2: Ensure all pages validate to the W3C
        HTML Validator and the W3C CSS Validator
        Checkpoint 3.3: Use style sheets, instead of tables to
        control layout and presentation.
        Checkpoint 3.4:Use relative rather than absolute
        units in tables and style sheet property values.
        Checkpoint 3.5: Code headings using H1, H2, H3 etc
        and specify the presentation of the headings using
        the style sheet.
        Checkpoint 3.6: Code lists properly, ending each item
        with a proper end tag.
        Checkpoint 3.7: Use Q and BLOCKQUOTE to
        markup quotations.
        Checkpoint 3.7: Do not use BLOCKQUOTE to indent
        text
        Checkpoint 7.4: Do not create periodically refreshing
        pages.
        Checkpoint 7.5: Use the server to perform redirects.
        Checkpoint 11.2: Use <EM> instead of <I> and
        <STRONG> instead of <B>
        Checkpoint 13.2: Include metadata.
        Checkpoint 12.4: For fields, use the LABEL FOR and
        ID tags
        Checkpoint 6.4: Ensure all JavaScript controls can be
        used by the keyboard or the mouse
        Checkpoint 4.3: Specify the language in the HEAD of
        the page
        Checkpoint 9.4: Ensure that the order of the code
        matches the order of the page with style sheets
        turned on
        Checkpoint 13.6: Include a visible skip navigation
        link.

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   36
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Building an accessible site – content checklist
        During the content phase you need to ensure that all information and language is
        presented as clearly as possible.

        Content Checklist                                          Yes           No
        Checkpoint 1.1: Make sure all non-text objects have
        a text equivalent - e.g. ALT attributes for images, text
        transcripts for audio files
        Checkpoint 2.1: Make sure you do not use colour as
        the only means to convey information
        Checkpoint 4.1: Make sure all changes in language
        are identified in the code
        Checkpoint 6.2: Make sure that where content is
        automatically generated that a static version is
        provided that is updated at the same time
        Checkpoint 14.1: Make sure your content is clear and
        concise
        Checkpoint 3.5: Use headings and nest them
        properly
        Checkpoint 12.3: Divide large blocks of information
        into more manageable groups where natural and
        appropriate, using tables, headings and lists.
        Checkpoint 13.1: Clearly identify the target of each
        link. Do not use ‘more’ or ‘click here’ or URLs as link
        text.
        Checkpoint 14.2: Use additional graphics and audio
        to supplement textual content.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                     37
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Evaluating a current site for accessibility (Evaluation phase)
        When you are performing a site evaluation it can be easier to complete the checkpoints in
        order. For example, if none of the images have ALT attributes there is no point testing
        whether the ALT attribute is equivalent to the image.

        Evaluating a current site for accessibility – Cynthia Says
        Cynthia Says can automatically detect where the site has failed some checkpoints. For
        more information on see the section on how to test using Cynthia Says.

        Cynthia Says                                                 Yes          No
        Checkpoint 1.1: Do all images have ALT attributes?
        Checkpoint 1.1: Do all objects have alternative
        content?
        Checkpoint 1.1: Do all buttons in forms have ALT
        attributes?
        Checkpoint 1.1: Do all image map links have ALT
        attributes?
        Checkpoint 6.2: There are no frames?
        Checkpoint 3.4: Have only relative units been used in
        tables or in style sheets?
        Checkpoint 3.6: Are all lists correctly coded?
        Checkpoint 7.4: There is no auto-refresh?
        Checkpoint 7.5: Redirects are all performed by the
        server?
        Checkpoint 11.2: There are no deprecated features
        of W3C technologies?
        Checkpoint 13.2: Metadata is provided
        Checkpoint 12.4: Fields have been labeled with
        LABEL FOR and ID.
        Checkpoint 6.4: Ensure JavaScript provide keyboard
        event handlers as well as mouse event handlers
        Checkpoint 4.3: The primary language has been
        coded




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        38
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Evaluating a current site for accessibility – Firefox Web Developer Toolbar

        For more information see the section on how to test using the Firefox Web Developer
        Toolbar.

        Firefox Web Developer Toolbar                                        Yes           No
        Checkpoint 1.1: Is the site readable if images are
        turned off?
        Checkpoint 6.1: Is the site readable if style sheets are
        turned off?
        Checkpoint 6.3: Does the site still function and can
        users navigate through the site if JavaScript, Flash
        and other programs are turned off or not supported?
        Checkpoint 5.1 and 5.2: Do all data tables have
        coded row and column headers using the TH ID and
        TD HEADER attributes?
        Checkpoint 10.2: Do all fields have appropriate labels
        and are they positioned immediately to the left or
        immediately above the relevant field (or immediately
        to the right or immediately below a radio button or
        checkbox)?
        Checkpoint 12.4: Are all field labels associated with
        the relevant field using the FOR and ID attributes?
        Checkpoint 3.5: Are all headings nested properly?

        Evaluating a current site for accessibility – manual testing
        Some checkpoints need to be tested manually. For more information on how to do this
        see the Level A and AA Checkpoints section .

        Manual testing                                                 Yes            No
        Checkpoint 1.1: Are the text equivalents of images,
        Flash, PDF and JavaScript meaningful?
        Checkpoint 1.2: Are all links in a server-side image
        map replicated as text links elsewhere on the same
        page?
        Checkpoint 1.3: Are audio descriptions provided for
        visual content in a video and is a text transcript
        provided?
        Checkpoint 1.4: Do all time-specific presentation
        have equivalent alternatives synchronized with the
        presentation?
        Checkpoint 2.1: Do you use some means other than
        colour to convey information?
        Checkpoint 6.2: Where content is dynamically
        generated is a static version provided that is updated
        at the same time?
        Checkpoint 7.1: Is the site free of flickering images?


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          39
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 11.4: If you cannot make a section of the
        site accessible is there another accessible version?
        Checkpoint 14.1: Is the content clear and concise?
        Checkpoint 12.3: Are large blocks of content divided
        into more natural groupings with tables, headings and
        lists?
        Checkpoint 13.1: Does each link properly indicate its
        target?
        Checkpoint 13.3: Is there a site map, A- Z index or
        table of contents?
        Checkpoint 13.4 and 13.5: Is navigation used
        consistently?
        Checkpoint 10.2:Do all fields have adequately
        descriptive field labels? Are they positioned
        immediately above or immediately to the left of the
        field (or immediately below or immediately to the right
        of checkboxes and radio buttons)?
        Checkpoint 9.4: Does the site make sense when you
        tab through using only the keyboard?
        Checkpoint 13.6: Is there a visible skip navigation
        link?
        Checkpoint 14.2: Is there additional graphics and
        audio that supplement the textual information on the
        page?
        Checkpoint 14.3: Is presentation consistent across
        the site?




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   40
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Fixing a current site to achieve accessibility (Implementation phase)
        When you are implementing changes to conform to the W3C Accessibility Guidelines
        certain people will be responsible for different features of the site. The following section
        outlines which roles are responsible for which accessibility measures.

        Fixing a current site to achieve accessibility – designer checklist
        Checkpoints that should be implemented by the graphic designer.

        Designer Checklist.                                           Yes           No
        Checkpoint 1.3: Are audio descriptions provided for
        visual content in a video and is a text transcript
        provided?
        Checkpoint 1.4: Do all time-specific presentation
        have equivalent alternatives synchronized with the
        presentation?
        Checkpoint 2.1: Do you use some means other than
        colour to identify information?
        Checkpoint 6.1: Is the site readable if style sheets are
        turned off?
        Checkpoint 6.2: Where content is automatically
        generated is a static version provided that is updated
        at the same time?
        Checkpoint 6.3: Does the site still function and can
        users navigate through the site if JavaScript, Flash
        and other programs are turned off or not supported?
        Checkpoint 7.1: Is the site free of flickering images?
        Checkpoint 2.2: Is there sufficient colour contrast?
        Checkpoint 3.5: Are there headings and are they
        nested properly?
        Checkpoint 10.1: Are users warned before links open
        in a new window?
        Checkpoint 12.3:Is information broken up by using
        headings, data tables and lists?
        Checkpoint 13.1: Are all links properly descriptive?
        Checkpoint 13.3: Is a site map, A- Z index or table of
        contents provided?
        Checkpoint 13.4 and 13.5: Is navigation consistent
        across the site?
        Checkpoint 10.2: Do all fields have descriptive
        labels?
        Checkpoint 7.2: There is no blinking?
        Checkpoint 7.3: Can any movement be stopped by
        the user?
        Checkpoint 13.6: Are visible skip navigation links
        provided?


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 41
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 14.2: Are graphics and audio used to
        complement text
        Checkpoint 14.3: Is consistent presentation used
        across the site?

        Fixing a current site to achieve accessibility – developer checklist
        Checkpoints that should be implemented by the developers responsible for the code and
        website build.

        Developer checklist                                            Yes      No
        Checkpoint 1.1: Do all images have ALT attributes?
        Checkpoint 1.1: Do all ornamental or spacer images
        have empty ALT attributes (eg. alt=“”)?
        Checkpoint 4.1: Are all changes in language
        identified in the code?
        Checkpoint 5.1 and 5.2: Do all data tables have
        coded row and column headers using the TH ID and
        TD HEADER attributes?
        Checkpoint 10.2: Do all fields have appropriate labels
        and are they positioned immediately to the left or
        immediately above the relevant field (or immediately
        to the right or immediately below a radio button or
        checkbox)?
        Checkpoint 12.4: Are all field labels associated with
        the relevant field using the FOR and ID attributes?
        Checkpoint 2.1: Do you use some means other than
        colour to identify information?
        Checkpoint 9.1: Are all image maps provided client-
        side instead of server-side wherever possible?
        Checkpoint 12.1: Are there no frames?
        Checkpoint 3.1: Are there no images of text?
        Checkpoint 3.2: Do all pages validate to the W3C
        HTML Validator and the W3C CSS Validator?
        Checkpoint 3.3: Are style sheets, used instead of
        tables to control layout and presentation?
        Checkpoint 3.4:Are relative rather than absolute units
        used in tables and style sheet property values?
        Checkpoint 3.5: Are headings coded using H1, H2,
        H3?
        Checkpoint 3.6: Are lists coded properly?
        Checkpoint 3.7: Are quotations coded using Q and
        BLOCKQUOTE?
        Checkpoint 3.7: BLOCKQUOTE is not used to indent
        text?


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                     42
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 7.4: Pages do not periodically refresh?
        Checkpoint 7.5: Redirects are server side only?
        Checkpoint 11.2: <EM> is used instead of <I> and
        <STRONG> instead of <B>?
        Checkpoint 13.2: Metadata is included?
        Checkpoint 12.4: Fields use the LABEL FOR and ID
        tags?
        Checkpoint 6.4: All JavaScript controls can be used
        by the keyboard or the mouse?
        Checkpoint 4.3: The language is coded in the HEAD
        area?
        Checkpoint 9.4: Does the order of the code match the
        order of the page with style sheets turned on?
        Checkpoint 13.6: Is there visible skip navigation?

        Fixing a current site to achieve accessibility – content checklist
        Checkpoints that should be implemented by the individual(s) responsible for the text and
        image content of the site.

        Content checklist                                               Yes       No
        Checkpoint 1.1: Are the text equivalents of images,
        Flash, PDF and JavaScript meaningful?
        Checkpoint 1.2: Are all links in a server-side image
        map replicated as text links elsewhere on the same
        page?
        Checkpoint 2.1: Do you use some means other than
        colour to identify information?
        Checkpoint 4.1: Check for any language changes in
        the content that need to be identified in the code.
        Checkpoint 11.4: If you cannot make a section of the
        site accessible is there another accessible version?
        Checkpoint 14.1: Is the content clear and concise?
        Checkpoint 3.5: Are headings used and nested
        properly?
        Checkpoint 12.3: Are large blocks of information
        broken up into natural groupings using tables,
        headings and lists?
        Checkpoint 13.1: Is the target of each link clear?
        Checkpoint 14.2: Are additional graphics and audio
        used to supplement textual content.?




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        43
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Case Study 1 - Victoria Online (Department for Innovation, Industry and Regional
Development)


Victoria Online (http://www.vic.gov.au/) is the Victorian Government’s portal and is managed by
Information Victoria within the Department for Innovation, Industry and Regional Development,
State Government of Victoria.

Peter Sculley is the Site Analyst for Victoria Online. He has been involved in the Victoria Online
project for several years, initially on secondment from Parliament of Victoria where he managed
the Parliament website. Prior to working at Parliament he was an Internet Trainer at RMIT
University. As Site Analyst, Peter is responsible for technical management of the Victoria Online
website, as well as ensuring accessibility compliance and website usage statistics. Here he
answers some questions on making the portal, Victoria Online, accessible.

        Did you find that building an accessible portal created different issues to building
        an accessible site?
        The issues we faced are not necessarily limited to building a portal website, but you are
        more likely to face them. Victoria Online is a metadata driven portal. The approximately
        3,000 metadata resources are catalogued against the topics (taxonomy) found on the
        home page. These resources are discoverable by browsing the topics or by searching.
        When a search is carried out metadata resources are searched as well as a separate
        index that is harvested using the metadata resources as starting points.

        Victoria Online uses dynamic addresses and dynamic data presentation. We needed to
        ensure that our URL addresses validated within pages. Proper encoding of URL links in
        portal pages is necessary. We found that certain characters in our URLs were causing
        validation errors. Therefore some characters, such as square brackets, spaces and
        exclamation marks in our URLs have to be encoded.

        Victoria Online does not link to foreign language sites, but it does link to English language
        pages that contain foreign language PDFs. If you are intending to link directly to foreign
        language pages you should provide the link in that language with the proper LANG tag
        (and character set).

        Any template driven site has the advantage that as long as its container parts e.g.
        header, footer and navigation system, are accessible, then it is a matter of process to
        ensure that newly 'authored' content conforms to the accessibility guidelines - this is
        mainly ensuring that new content validates, has correct heading structure and that if
        images are used they have appropriate alternative text.

        The Victoria Online portal (and other portals) do not rely so much on authored content.
        The content we do have is authored within a basic content management system and any
        new content is checked with the W3C HTML Validator.

        How did you ensure that the portal was accessible?
        We followed a very specific process: External Audit - Report - Fix - Review. This is an
        ongoing task for any website.

        Did you find accessibility compliance added a significant amount of time or cost to
        the build?
        Part of achieving accessibility compliance is engaging a known authority in web
        accessibility that can audit your site, provide reports and recommend best practice
        solutions to problems. The website vendor must also factor the extra cost of ensuring


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            44
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        accessibility into their build quote. The resourcing and planning this adds to a web site
        project is significant.

        It is important to remember that not only does the design phase require an accessibility
        review but each project build phase as well. A large amount of time and cost can involve
        three-way discussions between website vendor, customer and accessibility experts.
        Costs can be reduced by ensuring that accessibility is an acceptance requirement for the
        project, and by working through previously known issues to ensure that errors don't re-
        occur.

        Did you find that your decision to make the portal accessible constricted the
        technologies you chose for your portal, or the architecture of the portal in any
        way?
        It is difficult to assess particular portal delivery technologies with an eye to accessibility.
        There are platforms that have known issues, but it is only when a web site is being built
        that problems are found.

        Were there any particular aspects during the build where accessibility posed a
        major problem? If so, how did you deal with it?
        The main difficulty in achieving compliance has been with "Checkpoint 14.1: Use the
        clearest and simplest language appropriate for a site's content". This checkpoint is open
        to interpretation. Other checkpoints can be addressed by design or technical changes,
        but meeting the clear language checkpoint can be a subjective opinion.

        What advice would you give to people trying to build an accessible portal?
        Set the accessibility level requirement before you begin. Make the requirement a
        'deliverable' of the project. Be prepared to alter the design and data so that you can meet
        the designated requirement.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                45
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Case Study 2 -Youthcentral (Department for Planning and Community
Development)


Note: This case study was written prior to the requirement to make Victorian Government web
sites Level AA compliant. Therefore, although this case study refers to Level AA as an added
extra, it is now a mandatory requirement.

youthcentral is the Victorian Government's online initiative for young people. It provides
employment and participation opportunities that link Government, young people and their
communities. The youthcentral website is a valuable resource for young people wanting
information about jobs and careers, services and events in their local area, studying, travel,
money and more.

Ryan Twisk is the website administrator at youthcentral; he is responsible for the day-to-day
maintenance of the website. This includes content uploading/formatting, creation of visual
elements, statistical reporting, search engine optimization, strategic implementation of
accessibility features and technical liaison responsibilities. Here he answers some questions
about making youthcentral a Level AA web site.

        The youthcentral web site is a Level AA web site. Why did you choose this level of
        accessibility compliance? What issues affected your decision?
        It is requirement that all Victorian Government websites maintain a minimum Level A
        accessibility compliance (based on the W3C Web Content Accessibility Guidelines).
        While youthcentral aims to meet this as a minimum, it also strives to reach a Level AA
        rating wherever possible and/or practicable.

        Given that young people aged 12 to 25 were the target audience for the site it was felt
        that Level AA compliance could be met where possible. It was thought that this aim would
        allow sufficient flexibility to meet accessibility requirements while still providing a rich,
        vibrant user experience, as demanded by our users.

        The fact that youthcentral content is created by multiple authors and new content is
        published on the site on a daily basis poses quite a challenge for maintaining accessibility
        compliance. It was however felt that the Level AA was an achievable target for the
        youthcentral team from an ongoing compliance management point of view.

        How did you ensure that youthcentral was Level AA?
        Level AA compliance has been stated as a requirement at every stage of the youthcentral
        site's development and all vendors have been briefed as to the site's accessibility
        requirements. To date, the selected youthcentral web development and maintenance
        suppliers have a strong, demonstrated track record in building and maintaining Level AA
        compliant websites and also partner with youthcentral to not only provide technical
        compliance but to provide general advice regarding the ongoing compliance of content
        published on the site.

        An accessibility review was conducted by accessibility specialists following the site's first
        stage of development in January 2005 to ensure a minimum Level A compliance and to
        identify areas that needed fixing and/or improving. The web developer's in-house
        accessibility specialist reviewed the site following its second stage of development (in
        approximately June 2005). Ongoing accessibility compliance reviews and best practice
        reviews are also planned as part of youthcentral's continuous improvement approach.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             46
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Additionally, key youthcentral staff members have received training in accessibility
        compliance to ensure that any new content published via the site's content management
        system is compliant.

        Did you find accessibility compliance added a significant amount of time or cost to
        the build?
        It is difficult to gauge whether accessibility compliance added any cost to the site's
        development and maintenance as youthcentral has only used vendors, or potential
        vendors, with a strong track record in this area and would have no way of making
        comparisons of costs from non-compliant vendors.

        To our knowledge no development or maintenance project timeline has been
        compromised because of issues of accessibility compliance.

        We estimate that checking for and ensuring accessibility compliance on a day-to-day
        basis when publishing new content via the content management system probably adds
        an average 2 - 5 percent to the overall time taken to develop, edit and publish content.

        Did you find that your decision to make youthcentral Level AA constricted your
        choice of content management system or other technologies used within the site
        (for example, Flash, JavaScript etc)?
        There have been times where we have felt that form and content have been
        compromised, however, it is difficult to gauge whether this is because of any constraints
        of accessibility compliance or whether it is the constraints of managing a website via a
        content management system.

        With improvements in technologies and vendors' abilities to ensure accessibility
        compliance, we anticipate that this will become even less of an issue in the future.

        Were there any particular aspects during the build where accessibility compliance
        posed a major problem?
        No

        How do you ensure that youthcentral maintains its level of accessibility
        compliance?
        youthcentral will continue to commission periodic accessibility reviews to ensure that the
        site maintains its level of accessibility compliance and to run its own in-house reviews
        using available online tools and applying the collective knowledge of the youthcentral
        team.

        Any prospective or current vendors who provide new development work on the site will
        be required to ensure Level AA accessibility compliance as part of their contract.

        In addition, key staff that are responsible for the maintenance and publishing of content
        on the site will undertake accessibility training and will be required to ensure accessibility
        compliance (where the content management system allows) of the content they are
        responsible for.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              47
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Case Study 3 - Web Developer’s Resource Kit (Department of Education and Early
Childhood Development)


Since 2001, the Department of Education and Early Childhood Development’s Online Services
Unit (OSU) has been researching, consolidating and facilitating conformance with web standards
across the Department’s web portfolio. This collaborative effort required contributions from every
member of the OSU team and resulted, in 2003, in the creation of the Developer’s QA Checklist
aimed, primarily, at external web developers and covering a wide range of accessibility and
technical standards.

In 2004, the Developer’s QA Checklist provided a basis for the creation of the Web Developer’s
Resource Kit website 80 which extended the original QA Checklist to include more detailed
explanations, relevant techniques and links to external resources.

Elena Drinnan has been working as a Web Project Manager for the OSU for several years and
currently is managing a process of review and expansion of the Developer's Resource Kit with the
aim of ensuring that accessibility and usability standards are complied with. Here she answers
some questions regarding the creation and maintenance of the Web Developer’s Resource Kit.

            What kind of information is covered in the Web Developer’s Resource Kit?
            A variety of information is included in the Web Developer’s Resource Kit including:
                 W3C checkpoints, Whole of Victorian Government Web Standards requirements,
                    and Department of Education and Early Childhood Development (DEECD)
                    specific requirements;
                 accessibility and coding examples and explanations based around DEECD's
                    requirements;
                 information related to requirements for images, logos and footer layout; and
                 information specifically targeted at external developers.

            Information must be specific to DEECD's requirements and must be the first point of
            interaction between clients/external developers and DEECD IT staff.

            What is the purpose of the Web Developer’s Resource Kit and who uses it? Have
            you found that the development of the toolkit changed how people were building
            sites within the Department of Education and Early Childhood Development?
            Users are all people who need to have content added to web sites and/or who want web
            pages or sites built. This includes both internal and external staff.

            The purpose is to publish all DEECD's QA requirements, as well as how to do them and
            why they need to be done. It is important to incorporate quality into the content and the
            sites at the earliest possible time to avoid rework and QA right at the end of the design
            and build cycle.

            Have you found it difficult to keep the Web Developer’s Resource Kit up-to-date?
            No. Web standards don't change often. DEECD standards also are not frequently
            changed. This is a reflection of how DEECD does its business - this is not the final say on
            all internet standards for the web.




80
     http://www.education.vic.gov.au/devreskit/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              48
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
            How have you addressed accessibility within the Web Developer’s Resource Kit?
            There is always new research into various areas of accessibility – how have you
            dealt with this?
            We identified the relevant components of the W3C WCAG and incorporated them into the
            QA checklist. Not every WCAG point was addressed as they were either not relevant or
            rarely used. This is the first point of interaction with DEECD IT staff. Any complex or
            vague determinations can be referred to DEECD IT staff for clarification.

            The Web Developer’s Resource Kit is specifically for DEECD websites - some areas of
            accessibility are not applicable or too involved to explain for their limited DEECD use.
            DEECD IT staff will deal with these as they arise with projects.

            What would you say would be the best elements of the Web Developer’s Resource
            Kit? Are there any particular instances where the toolkit has been particularly
            useful?
            The QA checklist and linking back to a larger explanation, examples and reasons have
            been very popular. More detailed information is available to users if they require it.

            It is particularly important for external developers so they immediately know the DEECD
            baseline before they even get the contract. This cuts down on many questions to DEECD
            IT staff and forwarding of the same information over and over. It also serves as a clear
            baseline of what they have signed up to do.

            What advice would you give to other departments attempting to build a toolkit of
            their own?
            Make sure it fits in with Whole of Victorian Government Web Standards. Provide links to
            the full details of the original source requirement.

            Many QA items can be fulfilled in a number of different ways, such as hyperlink text for
            downloadable files, as well as many others. To ensure consistency please look at the
            DEECD Web Developer’s Resource Kit 81 .




81
     http://www.education.vic.gov.au/devreskit/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 49
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Section Four: Understanding and testing
Level A, AA and AAA checkpoints

Introduction to the Level A and Level AA checkpoints


There are 16 Level A checkpoints and 30 Level AA checkpoints in the W3C Web Content
Accessibility Guidelines (WCAG), Version 1.0. :These checkpoints are categorised as:
        general;
        images and image maps;
        tables;
        frames;
        forms;
        applets and scripts; and
        multimedia.

Conforming to the W3C Web Content Accessibility Guidelines will ensure that your site contains
many features that will assist people with disabilities. These checkpoints cover the areas of web
design and development that are prone to accessibility issues and make browsing a web site
difficult for people with disabilities.

These checkpoints include various testing methods. The testing methods marked as [compulsory]
are compulsory in order to test the checkpoint. Testing methods marked as [optional] are not
compulsory, but may assist in testing the checkpoint if other methods fail or the results are
inconclusive.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          50
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Level A, Level AA and non-essential Level AAA checkpoints


Please note that the following table includes six Level AAA checkpoints. As technology has
improved, these checkpoints have become more important to people with disabilities and easier
to comply with.

Guideline     Checkpoint                                                                   Done
1.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.
              Images such as spacers should have an ALT description of ALT=“ ”
1.2           Provide redundant text links for each active region of a server-side
              image map.
1.3           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.
1.4           For any time-based multimedia presentation (e.g., a movie or
              animation), synchronize equivalent alternatives (e.g., captions or
              auditory descriptions of the visual track) with the presentation.
2.1           Ensure that all information conveyed with color is also available without
              color, for example from context or markup.
2.2           Ensure that foreground and background color combinations provide
              sufficient contrast when viewed by someone having color deficits or
              when viewed on a black and white screen.
3.1           When an appropriate markup language exists, use markup rather than
              images to convey information.
3.2           Create documents that validate to published formal grammars
3.3           Use style sheets to control layout and presentation.
3.4           Use relative rather than absolute units in markup language attribute
              values and style sheet property values.
3.5           Use header elements to convey document structure and use them
              according to specification.
3.6           Mark up lists and list items properly.
3.7           Mark up quotations. Do not use quotation markup for formatting effects
              such as indentation.
4.1           Clearly identify changes in the natural language of a document's text
              and any text equivalents
4.3           Identify the primary natural language of a document.
5.1           For data tables, identify row and column headers.



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            51
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
5.2           For data tables that have two or more logical levels of row or column
              headers, use markup to associate data cells and header cells.
5.4           If a table is used for layout, do not use any structural markup for the
              purpose of visual formatting.
6.1           Organize 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.
6.2           Ensure that equivalents for dynamic content are updated when the
              dynamic content changes.
6.3           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.
6.4           For scripts and applets, ensure that event handlers are input device-
              independent.
6.5           Ensure that dynamic content is accessible or provide an alternative
              presentation or page.
7.1           Until user agents allow users to control flickering, avoid causing the
              screen to flicker.
7.2           Until user agents allow users to control blinking, avoid causing content
              to blink (i.e., change presentation at a regular rate, such as turning on
              and off).
7.3           Until user agents allow users to freeze moving content, avoid
              movement in pages.
7.4           Until user agents provide the ability to stop the refresh, do not create
              periodically auto-refreshing pages.
7.5           Until user agents provide the ability to stop auto-redirect, do not use
              markup to redirect pages automatically. Instead, configure the server to
              perform redirects.
8.1           Make programmatic elements such as scripts and applets directly
              accessible or compatible with assistive technologies
9.1           Provide client-side image maps instead of server-side image maps
              except where the regions cannot be defined with an available geometric
              shape.
9.2           Ensure that any element that has its own interface can be operated in a
              device-independent manner.
9.3           For scripts, specify logical event handlers rather than device-dependent
              event handlers.
9.4           Create a logical tab order through links, form controls, and objects.
10.1          Until user agents allow users to turn off spawned windows, do not
              cause pop-ups or other windows to appear and do not change the
              current window without informing the user.
10.2          Until user agents support explicit associations between labels and form
              controls, for all form controls with implicitly associated labels, ensure
              that the label is properly positioned.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                    52
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
11.1          Use W3C technologies when they are available and appropriate for a
              task and use the latest versions when supported.
11.2          Avoid deprecated features of W3C technologies.
11.4          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.
12.1          Title each frame to facilitate frame identification and navigation.
12.2          Describe the purpose of frames and how frames relate to each other if it
              is not obvious by frame titles alone.
12.3          Divide large blocks of information into more manageable groups where
              natural and appropriate.
12.4          Associate labels explicitly with their controls.
13.1          Clearly identify the target of each link.
13.2          Provide metadata to add semantic information to pages and sites
13.3          Provide information about the general layout of a site (e.g., a site map
              or table of contents).
13.4          Use navigation mechanisms in a consistent manner.
13.5          Provide navigation bars to highlight and give access to the navigation
              mechanism.
13.6          Group related links, identify the group (for user agents), and, until user
              agents do so, provide a way to bypass the group.
14.1          Use the clearest and simplest language appropriate for a site's content.
14.2          Supplement text with graphic or auditory presentations where they will
              facilitate comprehension of the page.
14.3          Create a style of presentation that is consistent across pages.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                     53
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

General checkpoints

Checkpoint 1.1
Level A
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.
                                                                              http://www.w3.org/TR/WCAG10/


        Guideline
        Provide equivalent alternatives to auditory and visual content

        Why?
        This is to ensure that people using text-only browsers or screen-readers, or people who
        browse with images turned off, can still access all the information in the web site. Text
        alternatives for audio and video files assist people with hearing impairments and allow
        the content to be accessed by a search engine. For graphs and diagrams it is important
        that the key points are described within the accompanying text.

        ALT attributes should describe the function of the image, not describe the image itself. If
        an image is purely ornamental i.e. a spacer GIF, and has no other function then the ALT
        attribute should reflect this. In this case the ALT attribute should be:
                 <IMG SRC=”image.gif” height=”15” width=”10” ALT=“”>

        This toolkit provides information about making images and image maps accessible.
        Example
        An example of the difference between an alternative description and an equivalent
        description are illustrated in the cartoon below.




                        Permission to reproduce this Tandberg cartoon provided to Multimedia Victoria (2002)


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                   54
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

            The ALT attribute for this cartoon on the Better Health Channel is ‘A Tandberg cartoon’ –
            which, while true, does not actually describe the image.

            In this case a long description would be beneficial. These links are recognized by screen-
            readers, but are not available through IE or Netscape browsers. Please note that D links
            are deprecated in favour of the LONGDESC attribute. TITLE attributes should also not be
            used with the IMG tag.

            To create a long description you need to use the LONGDESC attribute:
                    <IMG SRC=”tandberg.gif” height=”15” width=”10” ALT=“A
                    Tandberg cartoon” longdesc="tandberg.html">

            Then you will need to create the file referenced in the LONGDESC attribute (in this case
            tandberg.html) with appropriate descriptive text, for example:

                     Tandberg cartoon: Man slumped in front of the TV while a woman gestures to the computer on the
                     other side of the room labeled ‘Better Health Website’. Man says “I can’t walk that far.”

            How to test
             Use Cynthia Says to ensure that all images have ALT attributes and audio and video
               files have text equivalents [Compulsory]
             Using the IE Accessibility Toolbar, or the Firefox Developer toolbar, replace images
               with their ALT attributes and make sure that the ALT attribute is equivalent to the
               image [Compulsory]
             Manually test that all information is available in text by browsing the site with graphics
               and plug-ins turned off, or view the site in the text-only browser, Lynx [Compulsory]
             Manually browse through the site with all the images turned off and see if you can still
               navigate around the site and access information easily [Optional]
             User test the site with a blind or visually impaired person who is a competent screen-
               reader user [Optional]

            Techniques for addressing Checkpoint 1.1
            Text equivalents 82
            Images used as bullets 83
            Text for images used as links 84
            Short text equivalents for images ("alt-text") 85
            Long descriptions of images 86
            Text equivalents for client-side image maps 87
            Text and non-text equivalents for applets and programmatic objects 88
            Text equivalents for multimedia 89
            Describing frame relationships 90


82
     http://www.w3.org/TR/WCAG10-CORE-TECHS/text-equivalent
83
     http://www.w3.org/TR/WCAG10-HTML-TECHS/list-images
84
     http://www.w3.org/TR/WCAG10-HTML-TECHS/link-text-images
85
     http://www.w3.org/TR/WCAG10-HTML-TECHS/image-text-equivalent
86
     http://www.w3.org/TR/WCAG10-HTML-TECHS/long-descriptions
87
     http://www.w3.org/TR/WCAG10-HTML-TECHS/client-side-text-equivs
88
     http://www.w3.org/TR/WCAG10-HTML-TECHS/applet-text-equivalent
89
     http://www.w3.org/TR/WCAG10-HTML-TECHS/text-equivs-multimedia
90
     http://www.w3.org/TR/WCAG10-HTML-TECHS/frame-text-equivalent


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                55
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
           Writing for browsers that do not support FRAME 91
           Graphical buttons 92
           Alternative presentation of scripts 93




91
     http://www.w3.org/TR/WCAG10-HTML-TECHS/noframes
92
     http://www.w3.org/TR/WCAG10-HTML-TECHS/forms-graphical-buttons
93
     http://www.w3.org/TR/WCAG10-HTML-TECHS/scripts-alt


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   56
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 2.1
Level A
Ensure that all information conveyed with color is also available without color, for example from
context or markup.
                                                                            http://www.w3.org/TR/WCAG10/

            Guideline
            Don’t rely on colour alone.

            Why?
            This is to ensure that people who have trouble seeing colour can still understand the site
            through contextual information. People who may have trouble seeing the content include:
             people who are blind;
             people with vision impairments;
             people who are colour blind; and
             people using monochrome displays.

            Example 1
            A common example of colour being used to convey information is when red is used to
            indicate compulsory fields, for example in a form:

                      Fields in red are compulsory:

                      Name:
                      Address:
                      Contact details:


            Use the colour red in the above example in conjunction with some other indicator, such
            as the word “required”:

                      Fields in red marked (required) are compulsory:

                      Name (required):
                      Address:
                      Contact details (required):


            Previously an asterisk was recommended to indicate compulsory fields, but recent
            research has found that not all screen readers read out an asterisk symbol 94 .

            Example 2
            A common example of colour being used to convey information is in calendar format.


                      Days coloured in aqua are school holidays.




94
     http://www.visionaustralia.org.au/info.aspx?page=766


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               57
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
                                   Mon      Tue      Wed      Thu       Fri   Sat   Sun
                                            1        2        3         4     5     6
                                   7        8        9        10        11    12    13
                                   14       15       16       17        18    19    20
                                   21       22       23       24        25    26    27
                                   28       29       30

            The above example can be made more accessible by simply stating the dates of the
            school holidays, for example:

                     School holidays are from the 10th to the 20th (coloured in aqua below).

                                   Mon      Tue      Wed      Thu       Fri   Sat   Sun
                                            1        2        3         4     5     6
                                   7        8        9        10        11    12    13
                                   14       15       16       17        18    19    20
                                   21       22       23       24        25    26    27
                                   28       29       30

            How to test
             Manually browse the site and check that colours have not been used to indicate
               different items on a page [Compulsory]

            Techniques for addressing Checkpoint 2.1
            Structure vs. presentation 95
            Ensuring information is not in colour alone 96




95
     http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure
96
     http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-info-not-in-color-alone


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         58
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Checkpoint 4.1
Level A
Clearly identify changes in the natural language of a document's text and any text equivalents
(e.g., captions).
                                                                          http://www.w3.org/TR/WCAG10/


           Guideline
           Clarify natural language usage.

           Why?
           This is to ensure that people who use screen-readers will be notified when a change in
           language occurs. Some screen-readers can read the text in the appropriate language;
           others will read the text phonetically.

           Example:
           The following text is one example of an alternative language being used in an English
           site.


                    And then he said au revoir and rode off into the sunset.


           The correct HTML code for the above example would be:

                    And then he said <SPAN LANG=”FR”>au revoir</SPAN>and rode
                    off into the sunset.

           How to test
            Manually browse through the content in the site and identify any areas where there is
              a change in language, including slang type phrases, such as “c’est la vie”. Look in the
              code to see if the correct coding has been used. [Compulsory]

           Techniques for addressing Checkpoint 4.1
           Identifying changes in language 97




97
     http://www.w3.org/TR/WCAG10-HTML-TECHS/#changes-in-lang


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              59
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 6.1
Level A
Organize 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.
                                                                              http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure that pages featuring new technologies transform gracefully.

            Why?
            This is to ensure that the site is legible when the browser does not support style sheets.
            Recent research suggests that it is preferable to retain the original site’s layout 98 with
            style sheets off. This means that navigation should appear first on the page, followed by
            content and finally the footer information. It is also useful for people using screen readers
            and/or browsing with style sheets turned off if the navigation is properly labeled. This is
            to address the issue where disabling style sheets may render the navigation indistinct
            from the content.

            This toolkit provides information about creating valid CSS and building accurate page
            source order..

            Example
            Scope Vic (previously the Spastic Society of Victoria) was built using style sheets to
            control layout. With style sheets turned off the elements were laid out linearly.

            The original site, with style sheets on appeared as:




98
     http://www.usability.com.au/resources/source-order.cfm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 60
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
                            Permission to reproduce these screenshots provided to Multimedia Victoria (2002)




        With style sheets turned off the navigation appeared at the top of the screen, followed by
        the Search bar. The rest of the content then appeared, followed by the footer information.




        How to test
         Use the IE Accessibility Toolbar, or the Firefox Developer toolbar, to disable style
           sheets and make sure you can still identify and use the navigation and read the
           content [Compulsory]




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                   61
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
            Techniques for addressing Checkpoint 6.1
            Generated content 99
            Rules and borders 100
            Using style sheet positioning and markup to transform gracefully 101




99
     http://www.w3.org/TR/WCAG10-CSS-TECHS/#Generated
100
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-rules
101
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-transform-gracefully


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011             62
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 6.2
Level A
Ensure that equivalents for dynamic content are updated when the dynamic content changes.
                                                                              http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure that pages featuring new technologies transform gracefully.

            Why?
            This is to ensure that people who cannot see or who don’t have the ability to interact with
            dynamic content can still access the requisite information. Dynamic content is content
            that uses non-HTML technologies, is updated frequently and is usually automatically
            generated. All dynamic content should have an equivalent static HTML version – this
            static HTML content must be updated when the dynamic content is updated. Examples of
            dynamic content include:
             pages with multiple layers;
             rollovers / mouseovers which provide information not available elsewhere;
             scrolling text;
             flash presentations;
             Java applets; and
             PDFs.

            Example
            An example of a programmatic object is the “Salam” Indonesian activity on the
            Languages Online 102 web site:




            By selecting one of the speech bubbles an audio file is played pronouncing the phrase.
            The aim of the exercise is to teach both the meaning of the word and the proper
            pronunciation.

            A suitable alternative needs to be the equivalent of the activity, thus it needs to teach
            both the meaning of the word and the proper pronunciation. For example:


102
      http://www.education.vic.gov.au/languagesonline/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  63
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
            Hai!                       Hai means “Hi”
                                       Hai is pronounced hi-e
            Selamat pagi!              Selamat pagi means “Good morning”
                                       Selamat pagi is pronounced sell-amat pag-e with a hard g
            Selamat sore!              Selamat sore means “Good (late) afternoon”
                                       Selamat sore is pronounced sell-amat sore-ee
            Sampai jumpa               Sampai jumpa means “See you later”
                                       Sampai jumpa is pronounced sump-ay joomp-a
            Selamat siang              Selamat siang means “Good (middle of the) day”
                                       Selamat siang is pronounced sell-amat see-ang with a hard g
            Selamat malam     Selamat malam means “Good evening / night”
                                       Selamat malam is pronounced sell-amat mull-um



            How to test
             Manually test by reviewing the static content and dynamic content on a regular basis
               [Compulsory]
             Use the IE Accessibility Toolbar, or the Firefox Developer toolbar, to disable
               JavaScript and Flash and make sure you can still interact with the site [Compulsory]
             To ensure the static content is updated at the same time as the dynamic content,
               include an automated reminder somewhere in the update process [Optional]

            Techniques for addressing Checkpoint 6.2
            Text and non-text equivalents for scripts and programmatic objects 103
            Frame sources 104
            Alternative presentation of scripts 105




103
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#applet-text-equivalent
104
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#frame-has-html-src
105
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-alt


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               64
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit

Checkpoint 7.1
Level A
Until user agents allow users to control flickering, avoid causing the screen to flicker.
                                                                              http://www.w3.org/TR/WCAG10/


             Guideline
             Ensure user control of time-sensitive content changes.

             Why?
             Flickering between particular frequencies (4 to 59 Hertz) may cause epileptic fits or
             migraines. Flickering in this case is defined as:
                   abrupt movement in a web page;
                   sudden changes in colour; or
                   images that strobe (i.e. repeatedly switch from dark to light and back).

             These features are often used in web page banner advertisements to attract the user’s
             attention.

             How to test
              Manually browse your website ensure there are no scripts or images that cause
                flickering [Compulsory]
              Run any pages with flickering content through the TRACE Photosensitive Epilepsy
                Analysis Tool 106 [Compulsory]

             Techniques for addressing Checkpoint 7.1
             Screen flicker 107
             Visual information and motion 108




106
      http://trace.wisc.edu/peat/
107
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#flicker
108
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#video-information


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 65
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit

Checkpoint 14.1
Level A
Use the clearest and simplest language appropriate for a site's content.
                                                                               http://www.w3.org/TR/WCAG10/


             Guideline
             Ensure that documents are clear and simple.

             Why?
             This is to ensure that people who have difficulty with written English will still be able to
             gain adequate meaning from the site. People who are likely to experience these kinds of
             difficulties include:
              people born profoundly deaf;
              people with a non-English background;
              people with dyslexia or other learning disabilities.

             This toolkit provides information about creating sites accessible to people with cognitive
             disabilities.

             How to test
              Manually browse the content and identify areas of text that are unnecessarily wordy
                [Compulsory]
              Select pages that seem to have complex content and run them through the Juicy
                Studio Readability Test 109 [Compulsory]
              Manually browse through all instructions and ensure they are specified in step by
                step point form [Optional]
              User test the site with someone from an English as a Second Language background,
                e.g. someone born profoundly deaf or for whom AUSLAN is their first language
                [Optional]

             Techniques for addressing Checkpoint 14.1
             Comprehension 110




109
      http://juicystudio.com/services/readability.php
110
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  66
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoints on image maps

Checkpoint 1.2
Level A
Provide redundant text links for each active region of a server-side image map.
                                                                          http://www.w3.org/TR/WCAG10/


        Guideline
        Provide equivalent alternatives to auditory and visual content.

        Why?
        This is to ensure that people can access image maps using a keyboard as well as a
        mouse.

        What is an image map?
        An image map is a single image that contains links to different areas, depending on
        where you click on the image. Image maps can be either client-side or server-side. If an
        image map is client-side then all the information used to generate the image map and
        links in the image map are included in the code, and can be used by screen-readers and
        accessed using the keyboard. If an image map is server-side when a user clicks on a
        certain part of the image map the server (not the web site) decides where the user
        navigates. Server side image maps require the use of a mouse and cannot be used via
        the keyboard. This checkpoint requires that where server-side image maps have been
        used there should also be a list of text links that the user can activate instead of the
        image map.

        This toolkit provides information on making images and image maps accessible and
        information on Google maps.

        Example
        In this Metlink regions map each number represents a different active hotspot. This map
        is actually a client-side image map, but the regions are so small it could have been
        developed as a server-side image map. Each image map hotspot has an equivalent text
        link.




        How to test
         Use Cynthia Says to identify any areas where server-side image maps have been
           used [Compulsory]
         Manually browse the pages Cynthia Says has identified and ensure the links are
           available in text format somewhere else on the same page, preferably above or
           before the image map [Compulsory]

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             67
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

            Techniques for addressing Checkpoint 1.2
            Text equivalent 111
            Server side image maps 112


Checkpoint 9.1
Provide client-side image maps instead of server-side image maps except where the regions
cannot be defined with an available geometric shape.
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Design for device-independence when viewing pages.

            Why?
            This is to ensure that people can access image maps using a keyboard as well as a
            mouse. Server-side image maps cannot be activated using a keyboard as they rely on
            the coordinates of the cursor to determine which page to link to. Only in the cases where
            link areas are not easily coded i.e. as a square, triangle, etc, should server-side image
            maps be considered.

            This toolkit provides information on making images and image maps accessible and
            information on Google maps.

            How to test
             Use Cynthia Says to identify where server-side image maps have been used instead
               of client-side image maps. Discuss with your developer whether the image map can
               be provided client-side. [Compulsory]

            Techniques for addressing Checkpoint 9.1
            Client side vs server side image maps 113




111
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#text-equivalent
112
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#server-side
113
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#client-vs-server-side


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               68
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Checkpoints on tables

Checkpoint 5.1
Level A
For data tables, identify row and column headers.

Checkpoint 5.2
Level A
For data tables that have two or more logical levels of row or column headers, use markup to
associate data cells and header cells.
                                                                                           http://www.w3.org/TR/WCAG10/


             Guideline
             Create tables that transform gracefully.

             Why?
             This is to ensure that people using screen-readers that read text from left to right can
             understand the information presented in a table.

             Table headers should be included as TH ID and TD HEADERS. SCOPE should not be
             used as it is not recognized by some screen readers 114 . This toolkit provides information
             about making tables accessible.

             Example
             The Commonwealth Games web site contained a number of data tables categorizing
             results and scheduling. The following is from the Boxing results 115 .




             Without coded table headers, a screen-reader would interpret the above table as:
                       Country Gold Silver Bronze England five one two Australia two zero four India one two two South
                       Africa one one zero Namibia one zero zero


             Specifying table rows and headers allows users accessing the data through a screen-
             reader to determine what column the data is in. A screen-reader would interpret the
             Australia row as:
                       Country Australia
                       Gold two
                       Silver zero
                       Bronze four




114
      http://www.usability.com.au/resources/tables.cfm
115
      http://www.melbourne2006.com.au/Schedule+and+Results/By+Sport/Boxing


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                   69
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
             How to test
              Use Cynthia Says to identify any table without headers. Determine whether these
                tables are data tables or tables used for layout purposes only. [Compulsory]
              Use WAVE 116 or the Juicy Studio Complex Table Analyser 117 to analyse the headers
                used in a data table [Compulsory]
              User test the site with a blind or visually impaired person using a screen-reader
                [Optional]

             Techniques for addressing Checkpoint 5.1
             Identifying row and column information 118




116
      http://wave.webaim.org/index.jsp
117
      http://juicystudio.com/article/firefox-table-inspector.php
118
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        70
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Checkpoints on frames

Checkpoint 12.1
Level A
Title each frame to facilitate frame identification and navigation
                                                                           http://www.w3.org/TR/WCAG10/

           Note: Frames should be avoided if possible. Any information contained within a frame
           must be presented outside the frame (as required by Checkpoint 1.1)

           Guideline
           Provide context and orientation information.

           Why?
           This is to ensure that people using screen-readers or non-graphic browsers can identify
           which frame to open. People who cannot use frames must rely solely on the TITLE tag of
           the frame to identify what the frame does and therefore an alternative presentation of the
           contents of the frame must be provided.

           Frames can cause problems because:
            they break the “Back” button functionality offered by browsers;
            the URL displayed does not represent the contents of the page; and
            opening a frame in a new browser window can disorient users.

           However if frames are a necessity:
            ensure that all frames are properly titled; and
            ensure that any content within the frame is provided in an alternative, accessible
              format.

           This toolkit provides information on Frames and iframes.

           How to test
            Use Cynthia Says to identify any frames [Compulsory]
            Use Cynthia Says to test whether frames are using the TITLE tag [Compulsory]
            Manually check the frame titles to determine whether the frame titles identify
              navigation and contents frames [Compulsory]
            Ensure these frames are descriptive enough to allow proper navigation through the
              site [Compulsory]

           Techniques for addressing Checkpoint 12.1
           Providing a frame title 119




119
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#frame-names


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              71
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoints on applets and scripts

Checkpoint 6.3
Level A
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.
                                                                                            http://www.w3.org/TR/WCAG10/


        Guideline
        Ensure that pages featuring new technologies transform gracefully

        Why?
        This is to ensure that people who don’t or can’t interact with Flash, JavaScript, applets,
        etc., can still use the site.

        This toolkit provides information about:
         JavaScript;
         creating alternatives to PDFs;
         creating accessible PDFs;
         creating mashups;
         Flash; and
         maps and Google maps.

        Example
        The Live in Victoria web site has a number of video migrant stories. Each of the stories
        has an associated text transcript.

                 Ray and Gwen Cocker, Upholsterer and Stitcher - immigrated from the United Kingdom
                 Oscar Furniture, Horsham (West Victoria)
                 A great mix of work and pleasure is how husband and wife team, Ray and Gwen Cocker, as well as
                 Jeff Thurston describe their move to Victoria from the United Kingdom.
                 The three are based in Horsham in Victoria's west, all working for Oscar Furniture, a manufacturing
                 company that employed the British trio after searching the world for the perfect people to fill its long-
                 term vacancies.
                 For their prospective employer 'Down Under', Ray and Gwen had the advantage of having been self-
                 employed as an upholsterer and stitcher respectively, as well as having worked for a company for five
                 years.
                 Ray and Gwen concur that this background has helped them get the most out of their new position.
                 "It's no problem at all. We want to continue working for Oscar Furniture and make sure it's a
                 successful furniture company and we'll take it from there and just enjoy ourselves, basically. That's
                 what we have come over here to do, work and enjoy."
                 Their fellow countryman and colleague, Jeff Thurston, is also finding the living easy.
                 "I've been given an opportunity to settle in a nice country. It's got great prospects for me and my
                 family, whereas England wouldn't," he explains.
                 "I've been able to find new friends now and the experience is pretty good at the moment. My fiancée
                 has just come over from England and she is working for River Base Hospital as a nurse, so I think
                 things have begun to come together for us."
                 Oscar Furniture owner Anthony Op de Coul points out that although the preliminary work to get his
                 skilled migrants to Australia took some time, it was still a better alternative than his previous fruitless
                 searches.
                 "It's not a quick fix solution, it takes time - six months or longer. But it is a solution. (We) weren't
                 getting anywhere for a number of years.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                      72
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
                     "Over the last 10 years I guess we had advertised on and off in the city and the like, to get skilled
                     trades people with no avail. After having no luck advertising overseas myself in South Africa,
                     someone put me onto the State Government's Skilled Migration Unit and I contacted them.
                     "They had some contacts with the furniture Guild in England and they placed an ad in their magazine
                     and from that ad I have ended up with three staff."
                     Jeff openly encourages other employers to consider looking beyond Australia's borders to fill their
                     vacancies.
                     "It's worth putting an effort into (that is) to find some people to come over - there are a lot of good
                     people in other countries that can really help develop skills in this country," he says.




            How to test
             Use the IE Accessibility Toolbar, or the Firefox Developer toolbar, to disable
               JavaScript and Flash and make sure you can still access information [Compulsory]
             Make sure all PDFs, Word documents etc have HTML versions [Compulsory]
             Manually browse through the site and identify all downloadable documents. Are these
               documents available in a text or HTML version? [Compulsory]

            Techniques for addressing Checkpoint 6.3
            Text and non-text equivalents for applets and programmatic objects 120
            Directly accessible scripts 121




120
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#applet-text-equivalent
121
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                         73
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoints on multimedia

Checkpoint 1.3
Level A
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.
                                                                              http://www.w3.org/TR/WCAG10/


            Guideline
            Provide equivalent alternatives to auditory and visual content.

            Why?
            This is to ensure that people who are blind or using a text-only browser can still access
            the information presented in a visual track. Visual tracks are any moving content which
            relies on discernment of visual cues to understand the information e.g. movies or
            animations. Visual cues that might be used in a movie or animation include:
             body language;
             settings;
             actions and movement;
             displayed text; and
             use of colour.

            This toolkit provides information on:
             video;
             captioning video;
             audio describing video;
             vodcasts; and
             YouTube videos.

            How to test
             Manually test all multimedia objects with the screen turned off and determine whether
               the information is still available as an audio description [Compulsory]
             User test the site with a blind or visually impaired person using a screen-reader
               [Optional]

            Techniques for addressing Checkpoint 1.3
            Visual information and motion 122




122
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#video-information


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  74
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 1.4
Level A
For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent
alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.
                                                                              http://www.w3.org/TR/WCAG10/


            Guideline
            Provide equivalent alternatives to auditory and visual content.

            Why?
            This is to ensure that people who are hearing impaired or using a text-only browser can
            still interact as required with the movie or animation. Movies or animations that require
            responses at particular times e.g. selecting ‘Yes’ or ‘No’ to a question, must make these
            interactions available to people who may not be able to see or use the movie or
            animation as expected.

            This toolkit provides information on:
             video;
             captioning video;
             audio describing video;
             vodcasts; and
             YouTube videos.

            How to test
             Manually test the presentation by using a computer without images, JavaScript,
               Flash, etc. [Compulsory]
             Manually test the presentation by selecting options with the keyboard instead of the
               mouse [Compulsory]
             Manually test the ability to pause or slow down the presentation [Compulsory]
             Turn off the audio and watch the presentation to see if you can still understand the
               video [Compulsory]
             Manually test the presentation in a text-only browser such as Lynx [Optional]
             User test the site with a blind or visually impaired person using a screen-reader
               [Optional]

            Techniques for addressing Checkpoint 1.4
            Audio information 123
            Directly accessible applets 124




123
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#audio-information
124
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 75
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

If you can’t make it accessible

Checkpoint 11.4
Level A
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.
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Use W3C technologies and guidelines.

            Why?
            This is to ensure that if information cannot be made accessible; there are alternate
            means to accessing the information.

            This remains a contentious issue amongst the W3C members responsible for the W3C
            Web Content Accessibility Guidelines. Some members believe that if a page cannot be
            made accessible according to the other 15 checkpoints then the page should be deemed
            inaccessible. However, others believe that if there is a reason as to why the content is not
            accessible (impractical or unfeasible due to lack of resources or amount of time required),
            then as long as the information can be accessed in an alternative (including non-web)
            format then the page is still accessible.

            Examples where content could be made accessible using this latter definition are:
             when providing PDFs to download information include an HTML version of the
               document and contact details (phone number and email address) so that users can
               request a print or email version;
             when providing a pod cast, include a transcript of the information; and
             when providing a map, include relevant major intersections, roads and contact details
               (phone number and email address) so users can request further information about
               the area.

            How to test
             User test the entire site with a variety of people with different disabilities to ensure
               that all the content is accessible [Compulsory]
             Where you have included an alternative page, ensure it is updated at the same time
               as the original page; for example, include an automated reminder somewhere in the
               update process. [Optional]

            Techniques for addressing Checkpoint 11.4
            Alternative pages 125




125
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#alt-pages


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                76
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit


Level AA Checkpoints

Checkpoint 2.2
Ensure that foreground and background color combinations provide sufficient contrast when
viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2
for images, Priority 3 for text
                                                                               http://www.w3.org/TR/WCAG10/


             Guideline
             Don't rely on color alone.

             Why?
             Colour contrast is important for people who have vision impairments, particularly those
             with colour blindness. 126 .

             Relying on colour is problematic for users with screen readers, which cannot distinguish
             colours.

             This toolkit provides information on creating high colour contrast.




126
      Colour blindness is very common, affecting one in five men


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  77
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 3.1
When an appropriate markup language exists, use markup rather than images to convey
information.
                                                                              http://www.w3.org/TR/WCAG10/


            Guideline
            Use markup and style sheets and do so properly.

            Why?
            Markup can provide valuable information to screen reader users. For example, screen
            readers identify lists and include the number of items in the list. Screen readers also
            identify headings, including the specific level. Using markup also makes the site easier to
            use when style sheets are disabled.

            Using markup instead of images also allows content to be appropriately spidered by
            search engines, and web pages to be magnified without pixelation.

            Example
            The eGovernment website provides a good example of appropriate use of markup and
            images. With style sheets enabled, the bullets in this list appear as images, but with style
            sheets disabled the bullets fallback gracefully to the regular character..




            Other examples
            Images of text should be replaced with styled text. The benefits of creating styled text
            include:
                  The ability to scale up the text without quality loss (an image would become
                     pixelated);
                  Search engines will recognize the text (search engines cannot read the text
                     within images); and
                  separating presentation from content.

            Also note that mathematical equations should be coded with Methyl 127 instead of using
            standard ASCII characters.



127
      http://www.w3.org/Math/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 78
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
            How to test
             Disable style sheets and determine whether structure is maintained. [Compulsory].
             Increase text size and see if any content pixellates [Compulsory].

            Techniques for addressing Checkpoint 3.1
            HTML Techniques – using markup 128
            HTML Techniques – Structure vs Presentation 129




128
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup
129
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            79
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 3.2
Create documents that validate to published formal grammars.
                                                                          http://www.w3.org/TR/WCAG10/


        Guideline
        Use markup and style sheets and do so properly.

        Why?
        This checkpoint ensures that websites are built to standards. When a website validates to
        a published formal grammar it can be more easily interpreted by user agents such as
        browsers and screen readers.

        This remains a contentious issue amongst the W3C members responsible for the W3C
        Web Content Accessibility Guidelines, where some believe that validation is not a
        relevant accessibility issue.

        This toolkit provides information on creating valid HTML pages.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             80
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 3.3
Use style sheets to control layout and presentation.
                                                                        http://www.w3.org/TR/WCAG10/


        Guideline
        Use markup and style sheets and do so properly.

        Why?
        Presentational elements – such as spacer gifs and layout tables – can confuse screen
        reader users, making the separation of content from presentation a crucial accessibility
        requirement. CSS were developed specifically to separate content from presentation.
        Therefore, the more presentation elements that can be moved into style sheets, separate
        to web page content, the more accessible a website will be.

        This toolkit provides information on page structure, page source order and creating valid
        CSS.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           81
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 3.4
Use relative rather than absolute units in markup language attribute values and style sheet
property values.
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Use markup and style sheets and do so properly.

            Why?
            Users with vision impairments may increase the size of web page text in order to read it
            properly, as may other users. If website markup language and style sheet values are
            coded as absolute then the size of the container of text will not increase as the text size
            increases the web page layout (e.g. the size of the container) may not gracefully
            accommodate text size changes, resulting in the text overlapping or being cut off or made
            otherwise unreadable. Making markup language and style sheet values relative will mean
            that the web page layout will accommodate the increased text size.

            Example – Wordpress
            When creating a post in Wordpress, if you use the default, two-column mode and
            increase the text size, the post field expands under the third column.




            How to test
             Open the source code of the document and search for the following tags:
               o HR, IFRAME, TABLE, TD, TH
               Make sure all the values are relative (% or em) not absolute (px or pixels)
               [Compulsory]
             Open each external style sheet (search for “link rel='stylesheet'” in the source code to
               identify style sheets being used). Read through the style sheets and make sure all
               the values are relative (% or em), not absolute (px or pixels) [Compulsory]
             Open the web page, increase the text size (CTRL and +) and check the integrity of
               the web page layout and text [Compulsory].

            Techniques for addressing Checkpoint 3.4
            CSS Techniques – Relative units 130




130
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#units


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               82
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 3.5
Use header elements to convey document structure and use them according to specification.
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Use markup and style sheets and do so properly.

            Why?
            This checkpoint ensures screen reader users and people with cognitive disabilities are
            provided with adequate information about the web page. Headings improve the
            “scannability” of web pages which allows these users easier access to content.

            Example
            The eGovernment Resource Centre uses nested headings to convey information:




            How to test
            For details on how to test headings see the evaluation tools section.

            Techniques for addressing Checkpoint 3.5
            WebAIM – Creating semantic structure 131
            Section headings 132




131
      http://www.webaim.org/techniques/semanticstructure/
132
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-headers


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               83
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 3.6
Mark up lists and list items properly.
                                                                           http://www.w3.org/TR/WCAG10/


            Guideline
            Use markup and style sheets and do so properly.

            Why?
            This checkpoint serves to provide additional web page information to screen readers.
            Bulleted and numbered lists are easily identified by the screen reader and improve the
            “scannability” of the page for users.

           Example – eGovernment Resource Centre
           The eGovernment Resource Centre has appropriately marked up their bulleted lists.




           <ul>
           <li><a href="http://www.egov.vic.gov.au/index.php?env=-innews/detail:m1570-1-1-8-s-
           0:n-1719-1-0--">Australia - Online Availability of Government Entities' Documents Tabled
           in the Australian Parliament</a> </li>
           <li><a href="http://www.egov.vic.gov.au/index.php?env=-innews/detail:m3160-1-1-8-s-
           0:n-1721-1-0--">Maximising Engagement Online Whilst Reducing Costs: Best Practices
           for Government and Community Organizations</a> </li>
           ………
           </ul>

            How to test
             Use WAVE to determine if your lists have been coded as bulleted or numbered lists
               (denoted by the following icons) [Compulsory].




            Techniques for addressing Checkpoint 3.6
            HTML Techniques – Lists 133




133
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               84
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 3.7
Mark up quotations. Do not use quotation markup for formatting effects such as indentation.
                                                                           http://www.w3.org/TR/WCAG10/


            Guideline
            Use markup and style sheets and do so properly.

            Why use quotation markup?
            Text marked up as a quotation can be easily identified and read by a screen reader.

            Why not use BLOCKQUOTE for indentation?
            Screen readers identify the BLOCKQUOTE tag as a quotation and read the contained
            text accordingly. If the BLOCKQUOTE tag is used purely as a means to indent text the
            screen reader user will be getting incorrect information about the content.

            Example – Live in Victoria
            Live in Victoria provides an example of a quote that is coded using the BLOCKQUOTE
            element.




            <blockquote><p>"I called the Victorian Government’s Skilled Migration Program and was
            able to speak to someone straightaway – it was amazing. She really helped me through
            the process."</p></blockquote>

            How to test
             Use WAVE to determine if your quotations have been appropriately coded (denoted
               by the following icons) [Compulsory].




            Techniques for addressing Checkpoint 3.7
            HTML Techniques Quotations 134




134
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-quotes


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              85
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 6.5
Ensure that dynamic content is accessible or provide an alternative presentation or page.
                                                                           http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure that pages featuring new technologies transform gracefully.

            Why?
            This checkpoint ensures that if dynamic content cannot be made accessible there are
            alternate means to accessing the information.


           Example – Disability QLD
           Disability QLD uses JavaScript to provide a drop down menu. With JavaScript disabled
           an alternative is provided through a list of the menu links on the top level page.




            How to test
             Turn off JavaScript and see if all the content is still readable and functional
               [Compulsory].
             Turn off Flash and see if all the content is still readable and functional [Compulsory].
             Read and use the dynamic content using only the keyboard [Compulsory].
             Test with a screen reader user to determine if the dynamic content is readable and
               functional [Optional].

            Techniques for addressing Checkpoint 6.5
            Core Techniques – Alternative pages 135
            Core Techniques – Audio information 136


135
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#alt-pages
136
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#audio-information


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              86
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             HTML Techniques – The LINK element and alternative documents 137
             HTML Techniques – Directly accessible applets 138
             HTML Techniques – Writing for browsers that do not support FRAME 139
             HTML Techniques – Graceful transformation of scripts 140
             Office for People with a Disability – JavaScript factsheet 141
             Office for People with a Disability – Flash factsheet 142




137
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-alternative-docs
138
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
139
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#noframes
140
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-gt
141
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites
142
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                87
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 7.2
Until user agents allow users to control blinking, avoid causing content to blink (i.e., change
presentation at a regular rate, such as turning on and off).
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure user control of time-sensitive content changes.

            Why?
            Blinking content can distract users – especially users with attention disorders – and could
            potentially trigger an epileptic attack.

            Example
            The following is an example of blinking content:




            How to test
             Review all pages that contain movement and see if it can be paused or stopped
               [Compulsory].
             Use WAVE to determine if your page contains blinking (denoted by the following
               icon) [Compulsory].




            Techniques for addressing Checkpoint 7.2
            HTML Techniques – Directly accessible applets 143
            HTML Techniques – Scripts that cause movement and blinking 144
            CSS Techniques – Text style effects 145




143
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
144
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-movement-blinking
145
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-text


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                88
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 7.4
Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing
pages.
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure user control of time-sensitive content changes.

            Why?
            When a web page refreshes, screen readers automatically begin reading the page from
            the beginning. If a web page auto-refreshes it may become impossible for screen reader
            users to access the contained information.

            Example
            The Herald Sun 146 has an automatic refresh every 240 seconds.

            <meta http-equiv="refresh" content="0240">

            How to test
             Use WAVE to determine if the page contains any refresh elements (denoted by the
               following icon) [Compulsory].




            Techniques for addressing Checkpoint 7.4
            Core Techniques – Automatic page refresh 147
            HTML Techniques – The META element 148
            HTML Techniques – Directly accessible applets 149
            HTML Techniques – Page updates and new windows 150




146
      http://www.heraldsun.com.au
147
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh
148
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#meta-element
149
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
150
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                89
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 7.5
Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages
automatically. Instead, configure the server to perform redirects.
                                                                          http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure user control of time-sensitive content changes.

            Why?
            When a web page redirects to another page, an assumption is made that the user has
            had time to read all the information on the current page. This assumption often doesn’t
            consider that screen reader users may not have had enough time to access the required
            information.

            Example
            DHL includes a page which automatically redirects after two seconds.




            How to test
             Use WAVE to determine if the page contains any redirect elements (denoted by the
               following icon) [Compulsory].




            Techniques for addressing Checkpoint 7.5
            Core Techniques – Automatic page refresh 151
            HTML Techniques – The META element 152
            HTML Techniques – Page updates and new windows 153




151
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh
152
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#meta-element
153
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             90
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 10.1
Until user agents allow users to turn off spawned windows, do not cause pop-ups or other
windows to appear and do not change the current window without informing the user.
                                                                                         http://www.w3.org/TR/WCAG10/


            Guideline
            Use interim solutions.

            Why?
            Opening new windows without informing the user can be very disorienting for screen
            reader users and people with cognitive disabilities. It is important that you adequately
            inform the user when a new window will be opened.

            Example
            Live in Victoria provides an example of an icon that is used prior to the link to open a new
            window:




            This icon has an ALT attribute of: “Opens in a new window”. In addition to this a legend
            should be included somewhere on the page e.g. the footer.

            How to test
             Use an evaluation tool such as WAVE to indicate links that open in new windows
               [Compulsory].

            Techniques for addressing Checkpoint 10.1
            Dive into Accessibility – Not opening new windows 154
            WebCredible – Beware of opening links in a new windows 155
            HTML Techniques – Anchors and targets 156
            HTML Techniques – Directly accessible applets 157
            HTML Techniques – Using FRAME targets 158
            HTML Techniques – Page updates and new windows 159




154
      http://diveintoaccessibility.org/day_16_not_opening_new_windows.html
155
      http://www.webcredible.co.uk/user-friendly-resources/web-usability/new-browser-windows.shtml
156
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#anchors-targets
157
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
158
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#no-new-windows
159
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                            91
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 11.1
Use W3C technologies when they are available and appropriate for a task and use the latest
versions when supported.
                                                                      http://www.w3.org/TR/WCAG10/


        Guideline
        Use W3C technologies and guidelines.

        Why?
        W3C technologies are more likely to be supported by assistive technologies such as
        screen readers.

        Example – Department of Sustainability and Environment (DSE)
        DSE have used style sheets, a W3C technology, to style their navigation.

         Style sheets on:                      Style sheets off:




        How to test
        Ensure the following W3C technologies have been used: [Compulsory].
         Methyl for mathematical equations;
         HTML, XHTML, XML for structured documents;
         RDF for meta data;
         SMIL to create multimedia presentations;
         CSS and XSL to define style sheets;
         XSLT to create style transformations; and
         PNG for graphics (although some are best expressed in JPG and GIF).




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         92
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
           Techniques for addressing Checkpoint 11.1
           Core Techniques for W3C technologies 160




160
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#access-reviewed


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   93
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 11.2
Avoid deprecated features of W3C technologies.
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Use W3C technologies and guidelines.

            Why?
            Assistive technologies e.g. screenreaders, are more likely to support current W3C
            technologies than those that have been deprecated. Current releases of W3C
            technologies also often provide new or improved functionality over previous, deprecated
            releases, further increasing the accessibility of websites.

            Example
            This website 161 contains a deprecated attribute.

            Avoid deprecated features of W3C technologies.
                Rule: 11.2.1 - Identify the use of one or more deprecated elements or attributes
                 within the document.
                     o Failure - Document uses one or more deprecated elements or attributes.
                          The document contains the element: table with the deprecated attribute:
                          align

            How to test
             The most common deprecated HTML elements <B> (bolds text) and <I> (italicises
               text) are picked up by WAVE (denoted by the following icons) [Compulsory].


                Use Cynthia Says to identify any deprecated attributes or elements [Compulsory]

            Techniques for addressing Checkpoint 11.2
            Index of HTML attributes and elements 162 (deprecated elements and attributes are
                denoted by an asterisk)
            CSS Techniques – User override of styles 163
            CSS Techniques – Fonts 164




161
      http://www.theage.com.au
162
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#html-index
163
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#user-override
164
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-fonts


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               94
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Checkpoint 12.3
Divide large blocks of information into more manageable groups where natural and appropriate.
                                                                         http://www.w3.org/TR/WCAG10/


           Guideline
           Provide context and orientation information.

           Why?
           Users can scan and identify information more readily when content is grouped e.g. using
           headings.

           Example – Department of Innovation, Industry and Regional Development (DIIRD)
           DIIRD uses headings to break up naturally different items/blocks of content.




           How to test
            Browse through your site and identify any areas that can be naturally grouped via the
              following attributes and elements [Compulsory].
              o Use FIELDSET to group form controls into semantic units and describe the group
                   with the LEGEND element;
              o Use tables for tabular data and describe the table with CAPTION (except if the
                   table is used for layout only);
              o Group table rows and columns with THEAD, TBODY, TFOOT, and COLGROUP;
              o Nest lists with UL and OL.;
              o Use section headings (H1 - H6) to create structured documents and break up
                   long stretches of text; and
              o Break up lines of text into paragraphs (with the P element).


           Techniques for addressing Checkpoint 12.3
           Core Techniques – structural grouping 165


165
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#grouping


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            95
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
            HTML Techniques – Grouping form controls 166




166
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   96
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit

Checkpoint 13.1
Clearly identify the target of each link.
                                                                                                http://www.w3.org/TR/WCAG10/


             Guideline
             Provide clear navigation mechanisms.

             Why?
             Text links such as “click here” and “more” do not convey enough information to users that
             require screen readers or have cognitive disabilities. Clear indicators for navigation items
             e.g. descriptive text links, assist these users to understand the target of the particular link.
             Note that text links should not include TITLE attributes because:
              screen readers do not read TITLE attributes consistently;
              browsers do not display TITLE attributes consistently;
              magnifier users cannot access the entire TITLE attribute; and
              the TITLE attribute is not available to visual keyboard users.

             How to test
             For details on how to test headings see the evaluation tools section.

             Techniques for addressing Checkpoint 13.1
             The trouble with the TITLE attribute 167
             Too much accessibility: TITLE attribute 168




167
      http://www.sf.id.au/ozewai/
168
      http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                   97
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 13.2
Provide metadata to add semantic information to pages and sites.
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Provide clear navigation mechanisms.

            Why?
            Assistive technologies e.g. screen readers, use metadata to determine whether it can
            process a web page.

            Example
            This website 169 contains missing metadata.

            Provide metadata to add semantic information to pages and sites.
                Rule: 13.2.1 - Documents are required to use the TITLE element.
                     o   Note: Document uses the TITLE element.
                Rule: 13.2.2 - Documents are required to use META elements, that are defined as
                 required, in Head section.
                     o   Failure - Document does not contain a META element with the required
                         name: language or language does not have a 'content' value.

            How to test
             Use Cynthia Says to identify whether metadata has been included [Compulsory].

            Techniques for addressing Checkpoint 13.2
            Core Techniques – Navigation 170
            HTML Techniques – Metadata 171
            CSS Techniques – Providing contextual clues in HTML lists 172




169
      http://www.theage.com.au
170
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation
171
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-meta
172
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#lists


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               98
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Checkpoint 13.3
Provide information about the general layout of a site (e.g., a site map or table of contents).
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Provide clear navigation mechanisms.

            Why?
            Some people with disabilities prefer to navigate via a site map or table of contents, as
            navigation bars and search results may be too complex.

           Example – Monash University
           Monash University provides an A-Z index that encompasses the main areas of their many
           websites.




            How to test
             Review your website to determine whether a site map, table of contents or A-Z index
               have been used. This feature should be available from every page on the website.

            Techniques for addressing Checkpoint 13.3
            Core Techniques – Navigation 173




173
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 99
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 13.4
Use navigation mechanisms in a consistent manner.
                                                                           http://www.w3.org/TR/WCAG10/


        Guideline
        Provide clear navigation mechanisms.

        Why?
        People with cognitive disabilities will find it easier to use a website that has a consistent
        navigation. For screen reader users, consistent navigation means the user can identify
        navigation and choose to skip it.

        Example - DIIRD
        The DIIRD website displays top level pages and sub-pages consistently within the
        website navigation. Top level pages are highlighted with a blue arrow (pointing to the
        right, or down, depending on the selection status). Sub-pages are displayed within a grey
        background separated by white lines.

         DIIRD Projects and sub-items             DIIRD Initiatives and sub-items




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             100
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
            How to test
             Browse through the website, identify navigation elements and ensure they are
               consistent [Compulsory].

            Techniques for addressing Checkpoint 13.4
            Core Techniques – Navigation 174




174
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                101
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Tables

Checkpoint 5.3
Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table
does not make sense, provide an alternative equivalent (which may be a linearized version).
                                                                           http://www.w3.org/TR/WCAG10/

            This checkpoint no longer applies.



Checkpoint 5.4
If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
                                                                           http://www.w3.org/TR/WCAG10/


            Guideline
            Create tables that transform gracefully.

            Why?
            Screen readers assume that HTML tables with structural markup e.g. TH, TD tags, are
            intended for the presentation of data, and read them accordingly. For this reason,
            website page layouts should not be constructed with marked-up tables; screen readers
            will be unable to make sense of web page layouts that use tables in this way.

            How to test
             Cynthia Says will identify all tables. Of these tables, separate out any that are used
               for layout and ensure that they do not contain structural markup such as:
               o TH;
               o TD;
               o THEAD;
               o TBODY;
               o CAPTION; and/or
               o SUMMARY.
                [Compulsory].

            Techniques for addressing Checkpoint 5.4
            Core Techniques: Structure vs. Presentation 175
            HTML Techniques: Tables for layout 176




175
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure
176
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            102
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Frames

Checkpoint 12.2
Describe the purpose of frames and how frames relate to each other if it is not obvious by frame
titles alone.
                                                                        http://www.w3.org/TR/WCAG10/


        Guideline
        Provide context and orientation information.

        Why?
        Screen reader users and people using a text-only browser rely on the frame description
        to determine the content of a frame.

        This toolkit provides information on frames and iFrames.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         103
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Forms




Checkpoint 10.2
Until user agents support explicit associations between labels and form controls, for all form
controls with implicitly associated labels, ensure that the label is properly positioned.
                                                                         http://www.w3.org/TR/WCAG10/


        Guideline
        Use interim solutions.

        Why?
        Correct labeling of forms ensures that people using magnifiers and those with cognitive
        disabilities can understand the required input for a particular field.

        This toolkit provides information on forms.




Checkpoint 12.4
Associate labels explicitly with their controls.
                                                                         http://www.w3.org/TR/WCAG10/


        Guideline
        Provide context and orientation information.

        Why?
        Associating labels with form fields ensures that screen readers read the appropriate label
        for a particular field.

        This toolkit provides information on forms.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           104
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit



Scripts and applets




Checkpoint 6.4
For scripts and applets, ensure that event handlers are input device-independent.
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure that pages featuring new technologies transform gracefully.

            Why?
            Some users rely on only one input device (e.g. keyboard, mouse, trackball, headwand)
            therefore it is important that scripts and applets can be manipulated without relying on a
            specific device.

            This toolkit provides information on JavaScript

            .


Checkpoint 7.3
Until user agents allow users to freeze moving content, avoid movement in pages.
                                                                             http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure user control of time-sensitive content changes.

            Why?
            Moving content can distract users, especially users with attention disorders.

            How to test
             Review all pages that contain movement and see if it can be paused or stopped
               [Compulsory].
             Use WAVE to determine if your page contains the BLINK element[Compulsory].

            Techniques for addressing Checkpoint 7.3
            Core Techniques – Visual information and motion 177
            HTML Techniques – Animated images 178
            HTML Techniques – Directly accessible applets 179
            HTML Techniques – Scripts that cause movement and blinking 180
            CSS Techniques – Creating movement with style sheets and scripts 181


177
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#video-information
178
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#animated-images
179
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
180
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-movement-blinking


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              105
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit




181
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-movement


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   106
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Checkpoint 8.1
Make programmatic elements such as scripts and applets directly accessible or compatible with
assistive technologies [Priority 1 if functionality is important and not presented elsewhere,
otherwise Priority 2.]
                                                                            http://www.w3.org/TR/WCAG10/


            Guideline
            Ensure direct accessibility of embedded user interfaces.

            Why?
            Assistive technologies need access to scripts and applets to ensure all users are able to
            interact with a website as intended. Many of these languages and applications, such as
            JavaScript and Flash, contain accessibility features that make them directly accessible to
            some assistive technologies.

            Example
            The following Crossword Puzzles 182 are built with Flash and contain a number of
            accessibility features such as:
             Keyboard only operability
             Sound on action
             Active highlighting e.g. column and clue




            How to test
             Attempt to read and use website scripts and applets using only the keyboard
               [Compulsory].
             Test with a screen reader user to determine if the scripts and applets are readable
               and functional [Optional].

182
      http://www.eduplace.com/tacklereading/puzzles.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             107
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

             Techniques for addressing Checkpoint 8.1
             HTML Techniques – Directly accessible applets 183
             HTML Techniques – Directly accessible scripts 184
             Office for People with a Disability – JavaScript factsheet 185
             Office for People with a Disability – Flash factsheet 186




183
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
184
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-scripts
185
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites
186
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                108
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Checkpoint 9.2
Ensure that any element that has its own interface can be operated in a device-independent
manner.
                                                                                      http://www.w3.org/TR/WCAG10/


             Guideline
             Design for device-independence.

             Why?
             Assistive technologies need access to interfaces within, or that are triggered by, a web
             page to ensure all users are able to interact with a website as intended. Many of these
             interfaces, such as downloaded PDF and Word documents contain accessibility features
             that make them directly accessible to some assistive technologies.

            Example – eGovernment Accessibility Toolkit PDF
            The PDF version of the eGovernment Accessibility Toolkit can be operated via the
            keyboard only.

             How to test
              Read and use all on-page interfaces, and interfaces triggered on-page e.g.
                downloading documents, using only the keyboard [Compulsory].
              Test with a screen reader user to determine if the program/interface is readable and
                functional [Optional].

             Techniques for addressing Checkpoint 9.2
             HTML Techniques – Directly accessible applets 187
             HTML Techniques – Directly accessible scripts 188
             Office for People with a Disability – JavaScript factsheet 189
             Office for People with a Disability – Flash factsheet 190




187
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
188
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-scripts
189
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites
190
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                       109
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Checkpoint 9.3
For scripts, specify logical event handlers rather than device-dependent event handlers.
                                                                                      http://www.w3.org/TR/WCAG10/


             Guideline
             Design for device-independence.

             Why?
             It is important that the content of a website changes due to the actual request made by
             the user, not because of which input device (mouse, keyboard, headwand, trackball etc)
             has been used.

             How to test
              Read and use the program using only the keyboard [Compulsory].
              Test with a screen reader user to determine if the program is readable and functional
                [Optional].

             Techniques for addressing Checkpoint 9.3
             HTML Techniques – Directly accessible applets 191
             HTML Techniques – Directly accessible scripts 192
             Office for People with a Disability – JavaScript factsheet 193
             Office for People with a Disability – Flash factsheet 194




191
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets
192
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-scripts
193
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites
194
      http://www.officefordisability.vic.gov.au/research_and_resources.htm#websites


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                       110
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Level AAA Checkpoints


Checkpoint 4.3
Identify the primary natural language of a document.
                                                                          http://www.w3.org/TR/WCAG10/


            Guideline
            Clarify natural language usage

            Why?
            Screen readers use this information to determine how to interpret and read the web page
            content.

            Example - DIIRD
            <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

            How to test
             Use Cynthia Says to determine if the primary natural language has been identified
               [Compulsory]

            Techniques for addressing Checkpoint 10.1
            HTML Techniques: Identifying the primary language 195




195
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#identify-primary-lang


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           111
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 9.4
Create a logical tab order through links, form controls, and objects.
                                                                          http://www.w3.org/TR/WCAG10/


        Guideline
        Design for device-independence.

        Why?
        People with physical disabilities often use only the keyboard to navigate. These groups
        often have no problem viewing the site, but use the keyboard to tab from link to link. If the
        tab order is not logical then it makes the website very difficult for them to use. For screen
        reader users, skip links can be provided to skip over the navigation (which often occurs
        before the content).

        Websites should be built with a logical tab order and the TABINDEX element should not
        be used.

        This toolkit provides information on page structure.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           112
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Checkpoint 13.5
Provide navigation bars to highlight and give access to the navigation mechanism.
                                                                                 http://www.w3.org/TR/WCAG10/


            Guideline
            Provide clear navigation mechanisms.

            Why?
            People with cognitive disabilities will find a website easier to use if it includes a clear
            navigation system.

            How to test
             Browse through the site and ensure a clear navigation system has been used
               consistently [Compulsory].
             Ensure the navigation system is on every page in the site [Compulsory].

            Techniques for addressing Checkpoint 13.5
            Core Techniques – Navigation 196




196
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    113
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 13.6
Group related links, identify the group (for user agents), and, until user agents do so, provide a
way to bypass the group.
                                                                          http://www.w3.org/TR/WCAG10/


        Guideline
        Provide clear navigation mechanisms.

        Why?
        Screen reader users often have to skip similar information on each page to access the
        content they require e.g. navigation bars, search boxes, banners and advertisements.
        Providing a way to bypass these types of content greatly assists website navigation for
        people using screen readers.

        Magnifier users also use skip links so it is recommended that skip links are always
        visible.

        Example
        DIIRD provides a “Skip to Content” link as a way to bypass the:
             banner;
             search bar;
             left hand navigation; and
             breadcrumbs.




        How to test
         Check the website for a “Skip to content” link, or equivalent [Compulsory].




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           114
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit
            Techniques for addressing Checkpoint 13.6
            Core Techniques – Navigation 197




197
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   115
Copyright State of Victoria, 2009
                  Victorian Government Accessibility Toolkit

Checkpoint 14.2
Supplement text with graphic or auditory presentations where they will facilitate comprehension of
the page.
                                                                             http://www.w3.org/TR/WCAG10/


           Guideline
           Ensure that documents are clear and simple.

           Why?
           People with cognitive disabilities often have trouble reading text. Providing a graphic or
           audio version of the page can assist these users in understanding the content on the
           page.

           Example
           Companion Card uses different images to represent each navigation item, for example:
            the question mark represents ‘About Companion Card’;
            the spanner represents ‘Industry’; and
            the Q represents ‘FAQs’.




           How to test
            Review the navigation and see if icons can be used to assist in comprehension
              [Compulsory].

           Techniques for addressing Checkpoint 14.2
           Core Techniques – Comprehension 198




198
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              116
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Checkpoint 14.3
Create a style of presentation that is consistent across pages.
                                                                        http://www.w3.org/TR/WCAG10/


        Guideline
        Ensure that documents are clear and simple.

        Why?
        People with cognitive disabilities will find websites with a consistent presentation of
        information easier to navigate and use. For screen reader users, consistent presentation
        allows the user to avoid repeating common items on each page.

        Example – Monash University
        Monash University has numerous sub-sites which all use consistent templates. Although
        the top navigation changes for each site, the meta-navigation (Staff directory, A-Z Index
        and Site map) remains consistent. A number of elements are consistent across the
        websites, including:
         the logo;
         the use of a right hand image in the banner;
         the Search bar; and
         the presentation of the two horizontal levels of navigation.




        How to test
         Ensure that your website uses templates and that common items are consistent
           across the site [Compulsory].




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         117
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
            Techniques for addressing Checkpoint 14.3
            Core Techniques: Navigation 199
            CSS Techniques: Decrease maintenance and increase consistency 200




199
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#navigation
200
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#consistency


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011          118
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit


Section Five: Top issues
When attempting accessibility conformance you may find it difficult to follow some accessibility
guidelines. This section covers what to do in the following situations:
 Making images, image maps, maps and graphs accessible
 Making tables accessible
 PDFs and accessibility
 Making a PDF accessible
 Creating accessible forms
 JavaScript
 Making splash pages accessible
 Creating valid HTML pages
 Creating valid CSS
 Page source order
 Page structure
 Ensuring sufficient colour contrast
 Creating sites accessible to people with cognitive disabilities
 Conducting operating system and browser testing
 Additional accessibility features
 Videos and Accessibility
 Captioning dowloadable videos
 Captioning YouTube videos
 Audio describing video
 Captioning vodcasts
 Audio and podcasts
 Flash and accessibility
 Mashups and accessibility
 Blogging and accessibility
 Maps and Google maps
 Frames and iFrames
 Slideshare
 Facebook
 Twitter




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         119
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit

Making images, image maps, maps and graphs accessible
Images, image maps, maps and graphs can sometimes be difficult or even impossible to describe
in text. There will be people who want to access the image but cannot for any of the following
reasons:
 They are colour blind
 They are browsing with images turned off
 They have a vision impairment that affects their ability to read a map
 They are blind
 They are using a text-only browser
 They cannot read English labels on maps
 They are using a keyboard instead of a mouse

            Relationship to checkpoints
            Checkpoint 1.1 requires that for all non-text elements that a text equivalent is provided.
            This means that either a text explanation of the information is given near the non-text
            element, or that the description is coded with the information, such as in an ALT attribute
            of an image.

            Example solution - Maps
            The Melbourne 2006 Commonwealth Games venue map 201 is a very complex image that
            contains a lot of information. A section of the map is shown below.




            In the above example, information provided in the map includes the venue, the distance
            and direction the venue is from the CBD and the sports to be held at the venue. The map
            contains too much information to be contained in the ALT attribute and thus a long
            description would need to be written. The venue map still needs an ALT attribute
            however – a good example would be “Map of Commonwealth Games venues; for more
            information see the following table.” The long description provides the same information
            in a tabular form, for example:
                    Venue                                              Location
               Docklands Precinct     The venue for Walks is approximately 1.5 km south-west of the city centre.
               Melbourne Cricket     The venue for both Opening and Closing Ceremonies, Athletics and the start
                Ground (MCG)           and finish of the Marathon is approximately 2 km east of the city centre.
              Multi Purpose Venue       The venue for the Basketball Finals, Track Cycling and Netball Finals is
               (Melbourne Park)                       approximately 2 km east of the city centre.
               Rod Laver Arena         The venue for Gymnastics is approximately 2 km east of the city centre.
               (Melbourne Park)
                 Telstra Dome                  The venue for Rugby 7s is directly west of the city centre.

            The venue name also links to a page with further statistics.




201
      http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                         120
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Further information

             ALT attributes
                 W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
                 WebAIM: Appropriate use of alternative text 202

             Text description
                 W3C Checkpoint 11.4: If you cannot create an accessible page provide an alternative




202
      http://webaim.org/techniques/alttext/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           121
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Making tables accessible
Tables can cause a number of accessibility problems if they are not built using the accessibility
features within HTML. In web sites there are two ways to use tables: for layout or for data
presentation. Style sheets should always be used in preference to layout tables.

             Relationship to checkpoints
             Checkpoint 5.1 and 5.2 require that you mark up data tables with TH ID and TD
             HEADERS.
             Checkpoint 5.3 requires that the table makes sense when linearised.
             Checkpoint 5.4 requires that structural markup not be used for layout tables.
             Checkpoint 5.5 requires that tables use the SUMMARY attribute.
             Checkpoint 5.6 requires that you use abbreviations for data table headers.

             Marking up data tables with TH ID and TD HEADERS
             Ensure that all data tables are labeled properly, both in the table, and in the code. Table
             headers should be included as TH ID and TD HEADERS. SCOPE should not be used as
             it is not recognized by some screen readers 203 . For example the following table uses the
             following code:




                       <table summary="Mobile plans summary of costs and call
                       options" border=1>
                       <caption>Mobile Plans</caption>
                       <thead>
                       <tr>
                       <th></th>
                       <th id="play">Play Mobile Plan</th>
                       <th id="normal">Normal Mobile Plan</th>
                       <th id="business">Business Mobile Plan</th>
                       </tr>
                       </thead>
                       <tr>
                       <th id=”peak”>Cost per minute (peak)</th>
                       <td headers=”play peak”>52c</td>
                       <td headers=”normal peak”>42c</td>
                       <td headers=”business peak”>32c</td>
                       </tr>
                       <tr>
                       <th id=”off”>Cost per minute (off-peak)</th>
                       <td headers=”play off”>42c</td>
                       <td headers=”normal off”>32c</td>

203
      http://www.usability.com.au/resources/tables.cfm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               122
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
                 <td headers=”business off”>22c</td>
                 </tr>
                 <tr>
                 <th id=”total”>Total cost per month</th>
                 <td headers=”play total”>$5</td>
                 <td headers=”normal total”>$10</td>
                 <td headers=”business total”>$30</td>
                 </tr>
                 </table>
This table provides another example of correct markup:




        <table summary="Email" border=1>
        <thead>
        <tr>
        <th id="from">From</th>
        <th id="subject">Subject</th>
        <th id="date">Date</th>
        <th id="size">Size</th>
        </tr>
        </thead>
        <tbody>
        <tr>
        <td headers="from">Jetstar Airways</td>
        <td headers="subject">Jetstar’s 1,000,000 Seat Sale</td>
        <td headers="date">Dec 16</td>
        <td headers="size">11KB</td>
        </tr>
        <tr>
        <td headers="from">virginblue.com.au</td>
        <td headers="subject">Virgin Blue Update! Boxing Day Sale On No…</td>
        <td headers="date">Dec 16</td>
        <td headers="size">51KB</td>
        </tr>
        <tr>
        <td headers="from">virginblue.com.au </td>
        <td headers="subject">Virgin Blue Update!</td>
        <td headers="date">Dec 14</td>
        <td headers="size">31KB</td>
        </tr>
        </tbody>
        </table>


        Further information




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011          123
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                  Screen readers and the TH ID and TD HEADERS 204
                  Juicy Studio Complex Table Analyser 205




204
      http://www.usability.com.au/resources/tables.cfm
205
      http://juicystudio.com/article/firefox-table-inspector.php


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   124
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

PDFs and accessibility

Portable Document Format (PDFs), video files and other downloads are inaccessible according to
the W3C Web Content Accessibility Guidelines version 1.0. There are methods that can make the
actual PDF available to certain people with disabilities (for example, creating tagged PDFs206),
however even if these documents are created in an accessible way the information still will not
conform to the W3C Web Content Accessibility Guidelines. The Australian Human Rights
Commission has commented that Word documents are accessible:
http://www.hreoc.gov.au/about/media/media_releases/2008/86_08.html

"When documents are only put on the Internet in PDF format, it usually results in inadequate or
zero access for people with disability, "You can use HTML, Microsoft Word, or RTF formats", said
the Commissioner. "It's particularly depressing to see documents created in word-processor
formats, which provide very good access, being converted into PDF, which doesn't, then only
being posted in PDF." "

It is preferable, of course, to provide an HTML version.

There will be people who won’t be able to access the PDF because:
 They are using a version of a screen-reader that is not compatible with the required version of
   Adobe Reader
 They are using a computer that does not have Adobe Reader installed
 They are using a slow modem
 They have a vision or motor impairment that impedes their ability to use the Adobe Reader

            Relationship to checkpoints:
            Checkpoint 1.1 requires that a text equivalent is provided for all non-text elements,
            including PDFs.

            Providing details of the PDF
            Prior to downloading a PDF, the user needs to know certain information, such as the
            format of the file, the type of program required to access it, the size and summary of the
            file and an estimated download time.

            Every PDF file should include the following information:
             File type
             File size
             Estimated download time (considering bandwidth constraints)
             Number of pages
             Summary of content
             Link to the HTML equivalent

                      Example
                      The State Budget page on the Department of Education web site contains a PDF
                      version of the Victorian State Budget. The page contains summary information as
                      well as details on the size of the document.
                      State Budget 2006
                      You can download the “Budget Highlights PDF” file (4 pages, 397 KB, approx 4 min download on a
                      56K modem) or view the “HTML version of Budget Highlights”.
                      Summary


206
      Refer section on Making PDFs Accessible


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                            125
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
                 The State Government has tabled the 2006-07 Budget Statement which delivers an additional $1.2
                 billion to Victoria’s education and training system.
                 This Budget invests in new schools and school infrastructure, literacy skills and delivering a world-
                 class training system. It also recognizes the added expense to families when their children begin
                 primary or secondary school.
                 The 2006-07 Budget initiatives will play an important role in continuing to build the State’s education
                 and training system which in turn will build a better future for all Victorians.
                 Budget highlights include:
                    $448 million construction and equipment program for Schools and TAFE
                    $182 million School Start Bonus to help every child starting Prep or Year 7
                    $11.7 million for Literacy Improvement Teams
                    $36 million ‘Trades Bonus’ for all first year apprentices to encourage as many as possible to
                     complete their trade
                    $230 million towards Maintaining the Advantage: Skilled Victorians
                    $5.1 million for a new Academic Number to help improve outcomes for all students
                    $24.1 million to continue the Schools for Innovation and Excellence program
                    $47.2 million to continue the successful Victorian Certificate of Applied Learning
                    $11.6 million to school leadership initiative



        Providing equivalents to PDF
        Each PDF should have an equivalent HTML version that includes all the text, images,
        diagrams and references of the original PDF. Where necessary, this HTML equivalent
        should also include links and ALT attributes as well as other markup where required.
        When creating an equivalent of a very large PDF it is sometimes preferable to break the
        HTML equivalent into several pages, linked via a Table of Contents.

                 Example
                 Document Solutions has created a guide to developing accessible PDFs in
                 Acrobat 7.0:
                 http://www.appligent.com/adobeaccessibility

                 This initial page contains information about the guide, a link to the PDF version:
                 http://www.appligent.com/adobeaccessibility/AdobeAccess7bookv2.pdf

                 and a link to the HTML equivalent:
                 http://www.appligent.com/adobeaccessibility/AdobeAccessCover.html

                 This HTML equivalent includes an Index:
                 http://www.appligent.com/adobeaccessibility/AdobeAccess7IX.html

                 To further assist in navigating the HTML equivalent, each page has the following
                 links, available at the bottom of each page:
                       TOC (links to the HTML Table of Contents)
                       < Prev (links to the previous page)
                       > Next (links to the next page)
                       Index (links to the document index)

        Providing contact details
        It is important to always provide contact details in case users have trouble with the PDF.
        Users may also have difficulty with the PDF format or request a tagged PDF. When
        providing contact details make sure you include:


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                               126
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Name
                 Phone number
                 Email address
                 Postal address

             Further Information

             Text equivalents
                 W3C Checkpoint 1.1: Provide a text equivalent for every non-text element

             HTML converters
                 Converting to HTML 207

             PDF accessibility
                 Adobe accessibility 208
                 PDF accessibility 209




207
      http://www.w3.org/Tools/Filters.html
208
      http://www.adobe.com/accessibility/
209
      http://www.webaim.org/techniques/acrobat/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                       127
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Making a PDF accessible

PDFs cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people using screen readers. A PDF is made accessible by tagging
certain elements within it, for example images. If a PDF is tagged properly then a person using a
screen reader can often understand a PDF just as well as an HTML document. However PDF
does not yet have all the features of HTML, and therefore an equivalent must always be
provided 210 .

Please note: In order to create a tagged PDF you will need Adobe Acrobat Professional,
Version 5 or above and Microsoft Word, Version 2000 or above.

             Relationship to checkpoints:
             Checkpoint 8.1 requires that programmatic objects such as PDF are made directly
             accessible using the features available within the technology.

             Preparing the Word document
             It is preferable to create a tagged PDF from a Word document. However the Word
             document must have been created in a particular way.

             1. Use structural formatting
             Use the structural formatting already available in Word, for example headings, bullets and
             numbered lists.

             Make sure all text is formatted as Heading 1, Heading 2, Heading 3 and Body Text.

             Make sure a multi-column layout is achieved via column formatting and not through tabs
             or tables.

             Make sure all paragraphs end in a Paragraph Return instead of a Soft Return (an Enter
             versus a Shift+Enter)

             2. Create links
             Ensure all links in the Word document are live links.

             3. Group artwork
             If the document contains artwork comprised of several elements, group the entire artwork
             into one picture.

             4. Add alternative text to images
             Add alternative text to all images via the “Format picture” dialog box. Under the “Web”
             tab, there is a section available for alternative text.
             Please note: This is only available in Windows

             5. Format tables
             Ensure that tables are not nested.

             Turn off the “Allow row to break across pages” option in the “Table Formatting” dialog box
             to ensure rows do not break across pages.

             Where a table runs over two or more pages ensure the “Repeat as header row at the top
             of each page” is enabled.

210
      Refer to Section – Providing equivalents to PDF


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 128
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

        Creating the PDF document

        Please note: Do not use the option “Print as PDF” as this will not transfer across all the
        relevant formatting.

        1. Change Acrobat Conversion settings

                 Word 2000 / Acrobat 5.0
                 Open the “Change Conversion settings” via the “Acrobat” menu.

                 Under the “Office” tab ensure that “Embed tags in PDF” is enabled and “Page
                 labels” is disabled.

                 Under the “Bookmarks” tab ensure “Convert Word headings to bookmarks” is
                 enabled.

                 Under the “Settings” tab ensure that the “Enable Text Access for Screen Reader
                 Devices for the Visually Impaired” is enabled.

                 Word XP / Acrobat 6.0
                 Open the “Change Conversion settings” via the “Adobe PDF” menu.

                 Under the “Settings” tab ensure that the following are enabled:
                     “View Adobe PDF result”
                     “Prompt for Adobe PDF File Name”
                     “Convert Document Information”
                     “Add Bookmarks to Adobe PDF”
                     “Add Links to Adobe PDF”
                     “Enable Accessibility and Reflow with Tagged PDF”

                 Under the “Security” tab ensure that the “Enable Text Access for Screen Reader
                 Devices for the Visually Impaired” is enabled.

                 Under the “Bookmarks” tab ensure “Convert Word headings to bookmarks” is
                 enabled.

                 Word XP / Acrobat 7.0
                 Open the “Change Conversion settings” via the “Adobe PDF” menu.

                 Under the “Settings” tab ensure that the following are enabled:
                     “Convert Document Information”
                     “Add Bookmarks to Adobe PDF”
                     “Add Links to Adobe PDF”
                     “Enable Accessibility and Reflow with Tagged PDF”

                 Under the “Security” tab ensure that the “Enable Text Access for Screen Reader
                 Devices for the Visually Impaired” and “Enable Accessibility and Reflow with
                 Tagged PDF” is enabled.

                 Under the “Word” tab enable any options, such as cross-referencing, table of
                 contents etc that should become links in the accessible PDF.

                 Under the “Bookmarks” tab ensure “Convert Word headings to bookmarks” is
                 enabled.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           129
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             2. Create the PDF

                       Word 2000 / Acrobat 5.0
                       Create the accessible PDF by selecting “Convert to Adobe PDF” under the
                       “Acrobat” menu.

                       Word XP / Acrobat 6.0
                       Create the accessible PDF by selecting “Convert to Adobe PDF” under the
                       “Adobe PDF” menu.

                       Word XP / Acrobat 7.0
                       Create the accessible PDF by selecting “Convert to PDF” under the “Adobe PDF”
                       menu.

             Testing the PDF document

             1. Run a Full Check
             Run a Full Check of the accessibility of the PDF by selecting “Full Check” under the
             “Accessibility” tab in the “Advanced” menu.

             Under the “Report and Comments” section ensure that “Create Accessibility report” is
             enabled and “Create comments in document” is disabled.

             Under the “Checking options” section, make sure all options are enabled.

             The results of the Full Check will be created in an HTML document and saved in the
             same directory as the source PDF file. On completion of the Full Check this document
             automatically opens in the left window of the PDF file.
             Please note: Running a Full Check may be time-consuming.

             2. Use Reflow
             Reflow the text into a single column to determine whether the content still makes sense.
             Reflow can be turned on by selecting “Reflow” under the “View” menu.

             3. Turn on Read Out Loud
             Listen to the document being read aloud using the inbuilt Acrobat screen reader. Read
             Out Loud can be turned on by selecting “Read Out Loud” under the “View” menu.

             Further Information

             Creating tagged PDFs
                 Adobe – Acrobat Accessibility Training Resources 211
                 US Dept of Health and Human Services – Guidance making PDFs accessible 212




211
      http://www.adobe.com/accessibility/products/acrobat/training.html
212
      http://www.hhs.gov/web/policies/pdfaccessibility/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              130
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Creating accessible forms
Increasingly, the web is becoming more interactive. People can buy things online, from movie
tickets to clothes and even fridges. As the web takes over from traditional services such as retail
it is important that this new web functionality is accessible. Increasingly, forms are the method
through which many of these services are being provided to the general public. Accessibility of
these services becomes essential in the provision of Government services.

        Relationship to checkpoints:
        Checkpoint 1.1 requires that you provide text alternatives for all submit and other form
        buttons.
        Checkpoint 2.1 requires that you do not indicate mandatory fields via colour alone.
        Checkpoint 5.3 requires that if you use a table to lay out the form, that the form makes
        sense when the table is linearised.
        Checkpoint 6.3 requires that JavaScript is not used for form validation or submission
        without a server-side fallback.
        Checkpoint 9.4 requires that you create a logical tab order through form controls
        Checkpoint 10.2 requires that you position field labels immediately prior to the field.
        Checkpoint 12.4 requires that you use the LABEL FOR and ID attributes between fields
        and field labels.
        Checkpoint 13.8 requires that you place distinguishing information at the beginning of
        forms.

        Labeling fields
        All fields need to have an appropriate label. This label needs to explain what information
        is required by the associated field. The most common violation of this requirement is the
        Search field without a label, for example:



        The only way to determine the action of the field is based on the submit button called
        “Search”. However screen reader and magnifier users won’t be able to access that
        information until after they have passed the field. Therefore the field needs a preceding
        label.

        Often several fields are given only one label, and the user is meant to determine the
        required value for each field dependent on the positioning of the fields. For instance, in
        the following example, three fields have been given only one label, “Fax number”. A
        screen reader user or a magnifier user will not know that the first field is for the area code
        only, and that the second and third fields are for the respective three digits of the phone
        number.


        Breaking up the fax number into three fields was probably intended to ensure that users
        included their area code and included the right number of digits. A preferable, accessible
        solution would be to create two fields, both labeled. The first field would be labeled with
        “Fax number area code” and the second field would be labeled with “Fax number”.
        Alternatively, this could be replaced with one field with the label “Fax number (please
        include area code)”.

        This particular problem is also common when developing date fields. Often developers
        create three fields with one field label such as “Date of birth”, “Departing date” or “Date of
        arrival”. For instance, in the following example the three date fields have only one label
        “Date of arrival”. This example was taken from an international hotel site, and from this
        one label a screen reader user, a magnifier user or even a person with cognitive disability

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            131
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        would not be able to determine whether the first field is supposed to be the day date (as
        would be expected in Australia) or the month date (as would be expected in America):




        A preferable, accessible solution would be to allow the user to enter the date themselves
        in a free text input. Alternatively the three fields could remain with the respective labels
        “Date of arrival – day”, “Date of arrival – month” and “Date of arrival – year”.

        Positioning fields and field labels
        It is important not only to label every single field but to appropriately position that field
        label close to the particular field. This is required so that magnifier users – who only see a
        small portion of the screen at any one time – can determine what the required value of a
        field is. It is also important for people with cognitive disabilities to reinforce the intended
        use of a field and is a known usability requirement.

        Field labels should always be positioned immediately to the left or immediately above the
        associated field. The only exception to this rule is for radio buttons and checkboxes,
        where the field label should always be positioned immediately to the right or immediately
        below the associated field. The following is a correct example, where the field labels are
        immediately above the free text input field, and the checkbox field label is immediately to
        the right of the associated field:




        Coding fields
        Not only is it important that all fields have suitable field labels and that they are
        appropriately positioned, it is also important that the field label is explicitly associated with
        the respective field. Explicit association means coding a field and field label together.
        Screen readers can access this information and therefore ensure that the correct field
        label is read aloud when a user lands on a particular field.

        In the above example, the field label “Username” is coded with the LABEL FOR element:
                <label for="login_user">Username</label>

        The free text input field is coded with the ID attribute, which links the field label and the
        field:
                <INPUT type="text" class="input" style="width:80%;" id="login_user"
                 name="login_user" VALUE="" />

        Grouping fields
        In long or complex forms it is important to group fields. There are two methods to
        grouping fields; the FIELDSET LEGEND element and adding headings. Often these two
        methods can be used interchangeably; however FIELDSET LEGEND is the more


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               132
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        appropriate method. It is only in very complex forms that both headings and FIELDSET
        LEGEND will need to be used. With CSS, the FIELDSET LEGEND element can be
        formatted to even look like a heading. In the following example, the FIELDSET LEGEND
        “Job Contact Details” and “Job Opportunities Details” look like headings:




        The code for the text “Job Contact Details” is:
               <fieldset><legend>Job Contact Details</legend>
                 …Company Name fields etc…
                 </fieldset>

        Indicating mandatory fields
        Often forms will have some mandatory fields and some optional fields. It is useful to
        indicate which fields are mandatory; however colour cannot be used as the sole indicator
        of this, for example:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                       133
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        Users who are colour blind will not be able to identify red text as different to black text. To
        address this problem, many people started to use asterisks to indicate mandatory fields.
        However some screen readers (for example, Window Eyes) do not read out asterisks
        under their default settings. Therefore asterisks are not the preferred solution to indicate
        mandatory fields. Due to some screen readers not reading the TITLE element, adding a
        TITLE element to the asterisk will not address this problem. One solution is to indicate
        mandatory fields with the word “required” or “mandatory”, for example:




        The word (and the field) can be coloured red or a different colour to the main body text to
        enhance the visual hierarchy of that particular field, however this must always be in
        addition to some other way of indicating a mandatory field such as including the word
        “required”.

        Where there are specific constraints on space, the word required could be replaced with
        an image of an asterisk or some other marker that indicates a mandatory field. The ALT
        attribute of this image should be “Mandatory field”. Although both these solutions are
        workarounds until a more conventional resolution is found, they do adequately indicate
        mandatory fields to all users.

        Image buttons
        Often a form button is actually presented as an image to match the existing look and feel
        of the site. In this instance the image button must include an ALT attribute, for example:
                 <input type="image"
                 src="/wps/wcm/connect/DOJ+Internet/resources/file/eb5d7f01fe6f6d9/searchbutt
                 on_DOJ.gif" alt="Search" class="search-button">

        Consider carefully the actual ALT attribute and the visual label of the button. It is common
        to use “Go” as a label for the submit button in a Search field however screen reader user
        testing has found that some users do not understand this terminology as relating to a
        Search function. A better label is “Find” or “Search”, such as in the example above.

        It is not sufficient to use a TITLE attribute instead of an ALT attribute as some screen
        readers don’t read TITLE when it is associated with INPUT type=”image”.

        Layout of buttons
        Sometimes it is necessary to provide several buttons for a form, such as a reset button as
        well as a submit button. Only provide the reset feature if it is absolutely necessary. Users
        sometimes mistake the reset button for the submit button and when they activate this



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             134
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        button lose all their inputs. This is especially the case for people with cognitive
        disabilities.

        The following is an example where a reset button (labeled ‘cancel’) and submit button
        (labeled ‘continue’) are placed incorrectly on the page. Because the cancel button is
        closer to the fields themselves, this button has a higher visual hierarchy and therefore is
        more likely to be activated than the continue button.




        A preferable, accessible alternative is to provide cancel or reset options as links instead
        of buttons, which will reduce the likelihood of users activating them by mistake, such as in
        the following example:




        Form submission and validation
        The form must be able to be submitted with JavaScript disabled or not supported. There
        will be people who won’t be able to use a JavaScript form because:
         They are using a screen-reader which does not interact with JavaScript
         They are browsing without JavaScript
         They are using a text-only browser

        In many cases JavaScript submission can easily be replaced with a standard HTML
        submission, for instance the following code:
               <a href="javascript:void(open('lookup.php?find,'lookup',toolbar=no'))">
                 <img src=" http://support.microsoft.com/library/images/support/goright_hot.gif"
                 alt="search button" border="0" align="middle" width="24" height="24" /></a>

        can easily be replaced with:
               <input type="image"
                 src="http://support.microsoft.com/library/images/support/goright_hot.gif"
                 alt="Submit" />

        In some cases forms require validation and this is often best achieved with JavaScript.
        JavaScript form validation provides an almost immediate response and can be used to
        provide additional information easily and quickly to users. However there must always be
        a server-side fallback to JavaScript validation, in the instance where a user does not
        JavaScript installed.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           135
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Forms and tables
        Where possible the layout of fields within a form should be manipulated via style sheets,
        however sometimes this is not always feasible. When laying out fields using tables it is
        important to remember some important techniques.

        Firstly, if a table is used to lay out a form then it is defined as a layout table. Layout tables
        should not use TH ID and TD HEADERS markup and should not include SUMMARY or
        CAPTION attributes.

        Secondly the form must make sense if it is read from left to right, cell to cell. For instance,
        in the following form table cells are indicated using a fluorescent green, and the cells
        would be read in the following order:




        Introductory information
        Providing information at the beginning of a form can greatly assist users with disabilities
        when filling out an online form. This is especially important for people with cognitive
        disabilities who may need guidance through the form.

        Every form should have at least a sentence at the beginning which explains the form
        itself and the outcomes from submitting the form. This is also where an explanation of
        mandatory fields should be included. The ‘Advertise a Job’ form in the Live in Victoria site
        is complex and requires several paragraphs of introductory information:




        In the above example the first paragraph explains the purpose of the form. The second
        paragraph explains what users should do if this particular form is not relevant to them.
        The third paragraph explains how to use and fill out the form, including an explanation of
        mandatory fields. The fourth paragraph clarifies exactly what will and will not submit the
        form.

        Providing this kind of detail will decrease errors in using the form. For instance without
        this information, people may fill out this form even though there is another form more


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               136
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        suitable. Without clarification that the process is free, some users may not complete the
        form, assuming that there is a cost involved.

        At the end of the page there is contact information for users having difficulty with the
        form. It is preferable that this information is included in the introductory information prior
        to the beginning of the form.

        Providing contextual help
        When forms are complicated, contextual help can assist all users, but especially users
        with disabilities. Magnifier users can access extra information through contextual help,
        which they may not be able to access because they cannot determine the position of the
        field on the page. For instance, in the following example the field is separated from the
        field label, but the contextual help above the field provides as much information as the
        field label and even includes information on how to use the field:




        When providing contextual help it is important to remember some important techniques.

        Firstly the contextual help should appear before or above the respective field. Contextual
        help that occurs after the field or elsewhere on the page can be overlooked by the
        general public and often cannot be accessed by people with disabilities.

        Secondly the contextual help should be included in the LABEL element of the field. For
        information on the LABEL element see the section on Coding Labels.

        Complicated form techniques
        Recently there has been much publicity surrounding AJAX (Asynchronous JavaScript
        and XML). AJAX allows users to interact with a site without serving new pages and can
        significantly reduce the amount of time it takes to complete some actions. One web site
        that relies heavily on AJAX is the online photo album and sharing site, Flickr. A common
        example of AJAX within Flickr is the ability to scroll between thumbnail images without re-
        serving the page. Users select the “more” button and a new image is displayed:




        When JavaScript is turned off the ‘more’ functionality is no longer available. However the
        ‘browse’ option is still available which takes users to a page containing all their photos
        and this provides a suitable alternative to the ‘more’ options:




        Another aspect of AJAX functionality within Flickr is the ability to change the title of an
        image just by clicking on the title and typing a new name:

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                137
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        However there is an alternative to this AJAX functionality, through edit functionality
        elsewhere in the page:




        Flickr also has the functionality to add notes to photos. Notes can be added to the page
        without any server interaction:




        Unfortunately this functionality is not replicated when JavaScript is disabled.

        When developing accessible alternatives to AJAX, the alternative does not need to
        provide the same information and functionality in exactly the same way as the AJAX
        functionality. For instance, the ‘more’ functionality above allows users to browse through
        their images easily and quickly. The ‘browse’ functionality allows them to do the same,
        however it takes longer and they have to navigate away from the current page. Once
        again, with the ‘edit’ functionality, it is easier and quicker to change the title through the
        AJAX functionality, however an alternative is provided.

        The notes functionality does not have an accessible alternative. One such alternative
        would be to break the image into a client-side image map with pre-defined image map
        hotspots. A user could select a pre-defined hotspot and be taken to an online form where
        they could add the relevant text. Although these actions would require much more effort,
        they do adequately mimic the notes functionality.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             138
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             What about TABINDEX, place-holding characters and ACCESSKEYS?
             There are some W3C Web Content Accessibility Guidelines AAA checkpoints specific to
             forms that should no longer be attempted. These checkpoints are:
                  Checkpoint 9.4: Create a logical tab order through links, form controls, and
                     objects.
                  Checkpoint 9.5: Provide keyboard shortcuts to important links (including those in
                     client-side image maps), form controls, and groups of form controls.
                  Checkpoint 10.4: Until user agents handle empty controls correctly, include
                     default, place-holding characters in edit boxes and text areas.

             Checkpoint 9.4: Create a logical tab order through links, form controls, and objects.
             The W3C HTML Techniques document recommends using the element TABINDEX to
             define a tab order through a page or form. If pages and forms are laid out properly there
             is no need to define tab order through TABINDEX and using this element can be
             detrimental as it destroys the natural tab order of the page.

             However it is important that the page does contain a natural tab order and this can be
             achieved by structuring the page properly. For more information see the Page Structure
             section or page source order.

             Checkpoint 9.5: Provide keyboard shortcuts to important, form controls, and groups of form
             controls.
             Recent research indicates that keyboard shortcuts (using the ACCESSKEY attribute)
             often over-ride keyboard shortcuts inbuilt in certain screen readers. Previous research
             indicated that only numerals could be used as keyboard shortcuts as most other ASCII
             keys are used in program shortcuts (eg. ALT+F often opens the File menu). However this
             recent research indicates that some screen readers use numeral keyboard shortcuts for
             common functionality, such as displaying all headings in a page.

             Checkpoint 10.4: Until user agents handle empty controls correctly, include default, place-
             holding characters in edit boxes and text areas.
             This checkpoint was intended to provide information to screen reader users in cases
             where screen readers could not interpret the LABEL FOR element. Now that screen
             readers and other assistive technologies consistently interpret this element the
             requirement to include place-holding characters is no longer necessary. Place-holding
             characters can even reduce accessibility when users tab to a field and enter information
             without being aware that they need to delete the place-holding characters first.

             Further Information

             Accessibility of particular form elements
                 Shortened forms on the web 213
                 Screen reader software support for the TITLE attribute 214
                 ALT vs. TITLE 215
                 Graphical submit buttons 216

             Creating accessible forms
                 WebAIM: Creating accessible forms 217


213
      http://www.visionaustralia.org.au/info.aspx?page=766
214
      http://www.paciellogroup.com/resources/articles/WE05/forms.html
215
      http://www.456bereastreet.com/archive/200412/the_alt_and_title_attributes/
216
      http://www.w3.org/TR/html4/interact/forms.html#h-17.4.1
217
      http://www.webaim.org/techniques/forms/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                139
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Usability of forms (PDF) 218
                 Accessible HTML/XHTML Forms 219
                 Making accessible forms, part one 220
                 Making accessible forms, part two 221




218
      http://www.lukew.com/resources/articles/WebForms_LukeW.pdf
219
      http://www.webstandards.org/learn/tutorials/accessible-forms/beginner/
220
      http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/accessible-forms-1.shtml
221
      http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/accessible-forms-2.shtml


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  140
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

JavaScript
JavaScript is a client-side scripting language used by many different web sites. JavaScript can be
used to create fly-out menus, mouseovers and form validation. However JavaScript has many
accessibility problems; and a text equivalent is always required.


        Relationship to checkpoints:
        Checkpoint 1.1 requires that you provide text alternatives for all JavaScript.
        Checkpoint 6.2 requires that equivalents to JavaScript are updated when the JavaScript
        changes.
        Checkpoint 6.3 requires that if JavaScript is disabled, that the page is usable, or,
        alternatively, an equivalent is provided.
        Checkpoint 6.4 and 9.3 require that you use device-independent and logical event
        handlers, such as ONFOCUS instead of device-dependent event handlers, such as
        ONCLICK or ONMOUSEOVER.
        Checkpoint 6.5 and 8.1 requires that JavaScript is created in an accessible manner.
        Checkpoint 10.1 requires that JavaScript not be used to create popup windows unless
        after informing the user.

        Alternatives to JavaScript are used wherever possible
        When first developing a site, consider whether JavaScript need be used in the site at all.
        Many common JavaScript functions are adequately replicated in HTML and provide an
        enhanced level of accessibility. Some of the things that should be replaced with HTML
        functionality are detailed in the following table.

 Functionality               JavaScript                                Equivalent HTML

 Text link                   <a href=“javascript:                      <a href=“page.html”>
                             location.href ='page.html'”>              Page</a>
                             Page</a>
 Opening a new window        <a                                        <a href=“page.html”
                             href=“javascript:window.open              target=“_blank”>
                             ('page.html',
                             '_blank')”>Page</a>
 Form submission             <a href=“javascript:                      <input name=“submit”
                             this.form.submit();”>                     type=“submit”
                             Submit</a>                                value=“Submit”>


        Provide a NOSCRIPT alternative for all Javascript
        When it is necessary to include JavaScript functionality within a site, it is mandatory to
        require a text alternative. This can be done through the NOSCRIPT element. Content
        within the NOSCRIPT element must be the equivalent of the content or functionality
        provided by the JavaScript. The site must be functional and all content available when
        JavaScript is disabled.

        Example – JavaScript form validation with a server-side fallback
        When signing up for Gmail (with JavaScript enabled) there is a handy button to check the
        availability of your chosen login name:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           141
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        If you type in a login name that is already taken or does not comply with requirements
        then a message appears once you have clicked the button:




        This functionality is replicated when JavaScript is disabled. The login name availability is
        validated with the rest of the fields when the form is submitted:




        JavaScript is developed in an accessible manner
        It is important that JavaScript is developed in an accessible manner. Unfortunately, many
        known HTML accessibility problems can also result from the inaccessible use of
        JavaScript. For instance, the following is a list of accessibility issues applicable to both
        HTML and JavaScript.
               Content flickers
               Movement cannot be stopped


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           142
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit
                Timeouts occur without informing the user
                A new window opens without informing the user
                The page refreshes without informing the user
                The current focus is changed without informing the user.
                The browser is redirected to another location without informing the user
                The user requires a mouse to access content or functionality

        Event handlers
        Specifically, there are a number of common JavaScript accessibility errors.
            When JavaScript has been used to update information in a page, the updated
                information appears before the current focus.
            The event handler ONDBLCLICK is used
            The event handler ONCLICK has been used instead of the generic ONSELECT
            The event handler ONMOUSEOVER has been used instead of using both
                ONMOUSEOVER and ONFOCUS
            The event handler ONMOUSEDOWN has been used without also using the
                keyboard event handler ONKEYDOWN
            The event handler ONMOUSEUP has been used without also using the keyboard
                event handler ONKEYUP

        Flyout menus
        One of the most common misuses of JavaScript is to create inaccessible flyout menus.
        When JavaScript is used to create flyout menus, the relevant head navigation item must
        be a link which should link to a page that contains the links to the sub-navigation present
        in the initial flyout menu.

        In the following example a flyout menu appears when a user hovers their mouse over a
        particular menu. With JavaScript disabled the flyout menu does not appear, however the
        initial navigation item (eg. “Business”) does not operate as a link and is therefore
        inaccessible.

        Site with JavaScript enabled (mouse hovering over ‘Business’ navigation item)




        Site with JavaScript disabled (mouse hovering over ‘Business’ navigation item)




        In the following example a flyout menu appears when a user hovers their mouse over a
        particular menu.

        Flyout menu




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          143
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        With JavaScript disabled the flyout menu does not appear, however the initial navigation
        item (eg. “About us”) operates as a link. This link goes to a page which includes a list of
        the links that were available via the flyout menu.

        “About us” page that contains flyout menu items as text links




        JavaScript can also be used to create expandable and collapsible menus, such as in the
        following example:

         Unexpanded menu                           Expanded menu




        With JavaScript disabled the default presentation for expandable/collapsible menus
        should be to display all menu items and sub-items such as in the following example:

         JavaScript enabled – menu default         JavaScript disabled – menu default




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          144
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             Further Information

             Creating accessible JavaScript
                WebAIM – Creating Accessible JavaScript 222
                Jim Thatcher – Scripts and Applets 223
                IBM JavaScript Accessibility 224
                IBM - Scripts used for background processing and pop-ups 225


222
      http://www.webaim.org/techniques/javascript/
223
      http://www.jimthatcher.com/webcoursea.htm
224
      http://www-306.ibm.com/able/guidelines/web/webscripts.html
225
      http://www-306.ibm.com/able/guidelines/web/webscripts_background.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011          145
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 IBM - Hidden content, document.write, and scripts that modify content 226
                 IBM - DHTML 227
                 IBM – Scripts using event handlers 228
                 IBM – Non-essential scripts 229
                 IBM - Additional techniques to enhance accessibility of essential scripts 230
                 Accessible JavaScripting from the ground up 231

             JavaScript and screen readers
                 JavaScript and accessibility 232




226
      http://www-306.ibm.com/able/guidelines/web/webscripts_content.html
227
      http://www-306.ibm.com/able/guidelines/web/webscripts_dhtml.html
228
      http://www-306.ibm.com/able/guidelines/web/webscripts_eventhandlers.html
229
      http://www-306.ibm.com/able/guidelines/web/webscripts_nonessential.html
230
      http://www-306.ibm.com/able/guidelines/web/webscripts_noscript.html
231
      http://www.htmlgoodies.com/beyond/javascript/article.php/3673826
232
      http://v1.boxofchocolates.ca/archives/2005/06/12/javascript-and-accessibility


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            146
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Making splash pages accessible

If you use plug-ins (such as Flash) or scripts (such as JavaScript) on your pages you could be
preventing users from entering or using your site properly. There will be people who will have
difficulty accessing the navigation or progressing past a Flash front page (splash page) for any of
the following reasons:
           They are browsing without JavaScript and / or Flash
           They are using a text-only browser
           They are using a screen-reader which does not interact with JavaScript and / or
              Flash
           They are using a keyboard instead of a mouse
           They are using a slow modem

        Relationship to checkpoints
        Checkpoint 6.3 requires that pages remain usable when scripts, applets or other
        programmatic objects are turned off or not supported. This means that if a computer does
        not have Flash installed or does not support JavaScript, that the site still functions.

        Example Solution – Splash page

        Background
        Australian Centre for the Moving Image (ACMI) is a web site designed to promote ACMI
        at Federation Square. The site was built to Level A accessibility standards while still
        providing a modern look and feel. One thing ACMI requested was a Splash page:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          147
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Solution
             ACMI needed to design a solution that catered to the needs of people that did not have
             either the software or physical ability to interact with a Flash presentation. Their solution
             included:
              Flash detection script
              HTML link

                       Flash detection script
                       A flash detection script was used so that people without Flash installed were
                       taken straight to the home page of the site:




                       HTML link
                       For those people who preferred the HTML version, even if they had Flash, an
                       HTML link was provided at the bottom of the page. This would take users straight
                       to a non-Flash version of the site.

             Further information

             General
                 W3C Checkpoint 6.3: Ensure that pages are usable when scripts, applets or other
                  programmatic objects are turned off or not supported

             Use of Flash
                 Adobe Flash accessibility design guidelines 233
                 WebAIM – Creating Accessible Macromedia Flash content 234
                 Adobe Flash CS4 Professional accessibility FAQ 235
                 Best Practices for Accessible Flash Design 236 (Adobe Reader required)




233
      http://www.adobe.com/accessibility/products/flash/best_practices.html
234
      http://www.webaim.org/techniques/flash/
235
      http://www.adobe.com/accessibility/products/flash/faq.html
236
      http://www.adobe.com/resources/accessibility/best_practices/best_practices_acc_flash.pdf


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  148
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Creating valid HTML pages

Web sites are written in specific languages, and just like human languages, they have their own
grammar, vocabulary and syntax. Every web page written in these computer languages are
supposed to follow these rules. However just like texts in a human language can include spelling
or grammatical errors, web pages using computer languages can also include these types of
mistakes. The process of verifying whether a web page actually follows the rules for the
language(s) it uses is called validation, and the tool used for that is a validator. A web page that
passes this process with success is called valid or that it complies with its DOCTYPE definition.

With these concepts in mind, we can define "markup validation" as the process of checking a web
page against the grammar it claims to be using.

                                                          Adapted from the W3C Validation service 237

             Relationship to checkpoints:
             Checkpoint 3.2 requires that documents validate to published formal grammars. The
             most common DOCTYPE definitions are:
              HTML 4.01 Transitional:
                <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                    "http://www.w3.org/TR/html4/loose.dtd">
              HTML 4.01 Strict
                <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
                    "http://www.w3.org/TR/html4/strict.dtd">
              XHTML 1.0 Transitional
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
              XHTML 1.0 Strict
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

             DOCTYPE definitions must be the first line of code in a web page.

             Ensuring a page is valid
             There are some simple things you can do to ensure that your documents validate.

             A. DOCTYPE definition
             Ensure that all pages include a DOCTYPE definition in the first line of code
                Correct
                <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                "http://www.w3.org/TR/html4/loose.dtd">
                <html>
                <head>
                <meta http-equiv="Content-Type" content="text/html;
                charset=utf-8">

                  Incorrect:
                  <html>
                  <head>
                  <meta http-equiv="Content-Type" content="text/html;
                  charset=utf-8">


237
      http://validator.w3.org/docs/help.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           149
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

        B. Close relevant tags
        Ensure that all relevant tags are closed properly.
           Correct:
           <p>Join the thousands of people who have immigrated to
           Victoria.</p>
           <p>So why not see if you can immigrate and live in
           Victoria?</p>

            Incorrect:
            <p> Join the thousands of people who have immigrated to
            Victoria.
            <p> So why not see if you can immigrate and live in Victoria?

        C. Self-close tags
        In XHTML, make sure you self-close tags when they don’t have end tags.
            Correct:
            <img src=”test.jpg” height=”32” width=”32” alt=“” />

            Incorrect:
            <img src=”test.jpg” height=”32” width=”32” alt=“”>

        D. Don’t transpose tags
        Don’t transpose tags. Make sure you close tags in the order they are opened.
           Correct:
           <strong><a href=”www.vic.gov.au”>Victoria Online</a></strong>

            Incorrect:
            <strong><a href=”www.vic.gov.au”>Victoria Online</strong></a>

        E. Nest block level and inline elements properly
        Don’t nest block level elements inside inline elements.
           Correct:
           <p><strong>Drink drivers are warned that the chances of getting
           caught are now higher than ever.</strong></p>

            Incorrect:
            <strong><p>Drink drivers are warned that the chances of getting
            caught are now higher than ever.</p></strong>

        F. Don’t omit tags
        Don’t omit compulsory tags, even if the web page displays properly without them.
           Correct:
           <table><tr><td> My eGov allows you to rate content and bookmark
           your favourite resources.</td></tr></table>

            Incorrect:
            <table><td> My eGov allows you to rate content and bookmark
            your favourite resources.</td></table>

        G. Escape relevant entities
        Escape relevant entities.
           Correct:
           Then we went to the Elephant &amp; Wheelbarrow

            Incorrect:

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011              150
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                   Then we went to the Elephant & Wheelbarrow

             Testing a site for HTML validity
             The W3C maintains a validation service 238 that can test a site one page at a time via URL
             or page upload. Alternatively, you can use the WDG HTML Validator 239 to validate your
             entire site.

             Common errors
             There are many common errors of invalid sites. The W3C Validation service maintains a
             list of errors and their meanings 240 . This document can assist in determining errors if they
             occur.

             A.    Missing DOCTYPE

                   No DOCTYPE found! Attempting validation with XHTML 1.0 Transitional.

                   The DOCTYPE Declaration was not recognized or is missing. This probably means
                   that the Formal Public Identifier contains a spelling error, or that the Declaration is not
                   using correct syntax. Validation has been performed using a default “fallback”
                   Document Type Definition that closely resembles “XHTML 1.0 Transitional”, but the
                   document will not be valid until you have corrected this problem with the DOCTYPE
                   Declaration.

                   Learn how to add a doctype to your document from our FAQ.

             This error is caused when the page hasn’t specified a DOCTYPE definition, or if this
             definition is in the wrong place in the document. The DOCTYPE definition always has to
             be the first line of code.

             B. Missing attribute

                   Error Line 190 column 79: required attribute “alt” not specified.
                   …._images/home/sale/sale-static2.gif” / > </a><div style=”width: 271px; height: 6

                   The attribute given above is required for an element that you’ve used, but you have
                   omitted it. For instance, in most HTML and XHTML document types the “type”
                   attribute is required on the “script” element and the “alt” attribute is required for the
                   “img” element.
                   Typical values for type are type=”text/css” for <style> and type=”text/javascript” for
                   <script>.

             This error is caused by a missing ALT attribute in an IMG tag.

             C.    Tag is not self-closing

                   Error Line Line 332 column 131: end tag for “img” omitted, but OMITTAG NO was
                   specified.
                   ….e/products/get_into_business.gif”></a > </td></tr>
                   You may have neglected to close an element, or perhaps you mean to “self-close” an
                   element, that is, ending it with “/>” instead of “.”.


238
      http://validator.w3.org/
239
      http://www.htmlhelp.com/tools/validator/
240
      http://validator.w3.org/docs/errors.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    151
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Although the error highlights the </a> tag, this error occurred because the web page had
        a DOCTYPE definition of XHTML Transitional. This DOCTYPE definition requires, in this
        instance that the IMG tag ends with a self-closing tag, ie: />

        D. Forbidden elements are used

             Error Line 719 column 118: there is no attribute “onMouseOver”.
             …ormation’ target=”_self’ onMouseOver= ’ self.status=’Carry-on Baggage’; return

             You have used the attribute named above in your document, but the document type
             you are using does not support that attribute for this element. This error is often
             caused by incorrect use of the “Strict” document type with a document that uses
             frames (eg., you must use the “Transitional” document type to get the “target”
             attribute), or by using vendor proprietary extensions such as “marginheight” (this is
             usually fixed by using CSS to achieve the desired effect instead).

             This error may also result if the element itself is not supported in the document type
             you are using, as an undefined element will have no supported attributes; in this
             case, see the element-undefined error message for further information.

             How to fix: check the spelling and case of the element and attribute, (Remember
             XHTML is all lower-case) and/or check that they are both allowed in the chosen
             document type, and/or use CSS instead of this attribute.

        Some DOCTYPE definitions forbid certain elements, for example, this web page has a
        DOCTYPE definition of XHTML Transitional. The attribute ONMOUSEOVER is forbidden
        in this DOCTYPE.

        E.   Invalid attribute

             Error Line 48 column 59: value of attribute “ID” invalid: “_” cannot start a name.
             <form name=”_ct10” method=”post” action=”default.aspx” id=” _ ct10”>

             It is possible that you violated the naming convention for this attribute. For example,
             id and name attributes must begin with a letter, not a digit.

        Certain attributes must follow certain rules. In this example, the attribute ID begins with
        an underscore. The attribute ID must only begin with a letter.

        F.   Start tag missing

             Error Line 103 column 381: end tag for element “TD” which is not open.
             …/” target=” ”>Who\ ’s who</a></div></td> </tr></table></div><div class=”herotime

        This error occurs when a start tag is missing, or an extra end tag has been included.

        G. Non-unique ID

             Error Line 17 column 48: ID “LOGIN_USER” already defined.
             …UT type=”password” class=”input” id=”login_user” style=”width:80±;” name=”lo

             An “id” is a unique identifier. Each time this attribute is used in a document it must
             have a different value. If you are using this attribute as a hook for style sheets it may
             be more appropriate to use classes (which group elements) than id (which are used
             to identify exactly one element).


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             152
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
             This error occurs when an ID has already been defined earlier in the document. This is
             often the case when a field ID is not unique.

             Further Information

             DOCTYPE definitions
                  W3C Checkpoint 3.2: The DOCTYPE statement 241
                  W3C recommended DOCTYPE definitions 242

             Code specifications
                  HTML 4.01 specification 243
                  XHTML 1.0 specification 244

             HTML Validators
                  W3C HTML Validator 245
                  WDG HTML Validator 246

             Why validation is important
                  Why validate? 247
                  Validity and accessibility 248

             Information on validation
                  37 steps to perfect markup 249
                  Error explanations for the W3C Validation service 250
                  Help and FAQs for the W3C Validation service 251
                  Index dot HTML: information on HTML tags and attributes 252




241
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#doctype
242
      http://www.w3.org/QA/2002/04/valid-dtd-list.html
243
      http://www.w3.org/TR/html4/
244
      http://www.w3.org/TR/xhtml1/
245
      http://validator.w3.org/
246
      http://www.htmlhelp.com/tools/validator/
247
      http://validator.w3.org/docs/why.html
248
      http://juicystudio.com/article/validity-accessibility.php
249
      http://www.sitepoint.com/article/html-37-steps-perfect-markup
250
      http://validator.w3.org/docs/errors.html
251
      http://validator.w3.org/docs/help.html
252
      http://www.blooberry.com/indexdot/html/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            153
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Creating valid CSS

When designing a web site it is important to identify presentation as separate to content and
structure. Separating content from presentation and structure offers a number of advantages,
including improved accessibility and manageability.

        Relationship to checkpoints:
        Checkpoint 3.2 requires that documents validate to published formal grammars.
        Checkpoint 3.3 requires that style sheets are used to control layout and presentation.

        Using CSS
        There are three ways to use CSS. CSS can be inserted as inline styles: as attributes of
        any HTML element, changing the style of that element (and its descendants where
        appropriate). CSS can also be inserted into the HTML or XHTML within the HEAD tag of
        each page. This method is called an internal style sheet. Alternatively it can be inserted
        into an external style sheet and referenced in the HTML or XHTML of the web page. This
        is often the preferred method as the style sheet needs to be changed only once for the
        changes to deploy across the entire site. This option also means that the external style
        sheet only needs to be downloaded once by the user; not with every new page the user
        loads.

        Ensuring CSS is valid
        There are some simple things you can do to ensure that your CSS validates.

        A. Properly reference the CSS file
        Make sure the styles and/or the reference to the external style sheet are contained in the
        <head> element, not the <body> element. While browsers will often accept styles defined
        anywhere in the document, it's only valid it in the <head> element (inline styles excepted)
        or referenced from other style sheets.
             Correct
             <head>
            <style type="text/css"> @import url(style.css) </style>
            </head>

            Incorrect:
            <head>
            </head>
            <style type="text/css"> @import url(style.css) </style>

        B. Specify background colour when text colour is defined
        Whenever a text-colour is specified also specify a background-colour.
           Correct
           /* -- Generic Text -- */
            body {
            background: #FFF;
            color: #000;
            /*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
            font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           154
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                  }

                  Incorrect:
                  /* -- Generic Text -- */
                  body {
                  color: #000;
                  /*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
                  font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
                  }

             C. Specify text colour when background colour is defined
             Whenever a background-colour is specified also specify a text-colour.
                Correct
                /* -- Generic Text -- */
                  body {
                  background: #FFF;
                  color: #000;
                  /*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
                  font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
                  }

                  Incorrect:
                  /* -- Generic Text -- */
                  body {
                  background: #000;
                  /*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
                  font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
                  }

             D. Do not use “display: none”
             Commonly information that was to be hidden from visual users but presented to screen
             reader users would be hidden using the CSS property “display: none.” However research
             has indicated that screen readers do not read this information out either. It is preferable
             to use the “off-left technique” 253 when attempting to hide text or audio content.
                 Correct
                 .hidden {
                  position: absolute;
                  left: -1000px;
                  width: 100px;
                  }



253
      http://css-discuss.incutio.com/?page=OffLeft


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              155
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit
            Incorrect:
            .hidden {
            display: none;
            }


        Common errors
        There are many common errors of invalid CSS files.

        A. Typographical errors

           Line: 444
            Invalid number : background-color Unknown dimension : 99ccff

        This error is caused when the there is a typo somewhere in the CSS file. For example, in
        this instance, the number is missing the hash (#).

        B. Invalid keywords

           Line: 108
            Invalid number : color OrangeRed is not a color value : OrangeRed

        This error is caused when an invalid keyword has been used. In this instance the defined
        colour is “OrangeRed”, but that is not an accepted colour. Accepted colour names are:
        aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal,
        white, and yellow.

        C. Using words instead of numbers

           Line: 2436 Context : a.small
            Invalid number : font-weight none is not a font-weight value : none

        Some values require the use of a number instead of the word “none”. In this instance the
        number “0” should be used. When defining a background-color as zero or none, use
        “transparent”.

        D. Whitespace

           Line: 9 Context : .text1
            Too many values or values are not recognized : 13 px

        This error is caused because there is whitespace between “13” and “px”. The correct
        syntax is “13px”.

        E. Use of “auto”

           Line: 67 Context : .header4
            auto is not a padding-right value : 0 auto

        “Auto” can only be used in specific instances; such as with the “margin” attribute. “Auto”
        cannot be used in this example as a value for “padding-right”.

        F. Missing semi-colons

           Line: 205 Context : #bhVF


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            156
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                  Invalid number : background attempt to find a semi-colon before the property name.
                  add it

             This error is caused because there is a missing semi-colon.

             G. Missing dimensions

                 Line: 51 Context : .heroSR img
                  Invalid number : padding-bottom only 0 can be a length. You must put an unit after
                  your number : 4

             This error is caused because there is no dimension to the value “4”. In this instance the
             correct value would be “4px”.

             Further Information
             CSS
                 W3C Structure vs. presentation 254
                 W3C Emphasis 255
                 W3C Text instead of images 256
                 W3C Text formatting and position 257
                 W3C Layout, positioning, layering and alignment 258

             Code specifications
                 CSS 1.0 specification 259
                 CSS 2.0 specification 260
                 CSS 2.1 specification (Working Draft) 261

             CSS Validators
                 W3C CSS Validator 262

             Why using CSS is important
                 Why a CSS layout will make you money 263

             CSS tips and tricks
                 CSS tips and tricks 264
                 CSS Zen Garden 265
                 CSS Basics 266


254
      http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure
255
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-emphasis
256
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#text-not-images
257
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-text-formatting
258
      http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment
259
      http://www.w3.org/TR/REC-CSS1
260
      http://www.w3.org/TR/REC-CSS2/
261
      http://www.w3.org/TR/CSS21/
262
      http://jigsaw.w3.org/css-validator/
263
      http://www.webcredible.co.uk/user-friendly-resources/css/css-website-layout.shtml
264
      http://www.456bereastreet.com/archive/200503/css_tips_and_tricks_part_1/
265
      http://www.csszengarden.com/
266
      http://www.cssbasics.com/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              157
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 CSS and round corners 267
                 Developing CSS navigation 268
                 Ten CSS tricks 269
                 Off-left technique 270

             Information on CSS validation
                 CSS 2.1 properties 271
                 Index dot CSS: information on CSS 272




267
      http://www.webcredible.co.uk/user-friendly-resources/css/css-round-corners-borders.shtml
268
      http://www.webcredible.co.uk/user-friendly-resources/css/css-navigation-menu.shtml
269
      http://www.webcredible.co.uk/user-friendly-resources/css/css-tricks.shtml
270
      http://css-discuss.incutio.com/?page=OffLeft
271
      http://www.webreference.com/authoring/style/sheets/properties/
272
      http://www.blooberry.com/indexdot/css/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           158
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Page source order
Page source order is important to people who have vision impairments and rely on a screen
reader to navigate or interpret the site. It is also important to people with cognitive disabilities who
use a screen reader to assist in reading the information on the site. A document where source
order does not match the order of content with CSS on can be very confusing to these groups of
users. In addition, source order is important to people with physical impairments who rely on a
keyboard to navigate the site. People who rely on keyboards tab through the content and
therefore can find it difficult to navigate the page if the source order does not match the order of
the page with CSS on. Using TABINDEX does not address this problem as unless every single
element is provided with a TABINDEX it can render the page unusable by screen reader users.

        Relationship to checkpoints:
        Checkpoint 6.1 requires that documents can be read without style sheets.
        Checkpoint 13.4 requires that navigation mechanisms are presented in a consistent
        manner
        Checkpoint 9.4 requires that the page presents a logical tab order through links, form
        controls and objects
        Checkpoint 14.3 requires that the style of presentation is consistent across pages

        Ensuring correct page source order when developing a site
        When you have created your wireframes or graphical concepts label each element to
        indicate its source order. Source order should always read from left to right and down the
        page. This information can be provided to the developers to ensure they code elements
        in a particular order.

                 Example: YouthCentral site




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              159
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit


        The source order of this page should be:




        Testing a site for correct page source order
        There are three ways to test a site for correct page source order:
            Tab through the page
            Turn off CSS
            Run a screen reader over the page

            Tab through the page
            Using your preferred browser, select the URL in the address bar and press the TAB
            key. In Firefox the first item highlighted goes to the Google search bar and the
            subsequent item is the relevant FireFox tab, but on the third tab you will reach the
            page. Only links, fields and form controls are items highlighted through tabbing.
            Ensure that the tab order mimics the visual page order onscreen, and is the
            equivalent to the desired tab order decided upon during the development of the
            wireframes or visual concept.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        160
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Turn off CSS
                 Using the FireFox Web Developer toolbar you can easily turn off style sheets. Ensure
                 that with style sheets off, the order of elements mimics the visual page order with
                 style sheets on.

                 Run a screen reader over the page
                 Screen reader testing should only be performed by people with vision impairments or
                 people who use a screen reader to access information. However in this instance it is
                 feasible for a non-vision impaired individual to use a screen reader to determine the
                 order of a page and whether it mimics the visual page order onscreen.

            Further Information

            Information on page source order
                Source order, skip links and structural labels 273

            Tools
                FireFox Web Developer Toolbar 274
                What’s new in JAWS 10 275
                Demonstration version of JAWS screen reader 276 (To try a free demo version of
                 JAWS, select the appropriate FTP or HTTP link from the Download JAWS 10
                 section and run JAWS in 40-minute demo mode.)




273
      http://www.usability.com.au/resources/source-order.cfm
274
      http://chrispederick.com/work/webdeveloper/
275
      http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp#Enhancements
276
      http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp#download


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            161
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Page structure

Page structure is important to people with vision impairments, such as those using a screen
reader or a magnifier. Page structure is also important to people with cognitive disabilities and
can assist those with physical disabilities.

            Relationship to checkpoints:
            Checkpoint 3.3 requires that style sheets are used to control layout and presentation
            Checkpoint 3.5 requires that header elements are used to convey document structure
            Checkpoint 6.1 requires that documents may be read without style sheets.
            Checkpoint 9.4 requires that the page presents a logical tab order through links, form
            controls and objects
            Checkpoint 12.3 requires that large blocks of information are divided into more
            manageable groups where natural and appropriate
            Checkpoint 13.4 requires that navigation mechanisms are used in a consistent manner
            Checkpoint 13.5 requires that navigation bars are used to highlight and give access to
            the navigation mechanism
            Checkpoint 13.6 requires that related links are grouped, identified and can be bypassed
            Checkpoint 13.8 requires that distinguishing information is presented at the beginning of
            headings, paragraphs, lists, etc
            Checkpoint 14.3 requires that the style of presentation is consistent across pages

            Ensuring correct page structure
            There are a number of different elements that are required in order to create a correct
            page structure:
                TITLE element
                Skip links
                Properly marked up headings
                Structural labels
                Breadcrumbs

            It is also very important that your page source order 277 is correct.

                 TITLE element
                 It is very important that every page has its own, unique TITLE element. The TITLE of
                 every page appears in the header of the browser, for example:




277
      Link to “page source order” web page


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                162
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




            It is preferable to include the name of the web site in all TITLEs, as well as the name
            of the individual page: this ensures a user can identify the page as belonging to a
            particular site by the TITLE alone. In the example above, the title of the site: Live in
            Victoria, is included with the title of the page: “Sponsored Skilled Migration Visas”.

            Skip links
            Skip links are very important to both screen reader users and people using
            magnifiers. When moving through a site, people often only initially look at the
            navigation and then only refer to it when required. This is the same for people using
            screen readers and magnifiers: they only need to listen to the navigation once and
            from then on want to move straight to the content on the page. Most sites provide the
            navigation prior to the content, and because it is important to preserve the visual
            page source order and the HTML source order then sites should provide the ability to
            skip over the navigation via the use of skip links.

            There has been some discussion as to whether skip links should be visible or not.
            Most people think skip links are used only by people who use screen readers, but
            people who use magnifiers to view a web site also find skip links useful. Often a
            person using a magnifier will only see a small part of the screen. Often it is not
            obvious where the content is from this small part of the screen; providing a visual skip
            link is an important feature for this group of users.


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           163
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




            In the example above, Film Victoria has provided a visible “Skip to main content” link.
            The term “Skip to content” should be avoided as screen readers read “content” as in
            “contentment”, instead of “text content”. To avoid this issue ensure the link is “Skip to
            the content” or “Skip to main content”. It is also useful if this link is in the top left hand
            corner so it is the first thing the magnifier user will see.

            Sometimes it is also useful to provide a “Skip to navigation” or a “Skip to search” link.

            Properly marked up headings
            Properly marked up headings are important to screen reader users. Screen reader
            users scan a web page using a variety of features, such as links, form controls and
            headings. Most screen readers can pull out the headings, and present them to the
            screen reader user in hierarchical order. This can provide a great amount of
            information to users and help them navigate through the page effectively.

            It is important that headings are nested properly in order to convey the structure and
            hierarchy of the page. It is important not to skip heading levels (eg. a H4 should not
            follow an H2).

                 Example – Department of Innovation, Industry and Regional Development
                 (DIIRD)




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                164
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




            Structural labels
            Recent research has suggested that people who use screen readers sometimes
            cannot identify the navigation of a web site. Without visual context, these users
            sometimes cannot differentiate between sub-navigation and navigation.

            Example – DIIRD
            The DIIRD web site was built prior to research that recommended the use of
            structural labels. The DIIRD site used the popular technique of nesting navigation
            and sub-navigation items. Later research indicated this method did not provide
            enough information to people using screen readers.

              Through visual context it is   Although the same information is presented visually with
              apparent that the current      style sheets disabled, the screen reader cannot easily
              page is “Minister’s            convey this information in audio. Without this
              Foreword” which sits under     information it is difficult to determine the hierarchy of the


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            165
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
              a sub-navigation item of “10    navigation.
              year…” which sits under the
              main navigation item of
              “DIIRD Strategies”




            Providing hidden structural labels assists these users to identify these lists of links
            and access the information provided via the hierarchy.

            Use hidden structural labels such as “Global menu” or “Site navigation”. When
            providing hidden structural labels for sub-navigation you should include as much
            information as possible. For example in a site of exotic birds use: “Navigation for sea-
            side birds”, or “Sea-side birds”.

                 Example – Department of Education




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            166
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




            Include breadcrumbs
            Breadcrumbs are an additional navigation tool that assists both the general public
            and people with disabilities to navigate through a large or complex site. It is
            especially important where other navigation mechanisms, such as the Back button,
            have been broken. It is also important that breadcrumbs also have hidden structural
            labels, however the term “breadcrumbs” is an industry term. A preferable term is “You
            are here:”.

            Breadcrumbs should provide the hierarchical position not the chronological pathway
            in the site. For instance, even if a user came to a particular part of the site through
            inline links, the breadcrumbs should provide the navigational pathway to that page.

                 Example – YouthCentral breadcrumbs




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          167
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit




        Testing a site for correct page structure

            TITLE element
            Make sure that the TITLE element properly represents the page and is consistent
            with other pages in the site.

            Skip links
            Make sure all skip links are consistent.

            Properly marked up headings
            WAVE can be used to indicate which headings have been marked up. WAVE
            indicates each heading with H1, H2 or H3.

            Structural labels
            Using the FireFox Web Developer toolbar you can easily turn off style sheets. Ensure
            that with style sheets off, each navigation set is properly labeled and that sub-
            navigation is easily differentiated from other navigation items.

            Include breadcrumbs
            Make sure all breadcrumbs are consistent and have the relevant hidden structural
            label.

        Further Information

        Tools




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         168
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 FireFox Web Developer Toolbar 278
                 Demonstration version of JAWS screen reader 279 (To try a free demo version of
                  JAWS, select the appropriate FTP or HTTP link from the Download JAWS 10
                  section and run JAWS in 40-minute demo mode.)
                 WAVE 280

             Skip links
                 Skip links: Pros and Cons 281
                 Skip navigation 282

             Headings
                 Headings and accessibility 283
                 Navigation Accessibility 2: Accessing Page Content 284

             Information on structural labels
                 Source order, skip links and structural labels 285




278
      http://chrispederick.com/work/webdeveloper/
279
      http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp#download
280
      http://wave.webaim.org/index.jsp
281
      http://accessites.org/gbcms_xml/news_page.php?id=13
282
      http://www.jimthatcher.com/skipnav.htm
283
      http://www.utexas.edu/research/accessibility/research/summary/swat/swat_headings.html
284
      http://www.usability.com.au/resources/page-content.cfm
285
      http://www.usability.com.au/resources/source-order.cfm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             169
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Ensuring sufficient colour contrast

Colour contrast is important for people who have vision impairments, including people who are
colour blind. One in five men has some form of colour blindness, so this is a common problem.

There are different types of colour blindness caused by defective rods and cones in the eye,
however the three most common types of colour blindness are:
        Deuteranopia: Red / green colour deficit
        Protanopia: Red / green colour deficit
        Tritanopia: Blue / Yellow colour deficit (rare)

People without colour blindness see:




Depending on the type, people with colour blindness see:




            Relationship to checkpoints:
            Checkpoint 2.2: Ensure that foreground and background color combinations provide
            sufficient contrast when viewed by someone having color deficits or when viewed on a
            black and white screen
             This is a Level AA checkpoint for images conveying information.
             This is a Level AAA checkpoint for text.

            Ensuring adequate colour contrast when designing a site
            The W3C developed an algorithm to ensure adequate colour contras and luminosity 286 .
            This algorithm uses the hexadecimal values of foreground and background colours to
            determine if the colour contrast is sufficient. The W3C algorithm is a recommendation in
            the W3C Web Content Accessibility Guidelines, Version 2.0 and replaces the previous
            algorithm.



286
      http://www.w3.org/TR/AERT#color-contrast


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            170
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
             Instead of using the algorithm every time you need to test your colours, you can use the
             JuicyStudio Luminosity Colour Contrast Ratio Analyser 287 , which automatically calculates
             the algorithm for you.

             The Luminosity Colour Contrast Ratio Analyser provides several outputs:
              Large text sample
                Example of the foreground and background colours in a large text sample.
              Regular text sample
                Example of the foreground and background colours in a large text sample.
              Results for Luminosity Contrast Ratio
                The contrast ratio of the two colours and at what level (A, AA or AAA) the sample
                passes.

             The contrast ratio must be 4.5:1, except for the following:
              Large Text: Large-scale text and images of large-scale text have a contrast ratio of
                at least 3:1;
              Incidental: Text or images of text that are part of an inactive user interface
                component, that are pure decoration, that are not visible to anyone, or that are part of
                a picture that contains significant other visual content, have no contrast requirement.
              Logotypes: Text that is part of a logo or brand name has no minimum contrast
                requirement.

             Testing a site for adequate colour contrast
             There are two ways to test a current site for adequate colour contrast:
                 Run the colours through Juicy Studio
                 Use Vischeck

                  Run the colours through Juicy Studio
                  You can use Juicy Studio if you know the hexadecimal values of the colours. (You
                  can use the Iconico ColourPic tool 288 if you don’t know the hexadecimal values).

                  Use a colour blindness simulator
                  You can use Vischeck (or one of the other colour blindness simulators), however you
                  need to be aware that this does not utilize the W3C algorithm. You can test an entire
                  web page with Vischeck 289 , however style sheets etc are not well-supported.
                  Alternatively you can test an image with Vischeck 290 . If you have Adobe Photoshop or
                  ImageJ you can download a Vischeck plug-in 291 which applies a filter to images. The
                  easiest way to test a page for colour contrast is to take a screenshot of the page (by
                  pressing the “Print Screen” or “prt sc” button on your keyboard) and upload it via the
                  image facility or filter it using one of the plug-ins.

             Further Information

             W3C
                 W3C Accessibility Evaluation and Repair Tools - Colour contrast

             Information on colour vision



287
      http://juicystudio.com/services/luminositycontrastratio.php
288
      http://iconico.com/colorpic/
289
      http://www.vischeck.com/vischeck/vischeckURL.php
290
      http://www.vischeck.com/vischeck/vischeckImage.php
291
      http://www.vischeck.com/downloads/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              171
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                  Colour vision 292
                  Colour matters 293

             Information on colour blindness
                  Effective colour contrast 294
                  How do things look to a colour blind person? 295
                  What do colour blind people see (requires Java)? 296
                  Wikipedia – Colour blindness 297
                  Colour blindness 298
                  How to make figures and presentations that are friendly to color blind people 299

             Tools
                  Juicy Studio Luminosity colour contrast analyser 300
                  Vischeck colour blindness simulation 301
                  Colour blindness simulator 302
                  ColorLab – Colour blindness simulator 303




292
      http://www.diycalculator.com/sp-cvision.shtml
293
      http://www.colormatters.com/entercolormatters.html
294
      http://www.lighthouse.org/color_contrast.htm
295
      http://webexhibits.org/causesofcolor/2.html
296
      http://www.tsi.enst.fr/~brettel/colourblindness.html
297
      http://en.wikipedia.org/wiki/Color_blindness
298
      http://colorvisiontesting.com/
299
      http://jfly.iam.u-tokyo.ac.jp/html/color_blind/
300
      http://juicystudio.com/services/luminositycontrastratio.php
301
      http://www.vischeck.com/
302
      http://www.etre.com/tools/colourblindsimulator/
303
      http://colorlab.wickline.org/colorblind/colorlab/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 172
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Creating sites accessible to people with cognitive disabilities

People with cognitive, language and learning disabilities comprise the largest group of those with
disabilities accessing the web. Unfortunately the W3C Web Content Accessibility Guidelines,
Version 1.0 does not include many checkpoints aimed at assisting this sub-group. The second
version of the Web Content Accessibility Guidelines also does not fully address the needs of this
sub-group, as evidenced by the formal objection tabled by Lisa Seeman 304 and co-signed by over
fifty people involved in the accessibility industry.

It is important to remember that people with cognitive disabilities often have a problem in only one
area of cognition, and can be of average or higher-than-average intelligence. People with
cognitive disabilities are just as likely as those in the general public to be in technical careers
and/or careers requiring high intelligence. People with cognitive disabilities may even work in
industries which would appear to be impossible to them due to their disability. For instance Tom
Cruise has dyslexia and as a dyslexic he has great difficulty reading; however his career as an
actor requires him to read and interpret scripts on a daily basis.

             Relationship to checkpoints:
             Checkpoint 1.1 requires that all information provided in a non-text format is also provided
             as a text equivalent
             Checkpoint 3.4 requires that relative units are used instead of absolute units
             Checkpoint 3.5 requires that headers are marked up properly
             Checkpoint 4.2 requires that abbreviations be expanded where they first occur
             Checkpoint 7.1: requires no flickering
             Checkpoint 7.2 requires minimal blinking
             Checkpoint 7.3 prohibits movement that cannot be stopped by the user
             Checkpoint 7.4 requires no auto-refreshing pages
             Checkpoint 7.5 requires no auto-redirecting pages
             Checkpoint 9.4 requires that the site contain a logical tab order
             Checkpoint 10.1 requires no popups or opening new windows without informing the user
             Checkpoint 10.2 require that fields are placed close to the relevant field label
             Checkpoint 12.3 requires breaking content into more manageable groups
             Checkpoint 13.1 requires identifying the target of each link
             Checkpoint 13.3 requires the inclusion of a sitemap or table of contents
             Checkpoint 13.4 requires that navigation be used in a consistent manner
             Checkpoint 13.8 requires the inclusion of distinguishing information at the beginning of
             pages, paragraphs and lists
             Checkpoint 14.1 requires that content is clear and simple
             Checkpoint 14.2 requires the supplementation of text with graphics or audio
             Checkpoint 14.3 requires that a consistent style is used throughout the site

             Type of cognitive disabilities
             There are many different types of cognitive disabilities; however they all incorporate
             varying degrees of problems associated with:
                  Memory;
                  Perception;
                  Problem-solving; and
                  Conceptualizing.

             Memory



304
      http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0368.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                173
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Memory impairments include difficulty obtaining, recognizing or retrieving information
             from short-term, long-term or remote memory.

             Perception
             Perception impairments include difficulty digesting, attending to and discriminating
             between sensory information.

             Problem-solving
             Problem-solving impairments include difficulty recognizing problems, identifying, choosing
             or implementing solutions and evaluation of the outcome.

             Conceptualizing
             Conceptualizing impairments include difficulties with sequencing, generalizing previously
             learned information, categorizing, cause and effect, abstract concepts, skill development
             and comprehension.

                                                     From “Designing for users with Cognitive Disabilities” 305

             For example, dyslexia is a disorder where reading, spelling and writing are impaired.
             Often there is no effect on speaking or other brain function. Dyslexia is an example of a
             disorder involving:
                   Perception – difficulty interpreting a series of letters on a page as a particular
                      word; and
                   Conceptualizing – difficulty sequencing the order of letters when attempting to
                      write or spell a word.

             For example autism is a developmental disorder involving:
                   Memory – difficulty ‘picking up’ information;
                   Perception – difficulty perceiving another’s body language;
                   Problem-solving – difficulty determining that certain behaviour is inappropriate;
                     and
                   Conceptualizing – lack of spontaneous play.

             For example epilepsy is a neurological disorder with a physical impairment and involves:
                  Memory – memory loss after an epileptic fit
                  Perception – certain sensory events trigger an epileptic fit

             Making sites accessible to people with cognitive disabilities
             There are some simple things you can do to ensure that your site is accessible to people
             with cognitive disabilities. For instance, you can ensure your site is accessible through a
             screen reader. Many people with cognitive disabilities have difficulty reading and
             therefore use a screen reader to assist them when using a site. Certain Web Content
             Accessibility Guidelines checkpoints are particularly useful in this case, such as:
                   Checkpoint 1.1: Ensure all images have ALT attributes; and
                   Checkpoint 9.4: Ensure that the site contains a logical tab order (Checkpoint
                      9.4).

             Reducing movement is also important as people with cognitive disabilities often have
             difficulties focusing on important information and are distracted easily. You can greatly
             improve the accessibility of your site to people with cognitive disabilities by highlighting
             important elements, such as:
                    Navigation;
                    Necessary or urgent content;


305
      http://www.otal.umd.edu/uupractice/cognition


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                     174
Copyright State of Victoria, 2009
                 Victorian Government Accessibility Toolkit
                 Links; and
                 Headings.

        Improving readability is also important. Certain techniques aimed at assisting people with
        cognitive disabilities include:
             Shortening sentences;
             Reducing column width;
             Using headings;
             Reducing colour contrast; and
             Presenting only one idea per sentence.

        The following list of guidelines will assist you in making your site accessible to people
        with cognitive disabilities. Many guidelines, such as reducing column width, will be
        difficult or infeasible to implement. The more guidelines you comply with the more
        accessible your site will be to people with cognitive disabilities, however following only a
        few of the following guidelines is better than following none at all.

        A. Comply with the cognitive-related checkpoints in WCAG1.0
        Many of the cognitive-related checkpoints in the Web Content Accessibility Guidelines
        are in Level AA and Level AAA. Therefore if your site is only compliant to Level A you
        could still be creating a site inaccessible to people with cognitive disabilities.

        The important cognitive-related checkpoints are:
            Checkpoint 1.1:
               Ensure all information provided in a non-text format is also provided as a text
               equivalent
            Checkpoint 3.4:
               Ensure relative units are used instead of absolute units
            Checkpoint 3.5:
               Ensure all headings are marked up properly
            Checkpoint 4.2:
               Ensure all abbreviations are expanded where they first occur
            Checkpoint 7.1:
               Remove flickering
            Checkpoint 7.2:
               Reduce or remove blinking
            Checkpoint 7.3:
               Do not include movement that cannot be stopped by the user
            Checkpoint 7.4:
               Do not use auto-refresh
            Checkpoint 7.5:
               Do not use auto-redirect
            Checkpoint 9.4:
               Ensure the site uses a logical tab order
            Checkpoint 10.1:
               Do not include popups or open new windows without informing the user
            Checkpoint 10.2:
               Ensure that fields are placed close to the relevant field label
            Checkpoint 12.3:
               Break content into more manageable groups
            Checkpoint 13.1:
               Identify the target of each link
            Checkpoint 13.3:
               Include a sitemap or table of contents


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            175
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit
                Checkpoint 13.4:
                 Use navigation in a consistent manner
                Checkpoint 13.8:
                 Include distinguishing information at the beginning of pages, paragraphs and lists
                Checkpoint 14.1:
                 Ensure content is clear and simple
                Checkpoint 14.2:
                 Supplement text with graphics or audio
                Checkpoint 14.3:
                 Use a consistent style throughout the site

        B. Ensure that your site is simple-to-use
        People with cognitive disabilities often have difficulty locating information or can be easily
        distracted. Providing a simple and clean design can assist this group.

        To make your site simple-to-use, follow these techniques:
            Create a clean design with minimal distractions
            Provide instructions for unfamiliar interfaces
            Provide informative error messages (including detailed 404 errors)
            Do not use flyover (otherwise known as “flyout” or “drop-down”) or hover menus
            Do not have more than seven navigation options
            Avoid background audio or images
            Include breadcrumbs
            Ensure the site can be printed legibly
            Use a font of 12px or higher
            Do not make columns of text larger than 70 characters
            Use a sufficient, but low, contrast between text and background (eg. a pastel
              background and black text)
            Use a Sans Serif font, such as Arial or Verdana
            Limit different fonts within the site
            Ensure all the links work
            Ensure links are always underlined
            Provide large clickable areas for links
            Provide features so the user can easily change text and background colour, text
              font and size

        C. Ensure text is clear and simple
        People with cognitive disabilities often have difficulty understanding or reading
        information. Providing clear and simple content can assist this group.

        To make your text clear and simple, follow these techniques:
            Provide summary information about the site on the homepage, including the
              purpose of the site and what can be achieved in the site
            Highlight key information at the beginning of the page or in text boxes
            Reduce text where possible
            Limit complex ideas
            Include only one idea per sentence
            Ensure content is literal; avoid abstract or figurative concepts
            Avoid tangential information
            Use the correct grammar and spelling
            Do not use abbreviations
            Identify the target of each link
            Include a FAQs page
            Include a Contact Us page


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            176
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit
                Include a Glossary

        D. Focus on information and assist in readability
        People with cognitive disabilities often have difficulty focusing on, or noticing, information.
        Alternatively they could have trouble reading information if it is formatted in a particular
        way. Providing additional formatting features can assist this group.

        To focus on information and assist in readability, follow these techniques:
             Ensure headings are used
             Do not use italics
             Do not use ALLCAPS
             Increase the line height on paragraphs
             Include a hover effect on links so that the link highlights when the user hovers
                over it
             Include a hover effect on table cells so that a particular cell is highlighted when a
                user hovers over it
             Hide content until the user requests it
             Include audio feedback for any activation (eg. a “ping” sound when a link is
                clicked)
             Provide multi-sensory error feedback, for instance a dialog box and an audio
                error message
             Supplement text navigation with graphic icons

        E. Ensure forms are easy-to use
        People with cognitive disabilities often have difficulty completing forms. Providing
        information about the use of a form can assist this group.

        To make your forms easier-to-use, follow these techniques:
            Reduce the complexity of forms
            Limit the number of procedural steps
            Auto-fill form input where possible
            Provide information at the beginning of forms to reduce the likelihood of errors
            Include cues and prompts
            Limit the options or choices within forms
            Provide a list of links to choose from instead of requiring the user to type in
              options
            Allow users to enter a short code to represent a longer sequence (eg. VIC
              instead of Victoria)
            Provide field labels for all fields
            Ensure field labels are positioned physically close to the relevant field
            Ensure dual controls (eg. Submit and Reset) are not close together
            Do not use time limits
            Ask users to confirm choices before submitting them

        F. Provide equivalents to audio and video
        People with cognitive disabilities can often be assisted by audio and video however other
        groups of people with cognitive disabilities cannot use or interpret this information.
        Providing equivalents to audio and video can assist this group.

        To make your audio and video accessible, follow these techniques:
            Provide transcripts to audio and video
            Provide captions to video
            Provide audio descriptions to video
            Allow users to stop, pause or slow down audio and video


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             177
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Further Information

             Information on cognitive disabilities
                 HCI Education – cognitive disability 306
                 Assistive technology with cognitive disability emphasis 307
                 Cognitive disabilities and learning difficulties 308
                 Misunderstood Minds 309
                 Misunderstood Minds – Reading 310
                 Misunderstood Minds – Attention 311
                 Misunderstood Minds – Writing 312
                 Misunderstood Minds – Mathematics 313

             Information on developing sites accessible to people with cognitive disabilities
                 Cognitive disabilities: Conceptualizing design considerations 314
                 Designing for users with cognitive disabilities 315
                 Designing web pages for dyslexic readers 316

             Information on cognitive disabilities and the W3C
                 Cognitive disabilities: We still know so little, and we do even less 317
                 Inclusion of cognitive disabilities in the web accessibility movement 318
                 Formal objection to WCAG2 319
                 Recollection of phone calls on learning disabilities and WCAG2 320




306
      http://www.comp.lancs.ac.uk/computing/users/dixa/hci-education/cog-dis/cog-dis.html
307
      http://spot.colorado.edu/~dubin/bookmarks/b/445.html
308
      http://webboy.net/presentation/ozewai2004/index.htm
309
      http://www.pbs.org/wgbh/misunderstoodminds/
310
      http://www.pbs.org/wgbh/misunderstoodminds/reading.html
311
      http://www.pbs.org/wgbh/misunderstoodminds/attention.html
312
      http://www.pbs.org/wgbh/misunderstoodminds/writing.html
313
      http://www.pbs.org/wgbh/misunderstoodminds/math.html
314
      http://www.webaim.org/articles/cognitive/conceptualize/
315
      http://www.otal.umd.edu/uupractice/cognition/
316
      http://www.dyslexia-parent.com/mag35.html
317
      http://www.webaim.org/articles/cognitive/cognitive_too_little/
318
      http://www2002.org/CDROM/alternate/689/
319
      http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0368.html
320
      http://joeclark.org/access/webaccess/WCAG/cognitive/phonecalls.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          178
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Conducting Operating System and Browser testing
Although not technically an accessibility issue, ensuring that your site works on a variety of
operating systems and browsers will improve the accessibility of your site. Often a site that
functions on an older browser, such as Netscape 4.7, will also be accessible as accessibility and
OS/browser techniques are very similar. For instance, Netscape 4.7 does not have the JavaScript
plug-in, so a site that that works on Netscape 4.7 (ie. with JavaScript enabled) will also comply
with the Level A Checkpoint 6.3: Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported.

In addition to enhancing the accessibility of a site, making a site compliant to a number of
operating systems and browsers will increase the number of people able to access and use your
site. It is true that the operating system Windows and the browser Internet Explorer dominate the
market; however alternatives, such as Safari, FireFox and Chrome are becoming more common.
In May 2009 the browser statistics according to W3Schools were:

May 2009 Browser usage by browser type
         Internet           FireFox / Mozilla          Chrome              Safari           Opera
         Explorer

           41.0%                  47.7%                  5.5%               3.0%            2.2%

May 2009 Browser usage by browser version for Internet Explorer
 FireFox           IE7            IE6           Chrome          IE8        Safari   Opera

 47.7%             21.3%          14.5%         5.5%            5.2%       3.0%     2.2%

You can also access an updated list of monthly browser statistics 321 . It is important to note that
these browser statistics are based on the web statistics of the W3Schools web site. People
accessing this site are more technically-savvy than the average user and are therefore more
likely to be using alternative browsers.

May 2009 Operating system usage by operating system type
          Windows                       Mac                     Linux

            89.5%                       6.1%                    4.1%

May 2009 Operating system usage by operating system version
 Win XP            Win Vista      Mac           Linux           Win 2003   Win7     Win2000

 67.2%             18.4%          6.1%          4.1%            1.7%       1.1%     1.1%

            Relationship to checkpoints:
            Although there are no specific Web Content Accessibility Guidelines that refer to
            operating system and browser compliance, some do have an indirect effect on how a site
            will display in some operating systems and browsers. The following are some examples
            of how checkpoints are related to operating system and browser compliance.

            Checkpoint 1.1 requires that you provide ALT attributes for images. In Internet Explorer
            these ALT attributes appear as a tool tip when you hover over the image.

321
      http://www.w3schools.com/browsers/browsers_stats.asp


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 179
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Checkpoint 3.2 requires that pages validate to HTML and CSS standards. This will
        ensure sites display properly in standards-compliant browsers such as FireFox and
        Opera.
        Checkpoint 4.2 requires that you specify the expansion of each abbreviation or acronym.
        In FireFox these abbreviations and acronyms are underlined (with a dotted line) and are
        provided as a tool tip when you hover over the abbreviation or acronym

        Choosing operating systems and browsers to test
        It is important to choose accurate operating systems and browsers; too many and the
        cost and resources skyrocket, too few and you may miss some major problems. The
        most important way to determine which operating systems and browsers to test is to
        review the web statistics for your current site. If you don't have a current site then try to
        access web statistics for a similar site.

        Choosing operating systems and browsers to test
        The following is an example of web statistics for a small web site.

Browser and Operating system web statistics
                         Operating Systems                                  Percent

 Internet Explorer/Windows                                                  52.14 %
 FireFox / Windows                                                          39.32 %
 Safari / Macintosh                                                          5.98 %
 Chrome / Windows                                                            1.71 %
 FireFox / Macintosh                                                         0.85 %

        With the above information you might think that you should focus testing in the Windows
        operating system and test the latest Windows versions, such as Windows Vista and
        Windows XP. However if you look at the detailed web statistics of operating system
        usage you would actually find that more people use Windows 2000 than use Windows
        Vista.

Example of list of Windows operating system web statistics
         Versions               Percent

 Windows XP                     85.32 %
 Windows 2000                   7.34 %
 Windows Vista                  6.42 %
 Server 2003                    0.92 %

        As a general rule of thumb you should always test operating systems and browsers that
        occur more often than 1.0%, however this figure varies significantly depending on the
        purpose of your web site. If your site provides critical information to a wide range of users
        then you should ensure that all users can access that information. This is especially
        important if you have a very large number of users (eg. 30,000 unique users per day)
        then an operating system usage of 0.8% indicates 240 unique users per day.

        For the web statistics indicated above a reasonable range of operating systems to test
        would be:
         Windows XP


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              180
Copyright State of Victoria, 2009
                 Victorian Government Accessibility Toolkit
              Mac OS X
              Windows 2000
              Windows Vista

          Choosing browsers to test
          The following is an example of web statistics for a small web site.

Browser web statistics
                 Browsers                    Percent

 Internet Explorer                          52.14 %
 FireFox                                    40.17 %
 Safari                                     5.98 %
 Chrome                                     1.71 %

          Once again it is important to look at the full list of browsers to determine which versions to
          test.

Example of list of Internet Explorer browser web statistics
              IE Versions              Percent

 IE 6.0                               54.10%
 IE 7.0                               31.15%
 IE 8.0                               14.75%

          There are multiple browser versions for a particular browser and although each version
          has the potential to cause a bug within your web site, it is usually customary to test only
          major releases of browsers (ie. Internet Explorer 7 or FireFox 3).

          For the web statistics indicated above a reasonable range of browsers to test would be:
           Internet Explorer 6.01
           Internet Explorer 7.0
           FireFox 3.0
           Safari
           FireFox 2
           Chrome

          Choosing the combination of operating systems and browsers
          Once you have developed a list of operating systems and browsers it is not a case of
          testing each browser on each operating system. There are numerous reasons why some
          browsers should not be tested on some operating systems:

                   Some browsers only operate on a particular operating system.
                   Particular operating systems often build browsers for use specifically with their
                   operating system. For instance Safari is a Mac browser and therefore would not
                   need to be tested on any of the Windows versions. Alternatively, Microsoft no
                   longer supports Internet Explorer for Macintosh and recommends Apple’s Safari
                   browser instead.

                   Some operating browsers come pre-installed with a particular browser version



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              181
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
                 It is highly unlikely that someone would uninstall a pre-installed browser version
                 and install an older version of that particular browser. For instance Windows
                 Vista comes pre-installed with Internet Explorer 7.0 and therefore older versions
                 of Internet Explorer would not need to be tested on that operating system.

                 Some operating systems have been released recently
                 Browser versions much older than a particular operating system would not need
                 to be tested on that operating system. For instance Windows Vista was released
                 after FireFox 2.0 was released and therefore FireFox 1.5 would not need to be
                 tested on that operating system.

        A reasonable combination of operating system and browsers would be:

                 Windows XP
                  Internet Explorer 6.01
                  Internet Explorer 7.0
                  FireFox 3.0.
                  FireFox 2.0
                  Opera
                  Chrome

                 Mac OS X
                  Safari
                  FireFox 3.0

                 Windows Vista
                  Internet Explorer 7.0
                  Internet Explorer 8.0
                  FireFox 3.0

                 Windows 2000
                  Internet Explorer 6.01
                  Internet Explorer 7.0
                  FireFox 2.0.x
                  Opera

        Setting up an operating system and browser testing environment
        There are two ways to test an identified set of operating system and browser
        combinations. You can either purchase a product that will show you how a site would
        look in a particular operating system and browser or you can set up the operating
        systems and browsers yourself and test them manually. The latter option will give you
        more reliable results and may be cheaper if you expect to do a lot of operating system
        and browser testing. If you do decide to set up the operating systems and browsers
        yourself ensure you have access to decent technical support and a dedicated PC and
        Mac devoted to testing purposes only. Often the installation of multiple operating systems
        and browser versions will significantly slow down a computer.

        There are a number of programs that will emulate a particular operating system and
        browser combination. The pricing ranges from free to $US19.95 for unlimited use over a
        24 hour period and up to $US995 for unlimited use for an entire year. Some examples of
        these products are:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          182
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                 BrowserCam 322 (for details on BrowserCam see the article: Browser Compatibility
                  Testing: BrowserCam Gets Better - Video Review 323 )
                 BrowserShots 324
                 BrowserPhoto 325
                 Web Designers’ Toolkit 326
                 Web Page Backward Compatibility Viewer 327

             To test web sites in specific operating systems or browsers see:
              BrowsrCamp (Mac browsers Emulator) 328
              PearPC (Mac Emulator) 329
              Test Linux Desktop 330
              LynxViewer 331

             There are also viewers that can show you what your web site will look like in other
             technologies:
              Mobi – Mobile emulator 332
              Windows Mobile 5.0 Pocket PC Emulator 333
              Windows Mobile 2003 Pocket PC Emulator 334

             Installing multiple operating systems
             Most computers can run more than one operating system using the free Microsoft Virtual
             PC 335 . Microsoft Virtual PC allows you to install multiple operating systems and easily
             move between them. For more information see the Virtual PC Wiki 336 .

             For the identified list of operating system and browsers you would only need one PC and
             one Mac. By installing Virtual PC you can install Windows XP, Windows Vista and
             Windows 2000 on the one PC.

             Installing multiple browser versions
             It is possible to install multiple versions of a browser on the one operating system. The
             evolt.org browser archive 337 has the most comprehensive list of browsers on the internet.
             Other browser archives include:


322
      http://www.browsercam.com
323
      http://www.masternewmedia.org/news/2007/01/22/browser_compatibility_testing_browsercam_gets.htm
324
      http://browsershots.org
325
      http://www.netmechanic.com/products/browser-index.shtml
326
      http://www.webdesignerstoolkit.com/
327
      http://www.delorie.com/web/wpbcv.html
328
      http://www.browsrcamp.com/
329
      http://pearpc.sourceforge.net/
330
      http://opensource.region-stuttgart.de/test_linux_desktop.php
331
      http://www.delorie.com/web/lynxview.html
332
      http://emulator.mtld.mobi/emulator.php
333
  http://www.microsoft.com/downloads/details.aspx?familyid=EEC33AE3-C129-4C25-ABAA-
18E8E842178F&displaylang=en
334
      http://www.microsoft.com/downloads/details.aspx?familyid=57265402-47a8-4ce4-9aa7-5fe85b95de72&displaylang=en
335
      http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx
336
      http://en.wikipedia.org/wiki/Virtual_PC
337
      http://browsers.evolt.org/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                        183
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
                  Netscape browser archive 338
                  Internet Explorer browser archive 339
                  Mozilla Releases 340
                  Previous versions of Internet Explorer 341

             There is also information on running multiple versions of FireFox on Windows 342 .

             The operating system and browser testing process
             When testing a web site on a combination of operating systems and browsers there are
             some specific things to watch for:
              Does all the content display?
              Does all the functionality work? (eg. can the forms be submitted)
              Does the site still function with style sheets, JavaScript, Java and/or Flash turned off?
              Do all the colours display properly?
              Is the content aligned properly?
              Are backgrounds displayed in the correct area?
              Is the text size sufficient?

             Further Information

             General information on operating system and browser testing
                  The Ultimate testing checklist 343
                  Why your site should work on multiple browsers 344
                  Browser Testing 345
                  Cross Browser Testing: a detailed review of Tools and Services 346




338
      http://sillydog.org/narchive/
339
      http://www.microsoft.com/windows/ie/ie6/previous/default.mspx
340
      http://www.mozilla.org/releases/
341
      http://www.microsoft.com/windows/ie/ie6/previous/default.mspx
342
      http://www.hiveminds.co.uk/node/3114
343
      http://www.sitepoint.com/article/ultimate-testing-checklist
344
      http://www.siliconglen.com/usability/browsers.html
345
      http://css-discuss.incutio.com/?page=BrowserTesting
346
      http://www.smashingmagazine.com/2010/06/04/cross-browser-testing-a-detailed-review-of-tools-and-services/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                            184
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Additional accessibility features

Accessibility features can greatly enhance a site. Although they may not be referred to in the
W3C Web Content Accessibility Guidelines they are still very useful.

        Text size changer
        Although this functionality is replicated by the browser, most users do not know that these
        techniques exist.

        Print
        Although this functionality is replicated by the browser, a handy print link can prove
        useful.

        Colour contrast changer
        Some users find high colour contrast most legible. Other users find low contrast most
        legible. Providing an ability to change colour contrast via a colour contrast changer can
        assist accessibility.

        Other languages
        Users with English as a second language can have a lot of difficulty reading English.
        Providing critical pages in other languages can greatly assist these users.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           185
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Videos and accessibility

There will be people who won’t be able to access the video because:
       They are hearing impaired or deaf;
       They are visually impaired or blind;
       They are using a slow modem;
       They do not have the required media player; and/or
       They have a physical disability which prevents them from using the media player.
Videos cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people using screen readers. A video is made accessible by:
       Creating the video in a particular way;
       Inserting the video in the site a particular way;
       Providing a transcript of the video in text or HTML;
       Providing audio descriptions of all the visual content in the video 347 ; and
       Providing captions of all the audio content in the video 348 .

                  What about YouTube videos?
Just like other videos, you can caption YouTube videos. However it is currently not possible to
associate audio descriptions with a YouTube video. Thus when you are putting videos on
YouTube you must:
       Caption the video 349 ; and
       Provide a link to a page with the transcript and audio described video.
Embedding videos is not recommended. These videos are not keyboard accessible and pose a
number of accessibility problems to people with disabilities. Where a YouTube video has been
referenced, also include a link to the easy YouTube player by Chris Heilmann 350 . This player
allows users to paste in the URL and then use an accessible player to play the video. Make sure
you have provided users with the YouTube URL.

                  What about vodcasts?
Just like other videos, you can caption vodcasts. When putting vodcasts on your site you must:
       Caption the vodcast 351 ; and
       Provide a link to a page with the transcript and audio described video.
See the Vodcast section.




347
      See Captioning videos section
348
      See Audio describing videos section
349
      See Captioning YouTube videos section
350
      http://icant.co.uk/easy-youtube/
351
      See Captioning vodcasts section


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            186
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
                 What about live streaming content?
With live streaming content, captions and transcripts must be written live. It is possible to caption
existing media files for streaming download (WebAIM has a tutorial on Captioning streaming
media 352 ), however providing a downloadable audio or video file is more accessible.
Live streaming content should always have an alternative, for example, the songs being played
on a streaming radio site.

                 Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects, sounds
(played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

                 Complying with accessibility requirements when including video
Creating the video in a particular way
Accessibility needs to be considered both when videoing the content and when converting the
video for web use.

            When videoing the content
                Use only high contrast colours;
                Do not provide information in colour alone;
                Do not use patterned backgrounds; and
                Do not include flashing or flickering content.

            When converting the video for web use
                Use a consistent video file format;
                Allow users to zoom in and out on content;
                Limit video files to 2MB or less (for larger files, break them up into smaller downloads
                 as well as offering the full file, or create a low bandwidth version of the content);
                Allow users to control the video (e.g. pause, rewind, etc.) via the keyboard only;
                Allow users to control the video (e.g. pause, rewind, etc.) via the mouse only; and
                Allow users to control the volume.

Inserting the video in the site in a particular way
Accessibility needs to be considered in how the user will access the video.
                Never automatically start a video file;
                Never embed the video;
                Allow the user to skip over the video using the mouse only;
                Allow the user to skip over the video using keyboard only;
                Open the video in a new window;
                Ensure the site is functional and all content is available without the video; and

352
      http://www.webaim.org/techniques/captions/hicaption/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                 187
Copyright State of Victoria, 2009
                   Victorian Government Accessibility Toolkit
              Include information on how to access the video player;

Providing details of the video
Details can provide information to the user about the file and whether it is necessary to download
the file. Alternatively, if they cannot download the file, it will provide them with information on who
to contact to access an alternative copy.
              Provide contact details to arrange an alternative format of the video (e.g. HTML, text,
               Word, or hard copy)
              Include information on the site about the file, such as: file type, file size, estimated
               download time and duration of video.

Providing a transcript of the video in text or HTML
Where the user cannot access the video, it is vital that a transcript is provided (in HTML, text or
Word) so that they are not missing out on the content within the video.
             Example 1: Transcript of a video
Live in Victoria contains a number of migrant stories 353 , including a video. As well as the video
they include a page of information about the skilled migrant.




353
   http://www.liveinvictoria.vic.gov.au/information/skilled-migrants/migrant-stories/laura-lee-innes-
story?SQ_PAINT_LAYOUT_NAME=extended


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    188
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




                  Further Information
       W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
       W3C Checkpoint 6.2: Equivalents for dynamic content are updated when the dynamic content
        changes
       NCAM YouTube captioning 354
       YouTube captioning 355
       YouTube Australia Official Blog 356
       Easy YouTube video player 357




354
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/more_cc_topics.html#youtube
355
      http://www.reelseo.com/youtube-captioning-accessibility/
356
      http://www.youtube.com/blog?entry=mi8D3ntPgFQ
357
      http://icant.co.uk/easy-youtube/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                      189
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Captioning downloadable videos
There will be people who won’t be able to access the audio content of the video because:
 They are hearing impaired or deaf;
 They are in a noisy environment; or
 They cannot play sound.
Videos cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people who are hearing impaired or deaf. A video is made usable to
some people with disabilities by:
 Providing a transcript of the video in text or HTML 358 ;
 Providing audio descriptions of all the visual content in the video 359 ; and
 Providing captions of all the audio content in the video.

                 Relationship to WCAG1 checkpoints:
Checkpoint 1.4 requires that for any time-based multimedia presentation (e.g. a movie or
animation), synchronize equivalent alternatives (e.g. captions or auditory descriptions of the
visual track) with the presentation

                 Tools you will need
In order to create captions, your video file must be in MP4 format. You will also need the following
applications:
      MAGpie 2.0 (see MAGpie installation instructions 360 )
      Notepad
      Quicktime

                 Using MAGpie to create captions
MAGpie is very well-known accessible captioning software.

Create a project:
1. Under the File menu, select “New project”
2. In the dialog box, select the “Browse” button and select your video file
3. For “Caption styles” select 18pt, centred and click OK
4. When the “Create new project track” dialog box opens, click OK

Create a caption:
1. Press F6 to begin the video. After a sentence or two, press F6 again and type what you have
   heard into the “Caption” column.
           Each caption should not exceed two lines




358
      See Videos document
359
      See Audio describing document
360
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           190
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
       Speech does not need to be in quotes. Speech should be preceded by the name of the
        speaker in the first instance bracketed and in italics, eg:
        [Vera] We teach maths, English and LOTE
       Subsequent captions of speech do not need to be labeled unless there has been a
        change in speaker
       Important audio information should be included, bracketed and in italics, e.g,:
        [Laughs] Well we get all sorts in here.
       Unimportant audio information should not be included, for example “um”, “ah” etc.
       When there is a significant period of silence or background music without important audio
        information, then this should be captioned. Captions containing this information should be
        bracketed and in italics, e.g.:
        [Music plays]
2. When you have completed one caption, press Enter twice to create a new row for a new
   caption.

Setting the timestamp:
1. Press F7 to rewind the video to the beginning
2. Move to the first row and press F9 – this will set a timestamp of 0:00:00.00 and means that
   the first caption will appear as soon as the movie starts
3. Press F6 to begin playing the video.
4. When the beginning of the next caption is spoken press F9 – this will set a timestamp for the
   new caption The caption must appear on the screen at the same time as the speech, or
   sound, that is being captioned.
5. Continue until all captions have timestamps
6. MAGpie will automatically insert a new row at the end. Delete this row (right-click on the row
   and select “Delete selected rows”)

Checking your work:
1. Under the “Export” menu select “Quicktime – SMIL 1.0 format”
2. Open Quicktime and select the SMIL file that MAGpie created
3. Play the video with the sound on. Check that:
       Captions appear at the same time as the sound they are captioning; and
       That all important audio information has been captioned
4. Play the video with the sound off. Check that:
       Captions appear on the screen for enough time to read (approximately 3 – 4 seconds
        for a two line caption);
       There are no periods without captions; and
       That speech has been attributed to a particular speaker.

Uploading the video and caption:
1. Copy the following files to the appropriate directory on website:
       original_movie.mp4
       filename.qt.txt
2. Open filename.qt.smil file in Notepad


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        191
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
            Replace
                    <video dur="0:02:19.75" region="videoregion"
                    src="original_movie.mp4"/>
             with
                    <video dur="0:02:19.75" region="videoregion"
                    src="http://www.yoururl.com.au 361 /original_movie.mp4"/>
            Replace
                    <textstream dur="0:02:19.75" region="textregion"
                    src="filename.qt.txt"/>
             with
                    <textstream dur="0:02:19.75" region="textregion"
                    src="http://www.yoururl.com.au/filename.qt.txt"/>
3. Copy filename.qt.smil to your web site directory:
4. In the HTML of your web page insert the following HTML:
            <a href="/filename.qt.smil">My film with captions (2.2MB)</a>
                Example 1: Koorie education with Learning Objects, Part 1
In the Learning Objects movie, the file has important information presented in both the audio and
video tracks and therefore also requires audio descriptions. The file also needs an HTML
equivalent.
Page containing transcript and captions 362
                    Further Information
       Checkpoint 1.4: For any time-based multimedia presentation (e.g. a movie or animation),
        synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track)
        with the presentation
       NCDAE: Introduction to captioning 363
       MAGpie: Caption authoring 364
       WebAIM: Captioning with MAGpie 2.0 365
       Streaming Media: Merging captions and video 366
       Best practices in online captioning 367




361
   Replace http://www.yoururl.com.au with your web address and relevant path to the files, for example,
http://www.vic.gov.au/media/video/
362
      http://www.gianwild.com.au/video-example
363
      http://ncdae.org/tools/factsheets/captioning.cfm
364
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/#captioning
365
      http://www.webaim.org/techniques/captions/magpie/version2/
366
      http://streaming.wisconsin.edu/accessibility/magpie_tutorial/quicktime.html
367
      http://joeclark.org/access/captioning/bpoc/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    192
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Captioning YouTube videos

There will be people who won’t be able to access the audio content of the video because:
 They are hearing impaired or deaf;
 They are in a noisy environment; or
 They cannot play sound.
YouTube videos cannot be made fully accessible, but they can be made accessible to some
people with disabilities; for example people who are hearing impaired or deaf. A YouTube video is
made usable by some people with disabilities by:
 Providing a transcript of the video in text or HTML 368 ;
 Providing audio descriptions of all the visual content in the video 369 ; and
 Providing captions of all the audio content in the video.

                 Relationship to WCAG1 checkpoints:
Checkpoint 1.4 requires that for any time-based multimedia presentation (e.g., a movie or
animation), there must be synchronized equivalent alternatives (e.g., captions or auditory
descriptions of the visual track) with the presentation

                 Tools you will need
YouTube has introduced an automatic speech recognition service that automatically creates
captions for videos. It can either be done automatically, which will sometimes include errors, or it
can generate captions from a transcript.
Every YouTube video should be uploaded with a transcript. This transcript should also be
available to the general public in the event that they have a disability that prevents them from
viewing or hearing the YouTube video.
             Create a transcript
1. When creating a transcript you should include all the important information in the video (audio
and video content). However when creating a YouTube transcript include the speech only.


                 Upload the transcript
1. Select 'My Videos' under the 'Account' option.

2. Find the video and select the 'Captions' button.

3. Select the 'Add New Captions or Transcript' button.

4. Select the 'Browse' button and find the transcript file to upload.

5. Select the 'Transcript file' option.



368
      See Videos document
369
      See Audio describing document


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             193
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
6. Select the English option.

7. Select the 'Upload File' button.

            Examples:
   John Brumby announces improvements to Box Hill hospital

            Further Information
   Checkpoint 1.4: For any time-based multimedia presentation (e.g., a movie or animation),
    synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track)
    with the presentation
   Google Blog: YouTube launches auto-captioning
   Mashable: YouTube launches auto-captioning for videos




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           194
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Audio describing videos

There will be people who require audio descriptions because:
       They are visually impaired or blind;
       They have English as a Second language; and/or
       They have a physical disability which prevents them from pausing the media player to read
        the text on the screen.
Videos cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people using screen readers. A video is made accessible by:
       Providing a transcript of the video in text or HTML 370 ;
       Providing audio descriptions of all the visual content in the video; and
       Providing captions of all the audio content in the video 371 .

                 Relationship to WCAG1 checkpoints:
Checkpoint 1.3 requires that 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.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

                 Tools you will need
In order to create audio descriptions, your video file must be in MP4 format. There are numerous
methods to create a MP4 – this document deals with only one of them.
You will need the following applications installed:
       MAGpie 2.0 (see installation instructions 372 )
       Notepad
       Quicktime

                 Using MAGpie to create audio descriptions
MAGpie is very well-known accessible captioning software.

Create a project:
1. Under the File menu, select “New project”
2. In the dialog box, select the “Browse” button and select your video file
3. Click OK
4. When the “Create new project track” dialog box opens, select “Audio Descriptions” in the
   “Track Type” section
5. Click OK


370
      See Videos section
371
      See Captioning videos section
372
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            195
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
Create an audio description:
1. Press F6 to begin the video. When important information is provided in the visual part of the
   video, stop the video and click the “Record description” button
2. Select the “Use generated file name” option.
3. When you are ready to record the description click “Record” (you will need a microphone for
   this)
4. When you have finished recording, click “Stop” and then OK to close the dialog box
       The audio description must fit between existing dialog or important sounds.
       If there are time limits, describe only important visual information, such as people’s
        actions, or diagrams. If there is enough time, then describe other visual information
       Describe information consistently, ie using the same names and terminology
       Describe emotional states, but do not attribute reasoning or motivation (eg. do not say
        “Her prayers answered, Joan looks up with tearful eyes”, instead say “Joan looks up with
        tearful eyes”)
       Ensure the voice is sufficiently distinguishable from other voices in the production
       Read titles and credits
5. When you have completed one recording, press Enter twice to create a new row for a new
   audio description.

Setting the timestamp:
1. Press F7 to rewind the video to the beginning
2. Press F6 to begin playing the video.
3. When the audio description should be spoken press F9 – this will set a timestamp for the
   audio description
4. Continue until all audio descriptions have timestamps
5. MAGpie will automatically insert a new row at the end. Delete this row (right click on the row
   and select “Delete selected rows”)

            Testing the audio descriptions

Checking your work:
1. Under the “Export” menu select “Quicktime – SMIL 1.0 format”. Save the file.
2. Open Quicktime and select the SMIL file that MAGpie created in step 1
3. Play and watch the video. Check that:
       Audio descriptions adequately describe the visual information
       The audio descriptions do not impinge on other speech or important sounds
4. Play the video but do not watch it. Check that:
       Audio descriptions are sufficiently explanatory
       Audio descriptions are sufficiently distinguishable from other speech
            Putting the audio described video on a web site
Uploading the audio description and the video




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           196
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
1. Copy the following files to the appropriate directory on your website 373 :
           original_movie.mp4
           audiofile1.wav, audiofile2.wav etc.
2. Open filename_audio.qt.smil file in Notepad
           Replace
                   <video dur="0:02:19.75" region="videoregion"
                   src="original_movie.mp4"/>
            with
                   <video dur="0:02:19.75" region="videoregion"
                   src="http://www.yoururl.com.au/ 374 original_movie.mp4"/>
           Replace
                   <audio src="audiofile1.wav" begin="0:00:00.00"/>
            with
                   <audio src="http://www.yoururl.com.au/audiofile1.wav"
                   begin="0:00:00.00"/>
           Replace
                   <audio src="audiofile2.wav" begin="0:00:43.52"/>
            with
                   <audio src="http://www.yoururl.com.au/audiofile2.wav"
                   begin="0:00:43.52"/>
           Replace
                   <audio src="audiofile3.wav" begin="0:01:18.50"/>
            with
                   <audio src="http://www.yoururl.com.au/audiofile3.wav"
                   begin="0:01:18.50"/>
           Repeat for all audiofiles
3. Copy filename_audio.qt.smil to your web site directory:
4. In the HTML of your web page insert the following HTML:
           <a href=" http://www.yoururl.com.au/ 375 filename_audio.qt.smil">My
            film with audio descriptions (2.2MB)</a>

                   Example 1: Koorie education with Learning Objects, Part 1
In the Learning Objects movie, the file has important information presented in both the audio and
video tracks and therefore also requires captions. The file also needs an HTML equivalent.
Page containing transcript and audio described video 376




373
      If using a CMS, follow your web publishing/media upload process
374
   Replace http://www.yoururl.com.au with your web address and relevant path to the files, for example,
http://www.vic.gov.au/media/video/
375
   Replace http://www.yoururl.com.au with your web address and relevant path to the files, for example,
http://www.vic.gov.au/media/video/
376
      http://www.gianwild.com.au/video-example


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    197
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit

                  Further information
       MAGpie: Audio descriptions 377
       Joe Clark: Standard techniques in audio description 378
       Skills for Access: Provide audio descriptions for video or animated content – in MAGpie 379




377
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/#audiodescription
378
      http://joeclark.org/access/description/ad-principles.html
379
      http://www.skillsforaccess.org.uk/howto.php?id=135


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                198
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

Captioning vodcasts

There will be people who won’t be able to access the audio content of the video because:
 They are deaf or hearing impaired;
 They are in a noisy environment; or
 They cannot play sound.
Vodcasts cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people who are hearing impaired or deaf. A vodcast is made accessible
by:
 Providing a transcript of the video in text or HTML 380 ; and
 Providing captions of all the audio content in the video.

                 Relationship to WCAG1 checkpoints:
Checkpoint 1.4 requires that for any time-based multimedia presentation (e.g. a movie or
animation), there must be synchronized, equivalent alternatives (e.g. captions or auditory
descriptions of the visual track) with the presentation

                 Tools you will need
In order to create captions of your vodcast, your file must be in MP4 format. You will need the
following hardware and applications to create a vodcast:
       Speakers
       Microphone
       Webcam
       MAGpie 2.0 (see MAGpie installation instructions 381 )
       Quicktime Pro 382
       iTunes account (if you want to add the vodcast to iTunes)
       RSS feed URL

                 Using MAGpie to create captions
MAGpie is very well-known accessible captioning software.

Create a project:
1. Under the File menu, select “New project”
2. In the dialog box, select the “Browse” button and select your video file
3. For “Caption styles” select 18pt, centred and click OK
4. When the “Create new project track” dialog box opens, click OK




380
      See Videos document
381
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html
382
      http://www.apple.com/au/quicktime/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            199
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
Create a caption:
1. Press F6 to begin the video. After a sentence or two, press F6 again and type what you have
   heard into the “Caption” column.
       Each caption should not exceed two lines
       Speech does not need to be in quotes. Speech should be preceded by the name of the
        speaker in the first instance bracketed and in italics, e.g.:
        [Vera] We teach maths, English and LOTE
       Subsequent captions of speech do not need to be labeled unless there has been a
        change in speaker
       Important audio information should be included, bracketed and in italics, e.g.:
        [Laughs] Well we get all sorts in here
       Unimportant audio information should not be included, for example “um”, “ah” etc.
       When there is a significant period of silence or background music without important audio
        information, then this should be captioned. Captions containing this information should
        be bracketed and in italics, eg:
        [Music plays]
2. When you have completed one caption, press Enter twice to create a new row for a new
   caption.

Setting the timestamp:
1. Press F7 to rewind the video to the beginning
2. Move to the first row and press F9 – this will set a timestamp of 0:00:00.00 and means that
   the first caption will appear as soon as the movie starts
3. Press F6 to begin playing the video
4. When the beginning of the next caption is spoken press F9 – this will set a timestamp for the
   new caption The caption must appear on the screen at the same time as the speech, or
   sound, that is being captioned
5. Continue until all captions have timestamps
6. MAGpie will automatically insert a new row at the end. Delete this row (right-click on the row
   and select “Delete selected rows”)

Checking your work:
1. Under the “Export” menu select “Quicktime – SMIL 1.0 format”
2. Open Quicktime and select the SMIL file that MAGpie created
3. Play the video with the sound on. Check that:
       Captions appear at the same time as the sound they are captioning; and
       That all important audio information has been captioned.
4. Play the video with the sound off. Check that:
       Captions appear on the screen for enough time to read (approximately 3 – 4 seconds
        for a two line caption);
       There are no periods without captions; and
       That speech has been attributed to a particular speaker.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        200
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit


            Associate captions with the vodcast
Associate captions
1. Open the original vodcast (without captions) in Quicktime
2. Open the vodcast.qt.txt document in Quicktime
3. In the vodcast.qt.txt file, under the Edit menu, select the option “Select All”
4. Under the Edit menu, select Copy
5. Go to the original vodcast
6. Under the Edit menu, select Add to movie

Position captions on the screen
1. Under the Window menu, select Show Movie Properties
2. Select Video Track and then the Visual Settings tab
3. Write down the number in the second Scaled Size field (in the example below, this number is
   240)




4. Select Text Track and then the Visual Settings tab
5. In the second field of the Scaled Size fields, change the number to 80.
6. In the second Offset Field, insert the value you captured in step 3, above




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                     201
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




Export to MP4
1. Under the File menu, select Export
2. Under Export As select Movie to MPEG4 383

Upload and insert the vodcast to a site
1. Copy the vodcast to your web server
2. Add a link to the vodcast

If your RSS feed is not already uploaded to iTunes:
1. Go to iTunes
2. Select iTunes store
3. Select “Submit a podcast”
4. Select Podcasts on the left hand side
5. Down the bottom right hand side of the page, select “Submit a podcast”
6. Insert your RSS URL
7. Select Continue
iTunes will review your vodcasts before putting them on the iTunes site.
             Example 1: Test vodcast
A test vodcast, complete with captions has been created at Gian Wild’s 384 web site.


383
      Sometimes Quicktime crashes at this point. If so:

1.      Under the Edit menu, select Preferences and then Quicktime preferences

2.      Select the Advanced option and under Video select “Safe” mode

If you are still having problems then:

1.      Go to Control Panel

2.      Open Display

3.      Select Settings

4.      Click the “Advanced” tab
5.      Drag the Hardware Acceleration to “None”


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                 202
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                  Example 2: Koorie education captioned vodcast
A complex vodcast, complete with captions has been created at Gian Wild’s 385 web site

                  Further Information
       Checkpoint 1.4: For any time-based multimedia presentation (e.g. a movie or animation),
        synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track)
        with the presentation
       NCDAE: Introduction to captioning 386
       MAGpie: Caption authoring 387
       WebAIM: Captioning with MAGpie 2.0 388
       Streaming Media: Merging captions and video 389
       Best practices in online captioning 390
       How to create an accessible podcast 391
       WebAxe Podcasts: Jeffrey Frey on Accessible Podcasts 392
       Accessible podcasts 393
       Podcasting and accessibility 394
       Jeffrey Frey’s Podcast Captioning 395




384
      http://www.gianwild.com.au/2009/03/29/vodcastvodcast/
385
      http://www.gianwild.com.au/2009/03/29/koorie-education-captioned-vodcast
386
      http://ncdae.org/tools/factsheets/captioning.cfm
387
      http://ncam.wgbh.org/webaccess/magpie/magpie_help/#captioning
388
      http://www.webaim.org/techniques/captions/magpie/version2/
389
      http://streaming.wisconsin.edu/accessibility/magpie_tutorial/quicktime.html
390
      http://joeclark.org/access/captioning/bpoc/
391
      http://hightech.redwoods.edu/accessibility/podcasting/
392
      http://webaxe.blogspot.com/2007/11/podcast-59-jeffrey-frey-on-accessible.html
393
      http://www.lancs.ac.uk/celt/celtweb/accessible_podcasts
394
      http://www.techdis.ac.uk/index.php?p=3_10_13_3
395
      http://jdfrey.wordpress.com/2006/11/02/podcast-captioning/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               203
Copyright State of Victoria, 2009
                       Victorian Government Accessibility Toolkit

Audio and podcasts

There will be people who won’t be able to access the audio file or podcast because:
 They are deaf
 They are in a noisy environment
 They cannot play sound
Audio files and podcasts cannot be made fully accessible, but they can be made accessible to
some people with disabilities – for example people who are hearing impaired or deaf – by
providing a transcript of the content in text or HTML:
 Providing a transcript of the podcast or audio file in text or HTML 396

                  Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects, sounds
(played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

                  Tools you will need to create a podcast
There are numerous methods to create a podcast – this document deals with only one of them.
You will need the following hardware and applications installed to create a podcast:
       Speakers
       Microphone
       Audacity 397
       LAME 398 (add the .dll to the Audacity folder)
       STAMP 399
       iTunes account (if you want to upload the podcast to iTunes)
       RSS feed URL

                  Complying with accessibility requirements when creating
                  podcasts
Creating the podcast
1. Open Audacity
2. Select the red round button to start recording the podcast
3. Select the stop button to stop recording the podcast
4. Under the file menu, select Export as MP3
5. Save the file



396
      See Videos document
397
      http://audacity.sourceforge.net/
398
      http://audacity.sourceforge.net/help/faq?s=install&item=lame-mp3
399
      http://www.mp3tag.de/en/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           204
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
Add tags to the podcast
1. Open Stamp and maximize the window
2. On the left hand side browse and select your podcast
1. Select Genre and type in the correct genre
2. Select the Stamp button

Upload podcast to a site
1. Copy the podcast to your web server
2. Add a link to the podcast

If your RSS feed is not already uploaded to iTunes:
1. Go to iTunes
2. Select iTunes store
3. Select “Submit a podcast”
4. Select Podcasts on the left hand side
5. Down the bottom right hand side of the page, select “Submit a podcast”
6. Insert your RSS URL
7. Select Continue
iTunes will review your podcasts before putting them on the iTunes site.

                  Example 1: A test podcast
See Gian Wild’s 400 web site for an example podcast and transcript.

                  Further Information
       Checkpoint 1.4: For any time-based multimedia presentation (e.g. a movie or animation),
        synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track)
        with the presentation
       How to create an accessible podcast 401
       WebAxe Podcasts: Jeffrey Frey on Accessible Podcasts 402
       Accessible podcasts 403
       Podcasting and accessibility 404




400
      http://www.gianwild.com.au/2009/03/29/podcastpodcast/
401
      http://hightech.redwoods.edu/accessibility/podcasting/
402
      http://webaxe.blogspot.com/2007/11/podcast-59-jeffrey-frey-on-accessible.html
403
      http://www.lancs.ac.uk/celt/celtweb/accessible_podcasts
404
      http://www.techdis.ac.uk/index.php?p=3_10_13_3


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               205
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Flash and accessibility

There will be people who won’t be able to access the Flash file because:
   They are hearing impaired or deaf;
   They are visually impaired or blind;
   They are using a slow modem;
   They do not have the required Flash player; and/or
   They have a physical disability which prevents them from using the Flash player.
Flash cannot be made fully accessible, but it can be made accessible to some people with
disabilities; for example people using screen readers. A Flash file is made accessible by:
   Creating the Flash in a particular way;
   Inserting the Flash file in the site a particular way; and
   Providing a transcript of the Flash file in text or HTML.

            Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects, sounds
(played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

            Complying with accessibility requirements when including Flash
Creating the Flash in a particular way
The Flash file needs to be created in a particular way, in order to make it accessible. Accessibility
needs to be considered both when creating the Flash file and when inserting the file into the web
site.

        When creating the Flash file
        Use FlashMX to develop the Flash file and ensure that:
           On the Flash Accessibility Panel:
                 o   “Make object accessible” is selected on all objects;
                 o   “Make child object accessible” is selected on all relevant child objects;
                 o   “Make child object accessible” is deselected for all child object animations;
                 o   “Make Movie accessible” is selected for all movies;
                 o   “Auto-label” is selected;
                 o   “Name” is completed on all objects; and
                 o   “Description” is completed on all objects that require additional information to
                     that provided in the “Name” field.
           The command enableAccessibility () has been used in relevant components, such as
            simple button, check box, radio button etc.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           206
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
            When creating the Flash file ensure:
                The object or movie is structured in a logical order;
                There are no patterned backgrounds;
                There is no flashing content;
                Information is not provided via colour alone;
                All movement can be stopped;
                Only high contrast colours have been used;
                The Flash file has a logical tab order;
                A zooming mechanism has been provided to increase the size of text;
                Any time limits can be increased;
                The Flash file is limited to 2MB or less 405 ;
                Allow users to control the Flash file (e.g. pause, rewind, etc.) via the keyboard only;
                Allow users to control the Flash file (e.g. pause, rewind, etc.) via the mouse only;
                Allow users to control the volume; and
                Captions have been provided for all audio and video content.

Inserting the Flash file in the site in a particular way
The Flash file needs to be inserted in the site in a particular way, in order to make it accessible.
Accessibility needs to be considered in how the user will access the Flash file. Website Flash
content should 406 :
                Never automatically start a Flash file;
                Allow the user to skip over the Flash file using the mouse only;
                Allow the user to skip over the Flash file using keyboard only; and
                Open in a new window;
Further when inserting Flash content into your website:
                Ensure the site is functional and all content is available without the Flash file; and
                Include information on how to download the Flash player.

Providing a transcript of the Flash file in text or HTML
It is important to provide a transcript of the Flash file. Where the user cannot access the Flash
file, it is vital a transcript is provided (in HTML, text or Word) so that they are not missing out on
the content within the Flash file.

                 Example 1: Transcript of a Flash file
Languages Online (by the Department of Education and Early Childhood Development) contains
a variety of language activities, including an Indonesian language activity 407 .




405
   For larger files, break them up into smaller downloads as well as offering the full Flash file, or create a low bandwidth
version of the content
406
      Please note these requirements do not apply to Flash banners
407
      http://www.education.vic.gov.au/languagesonline/indonesian/sect01/no_5/no_5.htm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                   207
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




In the example above, selecting one of the children will play an audio file is played pronouncing a
phrase. The aim of the exercise is to test whether a student has learnt the Indonesian phrase for
“Good morning” and other words, and reinforcing the pronunciation of the word.
A suitable, accessible alternative needs to be the equivalent of the activity, thus it needs to test
whether the student knows the Indonesian phrase for “Good morning” and other words and
provide the pronunciation. In this instance the accessible alternative might be similar to the
example below:
        Fill the gaps with one of the following phrases:
           Selamat pagi (pronounced sell-amat pag-e with a hard g)
           Selamat siang (sell-amat see-ang with a hard g)
           Sampai jumpa (pronounced sump-ay joomp-a)
           Selamat malam (pronounced sell-amat mull-um)
           Selamat sore (pronounced sell-amat sore-ee)
        It’s before 11am. Jill says ___________
        It’s between 11am and 3pm. Jerry says ___________
        It’s between 3pm and 6pm. Jackie says ___________
        It’s after 6pm. Jack says _____________
        John says ______________
        Answers
        It’s before 11am. Jill says selamat pagi (good morning)
        It’s between 11am and 3pm. Jerry says selamat siang (good [middle of the] day)
        It’s between 3pm and 6pm. Jackie says selamat sore (good [late] afternoon)
        It’s after 6pm. Jack says selamat malam (good evening / night)
        John says sampai jumpa (see you later)




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             208
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit


                  Further Information
       W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
       Accessible Flash Banner Guidelines 408
       WebAIM – Creating Accessible Macromedia Flash content 409
       Best Practices for Accessible Flash Design 410 (Adobe Reader required)
       Create accessible Flash content 411
       AccRepair for Flash 412




408
      http://www.rnib.org.uk/wacblog/flash/accessible-flash-banner-ad-guidelines/
409
      http://www.webaim.org/techniques/flash/
410
      http://www.adobe.com/resources/accessibility/best_practices/best_practices_acc_flash.pdf
411
      http://www.brainbell.com/tutorials/Flash/Basic_Tasks_Create_Accessible_Flash_Content.htm
412
      http://www.hisoftware.com/accrepair_flash/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           209
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Mashups and accessibility

There will be people who won’t be able to access the mashup because:
       They are hearing impaired or deaf;
       They are visually impaired or blind;
       They have a physical disability;
       They have a cognitive disability;
       They are using a slow modem;
       They do not have the required media player; and/or
       They have a physical disability which means they cannot use the media player.
It is difficult to categorically state that mashups are inaccessible; it really depends on the primary
applications and how they have been put together. The best way to ensure that mashups do not
exclude people with disabilities is to provide a transcript of the mashup in text or HTML.

                  Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects, sounds
(played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

                  Complying with accessibility requirements when including
                  mashups
Providing a transcript of the mashup in text or HTML
It is important to provide a transcript of the mashup. Where the user cannot access the mashup, it
is vital that a transcript is provided (in HTML, text or Word) so that they are not missing out on the
content within the mashup.

                  Example 1: Transcript of a mashup
Google Maps created a mashup of the Victorian bushfires 413 in February 2009. This mashup was
updated with fundraising events in the months after Black Saturday.




413
      http://www.google.com.au/landing/victorianbushfires/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             210
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




The mashup has some accessibility features – for example, it can be manipulated via the
keyboard. However, the mashup might be inaccessible to some groups of people with disabilities
and thus a transcript must be provided. For example:
        A screen reader user might be able to listen to the text of the map, but cannot determine
         how far the Bushfire Concert is from Melbourne (or in what direction).
        People using a magnifier might not be able to access some of the information on the
         page, for instance, the text in the popup.
        Some of the activities (for example the ‘Long Beach Outreach – Australian Bushfire
         Appeal’) occur at an international location, which might not be obvious to someone using
         a screen reader or who cannot see the map.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         211
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
The following transcript might be appropriate for this mashup.


        Victorian concerts
        Comeback Concert
        4 April, 12:00pm - 10:00pm
        Whittlesea Showgrounds, Whittlesea
        A country music bushfire benefit concert. All proceeds to go to the Bushfire Appeal Fund
        to assist bushfire affected people, not only from Whittlesea's surrounds but from all over
        Victoria. The Concert will feature: Adam Brand, Catherine Britt, Travis Sinclair, Noll
        Brothers, Sam Hawksley, JR Williams, Paul Costa, Celestino, Andre Camilleri & the
        Broken Hearts, White Goat, The Prairie Oysters, Smokin’ Mahones, Mike Brady, and The
        Aaron Daniels Band. Tickets through Eventix and limited gate sales on the day. Adults
        $40. Kids 15 and under free. Free admission for fire survivors (on presentation of Blue
        D.H.S. form). For online ticket sales visit: www.whittleseacountrymusicfestival.com.au tel:
        (03) 9716 1923


        Bushfire Concert
        4 April 12:00pm
        Healesville Racecourse, Healesville
        14 live bands and solo artists including Brent Parlane, The Hannafords, Geoff Achison
        and more. ALL proceeds to the appeal.


        Milawa Muster
        5 April 2:00pm—9:00pm
        Milawa Recreation Reserve, Milawa
        From 2pm - 9pm 10 music artists will be playing. Australia's whip cracking champion Noel
        Cutler to compare (Noel will also be displaying his whip cracking and poetry talents
        throughout the event!). Other entertainment includes Mel Sporry's liberty horse displays,
        sheaf tossing, jumping castle, face painting. Food and bar available on the day. $15 entry
        (under 12 free) includes bus from Wangaratta return.


        Apollo Bay Charity Ball
        18 April 6:30pm—6:30pm
        Leisure Centre, Apollo Bay
        Bushfire Fundraiser 'Hollywood Ball' All funds raised to go to Red Cross. Saturday 18
        April 2009 7pm to late Apollo Bay Leisure Centre Tickets at Great Ocean Properties
        52377 366


        International concerts
        Long Beach Outreach - Australian Bushfire Appeal
        12 Apr 9:00am—11:00am
        Long Beach City Beach, California, USA



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          212
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        5km fun run/walk hosted in Long Beach California by the local Australian international
        student community. Starting at Grenada Boat ramp, running west along the city beach
        bike path.


        From the Ashes Cricket Match
        31 May 12:00pm—6:00pm
        Christiano Field, Greenwich, Connecticut, USA
        The Mad Dogs Cricket Club will be hosting a "From the Ashes" cricket match on May 31st
        in honor of and to raise funds for those affected by the Victorian Bushfires.

            Example 2: Doodle for Google Australia
Google had an Australia-wide competition for primary and secondary schools to recreate the
Google logo. A mashup of the entries has been created by Google:




To create an accessible version of this mashup, the search function could be replicated in an
accessible manner by:
       including search labels;
       associating the labels with the fields; and
       providing an HTML submit button.
In the Google mashup, once the user has selected a relevant school, the doodles are shown in
the map:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           213
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit




In the above example, users can view the eight different entries from Mt Beauty Primary School in
the map. This mashup can be made easily accessible through both HTML and images by:
           Organizing the images by name of the school and the name of the student (including year
            level); and
           Providing a brief description of the image in the ALT attribute (i.e. in the above example
            the ALT attribute would be “Emu, kangaroo and tree used in Google logo, with aboriginal
            symbolism, with a background of the setting sun”)

                 Further Information
      W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
      Mashup Awards 414
      eGovernment Resource Centre mashups 415
      IBM Web 2.0 mashup accessibility 416
      IBM The future is now 417




414
      http://mashupawards.com/winners/
415
      http://www.egov.vic.gov.au/index.php?env=-categories:m2649-1-1-8-s-0
416
      http://www-03.ibm.com/able/resources/mashup.html
417
      http://www-03.ibm.com/able/news/webmashup.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             214
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Blogging and accessibility

Blogging is often just text or a combination of text, images and links. Therefore it is easy to make
a blog accessible. However a blog has all the same potential accessibility issues as a web site
does. Consequently blogs should always be tested against the W3C Web Content Accessibility
Guidelines, Version 1.0, Level AA.

                  Relationship to WCAG1 checkpoints:
Checkpoint 3.5 requires that header elements are used to convey document structure and that
they are used according to specification.
Checkpoint 10.2 requires that all form controls with implicitly associated labels, that the label is
properly positioned.
Checkpoint 12.4 requires that labels are explicitly associated with their controls.
Checkpoint 13.1 requires that the target of each link is clearly identified.

                  Complying with accessibility requirements when creating blogs

Headings
Make sure that the blog post is a heading, and that each blog post heading is at the same level. If
you use headings within blog posts then make sure all headings are nested properly. The name
of the blog should be an H1.

Field labels
Where users can add comments, ensure that each field has a descriptive field label that is
immediately to the left or immediately above the relevant field.
Ensure that these fields and field labels are coded using the FOR ID and LABEL elements.

Links
Most blog posts contain links to the comments section. It is imperative that these links are unique.
So, for example, if there are a number of comments on a particular blog post then the link should
include the number of comments and the name of blog post. For example “34 comments on
Writing accessible blog posts”.

                  Example 1: Gian Wild’s blog
Gian Wild’s blog 418

                  Further Information
       Bruce Lawson Wordpress Accessibility Hacks 419
       Wordpress 2.6 Accessibility Features 420
       Accessites: Wordpress and accessibility 421


418
      http://www.gianwild.com.au/
419
      http://www.brucelawson.co.uk/2005/wordpress-accessibility-hacks/
420
      http://www.marcozehe.de/2008/07/16/wordpress-26-brings-a-lot-of-accessibility-improvements/
421
      http://accessites.org/site/2008/11/wordpress-and-accessibility/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              215
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit
       Wordpress embraces ARIA 422
       A brief introduction to WordPress and Web Accessibility 423
       ATAG assessment of WordPress by Joe Clark 424




422
      http://www.marcozehe.de/2008/07/16/wordpress-26-brings-a-lot-of-accessibility-improvements/
423
      http://www.youthtopia.net/acontent/wpaccess.htm
424
      http://joeclark.org/access/webaccess/WordPress-ATAG-evaluation.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              216
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Making maps and Google maps accessible

Online maps are inaccessible to vision impaired people so a textual alternative (long description)
must always be provided. It is also important to include accessibility features within the map so it
is accessible to people with other disabilities e.g. by making the map non-reliant on JavaScript
and keyboard accessible. Maps can be made accessible by:
   providing a long description of the map in text or HTML;
   making the map keyboard accessible;
   making an HTML version of any JavaScript features of the map;
   using only high contrast colours;
   not relying on colour to differentiate important parts of the map; and
   allowing users to increase the size of the map, legend and any text.
Note that there will be people who won’t be able to access the map because:
   they are blind;
   they have a text only browser; and/or
   they have a slow internet connection.


            Relationship to checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided 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.


            What about Google maps?
Google maps have a number of features that improve the accessibility of their maps; notably, you
can easily create non-JavaScript, keyboard accessible versions of any Google map. To create a
keyboard accessible map, start a map search by loading the URL
http://maps.google.com/?output=html and entering a search term. When the HTML result is
loaded, paste the page URL in to your site as an alternative to the standard Google map
interface.
            Complying with accessibility requirements when creating maps
Providing a long description of the map in text or HTML
When providing a long description of a map it is important to think of the function of the map. For
example, a long description of a map of Collins St will be different depending on the purpose of
the map. A map displaying the carparks in Collins St, will have a vastly different long description
to a map that displays the location of the Department of Treasury and Finance. While the two
maps may look similar, the long descriptions will be completely different.


When writing a long description consider the following:
   Describe only those aspects of the map that are relevant, first e.g. the most important point or
    the most common feature of the map. The following example is a long description of bushfire
    affected areas in Victoria:


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           217
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

       Uncontained bushfires are still burning in Wilson's Promontory (23,250 hectares). Contained
       bushfires are still burning in Churchill, Gippsland (32,000 hectares) and Marysville (330,600
       hectares). The total amount of land burnt in the February 9th, 2009 bushfires is 450,000
       hectares.
      Describe the distance (in kilometres or metres) from important points.


       Monash Clayton campus is 40 kilometres east of the Melbourne CBD.


      If the map will be used for transport, give directions for car, public transport and/or walking .
       The following example is a long description of how to get to the Department for Innovation,
       Industry and Regional Development from Flinders St station.


       Catch a tram North along Swanston St for one stop. Cross the road, so that you are on the
       North-East most side. Catch a tram four stops East along Collins St. Nauru House is directly
       North of the tram stop. Walk between the two buildings for fifty metres until you come to a
       revolving door. The lifts are on your left. Department of Innovation, Industry and Regional
       Development is on Level 20.


      If the map is time-sensitive, mark the times in the long description. The following is an
       example of a long description for the Melbourne Rain Radar map 425 :


       4.25pm Storm (strong) approaching east over Williamstown, eight kilometres in diameter.
       Light rain over Melbourne city, four kilometres in diameter.
       4.40pm Storm (strong) ten kilometres west of Melbourne city. Light rain over Clayton, four
       kilometres in diameter.
       4.55pm Storm (strong) over Melbourne city, eight kilometres in diameter. Rain (strong) over
       Richmond.
       5.10pm Storm (extreme) over inner city East Melbourne, ten kilometres ,in diameter.


      If the map is a topographical map, mark the height at which important points occur. The
       following is a long description for a hiker's map of the Purlingbrook Falls map:


       The waterfall is 109 metres tall. The track starts at the top and descends to the bottom of the
       waterfall before crossing behind the base of the waterfall and ascending back to the top. The
       track is a steep zig zagging track, descending about 40cm for every horizontal metre.


      If the map is a transport map, organise the map by train, bus or train line and describe the
       locations and distances travelled.




425
      http://www.bom.gov.au/products/IDR023.shtml


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                218
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
    Train line: City Loop
    The City Loop consists of four train stations set in a roughly square formation around
    Melbourne city: Flinders St station, Southern Cross station (formerly Spencer St station),
    Flagstaff station and Parliament station. Flinders St station is situated on the corner of
    Flinders St and Swanston St. Spencer St station is situated on the corner of Bourke and
    Collins Sts and Spencer St. Flagstaff is situated on the corner of La Trobe and King Streets.
    Parliament is situated off Collins St with entrances on Collins, Spring, Lonsdale, Nicholson
    and MacArthur Streets. During morning peak hour, trains run from Parliament to Flagstaff to
    Southern Cross and terminating at Flinders St. During afternoon peak hour trains run in the
    opposite direction.



Making the map keyboard accessible
Often maps rely upon distinct mouse movements or clicks to select an area, move to another
area or to zoom. These movements can, and should, be made available with the keyboard so that
users are not entirely reliant on mouse actions. For example, users should be able to use only the
keyboard to:
   move the map left, right, up or down;
   select different areas of the map; and
   zoom in or out on the top left, top right, centre, bottom left or bottom right quadrant.

Making an HTML version of any JavaScript features of the map
Often maps use JavaScript to provide enhanced features e.g. smooth, animated zooming. Maps
that use JavaScript-based features should always have an HTML fallback that allows users to.
   move the map left, right, up or down using HTML only;
   select different areas of the map using HTML only; and
   zoom in or out on the top left, top right, centre, bottom left or bottom right quadrant using
    HTML only.

Using only high contrast colours
Ensure that your map design complies with the 4.5:1 colour contrast ratio..

Not relying on colour to differentiate important parts of the map
Ensure that your maps use:
   borders to separate one area from another;
   different types of shading and change of colour to indicate different areas;
   label markers with an ASCII character and individual colours for different markers; and
   client-side image maps and accurate ALT attributes to indicate areas of a map or important
    markers.

Allowing users to increase the size of the map, legend and any text
To make maps accessible to some groups of people with vision impairments, it is important to
allow users to not only to zoom in on areas of the map, but to increase the size of the map,
legend and text. Often maps do not respond to browser requests to increase size, therefore
additional methods may be required to:



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              219
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit
       provide a “large” version of the map, where the user has increased the normal text size by
        200%; and
       maximize a particular point/area, or add a highlight box that shows the particular point/area in
        a larger size.


                   Example 1: An accessible bushfires map
The Department of Sustainability and Environment has developed a map of current bushfires
across the state of Victoria. This information is replicated via a text alternative in the table below
the map. See DSE- Fires Today - Summary of incidents on Public Land 426


                   Example 2: An accessible Google map
Well-known accessibility specialist, Derek Featherstone has set up a blog to track his marathons.
The blog contains maps that a keyboard accessible, usable with HTML only and without relying
on colour to convey information. He has also created other accessible features, such as average
heart rate details for heart rate graphs. See IronFeathers 427 .


                   Further Information
       Google maps 428
       Speech friendly textual directions from Google maps 429
       Opera – Keyboard accessible Google maps 430
       Can you really have an accessible Google map? 431
       Google Static Maps API 432
       Google Static map wizard 433




426

http://www.dse.vic.gov.au/DSE/nrenfoe.nsf/LinkView/519C51D981DAE41FCA257257000A5163DC25C965BDA0CAF5CA
2573B400013504
427
      http://ironfeathers.ca/
428
      http://maps.google.com
429
      http://googleblog.blogspot.com/2006/12/speech-friendly-textual-directions.html
430
      http://dev.opera.com/articles/view/keyboard-accessible-google-maps/
431
      http://blogs.cetis.ac.uk/accessibility/2007/01/29/can-you-really-have-an-accessible-google-map/
432
      http://code.google.com/apis/maps/documentation/staticmaps/
433
      http://gmaps-samples.googlecode.com/svn/trunk/simplewizard/makestaticmap.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                  220
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Frames and iFrames

According to the Web Content Accessibility Guidelines (WCAG), Version 1.0, frames are
inaccessible and any information contained within a frame must be provided elsewhere
(Checkpoint 1.1). Some assistive technologies do now interact with frames and iframes, however
it is still important to provide equivalent, accessible content where they are used.


The use of standard frames is now quite uncommon and not recommended practice. iFrames
are more common but still require strong consideration of their benefit against the issues they
raise with accessibility and website usability. Some of the issues raised by iFrames are that they:
   break the Back button;
   don’t allow users to bookmark pages; and they
   make printing website content difficult for users.


Therefore if you use frames or iFrames you must provide equivalent, accessible content in HTML
or text.

            Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: frames.
Checkpoint 6.5 requires that dynamic content is accessible or that provide an alternative
presentation or page is provided (eg. NOFRAMES for FRAME element)
Checkpoint 12.2 requires that the purpose of frames and how frames relate to each other is
described if it is not obvious by frame titles alone.

            What are iFrames?
An iFrame (also known as an inline frame) places one HTML document in a frame inside a
normal (rather than frameset) HTML document. iFrames can also be used as the “target” of a link,
in which case only the iFrame is opened. Alternative text is provided within the <IFRAME> tag
set, for example:
         <iframe src ="html_intro.asp" width="100%"
         height="300">Alternative text</iframe>

Note: the iFrame element is not supported in HTML 4.1 Strict DTD and in XHTML 1.0 Strict DTD.

            Creating accessible iFrames
Provide an equivalent
It is important to provide an equivalent of the content within the FRAME or IFRAME.
   The equivalent content for a FRAME should sit within the <NOFRAMES> tag:
        <FRAMESET title="Web site">
              <FRAME src="nav.html" title="Navigation">
              <FRAME src="contents.html" title="Contents of page">
              <NOFRAMES>


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             221
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                           Equivalent content
                    </NOFRAMES>
             </FRAMESET>
       The equivalent content for an IFRAME should sit within the <IFRAME> tag:
             <IFRAME src ="html_intro.asp" width="100%" height="300">
             Equivalent information
             </IFRAME>

Use relative sizing
It is important that when users increase the browser text size that the iFrame element scales with
the size of the text. This can be done using the default IFRAME SCROLLING attribute: auto.

Links within the iFrames should open in a new window
Links clicked within the iFrame will open within the iFrame element, therefore it is important to
ensure all iFrame content links are set to open in a new browser window. This can be achieved
by using the HTML TARGET=”_blank” attribute and value. For example:
         <A HREF=”http://www.vic.gov.au/” TARGET=”_blank”>Link</A>

            Example 1: Accessible iFrame
This accessible iFrame 434 resizes with text resize, opens links in new windows and offers a
complete equivalent for users without iFrames.
 http://www.cs.tut.fi/~jkorpela/indexen.html

                  Further Information
       About iFrames 435
       WebAIM accessible frames 436




434
      http://www.cs.tut.fi/~jkorpela/indexen.html
435
      http://www.web-wise-wizard.com/html-tutorials/html-inline-floating-frames.html
436
      http://www.webaim.org/techniques/frames/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          222
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Making Slideshare accessible

There will be people who won’t be able to access a powerpoint or open office presentation
because:
   They are blind
   They have a text only browser
   They are using a keyboard only
Slideshare is a presentation sharing website where users can upload, view and share
presentations. Presentations can be tagged and commented. It is also possible to embed
presentations into a web site or download the presentation. Presentations can be shared publicly
or privately.
Slideshare uses a combination of technologies which make it inaccessible; however there is an
accessible version of Slideshare that can be used instead. Slideshare can be made accessible
by:
   Providing an alternative of the presentation in HTML, text or Word; and
   Providing a link to Easy Slideshare (accessible Slideshare)

             Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects, sounds
(played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Checkpoint 6.3 requires 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

             Can Slideshare presentations be embedded in a site?
Slideshare presentations can be embedded into a web site, as the content is ignored by the
keyboard and screen readers. However an alternative must always be provided, both via Easy
Slideshare and an HTML, text or Word version.

             Creating accessible Slideshare presentations

Provide a link to Easy Slideshare
A link should be provided to both the Slideshare presentation and a link to an accessible version
of the Slideshare presentation by preceding the Slideshare URL with “http://icant.co.uk/easy-
slideshare/?slides=”
Therefore a slideshare presentation with the following URL:
        http://www.slideshare.net/cheilmann/purple-hack-fodder
Would have an Easy Slideshare URL of:
        http://icant.co.uk/easy-slideshare/?slides=http://www.slideshare.net/cheilmann/purple-
        hack-fodder

Providing a transcript of the Slideshare presentation in text or HTML
It is important to provide a transcript of the presentation.



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            223
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
       Include an transcript (HTML, text or Word) to all videos
        Creating HTML from a PowerPoint presentation
            Install the PowerPoint accessibility wizard 437 .
            Make sure all content is available in the outline view (content not visible in the outline
             view will not be converted to HTML)
            Avoid graphics where possible (if you have to use graphics make sure you add a text
             description during the accessibility wizard)
            Once the wizard is installed select "Save as accessible web page" from under the "File"
             menu to create the HTML version.

                  Example 1: Embedded Slideshare
Victoria Online: quality, Reliability and Trusts 438 is an embedded Slideshare presentation. It also
includes an HTML version and a link to the Easy Slideshare version.

                  Further Information
       Easy Slideshare 439
       PowerPoint Accessibility Wizard 440




437
      http://its.monash.edu/web/slideshows/accessibility-powerpoint/OETFull-en.exe
438
   http://www.egov.vic.gov.au/victorian-government-resources/victoria-online/victoria-online-quality-reliability-and-
trust.html
439
      http://icant.co.uk/easy-slideshare/about/
440
      http://its.monash.edu/web/slideshows/accessibility-powerpoint/OETFull-en.exe


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                                  224
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Facebook and accessibility

There will be people who won’t be able to access Facebook because:
       They have a text only browser
       They have a physical disability
       They are using a keyboard only
Facebook is a social networking site where users can keep in touch with their friends, post photos
and videos and play games.
Facebook uses a combination of technologies which make it inaccessible; however there is an
HTML version of Facebook (http://m.facebook.com/) which can be used by screen reader users.
However, Facebook is not accessible to other groups of people with disabilities. Therefore
Facebook can be made accessible by:
       Providing an alternative of the content in HTML, text or Word

                  Creating accessible Facebook

Providing a transcript of the Facebook content in text, Word or HTML
It is important to provide a transcript of the Facebook content on your site, for people who cannot
use the Facebook interface or do not have a Facebook account.

                  Example 1: Target 155
Save Water, Target 155 441 is a Facebook site. Information on the Facebook site is replicated on
the Our Water web site 442 .

                  Further Information
       Text only Facebook 443
       Facebook accessibility page 444




441
      http://www.facebook.com/group.php?sid=0b7d130e33debf7482bedeaf4e8ce04d&gid=42157958877&ref=search
442
      http://www.ourwater.vic.gov.au/target155
443
      http://m.facebook.com/home.php?r0467bae4&h4ed6449e&refid=8
444
      http://www.facebook.com/help.php?page=440


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    225
Copyright State of Victoria, 2009
                      Victorian Government Accessibility Toolkit

Twitter and accessibility

There will be people who won’t be able to access Twitter because:
       They are blind
       They have a text only browser
       They are using a keyboard only
Twitter is a social networking and microblogging site where users can tell their friends
(“followers”) what they are currently doing in 140 characters or less.
Twitter uses a combination of technologies which make it inaccessible; however there is an
accessible version of Twitter that can be used instead. Twitter can be made accessible by:
       Providing an alternative of the content in HTML, text or Word; and
       Providing a link to Accessible Twitter

                  Creating accessible Twitter

Providing a transcript of the Twitter content in text, Word or HTML
It is important to provide a transcript of the Twitter content on your site, for people who cannot
use the Twitter interface or do not have a Twitter account. If time is an issue then consider
sending out SMSes at the same time as you send out a tweet.

Provide a link to Accessible Twitter
A link should be provided to the Accessible Twitter interface for people who have trouble with the
standard Twitter interface. The link is:
             http://accessibletwitter.com/

                  Example 1: John Brumby
John Brumby 445 has a Twitter site. Tweets are replicated on the Premier web site 446 .

                  Further Information
       Accessible Twitter 447
       About Accessible Twitter 448




445
      http://twitter.com/vicpremier
446
      http://www.premier.vic.gov.au/
447
      http://accessibletwitter.com/
448
      http://accessibletwitter.com/about.php


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               226
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit


Section Six: Accessibility evaluation
tools
When testing large sites, automated testing tools are invaluable. However, while these tools can
highlight some common errors e.g. missing tags and attributes, they cannot test all accessibility
requirements. Consequently, these tools should be used as an aid to manual testing and not a
substitute.

For more information on the tools mentioned in this section see the W3C Evaluation, Repair, and
Transformation Tools for Web Content Accessibility 449

In addition to the overview below, detailed information is available for:
 AccVerify;
 Cynthia Says;
 Firefox Web Developer Toolbar;
 WAVE; and
 Web Accessibility Toolbar.


Page-by-page accessibility evaluation tools

            Cynthia Says
            http://www.cynthiasays.com/

            What is Cynthia Says?
            Cynthia Says is an online page-by-page accessibility evaluator that tests many of the
            W3C Web Content Accessibility Guidelines (WCAG). AccVerify is an equivalent
            downloadable, site-wide accessibility evaluator.

            How do you use Cynthia Says?
            Test one web page at a time on the Cynthia Says 450 site.

            How do you interpret Cynthia Says reports?
            Cynthia Says provides a report ordered by WCAG checkpoint.

            Which pages do you test with Cynthia Says?
            All web pages within your website.

            Are there any pitfalls with Cynthia Says?
            Cynthia Says cannot test some WCAG checkpoints and only partially check others i.e.
            checkpoint 14.1.

            For more information see the Cynthia Says example.

            WAVE
            http://wave.webaim.org/index.jsp

            What is WAVE?


449
      http://www.w3.org/WAI/ER/existingtools.html
450
      http://www.cynthiasays.com


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              227
Copyright State of Victoria, 2009
                       Victorian Government Accessibility Toolkit
             The WAVE is a page-by-page accessibility evaluator that tests many of the W3C Web
             Content Accessibility Guidelines.

             How do you use WAVE?
             Test one web page at a time on the WAVE 451 site. Alternatively you can install a WAVE
             toolbar or bookmarklet.

             How do you interpret WAVE reports?
             The WAVE provides a screenshot of the tested web page with icons and highlighting to
             represent accessibility errors and features.

             Which pages do you test with WAVE?
             All web pages within your website.

             Are there any pitfalls with WAVE?
             The WAVE cannot test some WCAG checkpoints and only partially check others i.e.
             checkpoint 7.1.

             For more information see the WAVE example.

             Functional Accessibility Evaluator (FAE)
             http://fae.cita.uiuc.edu/

             What is FAE?
             FAE is an online page-by-page accessibility evaluator. It tests against both the W3C Web
             Content Accessibility Guidelines and Section 508 (the US standard for accessibility
             compliance).

             How do you use FAE?
             Test one web page at a time on the FAE 452 website or create a user account and test
             multiple web pages (to a maximum of three levels deep).

             How do you interpret FAE reports?
             FAE categorises errors into five categories: Navigation & Orientation, Text Equivalents,
             Scripting, Styling and HTML Standards. Particular errors are detailed in each section.

             Which pages do you test with FAE?
             All web pages within your website.

             Are there any pitfalls with FAE?
             The relationship between some errors and particular W3C Web Content Accessibility
             Guidelines is unclear. FAE cannot test some WCAG checkpoints at all, such as clear and
             simple content.

             AChecker / ATRC Web Accessibility Checker
             http://www.achecker.ca/checker/index.php

             What is AChecker?
             AChecker is an online page-by-page accessibility evaluator, previously called A-Prompt.
             It tests many of the W3C Web Content Accessibility Guidelines.

             How do you use AChecker?


451
      http://wave.webaim.org
452
      http://fae.cita.uiuc.edu/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              228
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Test one web page at a time on the AChecker 453 website.

             How do you iinterpret AChecker reports?
             The AChecker categorises errors into seven categories: forms, headers, images, links,
             metadata, tables and text. Particular errors are detailed in each section.

             Which pages do you test with the AChecker?
             All web pages within your website.

             Are there any pitfalls with the AChecker?
             The AChecker cannot test some WCAG checkpoints.

             HERA
             http://www.sidar.org/hera/index.php.en

             What is HERA?
             HERA is an online page-by-page accessibility evaluator. It tests many of the W3C Web
             Content Accessibility Guidelines.

             How do you use HERA?
             Test one web page at a time on the HERA 454 website.

             How do you interpret HERA reports?
             HERA categorises errors by WCAG checkpoint.

             Which pages do you test with HERA?
             All web pages within your website.

             Are there any pitfalls with HERA?
             HERA cannot test some WCAG checkpoints, however it does give clear guidance on the
             manual testing required to meet these checkpoints.

             Web Accessibility Toolbar
             http://www.visionaustralia.org/info.aspx?page=614

             What is the Web Accessibility Toolbar?
             Developed by Vision Australia, the Web Accessibility Toolbar provides a variety of
             features that assists in testing a website. It can aid in testing many of the W3C Web
             Content Accessibility Guidelines.

             How do you use the Web Accessibility Toolbar?
             The Web Accessibility Toolbar can be installed on Windows Internet Explorer 5 or above
             or Opera.

             How do you interpret the Web Accessibility Toolbar outputs?
             The Web Accessibility Toolbar has a variety of functions which require different
             interpretations. For more information see the Web Accessibility Toolbar example on page
             261.

             Which pages do you test with the Web Accessibility Toolbar?
             All pages.



453
      http://www.achecker.ca/checker/index.php
454
      http://www.sidar.org/hera/index.php.en


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               229
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Are there any pitfalls with the Web Accessibility Toolbar?
        Each web page must be tested individually. The Web Accessibility Toolbar cannot test all
        WCAG checkpoints and is restricted to Windows Internet Explorer and Opera.

        For more information see the Web Accessibility Toolkit example.

        Firefox Web Developer Toolbar
        http://chrispederick.com/work/webdeveloper/

        What is the Web Developer Toolbar?
        The Web Developer Toolbar provides a variety of features to assist in testing a site for
        accessibility, including testing against many of the W3C Web Content Accessibility
        Guidelines.

        How do you use the Web Developer Toolbar?
        Install the Web Developer Toolbar on a Firefox, Flock, Mozilla or SeaMonkey browser.

        How do you interpret the Web Developer Toolbar outputs?
        The Web Developer Toolbar has a variety of functions which require different
        interpretations. For example, when disabling style sheets the tester needs to determine
        whether the site can be used.

        Which pages do you test with the Web Developer Toolbar?
        All web pages within your website.

        Are there any pitfalls with the Web Developer Toolbar?
        Each page must be tested individually. The Firefox Web Developer Toolbar cannot test
        all WCAG checkpoints and is restricted to Firefox and similar browsers.

        For more information see the Firefox Web Developer Toolbar example


Specific accessibility evaluation tools

        W3C HTML Validator
        http://validator.w3.org/

        What is the W3C HTML Validator?
        The HTML Validator is an application for testing conformance with HTML standards.
        Specifically, it tests for compliance with Level AA checkpoint 3.2: “Create documents that
        validate to published formal grammars”, however it will pick up other accessibility errors
        such as missing ALT attributes and invalid field labels.

        How do you use the W3C HTML Validator?
        Test one web page at a time on the HTML validator site.

        Which pages do you test with the W3C HTML Validator?
        All web pages within your website.

        How do you interpret a report from the W3C HTML Validator?
        The reports should be interpreted by – and will make most sense to – a person with
        HTML experience.

        Are there any pitfalls with the W3C HTML Validator?




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         230
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        If the formal grammar (DOCTYPE) is not specified (as required by Level AA W3C
        Accessibility Guidelines) the HTML Validator will not validate correctly. The DOCTYPE is
        the type of code used by the page.

        For more information see the section on HTML validation

        W3C CSS Validator
        http://jigsaw.w3.org/css-validator/

        What is the W3C CSS Validator?
        The CSS Validator tests cascading style sheets (CSS) to ensure they conform with CSS
        standards. Specifically, it tests for compliance with Level AA Checkpoint 3.2: “Create
        documents that validate to published formal grammars”.

        How do you use the W3C CSS Validator?
        Test one style sheet at a time, or one web page with embedded styles, on the CSS
        Validator site.

        Which pages do you test using the W3C CSS Validator?
        A variety of web pages from your website that utilise different style sheets.

        How do you interpret the W3C CSS Validator report?
        The reports should be interpreted by – and will make most sense to – someone with CSS
        experience.

        Are there any pitfalls to using the W3C CSS Validator?
        If the CSS version is not specified it may not validate correctly.

        For more information see the section on CSS validation.

        JuicyStudio Colour Contrast Analyser
        For more information see the section on Colour Contrast.

        JuicyStudio Readability Test
        http://juicystudio.com/services/readability.php

        What is the JuicyStudio Readability Test?
        This tool tests web pages against the various reading level algorithms i.e.
        Gunning Fog index, Flesch Reading Ease and the Flesch-Kincaid reading grade level.
        Specifically, it tests for compliance with Level A Checkpoint 14.1: “Ensure language is
        clear and simple”.

        How do you use the JuicyStudio Readability Test?
        Test one web page at a time on the Juicy Studio Readability Test page.

        Which pages do you test with the JuicyStudio Readability Test?
        All web pages within your website.

        How do you interpret the JuicyStudio Readability Test?
        The test provides a table of values, such as number of words, sentences, paragraphs etc.
        The table also provides the web page’s Gunning Fog index, the Flesch Reading Ease
        and the Flesch-Kincaid reading grade level.

        Are there any pitfalls with the JuicyStudio Readability Test?
        The test cannot differentiate where on the web page the text sits and whether the
        placement affects readability.

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                        231
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

        Vischeck
        http://vischeck.com/vischeck/vischeckURL.php

        What is Vischeck?
        Vischeck displays pages as they would look to someone with common colour disorders.
        Specifically, it tests for compliance with Level AA Checkpoint 2.2: “Ensure that
        foreground and background colour combinations provide sufficient contrast when viewed
        by someone having colour deficits or when viewed on a black and white screen”.

        How do you use Vischeck?
        You can run Vischeck on individual images or an entire web page on the Vischeck site.
        Alternatively you can download a Photoshop filter that manipulates an image to what
        people with certain types of colour blindness would see.

        Which pages do you test with Vischeck?
        Test each web page that is different in colour contrast.

        How do you interpret Vischeck?
        If, after filtering a web page, you can still read the website navigation and text, the colour
        use is satisfactory.

        Are there any pitfalls with Vischeck?
        Vischeck has difficulties testing pages with CSS, Flash and frames.




Entire site accessibility evaluation tools

        AccVerify
        http://www.hisoftware.com/products/accverify.html

        What is AccVerify?
        AccVerify is a site-wide accessibility evaluator that tests many of the W3C Web Content
        Accessibility Guidelines. The equivalent online page-by-page accessibility evaluator is
        CynthiaSays.

        How do you use AccVerify?
        For more information see the AccVerify example on page 233.

        How do you interpret AccVerify reports?
        AccVerify categorises errors by WCAG checkpoint.

        Which pages do you test with AccVerify?
        All web pages within your website.

        Are there any pitfalls with AccVerify?
        AccVerify cannot test some WCAG checkpoints and only partially check others i.e.
        checkpoint 7.1.

        For more information see the AccVerify example.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             232
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

AccVerify

Type: Whole site
Access: Download application
Rating: Excellent
Cost: Contact for current pricing, however standard desktop pricing is $US995 + $US199 per year
(maintenance)
Company: HiSoftware
URL: http://www.hisoftware.com/products/accverify.html

AccVerify is the downloadable version of Cynthia Says, with additional features such as the ability
to disable/enable particular checks. AccVerify reports detail guideline violations and warnings
ordered by the W3C Checklist. It can test certain issues with a very high degree of accuracy, for
example whether an IMG tag contains an ALT attribute. However there are some issues where
AccVerify cannot make an accurate assessment, for example in determining whether content is
clear and simple.

 Pros                                              Cons

 Can test Section 508, Level A, Level AA or        Cannot test some checkpoints
 Level AAA
 Includes a separate Alternative Text quality
 report
 Contains specific information on errors
 Can create specific reports
 Can also purchase AccRepair to assist in
 fixing accessibility errors

        How to use AccVerify

        Create project
        1. Create a new project by selecting the “New” button (1) in the bottom left corner.
        2. Name the project and choose how you will access your files.
        3. Select the Base folder and Save the project.
        4. Select the “Select” button (2) in the top left corner and choose the files you wish to
           test. To choose relevant accessibility checks select the “AccRules” button (3).
        5. Select the “Verify” button (4) to run AccVerify.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          233
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        View summary
        Once the report is completed a summary will be displayed. The summary includes a table
        of contents (1) where you can access information on the specific files, information about
        when AccVerify was run (2), including date, time and total files passed and total files
        failed. In addition the total files passed and total files failed are displayed via a graph (3).




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              234
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        View individual files
        To look at the results of individual files, select the relevant file under “Passed files” or
        “Failed files” (1). This report is an exact replica of a Cynthia Says report with information
        about the report itself (2) and the table of results (3).




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            235
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             For an example see the Cynthia Says example 455 .

             Further Information
             AccVerify has comprehensive in-product help.

             Information on AccVerify
                 AccVerify and AccRepair overview 456
                 Request trial version 457

             Using AccVerify
                 The Table Repair Utility 458
                 The Form Repair Utility 459
                 Custom checks 460
                 Chart of HiSoftware Remediation functionality 461


455
      Link to Cynthia Says example
456
      http://www.hisoftware.com/products/CS_Accessibility.html
457
      http://www.hisoftware.com/access/registration.htm
458
      http://www.hisoftware.com/access/tabutil.html
459
      http://www.hisoftware.com/access/formutil.html
460
      http://www.hisoftware.com/customchks/index.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   236
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 AccVerify Interaction Builder 462
                 AccVerify Add-ins 463




461
      http://www.hisoftware.com/access/whatwedow.html
462
      http://www.hisoftware.com/access/functionaltest.html
463
      http://www.hisoftware.com/access/valueadd.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   237
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Cynthia Says

Type: Page by page
Access: Online form
Cost: Free
Company: HiSoftware
URL: http://www.cynthiasays.com

Cynthia Says details guideline violations and warnings ordered by the W3C Checklist. Cynthia
Says can test certain issues with a very high degree of accuracy, for example whether an IMG
tag contains an ALT attribute. However there are some issues where Cynthia Says cannot make
an accurate assessment, for example in determining whether content is clear and simple.

 Pros                                             Cons

 Can test Section 508, Level A, Level AA or       Tests only one web page at a time
 Level AAA
 Emulates different browsers                      Cannot test some checkpoints
 Includes a separate Alternative Text quality
 report
 Contains specific information on errors

        How to use Cynthia Says
        Cynthia Says should only be used when you are testing a small number of web pages.
        You will need to run each web page manually.

        1. Insert page details
        Insert relevant details such as:
         the URL (1);
         the level of testing required (2);
         specific details such as the inclusion of the Alternative Text Quality Report (3); and
         the browser you wish to emulate (4).




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         238
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             Alternatively you could use the Cynthia Says full options tester 464 . This includes testing
             options such as potential screen movement and flickering as well as the ability to exclude
             lines from testing.

             Interpreting the report
             The Cynthia Says – Web Content Accessibility Report consists of three sections:
                 information about the page tested (1);
                 violations of the Web Content Accessibility Guidelines (or Section 508) ordered
                    by checkpoint (2); and if selected
                 the Alternative Text Quality Report (3).




464
      http://www.cynthiasays.com/fulloptions.asp


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               239
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        To interpret a Cynthia Says report, you will need to identify all instances where the site
        has failed. The report is organized into four columns:
             (Checkpoints) Basic Settings;


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           240
Copyright State of Victoria, 2009
                Victorian Government Accessibility Toolkit
                (Passed) Yes;
                (Passed) No; and
                (Passed) Other.

        All checkpoints that indicate a “No” or “Other” need to be investigated further. Often
        additional information is provided in the “Checkpoint” column.

        Example
        The following is an example failure from the Cynthia Says report run on
        www.egov.vic.gov.au:

        Checkpoint 13.1:
        Clearly identify the target of each link.
             Rule: 13.1.1 - All Anchor elements are required not to use any of the defined link
                 phrases in the link text.
                     o No Anchor elements that use any of the defined link phrases in the link
                          text were found in document body.
             Rule: 13.1.2 - All Anchor elements are required not to use the same link text to
                 refer to different resources.
                     o Failure - Anchor Element at Line: 177, Column: 10

        According to this error, the site fails checkpoint 13.1.2:

                 Clearly identify the target of each link – All anchor elements are required not to
                 use the same link text to refer to different resources.

        In this example there is an anchor element on Line 177 which uses the same link text as
        another link on the page but links to a different page.

        The HTML code on line 177 of the web page www.egov.vic.gov.au is:

        <li><a href="/index.php?env=-categories:m1825-1-1-8-s">Trends and Issues</a></li>


        Searching for the link text in this line - “Trends and Issues” - reveals another link on line
        139 with the same link text directing to a different page:

        <li><a href="http://www.egov.vic.gov.au/index.php?env=-categories:m3-1-1-8-s">Trends
        and Issues</a></li>


        The two links are clearly visible on the eGovernment homepage:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             241
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             This violation is easily fixed by changing the link text of one of the links. In this example, a
             possible solution might be to change the inline link to something like “Trends and Issues
             for Victorian Government”.

             Further Information

             Help using Cynthia Says
                The Alternative Text Quality Report 465
                A case for browser emulation 466
                Using Cynthia (video and transcript) 467

             Interpreting the reports
                Reading the report (video and transcript) 468
                Reviewing the results 469
                Tracking down errors 470
                Layout and data tables 471

             Specific errors
                Checkpoint 1.1 – ALT attributes 472


465
      http://www.cynthiasays.com/About%20Reports/Alt%20Quality.htm
466
      http://www.cynthiasays.com/About%20Reports/Browser%20Emulation.htm
467
      http://www.cynthiasays.com/media/UsingCynthia.htm
468
      http://www.cynthiasays.com/media/Readingthereport.htm
469
      http://www.cynthiasays.com/About%20Reports/ReviewingResults.htm
470
      http://www.cynthiasays.com/About%20Reports/ErrorTracking.htm
471
      http://www.cynthiasays.com/About%20Reports/DataTables.htm
472
      http://www.cynthiasays.com/tutorial/a11.htm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                   242
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                 Checkpoint 1.1 – audio files 473
                 Checkpoint 2.1 474
                 Checkpoint 1.2 475
                 Checkpoint 5.1 and Checkpoint 5.2 476
                 Checkpoint 12.1 477
                 Checkpoint 7.1 478
                 Checkpoint 6.3 479




473
      http://www.cynthiasays.com/tutorial/b11.htm
474
      http://www.cynthiasays.com/tutorial/c21.htm
475
      http://www.cynthiasays.com/tutorial/e12.htm
476
      http://www.cynthiasays.com/tutorial/gh5152.htm
477
      http://www.cynthiasays.com/tutorial/i11121.htm
478
      http://www.cynthiasays.com/tutorial/j71.htm
479
      http://www.cynthiasays.com/tutorial/l63.htm


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   243
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit

Firefox Web Developer Toolbar

Type: Page by page
Access: Downloadable toolbar for use with Firefox
Cost: Free
Company: Chris Pederick
URL: http://chrispederick.com/work/web-developer/

The Firefox Web Developer Toolbar is a page-by-page accessibility evaluator. The toolbar can
test many of the W3C Web Content Accessibility Guidelines and offers features such as disabling
cookies and changing screen resolution. Errors are highlighted within the web page being tested.

 Pros                                                          Cons

 Provides a quick overview of the accessibility                Tests only one page at a time
 of an entire page
 Includes additional features such as the ability              Cannot test some checkpoints
 to resize the browser to other screen
 resolutions and disable cookies
 Works with a keyboard                                         Must reselect options for every new web page
                                                               tested
                                                               Limited to Firefox, Flock, SeaMonkey and
                                                               Mozilla web browsers (the Web Accessibility
                                                               Toolbar contains similar features and works on
                                                               Internet Explorer and Opera)

             How to use the Firefox Web Developer Toolbar
             Use the Firefox Web Developer Toolbar for small amounts of individual page testing.

             Download the toolbar
             Before downloading the Firefox Web Developer Toolbar you will need check that you
             meet the system requirements 480 .

             You can download the extension from Chris Pederick 481 or from Firefox 482 .

             Running tests using the Firefox Web Developer Toolbar
             If the toolbar is not already visible after installation, open Firefox and click the “View”
             menu. Select the “Toolbars” option and then select the “Web Developer Toolbar” option
             from the sub-menu. The toolbar will now appear under the address bar and any other
             toolbars you may have installed.




480
      http://www.mozilla.com/en-US/firefox/system-requirements.html
481
      http://chrispederick.com/work/web-developer/
482
      https://addons.mozilla.org/en-US/firefox/addon/60


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                    244
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        There are twelve menu items, each containing a number of tests. These twelve menu
        items are:

        Disable
        This menu contains tests that allow you to disable Java, JavaScript, Cache, Meta
        Redirects, Minimum Font Size, Page Colours, Popups and Referrers.

        Cookies
        This menu contains tests that allow you to disable, clear, view and add cookies.

        CSS
        This menu contains tests that allow you to disable, view and edit cascading style sheets
        (CSS).

        Forms
        This menu contains tests that allow you to view form information, remove maximum
        lengths on forms and show passwords.

        Images
        This menu contains tests that allow you to disable images and ALT attributes and outline
        images with missing or empty ALT attributes and hide images.

        Information
        This menu contains tests that allow you to display <DIV> order, title attributes, JavaScript
        and anchors.

        Miscellaneous
        This menu contains tests that allow you to display line guides, make all links unvisited
        and clear private data.

        Outline
        This menu contains tests that allow you to outline frames, table cells, images and
        external links.

        Resize
        This menu contains tests that allow you to resize the current browser window or zoom in
        and out.

        Tools
        This menu contains tests that allow you to validate CSS, HTML and links.



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             245
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        View Source
        This menu contains tests that allow you to view the source code for the web page.

        Options
        This menu contains tests that allow you to modify other web developer extension options.

        At the far end of the toolbar are three icons:

        Standards Compliance Mode
        Clicking this icon will raise a window that provides a range of information on the web
        page and web site. If the toolbar finds an issue with the information it retrieves, the icon
        takes the form of a red cross, otherwise the icon takes the form of a green tick.

        JavaScript Errors/CSS Errors
        Clicking either of these icons will raise the browser error window. The browser error
        window contains a list of any JavaScript or CSS errors that have been raised by loading
        or interacting with the web page. If there are no errors on the web page the icons take the
        form of a green circle with a tick. If there are errors on the page the icons take the form
        of a red circle with an exclamation mark.

        To run any of the above tests, click a menu e.g. “Images” and select the test you want to
        run, e.g. “Display Alt Attributes”.




        The selected test will be run on the current loaded web page and will often display
        information directly within the web page. For example, the “Display Alt Attributes” test will
        show all images together with their respective ALT attribute inline on the web page, for
        example:

        eGovernment Resource Centre:




        eGovernment Resource Centre with the “Display Alt Attributes” test:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            246
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        Deciding which tests to run
        The following table lists some recommended tests for particular W3C Web Content
        Accessibility Guidelines checkpoints.

 Level A Checkpoint                                   Menu               Test

 1.1: testing ALT attributes of an image              Images             Display Alt Attributes
                                                                         Outline Images with
                                                                         Empty Alt Attributes
                                                                         Replace Images with
                                                                         Alt Attributes
 1.1: identify any frames                             Outline            Outline Frames
 1.1: identify any objects                            Information        Display Object
                                                                         Information
 2.1: testing whether information has been            Disable            Disable Page Colors
 provided without relying solely on colour
 4.1: determine whether the changes in the            Outline            Outline Custom
 language have been identified                                           Elements (insert
                                                                         “LANG”)
 5.1: test whether table headers have been used       Information        Display Table
                                                                         Information
 6.1: testing the site works with style sheets        CSS                Disable Styles
 disabled
 6.3: identify the use of JavaScript                  Information        View JavaScript
 6.3: test whether the site can be used with          Disable            Disable JavaScript
 JavaScript disabled
 6.3: test whether the site can be used with Java     Disable            Disable Java
 disabled
 12.1: test whether a frame has a title               View Source        View Frame Source


 Level AA Checkpoint                                  Menu               Test

 2.2: testing whether colour contrast is sufficient   Information        View Color
                                                                         Information
 3.2: validating the HTML                             Tools              Validate HTML
 3.2: validating the CSS                              Tools              Validate CSS



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                      247
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
 3.3: testing whether style sheets have been          CSS                     All Styles
 used for layout and presentation                     Disable Styles           Inline Styles
 3.4: determine whether relative units have been      Outline                 Relative
 used for style sheet property values                 Outline Positioned
                                                      Elements
 3.5: determine whether headings have been            Information              View Document
 used and whether they have been nested                                        Outline
 3.6: determine whether list markup has been          Outline                  Block Level
 used                                                                          Elements
 3.7: determine whether quotes have been              Outline                  Block Level
 marked up with Q and BLOCKQUOTE                                               Elements
 10.1: identify any pop-ups                           Disable                  Disable Referrers
 11.2: identify any deprecated HTML elements          Outline                  Outline Deprecated
                                                                               Elements
 12.3: determine whether FIELDSET has been            Forms                    View Form
 used to break up a form                                                       Information
 13.1: test whether links have clearly identified     Information              View Link
 targets                                                                       Information
 13.2: determine whether metadata has been            Information              View Meta Tag
 included                                                                      Information


 Level AAA Checkpoint                                 Menu                     Test

 4.2: test whether acronym and abbreviation           Outline                  Outline Custom
 markup has been used                                                          Elements (insert
                                                                               “ACRONYM” and
                                                                               “ABBR”)
 5.5: identify table summaries                        Information              Display Table
                                                                               Information
 9.4: identify the tab order of the page              Information              Display Tab Index
 9.5: identify whether access keys (keyboard          Information              Display Access keys
 shortcuts) have been used
 10.3: test whether a table can be used if it is      Miscellaneous            Linearise Page
 linearised

        Examples
        The following are failures from a random selection of website pages.

        1. Missing ALT attributes
        Test: Outline Images without Alt Attributes




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          248
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        According to this error, the menu icon images are missing ALT attributes, indicated by a
        red line outlining the image.

        2. Missing field label
        Test: View Form Information




        According to this error, the search field does not have a field label. In addition to this,
        testing the site with JavaScript disabled (using the “Disable JavaScript” test) reveals that
        this search field cannot be submitted without JavaScript

        3. Onmouseover
        Test: Disable JavaScript

        When hovering over the top navigation (“Personal”, “Business” etc) flyout menus appear:




        With JavaScript disabled these flyout menus do not appear, nor do alternative links,
        leaving the website inaccessible. On further testing, this menu also cannot be activated
        via the keyboard.

        4. Table Headers
        Test: Display Table Information




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           249
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        According to the above inline information, this table includes a SUMMARY tag (“Schedule
        of events”), and all data cells reference appropriate headers e.g. the header referenced in
        the first data cell is the cell labeled “Opening Ceremony” and “Wed 15 Day 0”).

        5. Displaying Headings
        Test: Outline Headings




        According to the above inline information, all headings are marked up appropriately on
        this web page. Use this test to determine whether headings have been nested properly
        within a web page.


        Further Information




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         250
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
             Download the Firefox Web Accessibility Extension
                 Download from Chris Pederick 483
                 Download from Firefox 484

             Help using the Firefox Web Accessibility Extension
                 WebAIM – Using the Firefox Web Accessibility Extension 485




483
      http://chrispederick.com/work/web-developer/
484
      https://addons.mozilla.org/en-US/firefox/addon/60
485
      http://www.webaim.org/articles/evaluatingwithfirefox/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011         251
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

The WAVE (version 4.0)

Type: Page by page
Access: Online form
Cost: Free
Company: WebAIM
URL: http://wave.webaim.org

The WAVE is a page-by-page accessibility evaluator that tests many of the W3C Web Content
Accessibility Guidelines. Errors are highlighted within the web page.

 Pros                                              Cons

 Can test Section 508, Level A, Level AA or        Tests only one page at a time
 Level AAA
 Details specific information, for instance ALT    Cannot test some checkpoints
 attributes are provided with the relevant image
 Provides a quick overview of the accessibility    Displaying errors and other accessibility
 of an entire page                                 features inline means that a WAVE output
                                                   page can be overly complex
 Different ways to access the WAVE tool
 Provides the ability to view accessibility
 features, warnings and semantic elements as
 well as accessibility errors.

        How to use the WAVE
        WAVE should only be used when you are testing a small number of pages. You will need
        to run each page individually. There are five different ways to use WAVE:
             1. submit a Web Address;
             2. upload a page;
             3. check HTML code;
             4. install the WAVE toolbar; or
             5. add the WAVE bookmarklet.

        1. Submit web page URL
        Insert the URL of the web page you wish to test.




        2. Upload a page
        Enter the file location or select the file you wish to test using the Browse button. Please
        note that this option will not test the graphics of the page.




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           252
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        3. Check the HTML code
        You can copy and paste chunks of HTML code for WAVE to test.




        4. Install the WAVE toolbar
        When you install the WAVE toolbar in your browser, simply load the web page you want
        to evaluate and then click on "WAVE this page!". Alternatively, type in the web page’s
        address using the "WAVE a different page" field.




        5. Add WAVE bookmarklet
        When you add the WAVE bookmarklet to your browser, simply load the web page that
        you want to evaluate and then click on the bookmarklet to process it through WAVE.




        Drag the WAVE bookmarklet:              to the bookmark bar.

        Interpreting the output
        Interpreting WAVE output requires an understanding of each of the output icons.

        The WAVE uses four different types of icons:
            Red icons denote failures or violations of WCAG checkpoints
            Yellow icons denote possible failures or violations of WCAG checkpoints. These
              are called “alerts”
            Green icons denote specific accessibility features used in the site


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                      253
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit
                     Light blue icons denote structural and semantic elements used in the site

            The following table is a description of all the red and yellow icons used by WAVE.
            For more information on icons, see the WAVE icons and explanations 486 page.

 Icon                Explanation

                     Image is missing an ALT attribute


                     A spacer image is missing an ALT attribute


                     Linked image missing alternative text


                     Image input missing alternative text


                     Image map missing alternative text


                     Image map area missing alternative text


                     Server-side image map


                     Invalid longdesc



                     Form label missing


                     Empty form label


                     Multiple form labels


                     Orphaned form label



                     Broken skip navigation link




486
      http://wave.webaim.org/icons


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            254
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
               Frame missing title


               Empty heading


               Marquee


               Blink


               Missing or non-informative <title>


               Empty link


               Suspicious alternative text


               Redundant alternative text


               A nearby image has the same alternative text


               Very long alternative text


               Complex image may require long description


               Background images should NOT contain important text


               Fieldset without a legend


               Missing fieldset


               Unlabeled form element with title


               Possible heading




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   255
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
               Incorrectly ordered headings


               Incorrect use of empty list


               Incorrect use of empty list


               Italics


               Bold


               Possible blockquote


               Very small text


               Popup window


               Problematic link text


               Frame with suspicious title


               Hidden skip link


               Invisible content


               Accesskey


               Tab index


               Page refreshes or redirects


               Missing structure


               Event handler




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   256
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
               JavaScript element


               JavaScript jump menu may be present


               Noscript element


               Link to media


               Applet


               Link to Word document


               Link to Excel document


               Link to PowerPoint document


               Link to WordPerfect document


               Link to OpenOffice.org document


               Link to Acrobat PDF document


               <object> or <embed>


               Flash


               Shockwave


               Quicktime


               RealPlayer




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   257
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
               Windows Media Player



        WAVE highlights accessibility features, semantic elements and accessibility errors and
        warnings.
        Examples
        The following are WAVE failures from a selection of random websites.

        1. Missing ALT attributes




        According to this error, the menu icon images are missing ALT attributes, indicated by the
        red icon to the right.

        2. Missing field label / JavaScript form submission




        According to this error, the search field does not have a field label. In addition to this,
        testing the site with JavaScript disabled (using the “Disable JavaScript” test) reveals that
        this search field cannot be submitted without JavaScript


        3. Onmouseover




        Although the image has an ALT attribute of “Help”, it also utilizes a mouseover call and
        JavaScript. On testing this onmouseover changes the colour of the “Help” section and
        initiates a flyout menu. This menu cannot be activated via the keyboard and is therefore
        inaccessible.

        4. Table Headers
        Test: Display Table Information




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                           258
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit




        All table headers are marked up properly e.g. the code for cell Wed 15 Day 0 is
        “id=day20060315”, and all data cells reference appropriate headers eg. the headers
        referenced by the first data cell are “openingceremony” and “day20060315”.

        5. Displaying Headings




        According to the above inline information, all headings are marked up appropriately on
        this web page. Use this test to determine whether headings have been nested properly
        within a web page.



Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                       259
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

            Further Information

            Help using WAVE
                Using WAVE 487




487
      http://webaim.org/resources/wave/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011   260
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Web Accessibility Toolbar

Type: Page by page
Access: Downloadable toolbar for use with Internet Explorer
Cost: Free
Company: Vision Australia
URL: http://www.visionaustralia.org/info.aspx?page=614

The Web Accessibility Toolbar is a downloadable toolbar for use with Internet Explorer and Opera
web browsers. It functions as a page-by-page accessibility evaluator, and can test many of the
W3C Web Content Accessibility Guidelines. In addition the toolbar contains other features such
as the ability to resize the browser to match a screen resolution. Errors are highlighted within the
web page.

 Pros                                               Cons

 Provides a quick overview of the accessibility     Tests only one page at a time
 of an entire web page
 Available in a variety of languages                Cannot test some checkpoints
 Uses access keys for each function to allow        Must reselect options for every new web page
 for use via a keyboard                             tested
 Includes additional features such as the ability   Limited to Internet Explorer and Opera web
 to resize the browser to other screen              browsers (the Firefox Web Developer
 resolutions                                        Extension contains similar features and works
                                                    on Firefox)

        How to use the Web Accessibility Toolbar
        The Web Accessibility Toolbar should only be used when you are testing a small number
        of pages. You will need to run each page individually.


        Download the toolbar
        Before downloading the Web Accessibility Toolbar you will need to meet the following
        system requirements:
         Microsoft Windows (Version 98, 2000, NT or XP); and
         Internet Explorer 5+ or Opera 8+ with JavaScript enabled.

        You can also download the Internet Explorer Web Accessibility Toolbar in the following
        languages:
         Chinese (Simplified);
         Chinese (Traditional);
         Danish;
         Dutch;
         French;
         German;
         Italian;
         Japanese;
         Korean;
         Portuguese (Brazilian);
         Spanish; and
         Swedish.

Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                          261
Copyright State of Victoria, 2009
                    Victorian Government Accessibility Toolkit

            There are separate downloads for the Internet Explorer Web Accessibility Toolbar 488 and
            the Opera Web Accessibility Toolbar 489 .

            Running tests using the Web Accessibility Toolbar
            If the toolbar is not already visible after installation, open your browser and click the
            “View” menu. Select the “Toolbars” option and then select the “Accessibility Toolbar”
            option from the sub menu. The toolbar will appear under the address bar and any other
            toolbars you may have installed.




            There are twelve menu items, each containing a number of tests. These twelve menu
            items are:

            AIS Web Accessibility Toolbar
            This menu contains information about the toolbar including features, documentation and
            links to relevant information.

            Validate
            This menu contains tests that allow you to check the whether the document is valid, such
            as the HTML and CSS Validators and link checkers.

            Resize
            This menu contains tests that allow you to resize the browser window to standard and
            custom screen resolutions.

            CSS
            This menu contains tests to turn disable style sheets.

            Images
            This menu contains tests that allow you to highlight ALT attributes, image maps and list
            all images.

            Colour



488
      http://www.visionaustralia.org/info.aspx?page=1569
489
      http://www.paciellogroup.com/resources/wat-about.html


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                             262
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        Colour contains tests that allow you to check colour contrast including luminosity,
        greyscale and various contrast tests from JuicyStudio and Vischeck.

        Structure
        This menu contains a number of tests that allow you to assess the page structure,
        including headings, table headers and abbreviations.

        Tools
        This menu contains links to common accessibility tools such as Juicy Studio’s Readability
        Test, WAVE and Cynthia Says. This menu also contains a Simulations section which
        includes specific tests for disabilities such as Glaucoma and Diabetic Retinopathy,
        including standard simulations of a disabled mouse or plug-ins.

        Doc Info
        This menu contains tests that allow you to assess page weight, metadata information and
        link information.

        Source
        This menu contains tests that allow you to view the page source code and highlight
        specific sections such as images, forms or deprecated HTML.

        IE options
        This menu contains standard Internet Explorer options such as turning off images,
        JavaScript and other plug-ins, as well as the option to change text size.

        Refs
        This menu includes links to reference websites such as W3C and other usability and
        accessibility resources and language information.

        Magnify
        This menu allows you to magnify the browser window from 25% to 600%.

        To run a test, select a particular menu, for example “Images” and then select the
        particular test you want to run, for example “Toggle Image/Alt”.




        The selected test will be run inline on the current page e.g. the “Toggle Image/Alt” test
        will replace all images with their ALT attribute, for example:

        eGovernment Resource Centre:




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                              263
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             eGovernment Resource Centre with the “Toggle Image/Alt” test:




             Deciding which tests to run
             For more information on all Web Accessibility Toolbar functions, see Vision Australia’s
             Toolbar functions 490 page. The following table lists some recommended tests for
             particular WCAG checkpoints.

 Level A Checkpoint                                       Menu                    Test

 1.1: testing ALT attributes of an image                  Images                  Toggle Image/Alt
 1.1: identify any frames                                 Structure               Frame Borders
 1.1: identify any downloadable files                     Doc Info                List Downloadable
                                                                                  Files
 1.1: identify any multimedia files                       Doc Info                Identify Multimedia
                                                                                  Files
 2.1: testing whether information has been                Images                  Greyscale
 provided without relying solely on colour
 4.1: determine whether the changes in the                Doc Info                Show Lang
 language have been identified                                                    Attributes
 5.1: test whether table headers have been used           Structure               Show Table Headers
                                                                                  Simple Data Table
                                                                                  Complex Data Table
 6.1: testing the site works with style sheets            CSS                     Disable CSS
 disabled
 6.3: identify the use of JavaScript                      Structure               JavaScript / New
                                                                                  Window Links


 6.3: test whether the site can be used with Java,        Tools                  Disable Plug-ins
 Flash and iframes disabled
                                                          Simulations
 6.3: test whether the site can be used with              IE Options              Toggle JavaScript


490
      http://www.visionaustralia.org/info.aspx?page=619


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                               264
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
 JavaScript disabled
 6.3: identify any scripts                            Doc Info             Identify Scripts
 7.1: test that the screen does not flicker           Images               GIF Flicker Test
 9.1: testing whether image maps are client-side      Images               Show Image Maps
 or server-side
 12.1: test whether a frame has a title               Structure            Frame Name / Title



 Level AA Checkpoint                                  Menu                 Test

 2.2: testing whether colour contrast is sufficient   Images               JuicyStudio
                                                                           Vischeck
 3.2: validating the HTML                             Validate            Validate HTML
                                                      W3C HTML Validator
 3.2: validating the CSS                              Validate            Validate CSS
                                                      W3C CSS Validator
 3.3: testing whether style sheets have been          CSS                  Show Applied Styles
 used for layout and presentation                                          Show Style Sheet(s)
 3.4: determine whether relative units have been      CSS                  Show Style Sheet(s)
 used for style sheet property values
 3.5: determine whether headings have been            Structure            Headings
 used and whether they have been nested                                    Heading Structure
 3.6: determine whether list markup has been          Structure            List items
 used
 3.7: determine whether quotes have been              Structure            Blockquote & Q
 marked up with Q and BLOCKQUOTE
 6.4: test whether device-dependent event             Structure            JavaScript / New
 handlers have been used                                                   Window Links
                                                                           Event Handlers
 10.1: test whether any links open in a new           Structure            JavaScript / New
 window                                                                    Window Links
 11.2: identify any deprecated HTML elements          Source               Deprecated HTML
 12.3: determine whether FIELDSET has been            Structure            Fieldset / Labels
 used to break up a form
 12.4: determine whether field labels have been       Structure            Fieldset / Labels
 explicitly associated with fields
 13.1: test whether links have clearly identified     Doc Info             List Links
 targets
 13.2: determine whether metadata has been            Doc Info             Metadata
 included                                                                  Information


 Level AAA Checkpoint                                 Menu                 Test


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                         265
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
 4.2: test whether acronym and abbreviation           Structure                  Acronyms/
 markup has been used                                                            Abbreviations
 9.4: identify the tab order of the page              Structure                  Show Tab Order
 9.5: identify whether access keys (keyboard          Structure                  Access keys
 shortcuts) have been used
 10.3: test whether a table can be used if it is      Structure                  Linearise (Remove
 linearised                                                                      Tables)

        Examples
        The following are Web Accessibility Toolbar failures from a selection of random websites.

        1. Missing ALT attributes
        Test: Toggle Image/Alt




        According to this error, the menu icon images are missing ALT attributes. Web
        Accessibility Toolbar also raises a dialog box to inform the user of the number of images
        missing ALT attributes.

        2. Missing field label
        Test: Fieldset / Labels




        According to this error, the search field does not have a field label.

        3. Onmouseover
        Test: Event Handlers




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                            266
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit
        This image utilizes an onmouseover call to change the colour of the “Personal” section
        and also initiates a flyout menu. This menu cannot be activated via the keyboard and is
        therefore inaccessible.

        4. Complex data tables
        Test: Complex data table




        According to the above inline information, the table includes a SUMMARY tag (“Schedule
        of events”), all table headers are marked up properly e.g. the code for cell Wed 15 Day 0
        is “id=day20060315”, and all data cells reference appropriate headers e.g. the headers
        referenced by the first data cell are “openingceremony” and “day20060315”.

        5. Displaying Headings
        Test: Headings




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                       267
Copyright State of Victoria, 2009
                     Victorian Government Accessibility Toolkit




             According to the above inline information, all headings are marked up appropriately on
             this web page. Use the ‘Heading Structure’ test to determine whether headings have
             been nested properly within a web page.

             Further Information

             Download the Web Accessibility Toolbar
                 Download the Internet Explorer Web Accessibility Toolbar 491
                 Download the Opera Web Accessibility Toolbar 492

             Help using the Web Accessibility Toolbar
                 Toolbar functions 493
                 WebCredible – Using the Web Accessibility Toolbar 494
                 WebAIM – Using the Web Accessibility Toolbar 495
                 Web Accessibility Toolbar Blogspot 496




491
      http://www.visionaustralia.org/info.aspx?page=1569
492
      http://www.paciellogroup.com/resources/wat-about.html
493
      http://www.visionaustralia.org/info.aspx?page=619
494
      http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/accessibility-toolbar.shtml
495
      http://www.webaim.org/articles/ais/
496
      http://web-accessibility-toolbar.blogspot.com/


Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                                     268
Copyright State of Victoria, 2009
               Victorian Government Accessibility Toolkit

Section Seven: Accessibility resources
General accessibility links
        eGovernment Resource Centre – Accessibility
        http://www.egov.vic.gov.au/index.php?env=-categories:m420-1-1-8-s
        W3C Web Accessibility Initiative (http://www.w3.org/wai)
        W3C Checklist (http://www.w3.org/TR/WCAG10/full-checklist.html)
        Web Accessibility page of HREOC
        (http://www.hreoc.gov.au/disability_rights/webaccess/index.htm)
        W3C Auxiliary Benefits of Accessible Web Design
        (http://www.w3.org/WAI/bcase/Overview)
        A list apart (http://www.alistapart.com/)
        Joe Clark (http://joeclark.org/)
        WebAIM (http://www.webaim.org/)
        eGovernment Resource Centre newsletter (http://www.egov.vic.gov.au/)
        Disability Rights page of HREOC (http://www.hreoc.gov.au/disability_rights/index.html)
        Adobe Accessibility (http://www.adobe.com/accessibility/)
        Apple accessibility (http://www.apple.com/accessibility/)
        Microsoft accessibility (http://www.microsoft.com/enable/)

Guidelines and Standards
        W3C Accessibility Guidelines (http://www.w3.org/TR/WCAG10/)
        Whole of Victorian Government Website Standards
        (http://www.egov.vic.gov.au/index.php?env=-categories:m1050-1-1-8-s&reset=1)
        Disability Discrimination Act (Advisory notes for Web)
        (http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html)

Tools
        Vischeck (http://vischeck.com/vischeck/vischeckURL.php)
        HTML Validator (w3.validator.org)
        CSS Validator (http://jigsaw.w3.org/css-validator/validator-uri.html)
        Juicy Studio (http://juicystudio.com/)
        Web Accessibility Toolbar (http://www.visionaustralia.org.au/ais/toolbar/)
        Firefox Web Developer Toolbar (https://addons.mozilla.org/firefox/60/)
        Web Accessibility Toolbar for Opera (http://www.paciellogroup.com/resources/wat-
        about.html)




Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011                       269
Copyright State of Victoria, 2009