eServices Unit, Information Victoria, Department of Business and Innovation.
Version 3.1.1
March 2011
4
Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011
Copyright State of Victoria, 2009
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:
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.
4
Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011
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) 39
Fixing a current site to achieve accessibility (Implementation phase) 42
Case Study 1 - Victoria Online (Department for Innovation, Industry and Regional Development) 45
Case Study 2 -Youthcentral (Department for Victorian Communities) 47
Case Study 3 - Web Developer’s Resource Kit (Department of Education and Early Childhood Development) 49
Section Four: Understanding and testing Level A, AA and AAA checkpoints 51
Introduction to the Level A and Level AA checkpoints 51
Level A, Level AA and non-essential Level AAA checkpoints 52
General checkpoints 55
Checkpoints on image maps 68
Checkpoints on tables 70
Checkpoints on frames 72
Checkpoints on applets and scripts 73
Checkpoints on multimedia 75
If you can’t make it accessible 77
Level AA Checkpoints 78
Checkpoint 2.2 78
Checkpoint 3.1 79
Checkpoint 3.3 82
Checkpoint 3.4 83
Checkpoint 3.5 84
Checkpoint 3.6 85
Checkpoint 3.7 86
Checkpoint 6.5 87
Checkpoint 7.2 89
Checkpoint 7.4 90
Checkpoint 7.5 91
Checkpoint 10.1 92
Checkpoint 11.1 93
Checkpoint 11.2 95
Checkpoint 12.3 96
Checkpoint 13.1 98
Checkpoint 13.2 99
Checkpoint 13.3 100
Checkpoint 13.4 101
Tables 103
Checkpoint 5.3 103
Checkpoint 5.4 103
Frames 104
Checkpoint 12.2 104
Forms 105
Checkpoint 10.2 105
Checkpoint 12.4 105
Scripts and applets 106
Checkpoint 6.4 106
Checkpoint 7.3 106
Checkpoint 8.1 108
Checkpoint 9.2 110
Checkpoint 9.3 111
Checkpoint 4.3 112
Checkpoint 9.4 113
Checkpoint 13.5 114
Checkpoint 13.6 115
Checkpoint 14.2 117
Checkpoint 14.3 118
Section Five: Top issues 120
Making images, image maps, maps and graphs accessible 121
Making tables accessible 123
PDFs and accessibility 126
Making a PDF accessible 129
Creating accessible forms 133
JavaScript 143
Making splash pages accessible 149
Creating valid HTML pages 151
Creating valid CSS 156
Page source order 160
Page structure 163
Ensuring sufficient colour contrast 171
Creating sites accessible to people with cognitive disabilities 174
Conducting Operating System and Browser testing 180
Additional accessibility features 186
Videos and accessibility 187
What about YouTube videos? 187
What about vodcasts? 187
What about live streaming content? 188
Relationship to WCAG1 checkpoints 188
Complying with accessibility requirements when including video 188
Example 1: Transcript of a video 189
Further Information 190
Captioning downloadable videos 191
Relationship to WCAG1 checkpoints: 191
Tools you will need 191
Using MAGpie to create captions 191
Example 1: Koorie education with Learning Objects, Part 1 193
Further Information 193
Captioning YouTube videos 194
Relationship to WCAG1 checkpoints: 194
Tools you will need 194
Using MAGpie to create captions 194
Using Subtitle Workshop to convert the file 195
Uploading captions to YouTube 196
Example 1: Koorie education with Learning Objects, Part 1 196
Further Information 196
Audio describing videos 198
Relationship to WCAG1 checkpoints: 198
Tools you will need 198
Using MAGpie to create audio descriptions 198
Testing the audio descriptions 199
Putting the audio described video on a web site 199
Example 1: Koorie education with Learning Objects, Part 1 200
Further information 201
Captioning vodcasts 202
Relationship to WCAG1 checkpoints: 202
Tools you will need 202
Using MAGpie to create captions 202
Associate captions with the vodcast 204
Example 1: Test vodcast 205
Example 2: Koorie education captioned vodcast 206
Further Information 206
Audio and podcasts 207
Relationship to WCAG1 checkpoints: 207
Tools you will need to create a podcast 207
Complying with accessibility requirements when creating podcasts 207
Example 1: A test podcast 208
Further Information 208
Flash and accessibility 209
Relationship to WCAG1 checkpoints 209
Complying with accessibility requirements when including Flash 209
Example 1: Transcript of a Flash file 210
Further Information 212
Mashups and accessibility 213
Relationship to WCAG1 checkpoints 213
Complying with accessibility requirements when including mashups 213
Example 1: Transcript of a mashup 213
Example 2: Doodle for Google Australia 216
Further Information 217
Blogging and accessibility 218
Relationship to WCAG1 checkpoints: 218
Complying with accessibility requirements when creating blogs 218
Example 1: Gian Wild’s blog 218
Further Information 218
Making maps and Google maps accessible 220
Relationship to checkpoints: 220
What about Google maps? 220
Complying with accessibility requirements when creating maps 220
Example 1: An accessible bushfires map 223
Example 2: An accessible Google map 223
Further Information 223
Frames and iFrames 224
Relationship to WCAG1 checkpoints: 224
What are iFrames? 224
Creating accessible iFrames 224
Example 1: Accessible iFrame 225
Further Information 225
Making Slideshare accessible 226
Relationship to WCAG1 checkpoints: 226
Can Slideshare presentations be embedded in a site? 226
Creating accessible Slideshare presentations 226
Example 1: Embedded Slideshare 227
Further Information 227
Facebook and accessibility 228
Creating accessible Facebook 228
Example 1: Target 155 228
Further Information 228
Twitter and accessibility 229
Creating accessible Twitter 229
Example 1: John Brumby 229
Further Information 229
Section Six: Accessibility evaluation tools 230
Page-by-page accessibility evaluation tools 230
Specific accessibility evaluation tools 233
Entire site accessibility evaluation tools 235
AccVerify 236
Cynthia Says 241
Firefox Web Developer Toolbar 247
The WAVE (version 4.0) 255
Web Accessibility Toolbar 264
Section Seven: Accessibility resources 272
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.
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.
4
Victorian Government Accessibility Toolkit – Version 3.1.1, March 2011
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
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