Victorian Government Accessibility Toolkit

Transcription

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
Copyright State of Victoria, 2009
1
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
2
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
3
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
Captioning YouTube videos..................................................................................... 193
4
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.
Audio describing videos............................................................................................ 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
Using MAGpie to create captions........................................................................... 199
Associate captions with the vodcast ....................................................................... 201
Example 1: Test vodcast ......................................................................................... 202
Example 2: Koorie education captioned vodcast.................................................... 203
Audio and podcasts ................................................................................................... 204
Tools you will need to create a podcast .................................................................. 204
Complying with accessibility requirements when creating podcasts ..................... 204
Example 1: A test podcast....................................................................................... 205
Flash and accessibility .............................................................................................. 206
Complying with accessibility requirements when including Flash ........................ 206
Example 1: Transcript of a Flash file...................................................................... 207
Mashups and accessibility ........................................................................................ 210
Complying with accessibility requirements when including mashups ................... 210
Example 1: Transcript of a mashup ........................................................................ 210
Example 2: Doodle for Google Australia ............................................................... 213
Blogging and accessibility ........................................................................................ 215
Complying with accessibility requirements when creating blogs........................... 215
Example 1: Gian Wild’s blog ................................................................................. 215
5
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
Frames and iFrames ................................................................................................. 221
What are iFrames? .................................................................................................. 221
Creating accessible iFrames.................................................................................... 221
Example 1: Accessible iFrame................................................................................ 222
Making Slideshare accessible................................................................................... 223
Can Slideshare presentations be embedded in a site?............................................. 223
Creating accessible Slideshare presentations.......................................................... 223
Example 1: Embedded Slideshare .......................................................................... 224
Facebook and accessibility ....................................................................................... 225
Creating accessible Facebook ................................................................................. 225
Example 1: Target 155............................................................................................ 225
Twitter and accessibility........................................................................................... 226
Creating accessible Twitter..................................................................................... 226
Example 1: John Brumby........................................................................................ 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
6
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--
7
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.
8
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
9
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
10
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
4
http://www.gawds.org/show.php?contentid=96
5
11

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 .
6
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
12

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
13
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.
14
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
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
15
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/
16
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
17
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
18
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
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
19
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
52
http://www.egov.vic.gov.au/index.php?env=-innews/detail:m427-1-1-8-s:n-882-1-0&n_event=
20
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.
2.
3.
4.
5.
Provide equivalent alternatives to auditory and visual content. 58
Don’t rely on colour alone. 59
Use markup and style sheets and do so properly. 60
Clarify natural language usage. 61
Create tables that transform gracefully. 62
53
http://www.tomw.net.au/2000/bat.html
54
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
21
6.
7.
8.
9.
10.
11.
12.
13.
14.
Ensure that pages featuring new technologies transform gracefully. 63
Ensure user control of time-sensitive changes. 64
Ensure direct Accessibility of embedded user interfaces. 65
Design for device-independence. 66
Use interim solutions. 67
Use W3C technologies and guidelines. 68
Provide context and orientation information. 69
Provide clear navigation mechanisms. 70
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
22
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--
23




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/
24
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
25
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
26
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).
27

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
28
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
Insert the following code into the site. For more
information see adding the Level AA logo 79
<a
href="http://www.w3.org/WAI/WCAG1AAConformance" title="Explanation of
Level Double-A Conformance"> <img
height="32" width="88"
src="http://www.w3.org/WAI/wcag1AA"
alt="Level Double-A conformance
icon, W3C-WAI Web Content
Accessibility Guidelines 1.0"></a>
W3C AA Level text
Insert the following text in the necessary
place on the site.
“This site conforms to W3C's "Web
Content Accessibility Guidelines 1.0",
available at
http://www.w3.org/TR/1999/WAIWEBCONTENT-19990505, level AA.”
78
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#Conformance
79
http://www.w3.org/WAI/WCAG1-Conformance.html#level-AA
29
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.
30
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.
31
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).
32
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
33
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
34
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.
35
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.
36
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.
37
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
38
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?
39
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?
40
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?
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?
41
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 9.1: Are all image maps provided clientside 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?
42
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 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.?
43
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
44
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 reoccur.
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.
45
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.
46
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.
47
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/
48
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/
49
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.
50
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
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.
Done
51
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 deviceindependent.
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.
52
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.
53
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.
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)
54
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 screenreaders, 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 screenreader 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
55
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
56
Checkpoint 2.1
Level A
Ensure that all information conveyed with color is also available without color, for example from
context or markup.
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
57
Mon
7
14
21
28
Tue
1
8
15
22
29
Wed
2
9
16
23
30
Thu
3
10
17
24
Fri
4
11
18
25
Sat
5
12
19
26
Sun
6
13
20
27
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
7
14
21
28
Tue
1
8
15
22
29
Wed
2
9
16
23
30
Thu
3
10
17
24
Fri
4
11
18
25
Sat
5
12
19
26
Sun
6
13
20
27
How to test
 Manually browse the site and check that colours have not been used to indicate
different items on a page [Compulsory]
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
58
Checkpoint 4.1
Level A
Clearly identify changes in the natural language of a document's text and any text equivalents
(e.g., captions).
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]
Identifying changes in language 97
97
http://www.w3.org/TR/WCAG10-HTML-TECHS/#changes-in-lang
59
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.
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
60
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]
61
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
62
Checkpoint 6.2
Level A
Ensure that equivalents for dynamic content are updated when the dynamic content changes.
Guideline
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/
63
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]
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
64
Checkpoint 7.1
Level A
Until user agents allow users to control flickering, avoid causing the screen to flicker.
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]
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
65
Checkpoint 14.1
Level A
Use the clearest and simplest language appropriate for a site's content.
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]
Comprehension 110
109
http://juicystudio.com/services/readability.php
110
http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension
66
Checkpoints on image maps
Checkpoint 1.2
Level A
Provide redundant text links for each active region of a server-side image map.
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]
67
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.
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]
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
68
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.
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 screenreader 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
69
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]
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
70
Checkpoints on frames
Checkpoint 12.1
Level A
Title each frame to facilitate frame identification and navigation
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]
Providing a frame title 119
119
http://www.w3.org/TR/WCAG10-HTML-TECHS/#frame-names
71
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.
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 longterm vacancies.
For their prospective employer 'Down Under', Ray and Gwen had the advantage of having been selfemployed 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.
72
"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]
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
73
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.
Guideline
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]
[Optional]
Visual information and motion 122
122
74
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.
Guideline
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]
[Optional]
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
75
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.
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]
Alternative pages 125
125
http://www.w3.org/TR/WCAG10-CORE-TECHS/#alt-pages
76
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
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
77
Checkpoint 3.1
When an appropriate markup language exists, use markup rather than images to convey
information.
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/
78
How to test
 Disable style sheets and determine whether structure is maintained. [Compulsory].
 Increase text size and see if any content pixellates [Compulsory].
HTML Techniques – using markup 128
HTML Techniques – Structure vs Presentation 129
128
http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup
129
79
Checkpoint 3.2
Create documents that validate to published formal grammars.
Guideline
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.
80
Checkpoint 3.3
Use style sheets to control layout and presentation.
Guideline
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.
81
Checkpoint 3.4
Use relative rather than absolute units in markup language attribute values and style sheet
property values.
Guideline
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].
CSS Techniques – Relative units 130
130
http://www.w3.org/TR/WCAG10-CSS-TECHS/#units
82
Checkpoint 3.5
Use header elements to convey document structure and use them according to specification.
Guideline
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.
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
83
Checkpoint 3.6
Mark up lists and list items properly.
Guideline
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-s0: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-s0: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].
HTML Techniques – Lists 133
133
http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists
84
Checkpoint 3.7
Mark up quotations. Do not use quotation markup for formatting effects such as indentation.
Guideline
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].
HTML Techniques Quotations 134
134
http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-quotes
85
Checkpoint 6.5
Ensure that dynamic content is accessible or provide an alternative presentation or page.
Guideline
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].
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
86
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
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
87
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).
Guideline
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].
HTML Techniques – Scripts that cause movement and blinking 144
CSS Techniques – Text style effects 145
143
144
http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-movement-blinking
145
http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-text
88
Checkpoint 7.4
Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing
pages.
Guideline
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].
Core Techniques – Automatic page refresh 147
HTML Techniques – The META element 148
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
150
http://www.w3.org/TR/WCAG10-HTML-TECHS/#script-refresh
89
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.
Guideline
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].
Core Techniques – Automatic page refresh 151
HTML Techniques – The META element 152
151
http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh
152
http://www.w3.org/TR/WCAG10-HTML-TECHS/#meta-element
153
90
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.
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].
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 – Using FRAME targets 158
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
158
http://www.w3.org/TR/WCAG10-HTML-TECHS/#no-new-windows
159
91
Checkpoint 11.1
Use W3C technologies when they are available and appropriate for a task and use the latest
versions when supported.
Guideline
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).
92
Core Techniques for W3C technologies 160
160
http://www.w3.org/TR/WCAG10-CORE-TECHS/#access-reviewed
93
Checkpoint 11.2
Guideline
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.

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]
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
94
Checkpoint 12.3
Divide large blocks of information into more manageable groups where natural and appropriate.
Guideline
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).
Core Techniques – structural grouping 165
165
http://www.w3.org/TR/WCAG10-HTML-TECHS/#grouping
95
HTML Techniques – Grouping form controls 166
166
http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping
96
Checkpoint 13.1
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.
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/
97
Checkpoint 13.2
Provide metadata to add semantic information to pages and sites.
Guideline
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].
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
98
Checkpoint 13.3
Provide information about the general layout of a site (e.g., a site map or table of contents).
Guideline
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.
173
99
Checkpoint 13.4
Use navigation mechanisms in a consistent manner.
Guideline
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
100
How to test
 Browse through the website, identify navigation elements and ensure they are
consistent [Compulsory].
174
101
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).
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.
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].
Core Techniques: Structure vs. Presentation 175
HTML Techniques: Tables for layout 176
175
176
http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout
102
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.
Guideline
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.
103
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.
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.
Guideline
Why?
Associating labels with form fields ensures that screen readers read the appropriate label
for a particular field.
This toolkit provides information on forms.
104
Scripts and applets
Checkpoint 6.4
For scripts and applets, ensure that event handlers are input device-independent.
Guideline
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.
Guideline
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].
Core Techniques – Visual information and motion 177
HTML Techniques – Animated images 178
HTML Techniques – Scripts that cause movement and blinking 180
CSS Techniques – Creating movement with style sheets and scripts 181
177
178
http://www.w3.org/TR/WCAG10-HTML-TECHS/#animated-images
179
180
http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-movement-blinking
105
181
http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-movement
106
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.]
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
107
HTML Techniques – Directly accessible scripts 184
183
184
http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-scripts
185
186
108
Checkpoint 9.2
Ensure that any element that has its own interface can be operated in a device-independent
manner.
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].
187
188
189
190
109
Checkpoint 9.3
For scripts, specify logical event handlers rather than device-dependent event handlers.
Guideline
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].
191
192
193
194
110
Level AAA Checkpoints
Checkpoint 4.3
Identify the primary natural language of a document.
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]
HTML Techniques: Identifying the primary language 195
195
http://www.w3.org/TR/WCAG10-HTML-TECHS/#identify-primary-lang
111
Checkpoint 9.4
Create a logical tab order through links, form controls, and objects.
Guideline
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.
112
Checkpoint 13.5
Provide navigation bars to highlight and give access to the navigation mechanism.
Guideline
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].
196
113
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.
Guideline
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].
114
197
115
Checkpoint 14.2
Supplement text with graphic or auditory presentations where they will facilitate comprehension of
the page.
Guideline
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].
Core Techniques – Comprehension 198
198
http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension
116
Checkpoint 14.3
Create a style of presentation that is consistent across pages.
Guideline
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].
117
Core Techniques: Navigation 199
CSS Techniques: Decrease maintenance and increase consistency 200
199
200
http://www.w3.org/TR/WCAG10-CSS-TECHS/#consistency
118
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
119
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
Ground (MCG)
The venue for both Opening and Closing Ceremonies, Athletics and the start
and finish of the Marathon is approximately 2 km east of the city centre.
Multi Purpose Venue
(Melbourne Park)
The venue for the Basketball Finals, Track Cycling and Netball Finals is
approximately 2 km east of the city centre.
Rod Laver Arena
(Melbourne Park)
The venue for Gymnastics is approximately 2 km east of the city centre.
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/
120
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

202
W3C Checkpoint 11.4: If you cannot create an accessible page provide an alternative
http://webaim.org/techniques/alttext/
121
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.
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
122
<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>
</tr>
<tr>
<td headers="from">virginblue.com.au </td>
<td headers="subject">Virgin Blue Update!</td>
</tr>
</tbody>
</table>
Further information
123


Screen readers and the TH ID and TD HEADERS 204
Juicy Studio Complex Table Analyser 205
204
205
http://juicystudio.com/article/firefox-table-inspector.php
124
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
125
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 worldclass 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:
126




Name
Phone number
Email address
Postal address
Further Information
Text equivalents

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/
127
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.
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
128
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.
enabled.
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.
enabled.
129
2. Create the PDF
Word 2000 / Acrobat 5.0
Create the accessible PDF by selecting “Convert to Adobe PDF” under the
“Acrobat” menu.
Create the accessible PDF by selecting “Convert to Adobe PDF” under the
“Adobe PDF” menu.
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
130
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.
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
131
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
132
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:
133
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
134
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
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.
135
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
136
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 reserving 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:
137
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.
138
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, placeholding 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/
139




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
140
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.
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:
location.href ='page.html'”>
Page</a>
<a href=“page.html”>
Page</a>
Opening a new window
<a
href=“javascript:window.open
('page.html',
'_blank')”>Page</a>
<a href=“page.html”
target=“_blank”>
Form submission
<a href=“javascript:
this.form.submit();”>
Submit</a>
<input name=“submit”
type=“submit”
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:
141
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
142






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
143
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
144
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
145






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
146
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 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
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:
147
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
148
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
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
149
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 & Wheelbarrow
Incorrect:
150
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
151
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).
152
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
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
153
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.
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;
154
}
Incorrect:
body {
color: #000;
}
C. Specify text colour when background colour is defined
Whenever a background-colour is specified also specify a text-colour.
Correct
body {
background: #FFF;
color: #000;
}
Incorrect:
body {
background: #000;
}
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
155
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
156
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
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/
157




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
158
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.
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
159
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.
160
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
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
161
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.
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
162
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.
163
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)
164
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
apparent that the current
page is “Minister’s
Foreword” which sits under
Although the same information is presented visually with
style sheets disabled, the screen reader cannot easily
convey this information in audio. Without this
information it is difficult to determine the hierarchy of the
165
a sub-navigation item of “10
year…” which sits under the
main navigation item of
“DIIRD Strategies”
navigation.
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 seaside birds”, or “Sea-side birds”.
Example – Department of Education
166
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
167
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 subnavigation 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
168



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
279
http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp#download
280
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
169
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:
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
170
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/
171


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/
172
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.
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
173
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
174


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
Ensure that fields are placed close to the relevant field label
Break content into more manageable groups
Identify the target of each link
Include a sitemap or table of contents
175





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
176

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
177
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
178
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
Explorer
FireFox / Mozilla
Chrome
Safari
Opera
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%
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
179
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
180



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
 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
181
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
 FireFox 3.0.
 FireFox 2.0
 Opera
 Chrome
Mac OS X
 Safari
 FireFox 3.0
Windows Vista
 FireFox 3.0
Windows 2000
 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:
182





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-ABAA18E8E842178F&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/
183




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/
184
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.
185
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
186
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.
352

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
http://www.webaim.org/techniques/captions/hicaption/
187

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-innesstory?SQ_PAINT_LAYOUT_NAME=extended
188
Further Information


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/
189
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.
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
190

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
191

Replace
<video dur="0:02:19.75" region="videoregion"
src="original_movie.mp4"/>
with
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/
192
Captioning YouTube videos
 They are hearing impaired or deaf;
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
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
193
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)

Google Blog: YouTube launches auto-captioning

Mashable: YouTube launches auto-captioning for videos
194
Audio describing videos
There will be people who require audio descriptions because:


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.
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 .
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.
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
Create a project:
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
195
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.
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
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
196
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
src="original_movie.mp4"/>
with
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
with
begin="0:00:43.52"/>

Replace
with
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
375
376
http://www.gianwild.com.au/video-example
197
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
198
Captioning vodcasts
 They are deaf or hearing impaired;
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
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
Create a project:
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
382
http://www.apple.com/au/quicktime/
199
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.
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
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.
200
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
201
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”
202
Example 2: Koorie education captioned vodcast
A complex vodcast, complete with captions has been created at Gian Wild’s 385 web site
Further Information

synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track)

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/
203
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
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/
204
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

synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track)

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
205
Flash and accessibility
There will be people who won’t be able to access the Flash file because:




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.
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
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.
206
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
207
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)
208
Further Information


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
209
Mashups and accessibility
There will be people who won’t be able to access the mashup because:



They have a physical disability;

They have a cognitive disability;


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.
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
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/
210
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.
211
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
212
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:
213
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


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
214
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.
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/
215

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
216
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.
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:
217
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.

425
If the map is a transport map, organise the map by train, bus or train line and describe the
locations and distances travelled.
http://www.bom.gov.au/products/IDR023.shtml
218
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;

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.
different types of shading and change of colour to indicate different areas;
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:
219

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
220
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.
"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>
221
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/
222
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)
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/easyslideshare/?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/purplehack-fodder
Providing a transcript of the Slideshare presentation in text or HTML
It is important to provide a transcript of the presentation.
223

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-andtrust.html
439
http://icant.co.uk/easy-slideshare/about/
440
http://its.monash.edu/web/slideshows/accessibility-powerpoint/OETFull-en.exe
224
Facebook and accessibility
There will be people who won’t be able to access Facebook because:


They have a physical disability

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
225
Twitter and accessibility
There will be people who won’t be able to access Twitter because:

They are blind


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
226
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
What is WAVE?
449
http://www.w3.org/WAI/ER/existingtools.html
450
http://www.cynthiasays.com
227
The WAVE is a page-by-page accessibility evaluator that tests many of the W3C Web
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?
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?
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/
228
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?
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
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?
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
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
229
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.
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?
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
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?
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?
230
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?
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.
231
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?
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.
232
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
Level AAA
Cannot test some checkpoints
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.
2.
3.
4.
Create a new project by selecting the “New” button (1) in the bottom left corner.
Name the project and choose how you will access your files.
Select the Base folder and Save the project.
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.
233
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).
234
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).
235
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
236


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
237
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
Level AAA
Tests only one web page at a time
Emulates different browsers
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).
238
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
239
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;
240



(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:
 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:
241
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
242







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
243
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
of an entire page
Tests only one page at a time
Includes additional features such as the ability
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
244
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.
245
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:
246
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
provided without relying solely on colour
Disable
Disable Page Colors
4.1: determine whether the changes in the
language have been identified
Outline
Outline Custom
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
disabled
CSS
Disable Styles
6.3: identify the use of JavaScript
Information
View JavaScript
6.3: test whether the site can be used with
JavaScript disabled
Disable
Disable JavaScript
6.3: test whether the site can be used with Java
disabled
Disable
Disable Java
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
247
3.3: testing whether style sheets have been
used for layout and presentation
CSS 
Disable Styles
3.4: determine whether relative units have been
used for style sheet property values
Outline 
Outline Positioned
Elements
All Styles
Inline Styles
Relative
3.5: determine whether headings have been
used and whether they have been nested
Information
View Document
Outline
3.6: determine whether list markup has been
used
Outline
Block Level
Elements
3.7: determine whether quotes have been
marked up with Q and BLOCKQUOTE
Outline
Block Level
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
used to break up a form
Forms
View Form
Information
13.1: test whether links have clearly identified
targets
Information
View Link
Information
13.2: determine whether metadata has been
included
Information
View Meta Tag
Information
Level AAA Checkpoint
Menu
Test
4.2: test whether acronym and abbreviation
markup has been used
Outline
Outline Custom
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
shortcuts) have been used
Information
Display Access keys
10.3: test whether a table can be used if it is
linearised
Miscellaneous
Linearise Page
Examples
The following are failures from a random selection of website pages.
1. Missing ALT attributes
Test: Outline Images without Alt Attributes
248
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
249
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
250
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/
251
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
Level AAA
Details specific information, for instance ALT
attributes are provided with the relevant image
of an entire page
Displaying errors and other accessibility
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.
252
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
253

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
254
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
255
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
256
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
257
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.
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
258
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”.
this web page. Use this test to determine whether headings have been nested properly
within a web page.
259
Further Information
Help using WAVE

487
Using WAVE 487
http://webaim.org/resources/wave/
260
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
of an entire web page
Available in a variety of languages
Uses access keys for each function to allow
for use via a keyboard
Must reselect options for every new web page
tested
Includes additional features such as the ability
to resize the browser to other screen
resolutions
Limited to Internet Explorer and Opera web
browsers (the Firefox Web Developer
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.
261
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
489
http://www.paciellogroup.com/resources/wat-about.html
262
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:
263
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
provided without relying solely on colour
Images
Greyscale
4.1: determine whether the changes in the
language have been identified
Doc Info
Show Lang
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
disabled
CSS
Disable CSS
6.3: identify the use of JavaScript
Structure
JavaScript / New
Window Links
6.3: test whether the site can be used with Java,
Flash and iframes disabled
Tools 
Simulations
Disable Plug-ins
6.3: test whether the site can be used with
IE Options
Toggle JavaScript
490
264
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
or server-side
Images
Show Image Maps
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 
W3C HTML Validator
Validate HTML
3.2: validating the CSS
Validate 
Validate CSS
W3C CSS Validator
3.3: testing whether style sheets have been
used for layout and presentation
CSS
Show Applied Styles
Show Style Sheet(s)
3.4: determine whether relative units have been
used for style sheet property values
CSS
Show Style Sheet(s)
3.5: determine whether headings have been
used and whether they have been nested
Structure
Headings
Heading Structure
3.6: determine whether list markup has been
used
Structure
List items
3.7: determine whether quotes have been
marked up with Q and BLOCKQUOTE
Structure
Blockquote & Q
6.4: test whether device-dependent event
handlers have been used
Structure
JavaScript / New
Window Links
Event Handlers
10.1: test whether any links open in a new
window
Structure
JavaScript / New
Window Links
11.2: identify any deprecated HTML elements
Source
Deprecated HTML
12.3: determine whether FIELDSET has been
used to break up a form
Structure
Fieldset / Labels
12.4: determine whether field labels have been
explicitly associated with fields
Structure
Fieldset / Labels
13.1: test whether links have clearly identified
targets
Doc Info
List Links
13.2: determine whether metadata has been
included
Doc Info
Metadata
Information
Level AAA Checkpoint
Menu
Test
265
4.2: test whether acronym and abbreviation
markup has been used
Structure
Acronyms/
Abbreviations
9.4: identify the tab order of the page
Structure
Show Tab Order
9.5: identify whether access keys (keyboard
shortcuts) have been used
Structure
Access keys
10.3: test whether a table can be used if it is
linearised
Structure
Linearise (Remove
Tables)
Examples
The following are Web Accessibility Toolbar failures from a selection of random websites.
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
266
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”.
Test: Headings
267
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
492
http://www.paciellogroup.com/resources/wat-about.html
493
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/
268
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/watabout.html)
269

Victorian Government Accessibility Toolkit

Transcription

Similar documents

Great Selection pf Period Lighting! FURNITURE

Women move transportation forward

Accessibility for all.

Furniture Sale - Clee Tompkinson Francis

LESSON PLANS FROM “DRAWING ON NARRATIVE PAINTING”

design - Escola Design Thinking

Mr. Fezziwig`s Victorian Weekend

July, August, September 2014 - Alamo Head Injury Association

Our Water Our Vote