Docstoc

accessibility-toolkit-v3.1.1-mar2011

Document Sample
accessibility-toolkit-v3.1.1-mar2011 Powered By Docstoc
					Victorian Government Accessibility Toolkit eServices Unit, Information Victoria, Department
of Business and Innovation.  Version 3.1.1  March 2011
Enquiries should be addressed to –

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

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

September 2009

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



Copyright State Government of Victoria, 2009

The Accessibility Toolkit is subject to copyright. Except as otherwise permitted under
the Copyright Act 1968 you must not reproduce or transmit in any form or by any means
the Accessibility Toolkit without prior written permission of the State Government of
Victoria.
Section One: Introduction to the Accessibility toolkit        9
Section Two: Accessibility basics (business case) 14
What is accessibility? 14
Why is it important to create accessible web sites? 15
Accessibility policy and guidelines 29
Common accessibility questions         31
Section Three: How to make a web site accessible 34
How do you make a web site accessible?          34
Building an accessible site 35
Making an existing site accessible 36
Maintaining an accessible site         40
Incorporating accessibility into tenders        41
Building an accessible site 43
Evaluating a current site for accessibility (Evaluation phase)      47
Fixing a current site to achieve accessibility (Implementation phase)    49
Case Study 1 - Victoria Online (Department for Innovation, Industry and Regional
Development) 52
Case Study 2 -Youthcentral (Department for Victorian Communities)        54
Case Study 3 - Web Developer‘s Resource Kit (Department of Education and Early Childhood
Development) 56
Section Four: Understanding and testing Level A, AA and AAA checkpoints         59
Introduction to the Level A and Level AA checkpoints          59
Level A, Level AA and non-essential Level AAA checkpoints           60
General checkpoints 62
Checkpoints on image maps 74
Checkpoints on tables 76
Checkpoints on frames          78
Checkpoints on applets and scripts 79
Checkpoints on multimedia 81
If you can‘t make it accessible        83
Level AA Checkpoints           84
Checkpoint 2.2          84
Checkpoint 3.1          85
Checkpoint 3.3          87
Checkpoint 3.4          88
Checkpoint 3.5          89
Checkpoint 3.6          90
Checkpoint 3.7          91
Checkpoint 6.5          92
Checkpoint 7.2          93
Checkpoint 7.4          94
Checkpoint 7.5          95
Checkpoint 10.1         96
Checkpoint 11.1         97
Checkpoint 11.2         98
Checkpoint 12.3         99
Checkpoint 13.1        100
Checkpoint 13.2        101
Checkpoint 13.3        102
Checkpoint 13.4        103
Tables 104
Checkpoint 5.3         104
Checkpoint 5.4         104
Frames 105
Checkpoint 12.2        105
Forms 106
Checkpoint 10.2        106
Checkpoint 12.4        106
Scripts and applets 107
Checkpoint 6.4         107
Checkpoint 7.3         107
Checkpoint 8.1         108
Checkpoint 9.2         109
Checkpoint 9.3         110
Checkpoint 4.3         111
Checkpoint 9.4         112
Checkpoint 13.5        113
Checkpoint 13.6        114
Checkpoint 14.2        115
Checkpoint 14.3        116
Section Five: Top issues       117
Making images, image maps, maps and graphs accessible 118
Making tables accessible       120
PDFs and accessibility         123
Making a PDF accessible        126
Creating accessible forms      130
JavaScript      138
Making splash pages accessible        142
Creating valid HTML pages 144
Creating valid CSS 150
Page source order      155
Page structure 157
Ensuring sufficient colour contrast 161
Creating sites accessible to people with cognitive disabilities 164
Conducting Operating System and Browser testing 171
Additional accessibility features     177
Videos and accessibility       178
What about YouTube videos? 178
What about vodcasts? 178
What about live streaming content? 178
Relationship to WCAG1 checkpoints 179
Complying with accessibility requirements when including video 179
Example 1: Transcript of a video      180
Further Information 180
Captioning downloadable videos        181
Relationship to WCAG1 checkpoints:           181
Tools you will need 181
Using MAGpie to create captions       181
Example 1: Koorie education with Learning Objects, Part 1 183
Further Information 183
Captioning YouTube videos 184
Relationship to WCAG1 checkpoints:           184
Tools you will need 184
Using MAGpie to create captions       Error! Bookmark not defined.194
Using Subtitle Workshop to convert the file Error! Bookmark not defined.195
Uploading captions to YouTube         Error! Bookmark not defined.196
Example 1: Koorie education with Learning Objects, Part 1 Error! Bookmark not defined.196
Further Information 184
Audio describing videos       186
Relationship to WCAG1 checkpoints:           186
Tools you will need 186
Using MAGpie to create audio descriptions 186
Testing the audio descriptions        187
Putting the audio described video on a web site    187
Example 1: Koorie education with Learning Objects, Part 1 188
Further information 188
Captioning vodcasts 189
Relationship to WCAG1 checkpoints:           189
Tools you will need 189
Using MAGpie to create captions       189
Associate captions with the vodcast 190
Example 1: Test vodcast       191
Example 2: Koorie education captioned vodcast      191
Further Information 191
Audio and podcasts 193
Relationship to WCAG1 checkpoints:           193
Tools you will need to create a podcast      193
Complying with accessibility requirements when creating podcasts 193
Example 1: A test podcast     194
Further Information 194
Flash and accessibility       195
Relationship to WCAG1 checkpoints 195
Complying with accessibility requirements when including Flash 195
Example 1: Transcript of a Flash file 196
Further Information 197
Mashups and accessibility     198
Relationship to WCAG1 checkpoints 198
Complying with accessibility requirements when including mashups      198
Example 1: Transcript of a mashup 198
Example 2: Doodle for Google Australia       200
Further Information 200
Blogging and accessibility 201
Relationship to WCAG1 checkpoints:           201
Complying with accessibility requirements when creating blogs   201
Example 1: Gian Wild‘s blog 201
Further Information 201
Making maps and Google maps accessible 203
Relationship to checkpoints: 203
What about Google maps? 203
Complying with accessibility requirements when creating maps    203
Example 1: An accessible bushfires map       205
Example 2: An accessible Google map          206
Further Information 206
Frames and iFrames 207
Relationship to WCAG1 checkpoints:           207
What are iFrames? 207
Creating accessible iFrames 207
Example 1: Accessible iFrame            208
Further Information 208
Making Slideshare accessible 209
Relationship to WCAG1 checkpoints:           209
Can Slideshare presentations be embedded in a site? 209
Creating accessible Slideshare presentations 209
Example 1: Embedded Slideshare 210
Further Information 210
Facebook and accessibility 211
Creating accessible Facebook 211
Example 1: Target 155           211
Further Information 211
Twitter and accessibility       212
Creating accessible Twitter 212
Example 1: John Brumby          212
Further Information 212
Section Six: Accessibility evaluation tools 213
Page-by-page accessibility evaluation tools 213
Specific accessibility evaluation tools      217
Entire site accessibility evaluation tools   219
AccVerify       221
Cynthia Says 223
Firefox Web Developer Toolbar           227
The WAVE (version 4.0)          232
Web Accessibility Toolbar 236
Section Seven: Accessibility resources       242
Section One: Introduction to the Accessibility toolkit
The Victorian Government Accessibility Toolkit
The Victorian Government‘s Accessibility Standard1 requires that:
All websites must be Level AA compliant (W3C Web Content Accessibility Guidelines, Version
1.0)
Where audience needs are specific, websites should become Level AAA .

This toolkit shows departments and agencies how to conform to this standard and the W3C Web
Content Accessibility Guidelines, Version 1.0. The toolkit is designed for Victorian Government
business managers and web site owners to enable them to effectively present the business case
for accessibility and manage the processes involved.
What about the Web Content Accessibility Guidelines, Version 2.0?
In December 2008, the W3C released the second version of the W3C Web Content Accessibility
Guidelines (WCAG2). According to the W3C these now supersede WCAG1. However, in
Victoria, we are still bound by the AHRC Disability Discrimination Act and the WOVG
Accessibility Standard. Both these standards still recommend the use of WCAG1 (correct as of
1st June 2009).

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

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

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

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

Conclusion
Due to the policy decisions that surround WCAG2 it is not recommended that WCAG2 be used
until both the AHRC and the Victorian Government have endorsed it.

The AHRC recommends testing with the first version of the W3C Web Content Accessibility
Guidelines. This is still true, despite the fact that a second version of these guidelines has just
been released as a W3C Candidate Recommendation. Once the AHRC have endorsed the
guidelines it may be some time before sites that are compliant with the first version of WCAG
will need to comply with WCAG 2.0.
About the author
Gian Wild has worked in the accessibility industry since 1998 when she was the accessibility
specialist on the first Australian Level AAA web site, Disability Information Victoria. Gian Wild
worked as the accessibility specialist for Melbourne 2006 Commonwealth Games, conducting
audits of the site and training Commonwealth Games staff including suppliers such as Microsoft
and Ticketmaster7. Gian wrote the original and updated Victorian Government Accessibility
Toolkit. More recently, Gian wrote a series of accessibility fact sheets for the Office for
Disability.
Contents of the Toolkit
Section One: Introduction

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

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

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

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

Section Six: Accessibility evaluation tools
Accessibility evaluation tools can be complex and often do not include adequate documentation
or instructions. This section covers how to use the more popular accessibility evaluation tools.
Section Seven: Accessibility resources
A list of common accessibility resources.
Section Two: Accessibility basics (business case)
This section introduces accessibility and describes the benefits of making web sites accessible.
The purpose is to give Victorian Government departments and agencies an understanding of how
accessible sites help people with disabilities, as well as the benefits to the wider community.
What is accessibility?
Accessibility means making web information available to all people, regardless of their ability.
Accessibility also assists people with varying means and technologies to access web information.

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

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

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

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

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

Increases the usability of a site
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 Act2. This Act requires that information be provided to all people without
discriminating on the basis of disability.
Assists people with disabilities
Approximately 20% of people in Australia3 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:
                                    4
Keyboards and other input devices
                            5
Braille and Low Vision aids
                             6
Alternative pointing devices
           7
Other aids

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

Alternative keyboards
Keyboards that have limited keys for people with motor disabilities.
Keyboards manipulated by fingers10
Keyboards manipulated using a head-wand11.

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 readers12
JAWS screen-reader13
Window Eyes14

Screen Magnifiers
Programs that magnify sections of the screen for people with vision impairments.
Video – Screen magnification and the web15
Windows Screen Magnifier16

Oversized cursors
Large cursors for people with vision impairments.
―Biggy‖ cursors17.

Onscreen keyboards
Keyboards for people with motor disabilities used in combination with switching devices.
On-screen keyboard18.

Programs that slow down applications for people with motor disabilities.
CPU Killer19 (for Windows)

More information

Disability, Ageing and Carers, Australia: Summary of Findings, 200320
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 disability21
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 People22
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 Web23
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 Disabilities24
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
Technology25
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.

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.


More information

Agelight – Design Guidelines for Users of All Ages26
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 issues27
The eGovernment Resource Centre archives all regional and rural issues highlighted in their
eGovernment weekly newsletter.

Usability for Senior Citizens28
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 Citizens29
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 Users30
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 Guidelines31
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 Guidelines32
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.
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.com33
Jakob Nielsen‘s web site on usability.

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

Cooper.com35
Cooper also provides regular newsletters on usability issues

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

Gerry Gaffney UXPod37
Podcasts of interviews and on various different usability issues by Melbourne Usability
Specialist, Gerry Gaffney.
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.
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 Optimization39
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 Techniques40
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 revisited42.

Examples of accessible sites43
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 People44
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 sites46



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

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 Standards48
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 disability49. 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 Act50 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.‖

HREOC. Version 3.1 May 1999. World Wide Web Access: Disability Discrimination Act
Advisory Notes51.

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 site52.
More information

Olympic Failure: A Case for Making the Web Accessible53
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 Notes54
Australian Human Rights Commission, Disability Discrimination Act web advisory notes.

Government warned on Web site discrimination55
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 Standard56 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.057 contain the following fourteen
guidelines:
                                                                  58
Provide equivalent alternatives to auditory and visual content.
                            59
Don’t rely on colour alone.
                                                  60
Use markup and style sheets and do so properly.
                                61
Clarify natural language usage.
                                       62
Create tables that transform gracefully.
                                                                   63
Ensure that pages featuring new technologies transform gracefully.
                                                 64
Ensure user control of time-sensitive changes.
                                                        65
Ensure direct Accessibility of embedded user interfaces.
                                  66
Design for device-independence.
                       67
Use interim solutions.
                                        68
Use W3C technologies and guidelines.
                                             69
Provide context and orientation information.
                                       70
Provide clear navigation mechanisms.
                                               71
Ensure that documents are clear and simple.

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.
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 Standard73
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 138.
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:
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.com74.

Improving usability can make a site accessible. Enhancing accessibility will often also improve
usability.
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.
Building an accessible site

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

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

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

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

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

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

The W3C has written a document called Selecting and Using Authoring Tools76 which can assist
you in deciding what tools to use when building your site.
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).

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 Checkpoints77 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
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 claims78.




Specifying conformance to the W3C Web Content Accessibility Guidelines                         W3C AA
Level logo W3C AA Level text     Insert the following code into the site. For more information see adding the
Level AA logo79 Insert the following text in the necessary place on the site.
<a href="http://www.w3.org/WAI/WCAG1AA-Conformance" 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>

―This site conforms to W3C's "Web Content Accessibility Guidelines 1.0", available at
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level AA.‖
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.
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.

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).
Building an accessible site

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

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

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

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

Designer Checklist. Yes No             Checkpoint 1.3: Are audio descriptions provided for visual
content in a video and is a text transcript provided?         Checkpoint 1.4: Do all time-specific
presentation have equivalent alternatives synchronized with the presentation?             Checkpoint
2.1: Do you use some means other than colour to identify information?              Checkpoint 6.1: Is
the site readable if style sheets are turned off?        Checkpoint 6.2: Where content is
automatically generated is a static version provided that is updated at the same
time?          Checkpoint 6.3: Does the site still function and can users navigate through the site
if JavaScript, Flash and other programs are turned off or not supported?            Checkpoint 7.1:
Is the site free of flickering images?         Checkpoint 2.2: Is there sufficient colour
contrast?          Checkpoint 3.5: Are there headings and are they nested
properly?           Checkpoint 10.1: Are users warned before links open in a new
window?            Checkpoint 12.3:Is information broken up by using headings, data tables and
lists?         Checkpoint 13.1: Are all links properly descriptive?          Checkpoint 13.3: Is a
site map, A- Z index or table of contents provided?           Checkpoint 13.4 and 13.5: Is
navigation consistent across the site?            HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-interim-accessibility"
     Checkpoint 10.2 : Do all fields have descriptive labels?             HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-movement"                  Checkpoint 7.2 :
There is no blinking?              HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "gl-movement"          Checkpoint 7.3 : Can any movement be stopped by the
user?             HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
facilitate-navigation"       Checkpoint 13.6 : Are visible skip navigation links
provided?               HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
facilitate-comprehension"        Checkpoint 14.2 : Are graphics and audio used to complement
text            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
facilitate-comprehension"        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           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-text-equivalent"   Checkpoint 1.1 : Do all images have ALT
attributes?           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l
"tech-text-equivalent"     Checkpoint 1.1 : Do all ornamental or spacer images have empty
ALT attributes (eg. alt=―‖)?          HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-identify-changes"    Checkpoint 4.1 : Are all changes in language
identified in the code?          HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-table-headers"      Checkpoint 5.1 and 5.2 : Do all data tables have
coded row and column headers using the TH ID and TD HEADER attributes?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "tech-unassociated-
labels"     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)?               HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "tech-associate-labels"             Checkpoint
12.4 : Are all field labels associated with the relevant field using the FOR and ID
attributes?           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l
"tech-color-convey"       Checkpoint 2.1 : Do you use some means other than colour to identify
information?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l
"tech-client-side-maps"      Checkpoint 9.1 : Are all image maps provided client-side instead of
server-side wherever possible?             HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-frame-titles"     Checkpoint 12.1 : Are there no frames?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-
presentation"     Checkpoint 3.1 : Are there no images of text?              HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-presentation"
     Checkpoint 3.2 : Do all pages validate to the W3C HTML Validator and the W3C CSS
Validator?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
structure-presentation"      Checkpoint 3.3 : Are style sheets, used instead of tables to control
layout and presentation?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "gl-structure-presentation"      Checkpoint 3.4 :Are relative rather than
absolute units used in tables and style sheet property values?            HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-presentation"
     Checkpoint 3.5 : Are headings coded using H1, H2, H3?                 HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-presentation"
     Checkpoint 3.6 : Are lists coded properly?             HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-presentation"
     Checkpoint 3.7 : Are quotations coded using Q and BLOCKQUOTE?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-
presentation"     Checkpoint 3.7 : BLOCKQUOTE is not used to indent text?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-movement"
     Checkpoint 7.4 : Pages do not periodically refresh?              HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-movement"               Checkpoint 7.5 :
Redirects are server side only?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "gl-use-w3c"       Checkpoint 11.2 : <EM> is used instead of <I> and
<STRONG> instead of <B>?                 HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "gl-facilitate-navigation"     Checkpoint 13.2 : Metadata is
included?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
complex-elements"        Checkpoint 12.4 : Fields use the LABEL FOR and ID tags?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-new-technologies"
     Checkpoint 6.4 : All JavaScript controls can be used by the keyboard or the
mouse?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
abbreviated-and-foreign"       Checkpoint 4.3 : The language is coded in the HEAD
area?           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
device-independence"        Checkpoint 9.4 : Does the order of the code match the order of the
page with style sheets turned on?             HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-facilitate-navigation"
    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            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-text-equivalent"       Checkpoint 1.1 : Are the text equivalents of
images, Flash, PDF and JavaScript meaningful?               HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "tech-redundant-server-links"
     Checkpoint 1.2 : Are all links in a server-side image map replicated as text links elsewhere
on the same page?             HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-color-convey"         Checkpoint 2.1 : Do you use some means other than
colour to identify information?             HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "tech-identify-changes"        Checkpoint 4.1 : Check for any language changes
in the content that need to be identified in the code.         HYPERLINK
"http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "tech-alt-pages"             Checkpoint
11.4 : If you cannot make a section of the site accessible is there another accessible
version?            HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "tech-
simple-and-straightforward"       Checkpoint 14.1 : Is the content clear and concise?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-structure-
presentation"      Checkpoint 3.5 : Are headings used and nested properly?
HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-complex-elements"
     Checkpoint 12.3 : Are large blocks of information broken up into natural groupings using
tables, headings and lists?           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-
pageauth.html" \l "gl-facilitate-navigation"      Checkpoint 13.1 : Is the target of each link
clear?           HYPERLINK "http://www.w3.org/TR/WCAG10/wai-pageauth.html" \l "gl-
facilitate-comprehension"       Checkpoint 14.2 : Are additional graphics and audio used to
supplement textual content.?
Case Study 1 - Victoria Online (Department for Innovation, Industry and Regional
Development)

Victoria Online ( HYPERLINK "http://www.vic.gov.au/"         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 accessibility into their build quote. The
resourcing and planning this adds to a web site project is significant.

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

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

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

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

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

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
HYPERLINK "http://www.education.vic.gov.au/devreskit/" DEECD Web Developer‘s
Resource Kit    .
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.
Level A, Level AA and non-essential Level AAA checkpoints

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

Guideline Checkpoint Done            1.1 Provide a text equivalent for every non-text element (e.g.,
via "alt", "longdesc", or in element content). This includes: images, graphical representations of
text (including symbols), image map regions, animations (e.g., animated GIFs), applets and
programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical
buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of
video, and video.
Images such as spacers should have an ALT description of ALT=― ‖              1.2 Provide
redundant text links for each active region of a server-side image map.         1.3 Until user
agents can automatically read aloud the text equivalent of a visual track, provide an auditory
description of the important information of the visual track of a multimedia
presentation.       1.4 For any time-based multimedia presentation (e.g., a movie or animation),
synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track)
with the presentation.       2.1 Ensure that all information conveyed with color is also available
without color, for example from context or markup.           2.2 Ensure that foreground and
background color combinations provide sufficient contrast when viewed by someone having
color deficits or when viewed on a black and white screen.          3.1 When an appropriate
markup language exists, use markup rather than images to convey information.             3.2 Create
documents that validate to published formal grammars            3.3 Use style sheets to control
layout and presentation.        3.4 Use relative rather than absolute units in markup language
attribute values and style sheet property values.       3.5 Use header elements to convey
document structure and use them according to specification.          3.6 Mark up lists and list
items properly.       3.7 Mark up quotations. Do not use quotation markup for formatting
effects such as indentation.       4.1 Clearly identify changes in the natural language of a
document's text and any text equivalents         4.3 Identify the primary natural language of a
document.         5.1 For data tables, identify row and column headers.         5.2 For data tables
that have two or more logical levels of row or column headers, use markup to associate data cells
and header cells.       5.4 If a table is used for layout, do not use any structural markup for the
purpose of visual formatting.        6.1 Organize documents so they may be read without style
sheets. For example, when an HTML document is rendered without associated style sheets, it
must still be possible to read the document.        6.2 Ensure that equivalents for dynamic
content are updated when the dynamic content changes.            6.3 Ensure that pages are usable
when scripts, applets, or other programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible page.         6.4 For scripts
and applets, ensure that event handlers are input device-independent.         6.5 Ensure that
dynamic content is accessible or provide an alternative presentation or page.         7.1 Until user
agents allow users to control flickering, avoid causing the screen to flicker.       7.2 Until user
agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at
a regular rate, such as turning on and off).      7.3 Until user agents allow users to freeze
moving content, avoid movement in pages.            7.4 Until user agents provide the ability to stop
the refresh, do not create periodically auto-refreshing pages.       7.5 Until user agents provide
the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead,
configure the server to perform redirects.         8.1 Make programmatic elements such as scripts
and applets directly accessible or compatible with assistive technologies          9.1 Provide
client-side image maps instead of server-side image maps except where the regions cannot be
defined with an available geometric shape.           9.2 Ensure that any element that has its own
interface can be operated in a device-independent manner.          9.3 For scripts, specify logical
event handlers rather than device-dependent event handlers.          9.4 Create a logical tab order
through links, form controls, and objects.         10.1 Until user agents allow users to turn off
spawned windows, do not cause pop-ups or other windows to appear and do not change the
current window without informing the user.            10.2 Until user agents support explicit
associations between labels and form controls, for all form controls with implicitly associated
labels, ensure that the label is properly positioned.       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.
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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                  http://www.w3.org/TR/WCAG10/

Guideline
Provide equivalent alternatives to auditory and visual content

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

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

This toolkit provides information about HYPERLINK \l "makingimages"             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)

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

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

To create a long description you need to use the LONGDESC attribute:
<IMG SRC=‖tandberg.gif‖ height=‖15‖ width=‖10‖ ALT=―A Tandberg cartoon‖
longdesc="tandberg.html">
Then you will need to create the file referenced in the LONGDESC attribute (in this case
tandberg.html) with appropriate descriptive text, for example:

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

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

Techniques for addressing Checkpoint 1.1
   HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/text-equivalent"      Text
equivalents
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/list-images"       Images
used as bullets
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/link-text-images"      Text
for images used as links
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/image-text-equivalent"
     Short text equivalents for images ("alt-text")
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/long-descriptions"
     Long descriptions of images
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/client-side-text-equivs"
     Text equivalents for client-side image maps
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/applet-text-equivalent"
     Text and non-text equivalents for applets and programmatic objects
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/text-equivs-multimedia"
     Text equivalents for multimedia
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/frame-text-equivalent"
    Describing frame relationships
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/noframes"     Writing for
browsers that do not support FRAME
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/forms-graphical-buttons"
    Graphical buttons
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/scripts-alt"  Alternative
presentation of scripts
Checkpoint 2.1
Level A
Ensure that all information conveyed with color is also available without color, for example from
context or markup.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                http://www.w3.org/TR/WCAG10/

Guideline
Don‘t rely on colour alone.

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

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

Fields in red are compulsory:

Name:
Address:
Contact details:


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

Fields in red marked (required) are compulsory:

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


Previously an asterisk was recommended to indicate compulsory fields, but recent research has
found that HYPERLINK
"http://www.nils.org.au/ais/web/resources/ozewai2003/short_forms.htm"       not all screen
readers read out an asterisk symbol   .

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


Days coloured in aqua are school holidays.

Mon Tue Wed Thu Fri Sat Sun             1 2 3 4 5 6           7 8 9 10 11 12 13               1
4 15 16 17 18 19 20         21 22 23 24 25 26 27             28 29 30
The above example can be made more accessible by simply stating the dates of the school
holidays, for example:

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

Mon Tue Wed Thu Fri Sat Sun                 1 2 3 4 5 6         7 8 9 10 11 12 13              1
4 15 16 17 18 19 20            21 22 23 24 25 26 27            28 29 30
How to test
Manually browse the site and check that colours have not been used to indicate different items on
a page [Compulsory]

Techniques for addressing Checkpoint 2.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "structure"      Structure
vs. presentation
   HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "style-info-not-in-color-
alone"     Ensuring information is not in colour alone
Checkpoint 4.1
Level A
Clearly identify changes in the natural language of a document's text and any text equivalents
(e.g., captions).
   HYPERLINK "http://www.w3.org/TR/WCAG10/"               http://www.w3.org/TR/WCAG10/

Guideline
Clarify natural language usage.

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

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


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


The correct HTML code for the above example would be:

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

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

Techniques for addressing Checkpoint 4.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "changes-in-lang"
   Identifying changes in language
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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                http://www.w3.org/TR/WCAG10/

Guideline
Ensure that pages featuring new technologies transform gracefully.

Why?
This is to ensure that the site is legible when the browser does not support style sheets. Recent
research suggests that it is HYPERLINK "http://www.usability.com.au/resources/source-
order.cfm" preferable to retain the original site‘s layout 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 HYPERLINK \l "css"      creating valid CSS          and
building HYPERLINK \l "pagesource"        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:


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]

Techniques for addressing Checkpoint 6.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "Generated"
    Generated content
  HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "style-rules"           Rules and
borders
  HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "style-transform-
gracefully"    Using style sheet positioning and markup to transform gracefully
Checkpoint 6.2
Level A
Ensure that equivalents for dynamic content are updated when the dynamic content changes.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"               http://www.w3.org/TR/WCAG10/

Guideline
Ensure that pages featuring new technologies transform gracefully.

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

Example
An example of a programmatic object is the ―Salam‖ Indonesian activity on the HYPERLINK
"http://www.education.vic.gov.au/languagesonline/"    Languages Online       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:
Hai!                   Hai means ―Hi‖
                       Hai is pronounced hi-e
Selamat pagi!          Selamat pagi means ―Good morning‖
                       Selamat pagi is pronounced sell-amat pag-e with a hard g
Selamat sore!          Selamat sore means ―Good (late) afternoon‖
                       Selamat sore is pronounced sell-amat sore-ee
Sampai jumpa           Sampai jumpa means ―See you later‖
                       Sampai jumpa is pronounced sump-ay joomp-a
Selamat siang          Selamat siang means ―Good (middle of the) day‖
                       Selamat siang is pronounced sell-amat see-ang with a hard g
Selamat malam          Selamat malam means ―Good evening / night‖
                       Selamat malam is pronounced sell-amat mull-um

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

Techniques for addressing Checkpoint 6.2
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "applet-text-equivalent"
   Text and non-text equivalents for scripts and programmatic objects
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "frame-has-html-src"
   Frame sources
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "scripts-alt"
   Alternative presentation of scripts
Checkpoint 7.1
Level A
Until user agents allow users to control flickering, avoid causing the screen to flicker.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                  http://www.w3.org/TR/WCAG10/

Guideline
Ensure user control of time-sensitive content changes.

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

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

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

Techniques for addressing Checkpoint 7.1
   HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "flicker"   Screen
flicker
   HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "video-information"
    Visual information and motion
Checkpoint 14.1
Level A
Use the clearest and simplest language appropriate for a site's content.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                 http://www.w3.org/TR/WCAG10/

Guideline
Ensure that documents are clear and simple.

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

This toolkit provides information about    HYPERLINK \l "cogdis"           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 HYPERLINK
"http://juicystudio.com/services/readability.php"    Juicy Studio Readability Test
[Compulsory]
Manually browse through all instructions and ensure they are specified in step by step point form
[Optional]
User test the site with someone from an English as a Second Language background, e.g.
someone born profoundly deaf or for whom AUSLAN is their first language [Optional]

Techniques for addressing Checkpoint 14.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "comprehension"
   Comprehension
Checkpoints on image maps
Checkpoint 1.2
Level A
Provide redundant text links for each active region of a server-side image map.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                  http://www.w3.org/TR/WCAG10/

Guideline
Provide equivalent alternatives to auditory and visual content.

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

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

This toolkit provides information on HYPERLINK \l "makingimages" making images
and image maps accessible and information on HYPERLINK \l "googlemaps"    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]

Techniques for addressing Checkpoint 1.2
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "text-equivalent"
   Text equivalent
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "server-side"     Server
side image maps

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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"               http://www.w3.org/TR/WCAG10/

Guideline
Design for device-independence when viewing pages.

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

This toolkit provides information on HYPERLINK \l "makingimages" making images
and image maps accessible and information on HYPERLINK \l "googlemaps"    Google
maps .

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

Techniques for addressing Checkpoint 9.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "client-vs-server-side"
   Client side vs server side image maps
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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                http://www.w3.org/TR/WCAG10/

Guideline
Create tables that transform gracefully.

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

Table headers should be included as TH ID and TD HEADERS. SCOPE should not be used as it
is not HYPERLINK "http://www.usability.com.au/resources/tables.cfm"      recognized by
some screen readers    . This toolkit provides information about HYPERLINK \l "tables"
    making tables accessible .

Example
The Commonwealth Games web site contained a number of data tables categorizing results and
scheduling. The following is from the HYPERLINK
"http://www.melbourne2006.com.au/Schedule+and+Results/By+Sport/Boxing"        Boxing
results   .



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

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

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 HYPERLINK "http://wave.webaim.org/index.jsp"                WAVE        or the HYPERLINK
"http://juicystudio.com/article/firefox-table-inspector.php"     Juicy Studio Complex Table
Analyser       to analyse the headers used in a data table [Compulsory]
User test the site with a blind or visually impaired person using a screen-reader [Optional]

Techniques for addressing Checkpoint 5.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "identifying-table-rows-
columns"     Identifying row and column information
Checkpoints on frames
Checkpoint 12.1
Level A
Title each frame to facilitate frame identification and navigation
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                 http://www.w3.org/TR/WCAG10/

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

Guideline
Provide context and orientation information.

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

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

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

This toolkit provides information on    HYPERLINK \l "frames"          Frames and iframes .

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

Techniques for addressing Checkpoint 12.1
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "frame-names"
   Providing a frame title
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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                  http://www.w3.org/TR/WCAG10/

Guideline
Ensure that pages featuring new technologies transform gracefully

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

This toolkit provides information about:
   HYPERLINK \l "js"        JavaScript ;
creating alternatives to HYPERLINK \l "pdfs"        PDFs ;
creating HYPERLINK \l "makingpdfsaccessible"          accessible PDFs ;
creating HYPERLINK \l "mashups"             mashups ;
   HYPERLINK \l "flash"         Flash ; and
   HYPERLINK \l "googlemaps"          maps and Google maps .

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

Ray and Gwen Cocker, Upholsterer and Stitcher - immigrated from the United Kingdom
Oscar Furniture, Horsham (West Victoria)
A great mix of work and pleasure is how husband and wife team, Ray and Gwen Cocker, as well
as Jeff Thurston describe their move to Victoria from the United Kingdom.
The three are based in Horsham in Victoria's west, all working for Oscar Furniture, a
manufacturing company that employed the British trio after searching the world for the perfect
people to fill its long-term vacancies.
For their prospective employer 'Down Under', Ray and Gwen had the advantage of having been
self-employed as an upholsterer and stitcher respectively, as well as having worked for a
company for five years.
Ray and Gwen concur that this background has helped them get the most out of their new
position.
"It's no problem at all. We want to continue working for Oscar Furniture and make sure it's a
successful furniture company and we'll take it from there and just enjoy ourselves, basically.
That's what we have come over here to do, work and enjoy."
Their fellow countryman and colleague, Jeff Thurston, is also finding the living easy.
"I've been given an opportunity to settle in a nice country. It's got great prospects for me and my
family, whereas England wouldn't," he explains.
"I've been able to find new friends now and the experience is pretty good at the moment. My
fiancée has just come over from England and she is working for River Base Hospital as a nurse,
so I think things have begun to come together for us."
Oscar Furniture owner Anthony Op de Coul points out that although the preliminary work to get
his skilled migrants to Australia took some time, it was still a better alternative than his previous
fruitless searches.
"It's not a quick fix solution, it takes time - six months or longer. But it is a solution. (We)
weren't getting anywhere for a number of years.
"Over the last 10 years I guess we had advertised on and off in the city and the like, to get skilled
trades people with no avail. After having no luck advertising overseas myself in South Africa,
someone put me onto the State Government's Skilled Migration Unit and I contacted them.
"They had some contacts with the furniture Guild in England and they placed an ad in their
magazine and from that ad I have ended up with three staff."
Jeff openly encourages other employers to consider looking beyond Australia's borders to fill
their vacancies.
"It's worth putting an effort into (that is) to find some people to come over - there are a lot of
good people in other countries that can really help develop skills in this country," he says.


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

Techniques for addressing Checkpoint 6.3
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "applet-text-equivalent"
    Text and non-text equivalents for applets and programmatic objects
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "directly-accessible-
scripts"   Directly accessible scripts
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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                 http://www.w3.org/TR/WCAG10/

Guideline
Provide equivalent alternatives to auditory and visual content.

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

This toolkit provides information on:
  HYPERLINK \l "videos"          video ;
  HYPERLINK \l "captioningvideos"          captioning video ;
  HYPERLINK \l "audiovideos"          audio describing video ;
  HYPERLINK \l "captioningvodcasts"          vodcasts ; and
  HYPERLINK \l "youtube"           YouTube videos .

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

Techniques for addressing Checkpoint 1.3
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "video-information"
   Visual information and motion
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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                   http://www.w3.org/TR/WCAG10/

Guideline
Provide equivalent alternatives to auditory and visual content.

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

This toolkit provides information on:
  HYPERLINK \l "videos"          video ;
  HYPERLINK \l "captioningvideos"          captioning video ;
  HYPERLINK \l "audiovideos"          audio describing video ;
  HYPERLINK \l "captioningvodcasts"          vodcasts ; and
  HYPERLINK \l "youtube"           YouTube videos .

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

Techniques for addressing Checkpoint 1.4
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "audio-information"
   Audio information
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "accessible-applets"
   Directly accessible applets
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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/"                   http://www.w3.org/TR/WCAG10/

Guideline
Use W3C technologies and guidelines.

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

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

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

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

Techniques for addressing Checkpoint 11.4
  HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "alt-pages"
   Alternative pages
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
   HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Don't rely on color alone.

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

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

This toolkit provides information on creating   HYPERLINK \l "colour"         high colour
contrast .
Checkpoint 3.1
When an appropriate markup language exists, use markup rather than images to convey
information.
   HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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

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




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

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

How to test
Disable style sheets and determine whether structure is maintained. [Compulsory].
Increase text size and see if any content pixellates [Compulsory].

Techniques for addressing Checkpoint 3.1
HTML Techniques – using markup
HTML Techniques – Structure vs Presentation
Checkpoint 3.2
Create documents that validate to published formal grammars.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"              http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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

This toolkit provides information on   HYPERLINK \l "creatingvalidhtml"        creating valid
HTML pages .
Checkpoint 3.3
Use style sheets to control layout and presentation.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"              http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

This toolkit provides information on HYPERLINK \l "pagestructure" page structure ,
HYPERLINK \l "pagesource"          page source order and HYPERLINK \l "css"   creating
valid CSS .
Checkpoint 3.4
Use relative rather than absolute units in markup language attribute values and style sheet
property values.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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


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

Techniques for addressing Checkpoint 3.4
CSS Techniques – Relative units
Checkpoint 3.5
Use header elements to convey document structure and use them according to specification.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"             http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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



How to test
For details on how to test headings see the   HYPERLINK \l "section6"        evaluation tools
section .

Techniques for addressing Checkpoint 3.5
  HYPERLINK "http://www.webaim.org/techniques/semanticstructure/" WebAIM –
Creating semantic structure
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "document-headers"
   Section headings
                   Checkpoint 3.6
Mark up            lists and list items properly.
 HYPERLINK "http://www.w3.org/TR/WCAG10/"               http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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



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

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



Techniques for addressing Checkpoint 3.6
HTML Techniques – Lists
                Checkpoint 3.7
Mark up         quotations. Do not use quotation markup for formatting effects such as
indentation.                 HYPERLINK "http://www.w3.org/TR/WCAG10/"
                            http://www.w3.org/TR/WCAG10/

Guideline
Use markup and style sheets and do so properly.

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

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

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


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

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



Techniques for addressing Checkpoint 3.7
HTML Techniques Quotations
Checkpoint 6.5
Ensure that dynamic content is accessible or provide an alternative presentation or page.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure that pages featuring new technologies transform gracefully.

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


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


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

Techniques for addressing Checkpoint 6.5
Core Techniques – Alternative pages
Core Techniques – Audio information
HTML Techniques – The LINK element and alternative documents
HTML Techniques – Directly accessible applets
HTML Techniques – Writing for browsers that do not support FRAME
HTML Techniques – Graceful transformation of scripts
Office for People with a Disability – JavaScript factsheet
Office for People with a Disability – Flash factsheet
            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).
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure user control of time-sensitive content changes.

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

Example
The following is an example of blinking content:




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




Techniques for addressing Checkpoint 7.2
HTML Techniques – Directly accessible applets
HTML Techniques – Scripts that cause movement and blinking
CSS Techniques – Text style effects
            Checkpoint 7.4
Until       user agents provide the ability to stop the refresh, do not create periodically
auto-       refreshing pages.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure user control of time-sensitive content changes.

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

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

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

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



Techniques for addressing Checkpoint 7.4
Core Techniques – Automatic page refresh
HTML Techniques – The META element
HTML Techniques – Directly accessible applets
HTML Techniques – Page updates and new windows
             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.
   HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure user control of time-sensitive content changes.

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

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



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



Techniques for addressing Checkpoint 7.5
Core Techniques – Automatic page refresh
HTML Techniques – The META element
HTML Techniques – Page updates and new windows
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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"               http://www.w3.org/TR/WCAG10/

Guideline
Use interim solutions.

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

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


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

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

Techniques for addressing Checkpoint 10.1
  HYPERLINK "http://diveintoaccessibility.org/day_16_not_opening_new_windows.html"
   Dive into Accessibility – Not opening new windows
  HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/web-usability/new-
browser-windows.shtml"       WebCredible – Beware of opening links in a new windows
HTML Techniques – Anchors and targets
HTML Techniques – Directly accessible applets
HTML Techniques – Using FRAME targets
HTML Techniques – Page updates and new windows
Checkpoint 11.1
Use W3C technologies when they are available and appropriate for a task and use the latest
versions when supported.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Use W3C technologies and guidelines.

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

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

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

Techniques for addressing Checkpoint 11.1
Core Techniques for W3C technologies
Checkpoint        11.2
Avoid             deprecated features of W3C technologies.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Use W3C technologies and guidelines.

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

Example
This website   contains a deprecated attribute.

Avoid deprecated features of W3C technologies.
Rule: 11.2.1 - Identify the use of one or more deprecated elements or attributes within the
document.
Failure - Document uses one or more deprecated elements or attributes. The document contains
the element: table with the deprecated attribute: align
How to test
The most common deprecated HTML elements <B> (bolds text) and <I> (italicises text) are
picked up by WAVE (denoted by the following icons) [Compulsory].


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

Techniques for addressing Checkpoint 11.2
Index of HTML attributes and elements (deprecated elements and attributes are denoted by an
asterisk)
CSS Techniques – User override of styles
CSS Techniques – Fonts
Checkpoint 12.3
Divide large blocks of information into more manageable groups where natural and appropriate.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide context and orientation information.

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

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



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

Techniques for addressing Checkpoint 12.3
Core Techniques – structural grouping
HTML Techniques – Grouping form controls
Checkpoint 13.1
Clearly identify the target of each link.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                    http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

How to test
For details on how to test headings see the     HYPERLINK \l "section6"            evaluation tools
section .

Techniques for addressing Checkpoint 13.1
  HYPERLINK "http://www.sf.id.au/ozewai/"        The trouble with the TITLE attribute
  HYPERLINK "http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-
accessibility-title-attributes/" Too much accessibility: TITLE attribute
Checkpoint 13.2
Provide metadata to add semantic information to pages and sites.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

Example
This website   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.
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.
Failure - Document does not contain a META element with the required name: language or
language does not have a 'content' value.
How to test
Use Cynthia Says to identify whether metadata has been included [Compulsory].

Techniques for addressing Checkpoint 13.2
Core Techniques – Navigation
HTML Techniques – Metadata
CSS Techniques – Providing contextual clues in HTML lists
Checkpoint 13.3
Provide information about the general layout of a site (e.g., a site map or table of contents).
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

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



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

Techniques for addressing Checkpoint 13.3
Core Techniques – Navigation
Checkpoint 13.4
Use navigation mechanisms in a consistent manner.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"              http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

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

DIIRD Projects and sub-items DIIRD Initiatives and sub-items
How to test
Browse through the website, identify navigation elements and ensure they are consistent
[Compulsory].

Techniques for addressing Checkpoint 13.4
Core Techniques – Navigation
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).
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

This checkpoint no longer applies.

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

Guideline
Create tables that transform gracefully.

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

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

Techniques for addressing Checkpoint 5.4
Core Techniques: HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l
"structure" Structure vs. Presentation
HTML Techniques: HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l
"tables-layout" Tables for layout
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.
    HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide context and orientation information.

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

This toolkit provides information on   HYPERLINK \l "frames"          frames and iFrames .
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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"                   http://www.w3.org/TR/WCAG10/

Guideline
Use interim solutions.

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

This toolkit provides information on    HYPERLINK \l "forms"           forms .


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

Guideline
Provide context and orientation information.

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

This toolkit provides information on    HYPERLINK \l "forms"           forms .
Scripts and applets

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

Guideline
Ensure that pages featuring new technologies transform gracefully.

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

This toolkit provides information on    HYPERLINK \l "js"         JavaScript

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

Guideline
Ensure user control of time-sensitive content changes.

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

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

Techniques for addressing Checkpoint 7.3
Core Techniques – Visual information and motion
HTML Techniques – Animated images
HTML Techniques – Directly accessible applets
HTML Techniques – Scripts that cause movement and blinking
CSS Techniques – Creating movement with style sheets and scripts
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.]
   HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure direct accessibility of embedded user interfaces.

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

Example
The following Crossword Puzzles 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].

Techniques for addressing Checkpoint 8.1
HTML Techniques – Directly accessible applets
HTML Techniques – Directly accessible scripts
Office for People with a Disability – JavaScript factsheet
Office for People with a Disability – Flash factsheet
Checkpoint 9.2
Ensure that any element that has its own interface can be operated in a device-independent
manner.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Design for device-independence.

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

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

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

Techniques for addressing Checkpoint 9.2
HTML Techniques – Directly accessible applets
HTML Techniques – Directly accessible scripts
Office for People with a Disability – JavaScript factsheet
Office for People with a Disability – Flash factsheet
Checkpoint 9.3
For scripts, specify logical event handlers rather than device-dependent event handlers.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Design for device-independence.

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

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

Techniques for addressing Checkpoint 9.3
HTML Techniques – Directly accessible applets
HTML Techniques – Directly accessible scripts
Office for People with a Disability – JavaScript factsheet
Office for People with a Disability – Flash factsheet
Level AAA Checkpoints
Checkpoint 4.3
Identify the primary natural language of a document.
  HYPERLINK "http://www.w3.org/TR/WCAG10/"              http://www.w3.org/TR/WCAG10/

Guideline
Clarify natural language usage

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

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

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

Techniques for addressing Checkpoint 10.1
HTML Techniques: Identifying the primary language
Checkpoint 9.4
Create a logical tab order through links, form controls, and objects.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Design for device-independence.

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

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

This toolkit provides information on    HYPERLINK \l "pagestructure"           page structure .
Checkpoint 13.5
Provide navigation bars to highlight and give access to the navigation mechanism.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

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

Techniques for addressing Checkpoint 13.5
Core Techniques – Navigation
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.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Provide clear navigation mechanisms.

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

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

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




How to test
Check the website for a ―Skip to content‖ link, or equivalent [Compulsory].

Techniques for addressing Checkpoint 13.6
Core Techniques – Navigation
Checkpoint 14.2
Supplement text with graphic or auditory presentations where they will facilitate comprehension
of the page.
   HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure that documents are clear and simple.

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

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



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

Techniques for addressing Checkpoint 14.2
Core Techniques – Comprehension
Checkpoint 14.3
Create a style of presentation that is consistent across pages.
  HYPERLINK "http://www.w3.org/TR/WCAG10/" http://www.w3.org/TR/WCAG10/

Guideline
Ensure that documents are clear and simple.

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

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




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

Techniques for addressing Checkpoint 14.3
Core Techniques: HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l
"navigation" Navigation
CSS Techniques: HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l
"consistency" Decrease maintenance and increase consistency
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:
  HYPERLINK \l "makingimages"             Making images, image maps, maps and graphs
accessible
  HYPERLINK \l "tables"          Making tables accessible
  HYPERLINK \l "pdfs"          PDFs and accessibility
  HYPERLINK \l "makingpdfsaccessible"            Making a PDF accessible
  HYPERLINK \l "forms"           Creating accessible forms
  HYPERLINK \l "js"         JavaScript
  HYPERLINK \l "splash"          Making splash pages accessible
  HYPERLINK \l "creatingvalidhtml"           Creating valid HTML pages
  HYPERLINK \l "css"          Creating valid CSS
  HYPERLINK \l "pagesource"           Page source order
  HYPERLINK \l "pagestructure"           Page structure
  HYPERLINK \l "colour"          Ensuring sufficient colour contrast
  HYPERLINK \l "cogdis"          Creating sites accessible to people with cognitive disabilities
  HYPERLINK \l "os"          Conducting operating system and browser testing
  HYPERLINK \l "additional"          Additional accessibility features
  HYPERLINK \l "videos"          Videos and Accessibility
  HYPERLINK \l "captioningvideos"           Captioning dowloadable videos
  HYPERLINK \l "youtube"           Captioning YouTube videos
  HYPERLINK \l "audiovideos"           Audio describing video
  HYPERLINK \l "captioningvodcasts"            Captioning vodcasts
  HYPERLINK \l "audiopodcasts"            Audio and podcasts
  HYPERLINK \l "flash"          Flash and accessibility
  HYPERLINK \l "mashups"            Mashups and accessibility
  HYPERLINK \l "blogging"           Blogging and accessibility
  HYPERLINK \l "googlemaps"            Maps and Google maps
  HYPERLINK \l "frames"           Frames and iFrames
  HYPERLINK \l "slideshare"          Slideshare
  HYPERLINK \l "facebook"           Facebook
  HYPERLINK \l "twitter"         Twitter
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 HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/"            Melbourne
2006 Commonwealth Games venue map           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           HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/By+Venue/Docklan
ds+Precinct/" Docklands Precinct       The venue for Walks is approximately 1.5 km south-west
of the city centre.      HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/By+Venue/Melbour
ne+Cricket+Ground+%28MCG%29/" 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.      HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/By+Venue/Melbour
ne+Park/" 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.
HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/By+Venue/Rod+La
ver+Arena+%28Melbourne+Park%29/" Rod Laver Arena (Melbourne Park)                 The venue for
Gymnastics is approximately 2 km east of the city centre.       HYPERLINK
"http://www.melbourne2006.com.au/Sports+and+Venues/Venue+Locations/By+Venue/Telstra+
Dome/" 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.

Further information

ALT attributes
   HYPERLINK "http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/" \l "tech-text-
equivalent"      W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
   HYPERLINK "http://webaim.org/techniques/alttext/"       WebAIM: Appropriate use of
alternative text

Text description
  HYPERLINK "http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/" \l "tech-alt-pages"
   W3C Checkpoint 11.4: If you cannot create an accessible page provide an alternative
Making tables accessible
Tables can cause a number of accessibility problems if they are not built using the accessibility
features within HTML. In web sites there are two ways to use tables: for layout or for data
presentation. Style sheets should always be used in preference to layout tables.

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

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

 INCLUDEPICTURE "http://www.egov.vic.gov.au/images/table1.gif" \*
MERGEFORMATINET

<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>
<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:
   INCLUDEPICTURE "http://www.egov.vic.gov.au/images/accessibletable.gif" \*
MERGEFORMATINET


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


Further information

  HYPERLINK "http://www.usability.com.au/resources/tables.cfm"    Screen readers and the
TH ID and TD HEADERS
  HYPERLINK "http://juicystudio.com/article/firefox-table-inspector.php"   Juicy Studio
Complex Table Analyser
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, HYPERLINK \l
"makingpdfsaccessible"       creating tagged PDFs       ), 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:
   HYPERLINK "http://www.hreoc.gov.au/about/media/media_releases/2008/86_08.html"
     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
The State Government has tabled the 2006-07 Budget Statement which delivers an additional
$1.2 billion to Victoria‘s education and training system.
This Budget invests in new schools and school infrastructure, literacy skills and delivering a
world-class training system. It also recognizes the added expense to families when their children
begin primary or secondary school.
The 2006-07 Budget initiatives will play an important role in continuing to build the State‘s
education and training system which in turn will build a better future for all Victorians.
Budget highlights include:
$448 million construction and equipment program for Schools and TAFE
$182 million School Start Bonus to help every child starting Prep or Year 7
$11.7 million for Literacy Improvement Teams
$36 million ‗Trades Bonus‘ for all first year apprentices to encourage as many as possible to
complete their trade
$230 million towards Maintaining the Advantage: Skilled Victorians
$5.1 million for a new Academic Number to help improve outcomes for all students
$24.1 million to continue the Schools for Innovation and Excellence program
$47.2 million to continue the successful Victorian Certificate of Applied Learning
$11.6 million to school leadership initiative

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

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

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

and a link to the HTML equivalent:
  HYPERLINK "http://www.appligent.com/adobeaccessibility/AdobeAccessCover.html"
   http://www.appligent.com/adobeaccessibility/AdobeAccessCover.html
This HTML equivalent includes an Index:
  HYPERLINK "http://www.appligent.com/adobeaccessibility/AdobeAccess7IX.html"
   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:
Name
Phone number
Email address
Postal address

Further Information

Text equivalents
  HYPERLINK "http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/" \l "tech-text-
equivalent"    W3C Checkpoint 1.1: Provide a text equivalent for every non-text element

HTML converters
  HYPERLINK "http://www.w3.org/Tools/Filters.html"           Converting to HTML

PDF accessibility
  HYPERLINK "http://www.adobe.com/accessibility/"   Adobe accessibility
  HYPERLINK "http://www.webaim.org/techniques/acrobat/"   PDF accessibility
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 HYPERLINK \l
"providingdetialsofthepdf"       equivalent must always be provided    .

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

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

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

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

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

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

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

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

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

4. Add alternative text to images
Add alternative text to all images via the ―Format picture‖ dialog box. Under the ―Web‖ tab,
there is a section available for alternative text.
Please note: This is only available in Windows
5. Format tables
Ensure that tables are not nested.

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

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

Creating the PDF document

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

1. Change Acrobat Conversion settings

Word 2000 / Acrobat 5.0
Open the ―Change Conversion settings‖ via the ―Acrobat‖ menu.

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

Under the ―Bookmarks‖ tab ensure ―Convert Word headings to bookmarks‖ is enabled.

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

Word XP / Acrobat 6.0
Open the ―Change Conversion settings‖ via the ―Adobe PDF‖ menu.

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

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

Under the ―Bookmarks‖ tab ensure ―Convert Word headings to bookmarks‖ is enabled.

Word XP / Acrobat 7.0
Open the ―Change Conversion settings‖ via the ―Adobe PDF‖ menu.
Under the ―Settings‖ tab ensure that the following are enabled:
―Convert Document Information‖
―Add Bookmarks to Adobe PDF‖
―Add Links to Adobe PDF‖
―Enable Accessibility and Reflow with Tagged PDF‖

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

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

Under the ―Bookmarks‖ tab ensure ―Convert Word headings to bookmarks‖ is enabled.

2. Create the PDF

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

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

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

Testing the PDF document

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

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

Under the ―Checking options‖ section, make sure all options are enabled.

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

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

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

Further Information

Creating tagged PDFs
  HYPERLINK "http://www.adobe.com/accessibility/products/acrobat/training.html"  Adobe
– Acrobat Accessibility Training Resources
  HYPERLINK "http://www.hhs.gov/web/policies/pdfaccessibility/index.html"    US Dept of
Health and Human Services – Guidance making PDFs accessible
Creating accessible forms
Increasingly, the web is becoming more interactive. People can buy things online, from movie
tickets to clothes and even fridges. As the web takes over from traditional services such as retail
it is important that this new web functionality is accessible. Increasingly, forms are the method
through which many of these services are being provided to the general public. Accessibility of
these services becomes essential in the provision of Government services.

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

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


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

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


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

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


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/searchbutton_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 button lose all their
inputs. This is especially the case for people with cognitive disabilities.

The following is an example where a reset button (labeled ‗cancel‘) and submit button (labeled
‗continue‘) are placed incorrectly on the page. Because the cancel button is closer to the fields
themselves, this button has a higher visual hierarchy and therefore is more likely to be activated
than the continue button.


A preferable, accessible alternative is to provide cancel or reset options as links instead of
buttons, which will reduce the likelihood of users activating them by mistake, such as in the
following example:


Form submission and validation
The form must be able to be submitted with JavaScript disabled or not supported. There will be
people who won‘t be able to use a JavaScript form because:
They are using a screen-reader which does not interact with JavaScript
They are browsing without JavaScript
They are using a text-only browser

In many cases JavaScript submission can easily be replaced with a standard HTML submission,
for instance the following code:
<a href="javascript:void(open('lookup.php?find,'lookup',toolbar=no'))">
<img src=" http://support.microsoft.com/library/images/support/goright_hot.gif" alt="search
button" border="0" align="middle" width="24" height="24" /></a>

can easily be replaced with:
<input type="image" src="http://support.microsoft.com/library/images/support/goright_hot.gif"
alt="Submit" />

In some cases forms require validation and this is often best achieved with JavaScript. JavaScript
form validation provides an almost immediate response and can be used to provide additional
information easily and quickly to users. However there must always be a server-side fallback to
JavaScript validation, in the instance where a user does not JavaScript installed.

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 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 HYPERLINK \l "coding"            section on Coding
Labels .

Complicated form techniques
Recently there has been much publicity surrounding AJAX (Asynchronous JavaScript and
XML). AJAX allows users to interact with a site without serving new pages and can significantly
reduce the amount of time it takes to complete some actions. One web site that relies heavily on
AJAX is the online photo album and sharing site, Flickr. A common example of AJAX within
Flickr is the ability to scroll between thumbnail images without re-serving the page. Users select
the ―more‖ button and a new image is displayed:


When JavaScript is turned off the ‗more‘ functionality is no longer available. However the
‗browse‘ option is still available which takes users to a page containing all their photos and this
provides a suitable alternative to the ‗more‘ options:


Another aspect of AJAX functionality within Flickr is the ability to change the title of an image
just by clicking on the title and typing a new name:


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.

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 HYPERLINK \l "pagestructure"
    Page Structure section or HYPERLINK \l "pagesource"               page source order .

Checkpoint 9.5: Provide keyboard shortcuts to important, form controls, and groups of form
controls.
Recent research indicates that keyboard shortcuts (using the ACCESSKEY attribute) often over-
ride keyboard shortcuts inbuilt in certain screen readers. Previous research indicated that only
numerals could be used as keyboard shortcuts as most other ASCII keys are used in program
shortcuts (eg. ALT+F often opens the File menu). However this recent research indicates that
some screen readers use numeral keyboard shortcuts for common functionality, such as
displaying all headings in a page.

Checkpoint 10.4: Until user agents handle empty controls correctly, include default, place-
holding characters in edit boxes and text areas.
This checkpoint was intended to provide information to screen reader users in cases where screen
readers could not interpret the LABEL FOR element. Now that screen readers and other assistive
technologies consistently interpret this element the requirement to include place-holding
characters is no longer necessary. Place-holding characters can even reduce accessibility when
users tab to a field and enter information without being aware that they need to delete the place-
holding characters first.

Further Information

Accessibility of particular form elements
  HYPERLINK "http://www.visionaustralia.org.au/info.aspx?page=766"            Shortened forms
on the web
   HYPERLINK "http://www.sf.id.au/WE05/forms.html"     Screen reader software support for
the TITLE attribute
   HYPERLINK "http://www.456bereastreet.com/archive/200412/the_alt_and_title_attributes/"
    ALT vs. TITLE
   HYPERLINK "http://www.w3.org/TR/html4/interact/forms.html" \l "h-17.4.1"    Graphical
submit buttons

Creating accessible forms
   HYPERLINK "http://www.webaim.org/techniques/forms/"       WebAIM: Creating accessible
forms
   HYPERLINK "http://www.lukew.com/resources/articles/WebForms_LukeW.pdf"
    Usability of forms (PDF)
   HYPERLINK "http://www.webstandards.org/learn/tutorials/accessible-forms/beginner/"
    Accessible HTML/XHTML Forms
   HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/web-
accessibility/accessible-forms-2.shtml" Making accessible forms, part one
   HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/web-
accessibility/accessible-forms-2.shtml" Making accessible forms, part two
JavaScript
JavaScript is a client-side scripting language used by many different web sites. JavaScript can be
used to create fly-out menus, mouseovers and form validation. However JavaScript has many
accessibility problems; and a text equivalent is always required.


Relationship to checkpoints:
Checkpoint 1.1 requires that you provide text alternatives for all JavaScript.
Checkpoint 6.2 requires that equivalents to JavaScript are updated when the JavaScript changes.
Checkpoint 6.3 requires that if JavaScript is disabled, that the page is usable, or, alternatively, an
equivalent is provided.
Checkpoint 6.4 and 9.3 require that you use device-independent and logical event handlers, such
as ONFOCUS instead of device-dependent event handlers, such as ONCLICK or
ONMOUSEOVER.
Checkpoint 6.5 and 8.1 requires that JavaScript is created in an accessible manner.
Checkpoint 10.1 requires that JavaScript not be used to create popup windows unless after
informing the user.

Alternatives to JavaScript are used wherever possible
When first developing a site, consider whether JavaScript need be used in the site at all. Many
common JavaScript functions are adequately replicated in HTML and provide an enhanced level
of accessibility. Some of the things that should be replaced with HTML functionality are detailed
in the following table.

Functionality JavaScript Equivalent HTML           Text link <a href=―javascript:
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:


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


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
Further Information

Creating accessible JavaScript
  HYPERLINK "http://www.webaim.org/techniques/javascript/"          WebAIM – Creating
Accessible JavaScript
  HYPERLINK "http://www.jimthatcher.com/webcoursea.htm"            Jim Thatcher – Scripts and
Applets
  HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts.html"           IBM
JavaScript Accessibility
  HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts_background.html"
    IBM - Scripts used for background processing and pop-ups
  HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts_content.html"
    IBM - Hidden content, document.write, and scripts that modify content
  HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts_dhtml.html"
    IBM - DHTML
  HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts_eventhandlers.html"
    IBM – Scripts using event handlers
  HYPERLINK "http://www-
306.ibm.com/able/guidelines/web/webscripts_nonessential.html"        IBM – Non-essential
scripts
   HYPERLINK "http://www-306.ibm.com/able/guidelines/web/webscripts_noscript.html"
    IBM - Additional techniques to enhance accessibility of essential scripts
   HYPERLINK "http://www.htmlgoodies.com/beyond/javascript/article.php/3673826"
    Accessible JavaScripting from the ground up

JavaScript and screen readers
  HYPERLINK "http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and-
accessibility"    JavaScript and accessibility
Making splash pages accessible

If you use plug-ins (such as Flash) or scripts (such as JavaScript) on your pages you could be
preventing users from entering or using your site properly. There will be people who will have
difficulty accessing the navigation or progressing past a Flash front page (splash page) for any of
the following reasons:
They are browsing without JavaScript and / or Flash
They are using a text-only browser
They are using a screen-reader which does not interact with JavaScript and / or Flash
They are using a keyboard instead of a mouse
They are using a slow modem

Relationship to checkpoints
Checkpoint 6.3 requires that pages remain usable when scripts, applets or other programmatic
objects are turned off or not supported. This means that if a computer does not have Flash
installed or does not support JavaScript, that the site still functions.

Example Solution – Splash page

Background
Australian Centre for the Moving Image (ACMI) is a web site designed to promote ACMI at
Federation Square. The site was built to Level A accessibility standards while still providing a
modern look and feel. One thing ACMI requested was a Splash page:
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
  HYPERLINK "http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/" \l "tech-scripts"
   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
  HYPERLINK "http://www.adobe.com/accessibility/products/flash/best_practices.html"
    Adobe Flash accessibility design guidelines
  HYPERLINK "http://www.webaim.org/techniques/flash/"          WebAIM – Creating
Accessible Macromedia Flash content
  HYPERLINK "http://www.adobe.com/accessibility/products/flash/faq.html"          Adobe Flash
CS4 Professional accessibility FAQ
  HYPERLINK
"http://www.adobe.com/resources/accessibility/best_practices/best_practices_acc_flash.pdf"
    Best Practices for Accessible Flash Design   (Adobe Reader required)
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     HYPERLINK "http://validator.w3.org/docs/help.html"           W3C Validation
service

Relationship to checkpoints:
Checkpoint 3.2 requires that documents validate to published formal grammars. The most
common DOCTYPE definitions are:
HTML 4.01 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
XHTML 1.0 Transitional
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

DOCTYPE definitions must be the first line of code in a web page.

Ensuring a page is valid
There are some simple things you can do to ensure that your documents validate.

A. DOCTYPE definition
Ensure that all pages include a DOCTYPE definition in the first line of code
Correct
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Incorrect:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


B. Close relevant tags
Ensure that all relevant tags are closed properly.
Correct:
<p>Join the thousands of people who have immigrated to Victoria.</p>
<p>So why not see if you can immigrate and live in Victoria?</p>

Incorrect:
<p> Join the thousands of people who have immigrated to Victoria.
<p> So why not see if you can immigrate and live in Victoria?

C. Self-close tags
In XHTML, make sure you self-close tags when they don‘t have end tags.
Correct:
<img src=‖test.jpg‖ height=‖32‖ width=‖32‖ alt=―‖ />

Incorrect:
<img src=‖test.jpg‖ height=‖32‖ width=‖32‖ alt=―‖>

D. Don‘t transpose tags
Don‘t transpose tags. Make sure you close tags in the order they are opened.
Correct:
<strong><a href=‖www.vic.gov.au‖>Victoria Online</a></strong>

Incorrect:
<strong><a href=‖www.vic.gov.au‖>Victoria Online</strong></a>

E. Nest block level and inline elements properly
Don‘t nest block level elements inside inline elements.
Correct:
<p><strong>Drink drivers are warned that the chances of getting caught are now higher than
ever.</strong></p>

Incorrect:
<strong><p>Drink drivers are warned that the chances of getting caught are now higher than
ever.</p></strong>

F. Don‘t omit tags
Don‘t omit compulsory tags, even if the web page displays properly without them.
Correct:
<table><tr><td> My eGov allows you to rate content and bookmark your favourite
resources.</td></tr></table>

Incorrect:
<table><td> My eGov allows you to rate content and bookmark your favourite
resources.</td></table>

G. Escape relevant entities
Escape relevant entities.
Correct:
Then we went to the Elephant &amp; Wheelbarrow

Incorrect:
Then we went to the Elephant & Wheelbarrow

Testing a site for HTML validity
The W3C maintains a HYPERLINK "http://validator.w3.org/"              validation service      that
can test a site one page at a time via URL or page upload. Alternatively, you can use the
HYPERLINK "http://www.htmlhelp.com/tools/validator/"            WDG HTML Validator           to
validate your entire site.

Common errors
There are many common errors of invalid sites. The W3C Validation service maintains a
HYPERLINK "http://validator.w3.org/docs/errors.html"          list of errors and their meanings      .
This document can assist in determining errors if they occur.

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

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 ―.‖.

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: />

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

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.

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

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
  HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "doctype"      W3C
Checkpoint 3.2: The DOCTYPE statement
  HYPERLINK "http://www.w3.org/QA/2002/04/valid-dtd-list.html" W3C recommended
DOCTYPE definitions

Code specifications
  HYPERLINK "http://www.w3.org/TR/html4/"              HTML 4.01 specification
  HYPERLINK "http://www.w3.org/TR/xhtml1/"          XHTML 1.0 specification

HTML Validators
  HYPERLINK "http://validator.w3.org/" W3C HTML Validator
  HYPERLINK "http://www.htmlhelp.com/tools/validator/" WDG HTML Validator

Why validation is important
  HYPERLINK "http://validator.w3.org/docs/why.html"       Why validate?
  HYPERLINK "http://juicystudio.com/article/validity-accessibility.php" Validity and
accessibility

Information on validation
   HYPERLINK "http://www.sitepoint.com/article/html-37-steps-perfect-markup"      37 steps
to perfect markup
   HYPERLINK "http://validator.w3.org/docs/errors.html"   Error explanations for the W3C
Validation service
   HYPERLINK "http://validator.w3.org/docs/help.html"    Help and FAQs for the W3C
Validation service
   HYPERLINK "http://www.blooberry.com/indexdot/html/index.html"       Index dot HTML:
information on HTML tags and attributes
Creating valid CSS

When designing a web site it is important to identify presentation as separate to content and
structure. Separating content from presentation and structure offers a number of advantages,
including improved accessibility and manageability.

Relationship to checkpoints:
Checkpoint 3.2 requires that documents validate to published formal grammars.
Checkpoint 3.3 requires that style sheets are used to control layout and presentation.

Using CSS
There are three ways to use CSS. CSS can be inserted as inline styles: as attributes of any HTML
element, changing the style of that element (and its descendants where appropriate). CSS can
also be inserted into the HTML or XHTML within the HEAD tag of each page. This method is
called an internal style sheet. Alternatively it can be inserted into an external style sheet and
referenced in the HTML or XHTML of the web page. This is often the preferred method as the
style sheet needs to be changed only once for the changes to deploy across the entire site. This
option also means that the external style sheet only needs to be downloaded once by the user; not
with every new page the user loads.

Ensuring CSS is valid
There are some simple things you can do to ensure that your CSS validates.

A. Properly reference the CSS file
Make sure the styles and/or the reference to the external style sheet are contained in the <head>
element, not the <body> element. While browsers will often accept styles defined anywhere in
the document, it's only valid it in the <head> element (inline styles excepted) or referenced from
other style sheets.
Correct
<head>
<style type="text/css"> @import url(style.css) </style>
</head>

Incorrect:
<head>
</head>
<style type="text/css"> @import url(style.css) </style>

B. Specify background colour when text colour is defined
Whenever a text-colour is specified also specify a background-colour.
Correct
/* -- Generic Text -- */
body {
background: #FFF;
color: #000;
/*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
}

Incorrect:
/* -- Generic Text -- */
body {
color: #000;
/*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
}

C. Specify text colour when background colour is defined
Whenever a background-colour is specified also specify a text-colour.
Correct
/* -- Generic Text -- */
body {
background: #FFF;
color: #000;
/*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
}

Incorrect:
/* -- Generic Text -- */
body {
background: #000;
/*font: 75%/1.3 Verdana, Arial, Helvetica, sans-serif;*/
font: 62.5%/1.2 Verdana, Arial, Helvetica, sans-serif;
}

D. Do not use ―display: none‖
Commonly information that was to be hidden from visual users but presented to screen reader
users would be hidden using the CSS property ―display: none.‖ However research has indicated
that screen readers do not read this information out either. It is preferable to use the ―
HYPERLINK "http://css-discuss.incutio.com/?page=OffLeft"              off-left technique‖ when
attempting to hide text or audio content.
Correct
.hidden {
position: absolute;
left: -1000px;
width: 100px;
}

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
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
   HYPERLINK "http://www.w3.org/TR/WCAG10-CORE-TECHS/" \l "structure"      W3C
Structure vs. presentation
   HYPERLINK "http://www.w3.org/TR/WCAG10-HTML-TECHS/" \l "text-emphasis"
    W3C Emphasis
   HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "text-not-images"
    W3C Text instead of images
   HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "style-text-formatting"
    W3C Text formatting and position
   HYPERLINK "http://www.w3.org/TR/WCAG10-CSS-TECHS/" \l "style-alignment"
    W3C Layout, positioning, layering and alignment

Code specifications
  HYPERLINK "http://www.w3.org/TR/REC-CSS1"     CSS 1.0 specification
  HYPERLINK "http://www.w3.org/TR/REC-CSS2/"    CSS 2.0 specification
  HYPERLINK "http://www.w3.org/TR/CSS21/"    CSS 2.1 specification (Working
Draft)
CSS Validators
  HYPERLINK "http://jigsaw.w3.org/css-validator/"     W3C CSS Validator

Why using CSS is important
   HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/css/css-website-
layout.shtml"   Why a CSS layout will make you money

CSS tips and tricks
  HYPERLINK "http://www.456bereastreet.com/archive/200503/css_tips_and_tricks_part_1/"
   CSS tips and tricks
  HYPERLINK "http://www.csszengarden.com/"       CSS Zen Garden
  HYPERLINK "http://www.cssbasics.com/"       CSS Basics
  HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/css/css-round-corners-
borders.shtml"      CSS and round corners
  HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/css/css-navigation-
menu.shtml"      Developing CSS navigation
  HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/css/css-tricks.shtml"
   Ten CSS tricks
  HYPERLINK "http://css-discuss.incutio.com/?page=OffLeft"    Off-left technique

Information on CSS validation
   HYPERLINK "http://www.webreference.com/authoring/style/sheets/properties/"   CSS 2.1
properties
   HYPERLINK "http://www.blooberry.com/indexdot/css/index.html"     Index dot CSS:
information on CSS
Page source order
Page source order is important to people who have vision impairments and rely on a screen
reader to navigate or interpret the site. It is also important to people with cognitive disabilities
who use a screen reader to assist in reading the information on the site. A document where
source order does not match the order of content with CSS on can be very confusing to these
groups of users. In addition, source order is important to people with physical impairments who
rely on a keyboard to navigate the site. People who rely on keyboards tab through the content
and therefore can find it difficult to navigate the page if the source order does not match the
order of the page with CSS on. Using TABINDEX does not address this problem as unless every
single element is provided with a TABINDEX it can render the page unusable by screen reader
users.

Relationship to checkpoints:
Checkpoint 6.1 requires that documents can be read without style sheets.
Checkpoint 13.4 requires that navigation mechanisms are presented in a consistent manner
Checkpoint 9.4 requires that the page presents a logical tab order through links, form controls
and objects
Checkpoint 14.3 requires that the style of presentation is consistent across pages

Ensuring correct page source order when developing a site
When you have created your wireframes or graphical concepts label each element to indicate its
source order. Source order should always read from left to right and down the page. This
information can be provided to the developers to ensure they code elements in a particular order.

Example: YouthCentral site




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.

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
   HYPERLINK "http://www.usability.com.au/resources/source-order.cfm"            Source order,
skip links and structural labels

Tools
   HYPERLINK "http://chrispederick.com/work/webdeveloper/"       FireFox Web Developer
Toolbar
What‘s new in JAWS 10
   HYPERLINK "http://www.freedomscientific.com/fs_products/software_jaws80fea.asp" \l
"download"     Demonstration version of JAWS screen reader     (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.)
Page structure

Page structure is important to people with vision impairments, such as those using a screen
reader or a magnifier. Page structure is also important to people with cognitive disabilities and
can assist those with physical disabilities.

Relationship to checkpoints:
Checkpoint 3.3 requires that style sheets are used to control layout and presentation
Checkpoint 3.5 requires that header elements are used to convey document structure
Checkpoint 6.1 requires that documents may be read without style sheets.
Checkpoint 9.4 requires that the page presents a logical tab order through links, form controls
and objects
Checkpoint 12.3 requires that large blocks of information are divided into more manageable
groups where natural and appropriate
Checkpoint 13.4 requires that navigation mechanisms are used in a consistent manner
Checkpoint 13.5 requires that navigation bars are used to highlight and give access to the
navigation mechanism
Checkpoint 13.6 requires that related links are grouped, identified and can be bypassed
Checkpoint 13.8 requires that distinguishing information is presented at the beginning of
headings, paragraphs, lists, etc
Checkpoint 14.3 requires that the style of presentation is consistent across pages

Ensuring correct page structure
There are a number of different elements that are required in order to create a correct page
structure:
TITLE element
Skip links
Properly marked up headings
Structural labels
Breadcrumbs

It is also very important that your page source order   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:


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.



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)


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 a sub-navigation item of ―10 year…‖ which sits under the main navigation item of ―DIIRD
Strategies‖ 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 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 sea-side birds‖, or ―Sea-side birds‖.

Example – Department of Education


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



Testing a site for correct page structure

TITLE element
Make sure that the TITLE element properly represents the page and is consistent with other
pages in the site.

Skip links
Make sure all skip links are consistent.

Properly marked up headings
WAVE can be used to indicate which headings have been marked up. WAVE indicates each
heading with H1, H2 or H3.

Structural labels
Using the FireFox Web Developer toolbar you can easily turn off style sheets. Ensure that with
style sheets off, each navigation set is properly labeled and that sub-navigation is easily
differentiated from other navigation items.

Include breadcrumbs
Make sure all breadcrumbs are consistent and have the relevant hidden structural label.

Further Information

Tools
   HYPERLINK "http://chrispederick.com/work/webdeveloper/"       FireFox Web Developer
Toolbar
   HYPERLINK "http://www.freedomscientific.com/fs_products/software_jaws80fea.asp" \l
"download"     Demonstration version of JAWS screen reader     (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.)
   HYPERLINK "http://wave.webaim.org/index.jsp"        WAVE

Skip links
  HYPERLINK "http://accessites.org/gbcms_xml/news_page.php?id=13"      Skip links: Pros
and Cons
  HYPERLINK "http://www.jimthatcher.com/skipnav.htm"     Skip navigation

Headings
  HYPERLINK
"http://www.utexas.edu/research/accessibility/research/summary/swat/swat_headings.html"
    Headings and accessibility
  HYPERLINK "http://www.usability.com.au/resources/page-content.cfm"         Navigation
Accessibility 2: Accessing Page Content

Information on structural labels
   HYPERLINK "http://www.usability.com.au/resources/source-order.cfm"           Source order,
skip links and structural labels
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:
   SHAPE \* MERGEFORMAT
Relationship to checkpoints:
Checkpoint 2.2: Ensure that foreground and background color combinations provide sufficient
contrast when viewed by someone having color deficits or when viewed on a black and white
screen
This is a Level AA checkpoint for images conveying information.
This is a Level AAA checkpoint for text.

Ensuring adequate colour contrast when designing a site
The W3C developed an algorithm to ensure adequate colour contras and luminosity . 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.

Instead of using the algorithm every time you need to test your colours, you can use the
HYPERLINK "http://juicystudio.com/services/colourcontrast.php"          JuicyStudio Luminosity
Colour Contrast Ratio Analyser      , 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
HYPERLINK "http://iconico.com/colorpic/" Iconico ColourPic tool 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 HYPERLINK
"http://www.vischeck.com/vischeck/vischeckURL.php"             entire web page with Vischeck         ,
however style sheets etc are not well-supported. Alternatively you can HYPERLINK
"http://www.vischeck.com/vischeck/vischeckImage.php"            test an image with Vischeck        . If
you have Adobe Photoshop or ImageJ you can HYPERLINK
"http://www.vischeck.com/downloads/"            download a Vischeck plug-in        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
  HYPERLINK "http://www.w3.org/WAI/ER/tools/complete"                   W3C Accessibility
Evaluation and Repair Tools - Colour contrast

Information on colour vision
   HYPERLINK "http://www.diycalculator.com/sp-cvision.shtml"    Colour vision
   HYPERLINK "http://www.colormatters.com/entercolormatters.html"    Colour matters

Information on colour blindness
   HYPERLINK "http://www.lighthouse.org/color_contrast.htm"          Effective colour
contrast
   HYPERLINK "http://webexhibits.org/causesofcolor/2.html"         How do things look to a
colour blind person?
   HYPERLINK "http://www.tsi.enst.fr/~brettel/colourblindness.html"       What do colour blind
people see (requires Java)?
   HYPERLINK "http://en.wikipedia.org/wiki/Color_blindness"         Wikipedia – Colour
blindness
   HYPERLINK "http://colorvisiontesting.com/"         Colour blindness
   HYPERLINK "http://jfly.iam.u-tokyo.ac.jp/html/color_blind/"       How to make figures and
presentations that are friendly to color blind people

Tools
   HYPERLINK "http://juicystudio.com/services/colourcontrast.php"    Juicy Studio
Luminosity colour contrast analyser
   HYPERLINK "http://www.vischeck.com/"        Vischeck colour blindness simulation
   HYPERLINK "http://www.etre.com/tools/colourblindsimulator/"      Colour blindness
simulator
   HYPERLINK "http://colorlab.wickline.org/colorblind/colorlab/"    ColorLab – Colour
blindness simulator
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 HYPERLINK "http://lists.w3.org/Archives/Public/w3c-wai-
gl/2006AprJun/0368.html"        formal objection tabled by Lisa Seeman      and co-signed by
over fifty people involved in the accessibility industry.

It is important to remember that people with cognitive disabilities often have a problem in only
one area of cognition, and can be of average or higher-than-average intelligence. People with
cognitive disabilities are just as likely as those in the general public to be in technical careers
and/or careers requiring high intelligence. People with cognitive disabilities may even work in
industries which would appear to be impossible to them due to their disability. For instance Tom
Cruise has dyslexia and as a dyslexic he has great difficulty reading; however his career as an
actor requires him to read and interpret scripts on a daily basis.

Relationship to checkpoints:
Checkpoint 1.1 requires that all information provided in a non-text format is also provided as a
text equivalent
Checkpoint 3.4 requires that relative units are used instead of absolute units
Checkpoint 3.5 requires that headers are marked up properly
Checkpoint 4.2 requires that abbreviations be expanded where they first occur
Checkpoint 7.1: requires no flickering
Checkpoint 7.2 requires minimal blinking
Checkpoint 7.3 prohibits movement that cannot be stopped by the user
Checkpoint 7.4 requires no auto-refreshing pages
Checkpoint 7.5 requires no auto-redirecting pages
Checkpoint 9.4 requires that the site contain a logical tab order
Checkpoint 10.1 requires no popups or opening new windows without informing the user
Checkpoint 10.2 require that fields are placed close to the relevant field label
Checkpoint 12.3 requires breaking content into more manageable groups
Checkpoint 13.1 requires identifying the target of each link
Checkpoint 13.3 requires the inclusion of a sitemap or table of contents
Checkpoint 13.4 requires that navigation be used in a consistent manner
Checkpoint 13.8 requires the inclusion of distinguishing information at the beginning of pages,
paragraphs and lists
Checkpoint 14.1 requires that content is clear and simple
Checkpoint 14.2 requires the supplementation of text with graphics or audio
Checkpoint 14.3 requires that a consistent style is used throughout the site

Type of cognitive disabilities
There are many different types of cognitive disabilities; however they all incorporate varying
degrees of problems associated with:
Memory;
Perception;
Problem-solving; and
Conceptualizing.

Memory
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 HYPERLINK "http://www.otal.umd.edu/uupractice/cognition" ―Designing for users
with Cognitive Disabilities‖

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;
Links; and
Headings.

Improving readability is also important. Certain techniques aimed at assisting people with
cognitive disabilities include:
Shortening sentences;
Reducing column width;
Using headings;
Reducing colour contrast; and
Presenting only one idea per sentence.

The following list of guidelines will assist you in making your site accessible to people with
cognitive disabilities. Many guidelines, such as reducing column width, will be difficult or
infeasible to implement. The more guidelines you comply with the more accessible your site will
be to people with cognitive disabilities, however following only a few of the following
guidelines is better than following none at all.

A. Comply with the cognitive-related checkpoints in WCAG1.0
Many of the cognitive-related checkpoints in the Web Content Accessibility Guidelines are in
Level AA and Level AAA. Therefore if your site is only compliant to Level A you could still be
creating a site inaccessible to people with cognitive disabilities.

The important cognitive-related checkpoints are:
Checkpoint 1.1:
Ensure all information provided in a non-text format is also provided as a text equivalent
Checkpoint 3.4:
Ensure relative units are used instead of absolute units
Checkpoint 3.5:
Ensure all headings are marked up properly
Checkpoint 4.2:
Ensure all abbreviations are expanded where they first occur
Checkpoint 7.1:
Remove flickering
Checkpoint 7.2:
Reduce or remove blinking
Checkpoint 7.3:
Do not include movement that cannot be stopped by the user
Checkpoint 7.4:
Do not use auto-refresh
Checkpoint 7.5:
Do not use auto-redirect
Checkpoint 9.4:
Ensure the site uses a logical tab order
Checkpoint 10.1:
Do not include popups or open new windows without informing the user
Checkpoint 10.2:
Ensure that fields are placed close to the relevant field label
Checkpoint 12.3:
Break content into more manageable groups
Checkpoint 13.1:
Identify the target of each link
Checkpoint 13.3:
Include a sitemap or table of contents
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
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 HYPERLINK \l "captioningvideos"            captions to video
Provide HYPERLINK \l "audiovideos"            audio descriptions to video
Allow users to stop, pause or slow down audio and video

Further Information

Information on cognitive disabilities
   HYPERLINK "http://www.comp.lancs.ac.uk/computing/users/dixa/hci-education/cog-dis/cog-
dis.html"      HCI Education – cognitive disability
   HYPERLINK "http://spot.colorado.edu/~dubin/bookmarks/b/445.html"    Assistive
technology with cognitive disability emphasis
   HYPERLINK "http://webboy.net/presentation/ozewai2004/index.htm"    Cognitive
disabilities and learning difficulties
   HYPERLINK "http://www.pbs.org/wgbh/misunderstoodminds/"       Misunderstood
Minds
 HYPERLINK "http://www.pbs.org/wgbh/misunderstoodminds/reading.html"
   Misunderstood Minds – Reading
 HYPERLINK "http://www.pbs.org/wgbh/misunderstoodminds/attention.html"
   Misunderstood Minds – Attention
 HYPERLINK "http://www.pbs.org/wgbh/misunderstoodminds/writing.html"
   Misunderstood Minds – Writing
 HYPERLINK "http://www.pbs.org/wgbh/misunderstoodminds/math.html"      Misunderstood
Minds – Mathematics

Information on developing sites accessible to people with cognitive disabilities
   HYPERLINK "http://www.webaim.org/articles/cognitive/cognitive_too_little/"         Cognitive
disabilities: Conceptualizing design considerations
   HYPERLINK "http://www.otal.umd.edu/uupractice/cognition/"           Designing for users with
cognitive disabilities
   HYPERLINK "http://www.dyslexia-parent.com/mag35.html"             Designing web pages for
dyslexic readers

Information on cognitive disabilities and the W3C
   HYPERLINK "http://www.webaim.org/articles/cognitive/cognitive_too_little/"        Cognitive
disabilities: We still know so little, and we do even less
   HYPERLINK "http://www2002.org/CDROM/alternate/689/"             Inclusion of cognitive
disabilities in the web accessibility movement
   HYPERLINK "http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0368.html"
    Formal objection to WCAG2
   HYPERLINK "http://joeclark.org/access/webaccess/WCAG/cognitive/phonecalls.html"
    Recollection of phone calls on learning disabilities and WCAG2
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 HYPERLINK
"http://www.w3schools.com/browsers/browsers_stats.asp"            monthly browser statistics   . It
is important to note that these browser statistics are based on the web statistics of the W3Schools
web site. People accessing this site are more technically-savvy than the average user and are
therefore more likely to be using alternative browsers.

May 2009 Operating system usage by operating system type
Windows Mac Linux           89.5% 6.1% 4.1%
May 2009 Operating system usage by operating system version
Win XP Win Vista Mac Linux Win
2003 Win7 Win2000           67.2% 18.4% 6.1% 4.1% 1.7% 1.1% 1.1%
Relationship to checkpoints:
Although there are no specific Web Content Accessibility Guidelines that refer to operating
system and browser compliance, some do have an indirect effect on how a site will display in
some operating systems and browsers. The following are some examples of how checkpoints are
related to operating system and browser compliance.

Checkpoint 1.1 requires that you provide ALT attributes for images. In Internet Explorer these
ALT attributes appear as a tool tip when you hover over the image.
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
Mac OS X
Windows 2000
Windows Vista

Choosing browsers to test
The following is an example of web statistics for a small web site.

Browser web statistics
Browsers Percent       Internet Explorer 52.14 %          FireFox 40.17 %      Safari 5.98
%    Chrome 1.71 %
Once again it is important to look at the full list of browsers to determine which versions to test.

Example of list of Internet Explorer browser web statistics
IE Versions Percent       IE 6.0 54.10%      IE 7.0 31.15%         IE 8.0 14.75%
There are multiple browser versions for a particular browser and although each version has the
potential to cause a bug within your web site, it is usually customary to test only major releases
of browsers (ie. Internet Explorer 7 or FireFox 3).

For the web statistics indicated above a reasonable range of browsers to test would be:
Internet Explorer 6.01
Internet Explorer 7.0
FireFox 3.0
Safari
FireFox 2
Chrome

Choosing the combination of operating systems and browsers
Once you have developed a list of operating systems and browsers it is not a case of testing each
browser on each operating system. There are numerous reasons why some browsers should not
be tested on some operating systems:

Some browsers only operate on a particular operating system.
Particular operating systems often build browsers for use specifically with their operating
system. For instance Safari is a Mac browser and therefore would not need to be tested on any of
the Windows versions. Alternatively, Microsoft no longer supports Internet Explorer for
Macintosh and recommends Apple‘s Safari browser instead.

Some operating browsers come pre-installed with a particular browser version
It is highly unlikely that someone would uninstall a pre-installed browser version and install an
older version of that particular browser. For instance Windows Vista comes pre-installed with
Internet Explorer 7.0 and therefore older versions of Internet Explorer would not need to be
tested on that operating system.

Some operating systems have been released recently
Browser versions much older than a particular operating system would not need to be tested on
that operating system. For instance Windows Vista was released after FireFox 2.0 was released
and therefore FireFox 1.5 would not need to be tested on that operating system.

A reasonable combination of operating system and browsers would be:

Windows XP
Internet Explorer 6.01
Internet Explorer 7.0
FireFox 3.0.
FireFox 2.0
Opera
Chrome

Mac OS X
Safari
FireFox 3.0

Windows Vista
Internet Explorer 7.0
Internet Explorer 8.0
FireFox 3.0

Windows 2000
Internet Explorer 6.01
Internet Explorer 7.0
FireFox 2.0.x
Opera

Setting up an operating system and browser testing environment
There are two ways to test an identified set of operating system and browser combinations. You
can either purchase a product that will show you how a site would look in a particular operating
system and browser or you can set up the operating systems and browsers yourself and test them
manually. The latter option will give you more reliable results and may be cheaper if you expect
to do a lot of operating system and browser testing. If you do decide to set up the operating
systems and browsers yourself ensure you have access to decent technical support and a
dedicated PC and Mac devoted to testing purposes only. Often the installation of multiple
operating systems and browser versions will significantly slow down a computer.

There are a number of programs that will emulate a particular operating system and browser
combination. The pricing ranges from free to $US19.95 for unlimited use over a 24 hour period
and up to $US995 for unlimited use for an entire year. Some examples of these products are:
  HYPERLINK "http://www.browsercam.com"             BrowserCam        (for details on
BrowserCam see the article: HYPERLINK
"http://www.masternewmedia.org/news/2007/01/22/browser_compatibility_testing_browsercam
_gets.htm"     Browser Compatibility Testing: BrowserCam Gets Better - Video Review         )
  HYPERLINK "http://browsershots.org"         BrowserShots
  HYPERLINK "http://www.netmechanic.com/products/browser-index.shtml"
    BrowserPhoto
 HYPERLINK "http://www.webdesignerstoolkit.com/" Web Designers‘ Toolkit
  HYPERLINK "http://www.delorie.com/web/wpbcv.html"             Web Page Backward
Compatibility Viewer

To test web sites in specific operating systems or browsers see:
  HYPERLINK "http://www.browsrcamp.com/"         BrowsrCamp (Mac browsers Emulator)
  HYPERLINK "http://pearpc.sourceforge.net/"     PearPC (Mac Emulator)
  HYPERLINK "http://opensource.region-stuttgart.de/test_linux_desktop.php" Test Linux
Desktop
  HYPERLINK "http://www.delorie.com/web/lynxview.html"         LynxViewer

There are also viewers that can show you what your web site will look like in other technologies:
  HYPERLINK "http://emulator.mtld.mobi/emulator.php"          Mobi – Mobile emulator
  HYPERLINK "http://www.microsoft.com/downloads/details.aspx?familyid=EEC33AE3-
C129-4C25-ABAA-18E8E842178F&displaylang=en"              Windows Mobile 5.0 Pocket PC
Emulator
  HYPERLINK "http://www.microsoft.com/downloads/details.aspx?familyid=57265402-47a8-
4ce4-9aa7-5fe85b95de72&displaylang=en"         Windows Mobile 2003 Pocket PC Emulator

Installing multiple operating systems
Most computers can run more than one operating system using the free HYPERLINK
"http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx"           Microsoft
Virtual PC     . Microsoft Virtual PC allows you to install multiple operating systems and easily
move between them. For more information see the HYPERLINK
"http://en.wikipedia.org/wiki/Virtual_PC"     Virtual PC Wiki       .

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
HYPERLINK "http://browsers.evolt.org/"             evolt.org browser archive    has the most
comprehensive list of browsers on the internet. Other browser archives include:
    HYPERLINK "http://sillydog.org/narchive/"           Netscape browser archive
    HYPERLINK "http://www.microsoft.com/windows/ie/ie6/previous/default.mspx"                Internet
Explorer browser archive
  HYPERLINK "http://www.mozilla.org/releases/"  Mozilla Releases
  HYPERLINK "http://www.microsoft.com/windows/ie/ie6/previous/default.mspx"
   Previous versions of Internet Explorer

There is also information on running HYPERLINK "http://www.hiveminds.co.uk/node/3114"
   multiple versions of FireFox on Windows .

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
   HYPERLINK "http://www.sitepoint.com/article/ultimate-testing-checklist"      The Ultimate
testing checklist
   HYPERLINK "http://www.siliconglen.com/usability/browsers.html"         Why your site
should work on multiple browsers
   HYPERLINK "http://css-discuss.incutio.com/?page=BrowserTesting"         Browser
Testing
   HYPERLINK "http://www.smashingmagazine.com/2010/06/04/cross-browser-testing-a-
detailed-review-of-tools-and-services/"   Cross Browser Testing: a detailed review of Tools
and Services
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.
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 ; and
Providing captions of all the audio content in the video .

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 ; 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 . 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 ; and
Provide a link to a page with the transcript and audio described video.
See the HYPERLINK \l "captioningvodcasts"              Vodcast section .
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 ), however providing a downloadable audio or video file is more accessible.
Live streaming content should always have an alternative, for example, the songs being played
on a streaming radio site.
Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects,
sounds (played with or without user interaction), stand-alone audio files, audio tracks of video,
and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

Complying with accessibility requirements when including video
Creating the video in a particular way
Accessibility needs to be considered both when videoing the content and when converting the
video for web use.
When videoing the content
Use only high contrast colours;
Do not provide information in colour alone;
Do not use patterned backgrounds; and
Do not include flashing or flickering content.
When converting the video for web use
Use a consistent video file format;
Allow users to zoom in and out on content;
Limit video files to 2MB or less (for larger files, break them up into smaller downloads as well
as offering the full file, or create a low bandwidth version of the content);
Allow users to control the video (e.g. pause, rewind, etc.) via the keyboard only;
Allow users to control the video (e.g. pause, rewind, etc.) via the mouse only; and
Allow users to control the volume.
Inserting the video in the site in a particular way
Accessibility needs to be considered in how the user will access the video.
Never automatically start a video file;
Never embed the video;
Allow the user to skip over the video using the mouse only;
Allow the user to skip over the video using keyboard only;
Open the video in a new window;
Ensure the site is functional and all content is available without the video; and
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 , including a video. As well as the video
they include a page of information about the skilled migrant.


Further Information
W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
W3C Checkpoint 6.2: Equivalents for dynamic content are updated when the dynamic content
changes
    HYPERLINK "http://ncam.wgbh.org/webaccess/magpie/magpie_help/more_cc_topics.html"
\l "youtube"    NCAM YouTube captioning
    HYPERLINK "http://www.reelseo.com/youtube-captioning-accessibility/"     YouTube
captioning
    HYPERLINK "http://www.youtube.com/blog?entry=mi8D3ntPgFQ"            YouTube Australia
Official Blog
    HYPERLINK "http://icant.co.uk/easy-youtube/"      Easy YouTube video player
Captioning downloadable videos
There will be people who won‘t be able to access the audio content of the video because:
They are hearing impaired or deaf;
They are in a noisy environment; or
They cannot play sound.
Videos cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people who are hearing impaired or deaf. A video is made usable to
some people with disabilities by:
Providing a transcript of the video in text or HTML ;
Providing audio descriptions of all the visual content in the video ; 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 )
Notepad
Quicktime

Using MAGpie to create captions
MAGpie is very well-known accessible captioning software.
Create a project:
Under the File menu, select ―New project‖
In the dialog box, select the ―Browse‖ button and select your video file
For ―Caption styles‖ select 18pt, centred and click OK
When the ―Create new project track‖ dialog box opens, click OK
Create a caption:
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, 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]
When you have completed one caption, press Enter twice to create a new row for a new caption.
Setting the timestamp:
Press F7 to rewind the video to the beginning
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
Press F6 to begin playing the video.
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.
Continue until all captions have timestamps
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:
Under the ―Export‖ menu select ―Quicktime – SMIL 1.0 format‖
Open Quicktime and select the SMIL file that MAGpie created
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
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:
Copy the following files to the appropriate directory on website:
original_movie.mp4
filename.qt.txt
Open filename.qt.smil file in Notepad
Replace
<video dur="0:02:19.75" region="videoregion" src="original_movie.mp4"/>
with
<video dur="0:02:19.75" region="videoregion"
src="http://www.yoururl.com.au /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"/>
Copy filename.qt.smil to your web site directory:
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
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
   HYPERLINK "http://ncdae.org/tools/factsheets/captioning.cfm"           NCDAE: Introduction to
captioning
   HYPERLINK "http://ncam.wgbh.org/webaccess/magpie/magpie_help/" \l "captioning"
    MAGpie: Caption authoring
   HYPERLINK "http://www.webaim.org/techniques/captions/magpie/version2/"                WebAIM:
Captioning with MAGpie 2.0
   HYPERLINK "http://streaming.wisconsin.edu/accessibility/magpie_tutorial/quicktime.html"
    Streaming Media: Merging captions and video
   HYPERLINK "http://joeclark.org/access/captioning/bpoc/"          Best practices in online
captioning
Captioning YouTube videos

There will be people who won‘t be able to access the audio content of the video because:
They are hearing impaired or deaf;
They are in a noisy environment; or
They cannot play sound.
YouTube videos cannot be made fully accessible, but they can be made accessible to some
people with disabilities; for example people who are hearing impaired or deaf. A YouTube video
is made usable by some people with disabilities by:
Providing a transcript of the video in text or HTML ;
Providing audio descriptions of all the visual content in the video ; and
Providing captions of all the audio content in the video.

Relationship to WCAG1 checkpoints:
Checkpoint 1.4 requires that for any time-based multimedia presentation (e.g., a movie or
animation), there must be synchronized equivalent alternatives (e.g., captions or auditory
descriptions of the visual track) with the presentation

Tools you will need
YouTube has introduced an automatic speech recognition service that automatically creates
captions for videos. It can either be done automatically, which will sometimes include errors, or
it can generate captions from a transcript.
Every YouTube video should be uploaded with a transcript. This transcript should also be
available to the general public in the event that they have a disability that prevents them from
viewing or hearing the YouTube video.
Create a transcript
1. When creating a transcript you should include all the important information in the video
(audio and video content). However when creating a YouTube transcript include the speech only.
Upload the transcript
1. Select 'My Videos' under the 'Account' option.
2. Find the video and select the 'Captions' button.
3. Select the 'Add New Captions or Transcript' button.
4. Select the 'Browse' button and find the transcript file to upload.
5. Select the 'Transcript file' option.
6. Select the English option.
7. Select the 'Upload File' button.
Examples:
   HYPERLINK
"http://www.youtube.com/watch?v=u8IibOLLO64&feature=PlayList&p=4ABC2E9B505350EF
&playnext_from=PL&playnext=1&index=1"               John Brumby announces improvements to Box
Hill hospital

Further Information
Checkpoint 1.4: For any time-based multimedia presentation (e.g., a movie or animation),
synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track)
with the presentation
  HYPERLINK "http://googleblog.blogspot.com/2009/11/automatic-captions-in-youtube.html"
  Google Blog: YouTube launches auto-captioning
  HYPERLINK "http://mashable.com/2010/03/04/youtube-auto-captioning/" Mashable:
YouTube launches auto-captioning for videos
Audio describing videos

There will be people who require audio descriptions because:
They are visually impaired or blind;
They have English as a Second language; and/or
They have a physical disability which prevents them from pausing the media player to read the
text on the screen.
Videos cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people using screen readers. A video is made accessible by:
Providing a transcript of the HYPERLINK \l "videos"             video in text or HTML      ;
Providing audio descriptions of all the visual content in the video; and
Providing captions of all the HYPERLINK \l "audiovideos"              audio content in the
video      .

Relationship to WCAG1 checkpoints:
Checkpoint 1.3 requires that until user agents can automatically read aloud the text equivalent of
a visual track, provide an auditory description of the important information of the visual track of
a multimedia presentation.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

Tools you will need
In order to create audio descriptions, your video file must be in MP4 format. There are numerous
methods to create a MP4 – this document deals with only one of them.
You will need the following applications installed:
MAGpie 2.0 ( HYPERLINK
"http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html"         see installation
instructions    )
Notepad
Quicktime

Using MAGpie to create audio descriptions
MAGpie is very well-known accessible captioning software.
Create a project:
Under the File menu, select ―New project‖
In the dialog box, select the ―Browse‖ button and select your video file
Click OK
When the ―Create new project track‖ dialog box opens, select ―Audio Descriptions‖ in the
―Track Type‖ section
Click OK
Create an audio description:
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
Select the ―Use generated file name‖ option.
When you are ready to record the description click ―Record‖ (you will need a microphone for
this)
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
When you have completed one recording, press Enter twice to create a new row for a new audio
description.
Setting the timestamp:
Press F7 to rewind the video to the beginning
Press F6 to begin playing the video.
When the audio description should be spoken press F9 – this will set a timestamp for the audio
description
Continue until all audio descriptions have timestamps
MAGpie will automatically insert a new row at the end. Delete this row (right click on the row
and select ―Delete selected rows‖)

Testing the audio descriptions
Checking your work:
Under the ―Export‖ menu select ―Quicktime – SMIL 1.0 format‖. Save the file.
Open Quicktime and select the SMIL file that MAGpie created in step 1
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
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
Copy the following files to the appropriate directory on your website :
original_movie.mp4
audiofile1.wav, audiofile2.wav etc.
Open filename_audio.qt.smil file in Notepad
Replace
<video dur="0:02:19.75" region="videoregion"
src="original_movie.mp4"/>
with
<video dur="0:02:19.75" region="videoregion"
src="http://www.yoururl.com.au/ original_movie.mp4"/>
Replace
<audio src="audiofile1.wav" begin="0:00:00.00"/>
with
<audio src="http://www.yoururl.com.au/audiofile1.wav" begin="0:00:00.00"/>
Replace
<audio src="audiofile2.wav" begin="0:00:43.52"/>
with
<audio src="http://www.yoururl.com.au/audiofile2.wav" begin="0:00:43.52"/>
Replace
<audio src="audiofile3.wav" begin="0:01:18.50"/>
with
<audio src="http://www.yoururl.com.au/audiofile3.wav" begin="0:01:18.50"/>
Repeat for all audiofiles
Copy filename_audio.qt.smil to your web site directory:
In the HTML of your web page insert the following HTML:
<a href=" http://www.yoururl.com.au/ 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

Further information
  HYPERLINK "http://ncam.wgbh.org/webaccess/magpie/magpie_help/" \l "audiodescription"
    MAGpie: Audio descriptions
  HYPERLINK "http://joeclark.org/access/description/ad-principles.html"   Joe Clark:
Standard techniques in audio description
  HYPERLINK "http://www.skillsforaccess.org.uk/howto.php?id=135"        Skills for Access:
Provide audio descriptions for video or animated content – in MAGpie
Captioning vodcasts

There will be people who won‘t be able to access the audio content of the video because:
They are deaf or hearing impaired;
They are in a noisy environment; or
They cannot play sound.
Vodcasts cannot be made fully accessible, but they can be made accessible to some people with
disabilities; for example people who are hearing impaired or deaf. A vodcast is made accessible
by:
Providing a transcript of the video in text or HTML ; and
Providing captions of all the audio content in the video.

Relationship to WCAG1 checkpoints:
Checkpoint 1.4 requires that for any time-based multimedia presentation (e.g. a movie or
animation), there must be synchronized, equivalent alternatives (e.g. captions or auditory
descriptions of the visual track) with the presentation

Tools you will need
In order to create captions of your vodcast, your file must be in MP4 format. You will need the
following hardware and applications to create a vodcast:
Speakers
Microphone
Webcam
MAGpie 2.0 (see HYPERLINK
"http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html"         MAGpie installation
instructions    )
   HYPERLINK "http://www.apple.com/au/quicktime/"             Quicktime Pro
iTunes account (if you want to add the vodcast to iTunes)
RSS feed URL

Using MAGpie to create captions
MAGpie is very well-known accessible captioning software.
Create a project:
Under the File menu, select ―New project‖
In the dialog box, select the ―Browse‖ button and select your video file
For ―Caption styles‖ select 18pt, centred and click OK
When the ―Create new project track‖ dialog box opens, click OK

Create a caption:
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]
When you have completed one caption, press Enter twice to create a new row for a new caption.
Setting the timestamp:
Press F7 to rewind the video to the beginning
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
Press F6 to begin playing the video
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
Continue until all captions have timestamps
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:
Under the ―Export‖ menu select ―Quicktime – SMIL 1.0 format‖
Open Quicktime and select the SMIL file that MAGpie created
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.
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.


Associate captions with the vodcast
Associate captions
Open the original vodcast (without captions) in Quicktime
Open the vodcast.qt.txt document in Quicktime
In the vodcast.qt.txt file, under the Edit menu, select the option ―Select All‖
Under the Edit menu, select Copy
Go to the original vodcast
Under the Edit menu, select Add to movie
Position captions on the screen
Under the Window menu, select Show Movie Properties
Select Video Track and then the Visual Settings tab
Write down the number in the second Scaled Size field (in the example below, this number is
240)

Select Text Track and then the Visual Settings tab
In the second field of the Scaled Size fields, change the number to 80.
In the second Offset Field, insert the value you captured in step 3, above

Export to MP4
Under the File menu, select Export
Under Export As select Movie to MPEG4
Upload and insert the vodcast to a site
Copy the vodcast to your web server
Add a link to the vodcast
If your RSS feed is not already uploaded to iTunes:
Go to iTunes
Select iTunes store
Select ―Submit a podcast‖
Select Podcasts on the left hand side
Down the bottom right hand side of the page, select ―Submit a podcast‖
Insert your RSS URL
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 HYPERLINK
"http://www.gianwild.com.au/2009/03/29/vodcastvodcast/" Gian Wild‘s web site.
Example 2: Koorie education captioned vodcast
A complex vodcast, complete with captions has been created at HYPERLINK
"http://www.gianwild.com.au/2009/03/29/koorie-education-captioned-vodcast" Gian
Wild‘s web site

Further Information
Checkpoint 1.4: For any time-based multimedia presentation (e.g. a movie or animation),
synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track)
with the presentation
  HYPERLINK "http://ncdae.org/tools/factsheets/captioning.cfm"           NCDAE: Introduction to
captioning
  HYPERLINK "http://ncam.wgbh.org/webaccess/magpie/magpie_help/" \l "captioning"
    MAGpie: Caption authoring
  HYPERLINK "http://www.webaim.org/techniques/captions/magpie/version2/"          WebAIM:
Captioning with MAGpie 2.0
  HYPERLINK "http://streaming.wisconsin.edu/accessibility/magpie_tutorial/quicktime.html"
    Streaming Media: Merging captions and video
  HYPERLINK "http://joeclark.org/access/captioning/bpoc/"     Best practices in online
captioning
  HYPERLINK "http://hightech.redwoods.edu/accessibility/podcasting/"      How to create an
accessible podcast
  HYPERLINK "http://webaxe.blogspot.com/2007/11/podcast-59-jeffrey-frey-on-
accessible.html"    WebAxe Podcasts: Jeffrey Frey on Accessible Podcasts
  HYPERLINK "http://www.lancs.ac.uk/celt/celtweb/accessible_podcasts"       Accessible
podcasts
  HYPERLINK "http://www.techdis.ac.uk/index.php?p=3_10_13_3"          Podcasting and
accessibility
  HYPERLINK "http://jdfrey.wordpress.com/2006/11/02/podcast-captioning/"        Jeffrey
Frey‘s Podcast Captioning
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 HYPERLINK \l "videos"           podcast or audio file in text or
HTML

Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects,
sounds (played with or without user interaction), stand-alone audio files, audio tracks of video,
and video.

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
  HYPERLINK "http://audacity.sourceforge.net/"         Audacity
  HYPERLINK "http://audacity.sourceforge.net/help/faq?s=install&item=lame-mp3"
   LAME        (add the .dll to the Audacity folder)
  HYPERLINK "http://www.mp3tag.de/en/"             STAMP
iTunes account (if you want to upload the podcast to iTunes)
RSS feed URL

Complying with accessibility requirements when creating podcasts
Creating the podcast
Open Audacity
Select the red round button to start recording the podcast
Select the stop button to stop recording the podcast
Under the file menu, select Export as MP3
Save the file
Add tags to the podcast
Open Stamp and maximize the window
On the left hand side browse and select your podcast
Select Genre and type in the correct genre
Select the Stamp button
Upload podcast to a site
Copy the podcast to your web server
Add a link to the podcast
If your RSS feed is not already uploaded to iTunes:
Go to iTunes
Select iTunes store
Select ―Submit a podcast‖
Select Podcasts on the left hand side
Down the bottom right hand side of the page, select ―Submit a podcast‖
Insert your RSS URL
Select Continue
iTunes will review your podcasts before putting them on the iTunes site.

Example 1: A test podcast
See HYPERLINK "http://www.gianwild.com.au/2009/03/29/podcastpodcast/"                  Gian
Wild‘s web site fo an example podcast and transcript.
                     r

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
  HYPERLINK "http://hightech.redwoods.edu/accessibility/podcasting/"             How to create an
accessible podcast
  HYPERLINK "http://webaxe.blogspot.com/2007/11/podcast-59-jeffrey-frey-on-
accessible.html"     WebAxe Podcasts: Jeffrey Frey on Accessible Podcasts
  HYPERLINK "http://www.lancs.ac.uk/celt/celtweb/accessible_podcasts"              Accessible
podcasts
  HYPERLINK "http://www.techdis.ac.uk/index.php?p=3_10_13_3"                Podcasting and
accessibility
Flash and accessibility

There will be people who won‘t be able to access the Flash file because:
They are hearing impaired or deaf;
They are visually impaired or blind;
They are using a slow modem;
They do not have the required Flash player; and/or
They have a physical disability which prevents them from using the Flash player.
Flash cannot be made fully accessible, but it can be made accessible to some people with
disabilities; for example people using screen readers. A Flash file is made accessible by:
Creating the Flash in a particular way;
Inserting the Flash file in the site a particular way; and
Providing a transcript of the Flash file in text or HTML.

Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects,
sounds (played with or without user interaction), stand-alone audio files, audio tracks of video,
and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

Complying with accessibility requirements when including Flash
Creating the Flash in a particular way
The Flash file needs to be created in a particular way, in order to make it accessible.
Accessibility needs to be considered both when creating the Flash file and when inserting the file
into the web site.
When creating the Flash file
Use FlashMX to develop the Flash file and ensure that:
On the Flash Accessibility Panel:
―Make object accessible‖ is selected on all objects;
―Make child object accessible‖ is selected on all relevant child objects;
―Make child object accessible‖ is deselected for all child object animations;
―Make Movie accessible‖ is selected for all movies;
―Auto-label‖ is selected;
―Name‖ is completed on all objects; and
―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.

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 ;
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 :
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 HYPERLINK
"http://www.education.vic.gov.au/languagesonline/indonesian/sect01/no_5/no_5.htm"
    Indonesian language activity       .


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)




Further Information
  HYPERLINK "http://www.w3.org/TR/WCAG10-TECHS/" \l "tech-text-equivalent"               W3C
Checkpoint 1.1 : Provide a text equivalent for every non-text element
  HYPERLINK "http://www.rnib.org.uk/wacblog/flash/accessible-flash-banner-ad-guidelines/"
    Accessible Flash Banner Guidelines
  HYPERLINK "http://www.webaim.org/techniques/flash/"            WebAIM – Creating
Accessible Macromedia Flash content
  HYPERLINK
"http://www.adobe.com/resources/accessibility/best_practices/best_practices_acc_flash.pdf"
    Best Practices for Accessible Flash Design    (Adobe Reader required)
  HYPERLINK
"http://www.brainbell.com/tutorials/Flash/Basic_Tasks_Create_Accessible_Flash_Content.htm"
    Create accessible Flash content
  HYPERLINK "http://www.hisoftware.com/accrepair_flash/index.html"           AccRepair for
Flash
Mashups and accessibility

There will be people who won‘t be able to access the mashup because:
They are hearing impaired or deaf;
They are visually impaired or blind;
They have a physical disability;
They have a cognitive disability;
They are using a slow modem;
They do not have the required media player; and/or
They have a physical disability which means they cannot use the media player.
It is difficult to categorically state that mashups are inaccessible; it really depends on the primary
applications and how they have been put together. The best way to ensure that mashups do not
exclude people with disabilities is to provide a transcript of the mashup in text or HTML.

Relationship to WCAG1 checkpoints
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g. via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects,
sounds (played with or without user interaction), stand-alone audio files, audio tracks of video,
and video.
Checkpoint 6.2 requires that equivalents for dynamic content are updated when the dynamic
content changes.

Complying with accessibility requirements when including mashups
Providing a transcript of the mashup in text or HTML
It is important to provide a transcript of the mashup. Where the user cannot access the mashup, it
is vital that a transcript is provided (in HTML, text or Word) so that they are not missing out on
the content within the mashup.

Example 1: Transcript of a mashup
Google Maps created a mashup of the Victorian bushfires in February 2009. This mashup was
updated with fundraising events in the months after Black Saturday.


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

In the above example, users can view the eight different entries from Mt Beauty Primary School
in the map. This mashup can be made easily accessible through both HTML and images by:
Organizing the images by name of the school and the name of the student (including year level);
and
Providing a brief description of the image in the ALT attribute (i.e. in the above example the
ALT attribute would be ―Emu, kangaroo and tree used in Google logo, with aboriginal
symbolism, with a background of the setting sun‖)

Further Information
W3C Checkpoint 1.1: Provide a text equivalent for every non-text element
  HYPERLINK "http://mashupawards.com/winners/"           Mashup Awards
  HYPERLINK "http://www.egov.vic.gov.au/website-practice/web-2-0-
a/mashups.html"     eGovernment Resource Centre mashups
  HYPERLINK "http://www-03.ibm.com/able/resources/mashup.html"           IBM Web 2.0
mashup accessibility
  HYPERLINK "http://www-03.ibm.com/able/news/webmashup.html"             IBM The future is
now
Blogging and accessibility

Blogging is often just text or a combination of text, images and links. Therefore it is easy to
make a blog accessible. However a blog has all the same potential accessibility issues as a web
site does. Consequently blogs should always be tested against the W3C Web Content
Accessibility Guidelines, Version 1.0, Level AA.

Relationship to WCAG1 checkpoints:
Checkpoint 3.5 requires that header elements are used to convey document structure and that
they are used according to specification.
Checkpoint 10.2 requires that all form controls with implicitly associated labels, that the label is
properly positioned.
Checkpoint 12.4 requires that labels are explicitly associated with their controls.
Checkpoint 13.1 requires that the target of each link is clearly identified.

Complying with accessibility requirements when creating blogs
Headings
Make sure that the blog post is a heading, and that each blog post heading is at the same level. If
you use headings within blog posts then make sure all headings are nested properly. The name of
the blog should be an H1.
Field labels
Where users can add comments, ensure that each field has a descriptive field label that is
immediately to the left or immediately above the relevant field.
Ensure that these fields and field labels are coded using the FOR ID and LABEL elements.
Links
Most blog posts contain links to the comments section. It is imperative that these links are
unique. So, for example, if there are a number of comments on a particular blog post then the
link should include the number of comments and the name of blog post. For example ―34
comments on Writing accessible blog posts‖.

Example 1: Gian Wild‘s blog
  HYPERLINK "http://www.gianwild.com.au/" Gian Wild‘s blog

Further Information
  HYPERLINK "http://www.brucelawson.co.uk/2005/wordpress-accessibility-hacks/"
    Bruce Lawson Wordpress Accessibility Hacks
  HYPERLINK "http://www.marcozehe.de/2008/07/16/wordpress-26-brings-a-lot-of-
accessibility-improvements/"  Wordpress 2.6 Accessibility Features
  HYPERLINK "http://accessites.org/site/2008/11/wordpress-and-accessibility/" Accessites:
Wordpress and accessibility
  HYPERLINK "http://www.marcozehe.de/2008/07/16/wordpress-26-brings-a-lot-of-
accessibility-improvements/"   Wordpress embraces ARIA
  HYPERLINK "http://www.youthtopia.net/acontent/wpaccess.htm"   A brief introduction to
WordPress and Web Accessibility
  HYPERLINK "http://joeclark.org/access/webaccess/WordPress-ATAG-evaluation.html"
    ATAG assessment of WordPress by Joe Clark
Making maps and Google maps accessible

Online maps are inaccessible to vision impaired people so a textual alternative (long description)
must always be provided. It is also important to include accessibility features within the map so
it is accessible to people with other disabilities e.g. by making the map non-reliant on JavaScript
and keyboard accessible. Maps can be made accessible by:
providing a long description of the map in text or HTML;
making the map keyboard accessible;
making an HTML version of any JavaScript features of the map;
using only high contrast colours;
not relying on colour to differentiate important parts of the map; and
allowing users to increase the size of the map, legend and any text.
Note that there will be people who won‘t be able to access the map because:
they are blind;
they have a text only browser; and/or
they have a slow internet connection.

Relationship to checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element e.g. via
"alt", "longdesc", or in element content. This includes: images, graphical representations of text
(including symbols), image map regions, animations e.g., animated GIFs, applets and
programmatic objects.

What about Google maps?
Google maps have a number of features that improve the accessibility of their maps; notably, you
can easily create non-JavaScript, keyboard accessible versions of any Google map. To create a
keyboard accessible map, start a map search by loading the URL HYPERLINK
"http://maps.google.com/?output=html"         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:

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 HYPERLINK "http://www.bom.gov.au/products/IDR023.shtml"
     Melbourne Rain Radar map        :

4.25pm Storm (strong) approaching east over Williamstown, eight kilometres in diameter. Light
rain over Melbourne city, four kilometres in diameter.
4.40pm Storm (strong) ten kilometres west of Melbourne city. Light rain over Clayton, four
kilometres in diameter.
4.55pm Storm (strong) over Melbourne city, eight kilometres in diameter. Rain (strong) over
Richmond.
5.10pm Storm (extreme) over inner city East Melbourne, ten kilometres ,in diameter.

If the map is a topographical map, mark the height at which important points occur. The
following is a long description for a hiker's map of the Purlingbrook Falls map:

The waterfall is 109 metres tall. The track starts at the top and descends to the bottom of the
waterfall before crossing behind the base of the waterfall and ascending back to the top. The
track is a steep zig zagging track, descending about 40cm for every horizontal metre.

If the map is a transport map, organise the map by train, bus or train line and describe the
locations and distances travelled.

Train line: City Loop
The City Loop consists of four train stations set in a roughly square formation around Melbourne
city: Flinders St station, Southern Cross station (formerly Spencer St station), Flagstaff station
and Parliament station. Flinders St station is situated on the corner of Flinders St and Swanston
St. Spencer St station is situated on the corner of Bourke and Collins Sts and Spencer St.
Flagstaff is situated on the corner of La Trobe and King Streets. Parliament is situated off Collins
St with entrances on Collins, Spring, Lonsdale, Nicholson and MacArthur Streets. During
morning peak hour, trains run from Parliament to Flagstaff to Southern Cross and terminating at
Flinders St. During afternoon peak hour trains run in the opposite direction.

Making the map keyboard accessible
Often maps rely upon distinct mouse movements or clicks to select an area, move to another
area or to zoom. These movements can, and should, be made available with the keyboard so that
users are not entirely reliant on mouse actions. For example, users should be able to use only the
keyboard to:
move the map left, right, up or down;
select different areas of the map; and
zoom in or out on the top left, top right, centre, bottom left or bottom right quadrant.
Making an HTML version of any JavaScript features of the map
Often maps use JavaScript to provide enhanced features e.g. smooth, animated zooming. Maps
that use JavaScript-based features should always have an HTML fallback that allows users to.
move the map left, right, up or down using HTML only;
select different areas of the map using HTML only; and
zoom in or out on the top left, top right, centre, bottom left or bottom right quadrant using
HTML only.
Using only high contrast colours
Ensure that your map design complies with the 4.5:1 colour contrast ratio..
Not relying on colour to differentiate important parts of the map
Ensure that your maps use:
borders to separate one area from another;
different types of shading and change of colour to indicate different areas;
label markers with an ASCII character and individual colours for different markers; and
client-side image maps and accurate ALT attributes to indicate areas of a map or important
markers.
Allowing users to increase the size of the map, legend and any text
To make maps accessible to some groups of people with vision impairments, it is important to
allow users to not only to zoom in on areas of the map, but to increase the size of the map,
legend and text. Often maps do not respond to browser requests to increase size, therefore
additional methods may be required to:
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 HYPERLINK
"http://www.dse.vic.gov.au/DSE/nrenfoe.nsf/LinkView/519C51D981DAE41FCA257257000A5
163DC25C965BDA0CAF5CA2573B400013504"                     DSE- Fires Today - Summary of incidents
on Public Land
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 HYPERLINK "http://ironfeathers.ca/"
    IronFeathers       .

Further Information
   HYPERLINK "http://maps.google.com"          Google maps
   HYPERLINK "http://googleblog.blogspot.com/2006/12/speech-friendly-textual-
directions.html"    Speech friendly textual directions from Google maps
   HYPERLINK "http://dev.opera.com/articles/view/keyboard-accessible-google-maps/"
    Opera – Keyboard accessible Google maps
   HYPERLINK "http://blogs.cetis.ac.uk/accessibility/2007/01/29/can-you-really-have-an-
accessible-google-map/"     Can you really have an accessible Google map?
   HYPERLINK "http://code.google.com/apis/maps/documentation/staticmaps/"         Google
Static Maps API
   HYPERLINK "http://gmaps-
samples.googlecode.com/svn/trunk/simplewizard/makestaticmap.html"       Google Static map
wizard
Frames and iFrames

According to the Web Content Accessibility Guidelines (WCAG), Version 1.0, frames are
inaccessible and any information contained within a frame must be provided elsewhere
(Checkpoint 1.1). Some assistive technologies do now interact with frames and iframes, however
it is still important to provide equivalent, accessible content where they are used.

The use of standard frames is now quite uncommon and not recommended practice. iFrames are
more common but still require strong consideration of their benefit against the issues they raise
with accessibility and website usability. Some of the issues raised by iFrames are that they:
break the Back button;
don‘t allow users to bookmark pages; and they
make printing website content difficult for users.

Therefore if you use frames or iFrames you must provide equivalent, accessible content in
HTML or text.

Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: frames.
Checkpoint 6.5 requires that dynamic content is accessible or that provide an alternative
presentation or page is provided (eg. NOFRAMES for FRAME element)
Checkpoint 12.2 requires that the purpose of frames and how frames relate to each other is
described if it is not obvious by frame titles alone.

What are iFrames?
An iFrame (also known as an inline frame) places one HTML document in a frame inside a
normal (rather than frameset) HTML document. iFrames can also be used as the ―target‖ of a
link, in which case only the iFrame is opened. Alternative text is provided within the
<IFRAME> tag set, for example:
<iframe src ="html_intro.asp" width="100%" height="300">Alternative text</iframe>

Note: the iFrame element is not supported in HTML 4.1 Strict DTD and in XHTML 1.0 Strict
DTD.

Creating accessible iFrames
Provide an equivalent
It is important to provide an equivalent of the content within the FRAME or IFRAME.
The equivalent content for a FRAME should sit within the <NOFRAMES> tag:
<FRAMESET title="Web site">
    <FRAME src="nav.html" title="Navigation">
    <FRAME src="contents.html" title="Contents of page">
    <NOFRAMES>
       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=‖ HYPERLINK "http://www.vic.gov.au/" http://www.vic.gov.au/‖
TARGET=‖_blank‖>Link</A>

Example 1: Accessible iFrame
This HYPERLINK "http://www.cs.tut.fi/~jkorpela/indexen.html"            accessible iFrame
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
   HYPERLINK "http://www.web-wise-wizard.com/html-tutorials/html-inline-floating-
frames.html"     About iFrames
   HYPERLINK "http://www.webaim.org/techniques/frames/"     WebAIM accessible
frames
Making Slideshare accessible

There will be people who won‘t be able to access a powerpoint or open office presentation
because:
They are blind
They have a text only browser
They are using a keyboard only
Slideshare is a presentation sharing website where users can upload, view and share
presentations. Presentations can be tagged and commented. It is also possible to embed
presentations into a web site or download the presentation. Presentations can be shared publicly
or privately.
Slideshare uses a combination of technologies which make it inaccessible; however there is an
accessible version of Slideshare that can be used instead. Slideshare can be made accessible by:
Providing an alternative of the presentation in HTML, text or Word; and
Providing a link to Easy Slideshare (accessible Slideshare)

Relationship to WCAG1 checkpoints:
Checkpoint 1.1 requires that a text equivalent is provided for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: applets and programmatic objects,
sounds (played with or without user interaction), stand-alone audio files, audio tracks of video,
and video.
Checkpoint 6.3 requires that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide equivalent information on
an alternative accessible page

Can Slideshare presentations be embedded in a site?
Slideshare presentations can be embedded into a web site, as the content is ignored by the
keyboard and screen readers. However an alternative must always be provided, both via Easy
Slideshare and an HTML, text or Word version.

Creating accessible Slideshare presentations
Provide a link to Easy Slideshare
A link should be provided to both the Slideshare presentation and a link to an accessible version
of the Slideshare presentation by preceding the Slideshare URL with ―http://icant.co.uk/easy-
slideshare/?slides=‖
Therefore a slideshare presentation with the following URL:
http://www.slideshare.net/cheilmann/purple-hack-fodder
Would have an Easy Slideshare URL of:
http://icant.co.uk/easy-slideshare/?slides=http://www.slideshare.net/cheilmann/purple-hack-
fodder
Providing a transcript of the Slideshare presentation in text or HTML
It is important to provide a transcript of the presentation.
Include an transcript (HTML, text or Word) to all videos
Creating HTML from a PowerPoint presentation
Install the HYPERLINK "http://its.monash.edu/web/slideshows/accessibility-
powerpoint/OETFull-en.exe"         PowerPoint accessibility wizard      .
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
  HYPERLINK "http://www.egov.vic.gov.au/victorian-government-resources/victoria-
online/victoria-online-quality-reliability-and-trust.html"   Victoria Online: quality, Reliability
and Trusts      is an embedded Slideshare presentation. It also includes an HTML version and a
link to the HYPERLINK "http://icant.co.uk/easy-slideshare/about/"           Easy Slideshare
version.

Further Information
  HYPERLINK "http://icant.co.uk/easy-slideshare/about/" Easy Slideshare
  HYPERLINK "http://its.monash.edu/web/slideshows/accessibility-powerpoint/OETFull-
en.exe"     PowerPoint Accessibility Wizard
Facebook and accessibility

There will be people who won‘t be able to access Facebook because:
They have a text only browser
They have a physical disability
They are using a keyboard only
Facebook is a social networking site where users can keep in touch with their friends, post
photos and videos and play games.
Facebook uses a combination of technologies which make it inaccessible; however there is an
HTML version of Facebook ( HYPERLINK "http://m.facebook.com/"
    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
  HYPERLINK
"http://www.facebook.com/group.php?sid=0b7d130e33debf7482bedeaf4e8ce04d&gid=4215795
8877&ref=search"        Save Water, Target 155 is a Facebook site. Information on the
Facebook site is replicated on the HYPERLINK "http://www.ourwater.vic.gov.au/target155"
    Our Water web site      .

Further Information
  HYPERLINK "http://m.facebook.com/home.php?r0467bae4&h4ed6449e&refid=8"      Text
only Facebook
  HYPERLINK "http://www.facebook.com/help.php?page=440"   Facebook accessibility
page
Twitter and accessibility

There will be people who won‘t be able to access Twitter because:
They are blind
They have a text only browser
They are using a keyboard only
Twitter is a social networking and microblogging site where users can tell their friends
(―followers‖) what they are currently doing in 140 characters or less.
Twitter uses a combination of technologies which make it inaccessible; however there is an
accessible version of Twitter that can be used instead. Twitter can be made accessible by:
Providing an alternative of the content in HTML, text or Word; and
Providing a link to Accessible Twitter

Creating accessible Twitter
Providing a transcript of the Twitter content in text, Word or HTML
It is important to provide a transcript of the Twitter content on your site, for people who cannot
use the Twitter interface or do not have a Twitter account. If time is an issue then consider
sending out SMSes at the same time as you send out a tweet.
Provide a link to Accessible Twitter
A link should be provided to the Accessible Twitter interface for people who have trouble with
the standard Twitter interface. The link is:
    HYPERLINK "http://accessibletwitter.com/"          http://accessibletwitter.com/

Example 1: John Brumby
   HYPERLINK "http://twitter.com/vicpremier" John Brumby       has a Twitter site. Tweets
are replicated on the HYPERLINK "http://www.premier.vic.gov.au/"     Premier web
site    .

Further Information
  HYPERLINK "http://accessibletwitter.com/"    Accessible Twitter
  HYPERLINK "http://accessibletwitter.com/about.php"    About Accessible Twitter
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 HYPERLINK
"http://www.w3.org/WAI/ER/existingtools.html"        the W3C Evaluation, Repair, and
Transformation Tools for Web Content Accessibility

In addition to the overview below, detailed information is available for:
   HYPERLINK \l "accverify"         AccVerify ;
   HYPERLINK \l "cynthiasays"         Cynthia Says ;
   HYPERLINK \l "ff"        Firefox Web Developer Toolbar ;
   HYPERLINK \l "wave"          WAVE ; and
   HYPERLINK \l "wat"         Web Accessibility Toolbar .
Page-by-page accessibility evaluation tools

Cynthia Says
  HYPERLINK "http://www.cynthiasays.com/"             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    HYPERLINK "http://www.cynthiasays.com"             Cynthia
Says     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    HYPERLINK \l "cynthiasays"           Cynthia Says example .

WAVE
  HYPERLINK "http://wave.webaim.org/index.jsp"           http://wave.webaim.org/index.jsp

What is WAVE?
The WAVE is a page-by-page accessibility evaluator that tests many of the W3C Web Content
Accessibility Guidelines.

How do you use WAVE?
Test one web page at a time on the HYPERLINK "http://wave.webaim.org"             WAVE
site. Alternatively you can install a WAVE toolbar or bookmarklet.

How do you interpret WAVE reports?
The WAVE provides a screenshot of the tested web page with icons and highlighting to
represent accessibility errors and features.

Which pages do you test with WAVE?
All web pages within your website.

Are there any pitfalls with WAVE?
The WAVE cannot test some WCAG checkpoints and only partially check others i.e. checkpoint
7.1.

For more information see the    HYPERLINK \l "wave"          WAVE example .

Functional Accessibility Evaluator (FAE)
  HYPERLINK "http://fae.cita.uiuc.edu/"       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 HYPERLINK "http://fae.cita.uiuc.edu/"         FAE
website or create a user account and test multiple web pages (to a maximum of three levels
deep).

How do you interpret FAE reports?
FAE categorises errors into five categories: Navigation & Orientation, Text Equivalents,
Scripting, Styling and HTML Standards. Particular errors are detailed in each section.

Which pages do you test with FAE?
All web pages within your website.

Are there any pitfalls with FAE?
The relationship between some errors and particular W3C Web Content Accessibility Guidelines
is unclear. FAE cannot test some WCAG checkpoints at all, such as clear and simple content.

AChecker / ATRC Web Accessibility Checker
http://www.achecker.ca/checker/index.php

What is AChecker?
AChecker is an online page-by-page accessibility evaluator, previously called A-Prompt. It tests
many of the W3C Web Content Accessibility Guidelines.

How do you use AChecker?
Test one web page at a time on the   HYPERLINK "http://checker.atrc.utoronto.ca/index.html"
   AChecker      website.

How do you iinterpret AChecker reports?
The AChecker categorises errors into seven categories: forms, headers, images, links, metadata,
tables and text. Particular errors are detailed in each section.

Which pages do you test with the AChecker?
All web pages within your website.

Are there any pitfalls with the AChecker?
The AChecker cannot test some WCAG checkpoints.

HERA
  HYPERLINK "http://www.sidar.org/hera/index.php.en"
   http://www.sidar.org/hera/index.php.en

What is HERA?
HERA is an online page-by-page accessibility evaluator. It tests many of the W3C Web Content
Accessibility Guidelines.

How do you use HERA?
Test one web page at a time on the   HYPERLINK "http://www.sidar.org/hera/index.php.en"
   HERA       website.

How do you interpret HERA reports?
HERA categorises errors by WCAG checkpoint.

Which pages do you test with HERA?
All web pages within your website.

Are there any pitfalls with HERA?
HERA cannot test some WCAG checkpoints, however it does give clear guidance on the manual
testing required to meet these checkpoints.

Web Accessibility Toolbar
 HYPERLINK "http://www.visionaustralia.org/info.aspx?page=614"
  http://www.visionaustralia.org/info.aspx?page=614

What is the Web Accessibility Toolbar?
Developed by Vision Australia, the Web Accessibility Toolbar provides a variety of features that
assists in testing a website. It can aid in testing many of the W3C Web Content Accessibility
Guidelines.

How do you use the Web Accessibility Toolbar?
The Web Accessibility Toolbar can be installed on Windows Internet Explorer 5 or above or
Opera.

How do you interpret the Web Accessibility Toolbar outputs?
The Web Accessibility Toolbar has a variety of functions which require different interpretations.
For more information see the Web Accessibility Toolbar example on page PAGEREF wat \h
    189 .

Which pages do you test with the Web Accessibility Toolbar?
All pages.

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    HYPERLINK \l "wat"          Web Accessibility Toolkit
example .

Firefox Web Developer Toolbar
   HYPERLINK "http://chrispederick.com/work/webdeveloper/"
    http://chrispederick.com/work/webdeveloper/

What is the Web Developer Toolbar?
The Web Developer Toolbar provides a variety of features to assist in testing a site for
accessibility, including testing against many of the W3C Web Content Accessibility Guidelines.

How do you use the Web Developer Toolbar?
Install the Web Developer Toolbar on a Firefox, Flock, Mozilla or SeaMonkey browser.

How do you interpret the Web Developer Toolbar outputs?
The Web Developer Toolbar has a variety of functions which require different interpretations.
For example, when disabling style sheets the tester needs to determine whether the site can be
used.
Which pages do you test with the Web Developer Toolbar?
All web pages within your website.

Are there any pitfalls with the Web Developer Toolbar?
Each page must be tested individually. The Firefox Web Developer Toolbar cannot test all
WCAG checkpoints and is restricted to Firefox and similar browsers.

For more information see the HYPERLINK \l "ff"            Firefox Web Developer Toolbar
example
Specific accessibility evaluation tools

W3C HTML Validator
 HYPERLINK "http://validator.w3.org/"          http://validator.w3.org/

What is the W3C HTML Validator?
The HTML Validator is an application for testing conformance with HTML standards.
Specifically, it tests for compliance with Level AA checkpoint 3.2: ―Create documents that
validate to published formal grammars‖, however it will pick up other accessibility errors such as
missing ALT attributes and invalid field labels.

How do you use the W3C HTML Validator?
Test one web page at a time on the HTML validator site.

Which pages do you test with the W3C HTML Validator?
All web pages within your website.

How do you interpret a report from the W3C HTML Validator?
The reports should be interpreted by – and will make most sense to – a person with HTML
experience.

Are there any pitfalls with the W3C HTML Validator?
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    HYPERLINK \l "creatingvalidhtml"          HTML
validation

W3C CSS Validator
 HYPERLINK "http://jigsaw.w3.org/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     HYPERLINK \l "css"         CSS validation .

JuicyStudio Colour Contrast Analyser
For more information see the section on     HYPERLINK \l "colour"          Colour Contrast .

JuicyStudio Readability Test
  HYPERLINK "http://juicystudio.com/services/readability.php"
    http://juicystudio.com/services/readability.php

What is the JuicyStudio Readability Test?
This tool tests web pages against the various reading level algorithms i.e.
Gunning Fog index, Flesch Reading Ease and the Flesch-Kincaid reading grade level.
Specifically, it tests for compliance with Level A Checkpoint 14.1: ―Ensure language is clear and
simple‖.

How do you use the JuicyStudio Readability Test?
Test one web page at a time on the Juicy Studio Readability Test page.

Which pages do you test with the JuicyStudio Readability Test?
All web pages within your website.

How do you interpret the JuicyStudio Readability Test?
The test provides a table of values, such as number of words, sentences, paragraphs etc. The
table also provides the web page‘s Gunning Fog index, the Flesch Reading Ease and the Flesch-
Kincaid reading grade level.

Are there any pitfalls with the JuicyStudio Readability Test?
The test cannot differentiate where on the web page the text sits and whether the placement
affects readability.

Vischeck
  HYPERLINK "http://vischeck.com/vischeck/vischeckURL.php"
    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
  HYPERLINK "http://www.hisoftware.com/products/accverify.html"
   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          PAGEREF accverify \h          162 .

How do you interpret AccVerify reports?
AccVerify categorises errors by WCAG checkpoint.

Which pages do you test with AccVerify?
All web pages within your website.

Are there any pitfalls with AccVerify?
AccVerify cannot test some WCAG checkpoints and only partially check others i.e. checkpoint
7.1.

For more information see the   HYPERLINK \l "accverify"   AccVerify example.
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: HYPERLINK "http://www.hisoftware.com/products/accverify.html"
    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
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).
Select the ―Verify‖ button (4) to run AccVerify.



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



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).
For an example see the Cynthia Says example .

Further Information
AccVerify has comprehensive in-product help.

Information on AccVerify
   HYPERLINK "http://www.hisoftware.com/access/accds2ibtro.html"    AccVerify and
AccRepair overview
   HYPERLINK "http://www.hisoftware.com/access/registration.htm"    Request trial
version

Using AccVerify
   HYPERLINK "http://www.hisoftware.com/access/tabutil.html"    The Table Repair
Utility
   HYPERLINK "http://www.hisoftware.com/access/formutil.html"     The Form Repair
Utility
   HYPERLINK "http://www.hisoftware.com/customchks/index.html"      Custom checks
   HYPERLINK "http://www.hisoftware.com/access/whatwedow.html"       Chart of HiSoftware
Remediation functionality
   HYPERLINK "http://www.hisoftware.com/access/functionaltest.html"    AccVerify
Interaction Builder
   HYPERLINK "http://www.hisoftware.com/access/valueadd.html"      AccVerify Add-ins
Cynthia Says

Type: Page by page
Access: Online form
Cost: Free
Company: HiSoftware
URL: HYPERLINK "http://www.cynthiasays.com"                 http://www.cynthiasays.com

Cynthia Says details guideline violations and warnings ordered by the W3C Checklist. Cynthia
Says can test certain issues with a very high degree of accuracy, for example whether an IMG tag
contains an ALT attribute. However there are some issues where Cynthia Says cannot make an
accurate assessment, for example in determining whether content is clear and simple.

Pros Cons      Can test Section 508, Level A, Level AA or Level AAA Tests only one web
page at a time    Emulates different browsers Cannot test some checkpoints      Includes a
separate Alternative Text quality report    Contains specific information on errors
How to use Cynthia Says
Cynthia Says should only be used when you are testing a small number of web pages. You will
need to run each web page manually.

1. Insert page details
Insert relevant details such as:
the URL (1);
the level of testing required (2);
specific details such as the inclusion of the Alternative Text Quality Report (3); and
the browser you wish to emulate (4).


Alternatively you could use the HYPERLINK "http://www.cynthiasays.com/fulloptions.asp"
    Cynthia Says full options tester  . 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).




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;
(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       HYPERLINK
"http://www.egov.vic.gov.au"      www.egov.vic.gov.au :

Checkpoint 13.1:
Clearly identify the target of each link.
Rule: 13.1.1 - All Anchor elements are required not to use any of the defined link phrases in the
link text.
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.
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         HYPERLINK "http://www.egov.vic.gov.au"
   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:
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
   HYPERLINK "http://www.cynthiasays.com/About%20Reports/Alt%20Quality.htm"   The
Alternative Text Quality Report
   HYPERLINK "http://www.cynthiasays.com/About%20Reports/Browser%20Emulation.htm"
    A case for browser emulation
   HYPERLINK "http://www.cynthiasays.com/media/UsingCynthia.htm"  Using Cynthia
(video and transcript)

Interpreting the reports
   HYPERLINK "http://www.cynthiasays.com/media/Readingthereport.htm"   Reading the
report (video and transcript)
   HYPERLINK "http://www.cynthiasays.com/About%20Reports/ReviewingResults.htm"
    Reviewing the results
   HYPERLINK "http://www.cynthiasays.com/About%20Reports/ErrorTracking.htm"
    Tracking down errors
   HYPERLINK "http://www.cynthiasays.com/About%20Reports/DataTables.htm"     Layout
and data tables

Specific errors
   HYPERLINK "http://www.cynthiasays.com/tutorial/a11.htm"    Checkpoint 1.1 – ALT
attributes
   HYPERLINK "http://www.cynthiasays.com/tutorial/b11.htm"    Checkpoint 1.1 – audio
files
   HYPERLINK "http://www.cynthiasays.com/tutorial/c21.htm"    Checkpoint 2.1
   HYPERLINK "http://www.cynthiasays.com/tutorial/e12.htm"    Checkpoint 1.2
   HYPERLINK "http://www.cynthiasays.com/tutorial/gh5152.htm"    Checkpoint 5.1 and
Checkpoint 5.2
  HYPERLINK "http://www.cynthiasays.com/tutorial/i11121.htm"    Checkpoint 12.1
  HYPERLINK "http://www.cynthiasays.com/tutorial/j71.htm"    Checkpoint 7.1
  HYPERLINK "http://www.cynthiasays.com/tutorial/l63.htm"    Checkpoint 6.3
Firefox Web Developer Toolbar

Type: Page by page
Access: Downloadable toolbar for use with Firefox
Cost: Free
Company: Chris Pederick
URL: HYPERLINK "http://chrispederick.com/work/web-developer/"
   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 Cannot test some checkpoints          Works with a
keyboard Must reselect options for every new web page tested            Limited to Firefox, Flock,
SeaMonkey and Mozilla web browsers (the HYPERLINK \l "wat"                    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
HYPERLINK "http://www.mozilla.com/en-US/firefox/system-requirements.html"         the
system requirements    .

You can download the extension from HYPERLINK "http://chrispederick.com/work/web-
developer/"    Chris Pederick    or from HYPERLINK "https://addons.mozilla.org/en-
US/firefox/addon/60"    Firefox    .

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.



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.

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:


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            3.3: testing whether style sheets
have been used for layout and presentation
Disable Styles All Styles
Inline Styles      3.4: determine whether relative units have been used for style sheet property
values
Outline Positioned Elements 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


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



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

Download the Firefox Web Accessibility Extension
   HYPERLINK "http://chrispederick.com/work/web-developer/"      Download from Chris
Pederick
   HYPERLINK "https://addons.mozilla.org/en-US/firefox/addon/60"    Download from
Firefox

Help using the Firefox Web Accessibility Extension
  HYPERLINK "http://www.webaim.org/articles/evaluatingwithfirefox/"             WebAIM – Using
the Firefox Web Accessibility Extension
The WAVE (version 4.0)

Type: Page by page
Access: Online form
Cost: Free
Company: WebAIM
URL: HYPERLINK "http://wave.webaim.org"                 http://wave.webaim.org

The WAVE is a page-by-page accessibility evaluator that tests many of the W3C Web Content
Accessibility Guidelines. Errors are highlighted within the web page.

Pros Cons       Can test Section 508, Level A, Level AA or Level AAA Tests only one page at
a time     Details specific information, for instance ALT attributes are provided with the relevant
image Cannot test some checkpoints          Provides a quick overview of the accessibility 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:
submit a Web Address;
upload a page;
check HTML code;
install the WAVE toolbar; or
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.


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
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 HYPERLINK
"http://www.wave.webaim.org/wave/explanation.htm"            WAVE icons and explanations
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          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          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          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        Windows Media Player
WAVE highlights accessibility features, semantic elements and accessibility errors and
warnings.
Examples
The following are WAVE failures from a selection of random websites.

1. Missing ALT attributes


According to this error, the menu icon images are missing ALT attributes, indicated by the red
icon to the right.

2. Missing field label / JavaScript form submission


According to this error, the search field does not have a field label. In addition to this, testing the
site with JavaScript disabled (using the ―Disable JavaScript‖ test) reveals that this search field
cannot be submitted without JavaScript


3. Onmouseover


Although the image has an ALT attribute of ―Help‖, it also utilizes a mouseover call and
JavaScript. On testing this onmouseover changes the colour of the ―Help‖ section and initiates a
flyout menu. This menu cannot be activated via the keyboard and is therefore inaccessible.

4. Table Headers
Test: Display Table Information



All table headers are marked up properly e.g. the code for cell Wed 15 Day 0 is
―id=day20060315‖, and all data cells reference appropriate headers eg. the headers referenced by
the first data cell are ―openingceremony‖ and ―day20060315‖.

5. Displaying Headings



According to the above inline information, all headings are marked up appropriately on this web
page. Use this test to determine whether headings have been nested properly within a web page.
Further Information

Help using WAVE
  HYPERLINK "http://webaim.org/resources/wave/"   Using WAVE
Web Accessibility Toolbar

Type: Page by page
Access: Downloadable toolbar for use with Internet Explorer
Cost: Free
Company: Vision Australia
URL: HYPERLINK "http://www.visionaustralia.org/info.aspx?page=614"
   http://www.visionaustralia.org/info.aspx?page=614

The Web Accessibility Toolbar is a downloadable toolbar for use with Internet Explorer and
Opera web browsers. It functions as a page-by-page accessibility evaluator, and can test many of
the W3C Web Content Accessibility Guidelines. In addition the toolbar contains other features
such as the ability to resize the browser to match a screen resolution. Errors are highlighted
within the web page.

Pros Cons       Provides a quick overview of the accessibility of an entire web page Tests only
one page at a time    Available in a variety of languages Cannot test some checkpoints          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
HYPERLINK \l "ff"         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.

There are separate downloads for the HYPERLINK
"http://www.nils.org.au/info.aspx?page=1569" Internet Explorer Web Accessibility
Toolbar     and the HYPERLINK "http://www.paciellogroup.com/resources/wat-about.html"
    Opera Web Accessibility Toolbar     .

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


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 
HYPERLINK "http://www.nils.org.au/info.aspx?page=619"         Toolbar functions      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 JavaScript
disabled IE Options Toggle JavaScript               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
W3C CSS Validator Validate CSS            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               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.
1. Missing ALT attributes
Test: Toggle Image/Alt



According to this error, the menu icon images are missing ALT attributes. Web Accessibility
Toolbar also raises a dialog box to inform the user of the number of images missing ALT
attributes.

2. Missing field label
Test: Fieldset / Labels



According to this error, the search field does not have a field label.

3. Onmouseover
Test: Event Handlers



This image utilizes an onmouseover call to change the colour of the ―Personal‖ section and also
initiates a flyout menu. This menu cannot be activated via the keyboard and is therefore
inaccessible.

4. Complex data tables
Test: Complex data table



According to the above inline information, the table includes a SUMMARY tag (―Schedule of
events‖), all table headers are marked up properly e.g. the code for cell Wed 15 Day 0 is
―id=day20060315‖, and all data cells reference appropriate headers e.g. the headers referenced
by the first data cell are ―openingceremony‖ and ―day20060315‖.

5. Displaying Headings
Test: Headings



According to the above inline information, all headings are marked up appropriately on this web
page. Use the ‗Heading Structure‘ test to determine whether headings have been nested properly
within a web page.

Further Information
Download the Web Accessibility Toolbar
  HYPERLINK "http://www.nils.org.au/info.aspx?page=1569"    Download the Internet
Explorer Web Accessibility Toolbar
  HYPERLINK "http://www.paciellogroup.com/resources/wat-about.html"   Download the
Opera Web Accessibility Toolbar

Help using the Web Accessibility Toolbar
  HYPERLINK "http://www.nils.org.au/info.aspx?page=619"        Toolbar functions
  HYPERLINK "http://www.webcredible.co.uk/user-friendly-resources/web-
accessibility/accessibility-toolbar.shtml" WebCredible – Using the Web Accessibility
Toolbar
  HYPERLINK "http://www.webaim.org/articles/ais/"       WebAIM – Using the Web
Accessibility Toolbar
  HYPERLINK "http://web-accessibility-toolbar.blogspot.com/"      Web Accessibility Toolbar
Blogspot
Section Seven: Accessibility resources
General accessibility links
eGovernment Resource Centre – Accessibility HYPERLINK
"http://www.egov.vic.gov.au/index.php?env=-categories:m420-1-1-8-s"
    http://www.egov.vic.gov.au/index.php?env=-categories:m420-1-1-8-s
W3C Web Accessibility Initiative ( HYPERLINK "http://www.w3.org/wai"
    http://www.w3.org/wai )
W3C Checklist ( HYPERLINK "http://www.w3.org/TR/WCAG10/full-checklist.html"
    http://www.w3.org/TR/WCAG10/full-checklist.html )
   HYPERLINK "http://www.hreoc.gov.au/disability_rights/webaccess/index.htm"              Web
Accessibility page of HREOC
(http://www.hreoc.gov.au/disability_rights/webaccess/index.htm)
W3C Auxiliary Benefits of Accessible Web Design ( HYPERLINK
"http://www.w3.org/WAI/bcase/Overview"           http://www.w3.org/WAI/bcase/Overview )
A list apart ( HYPERLINK "http://www.alistapart.com/"            http://www.alistapart.com/ )
Joe Clark ( HYPERLINK "http://joeclark.org/"           http://joeclark.org/ )
WebAIM ( HYPERLINK "http://www.webaim.org/"                   http://www.webaim.org/ )
eGovernment Resource Centre newsletter ( HYPERLINK "http://www.egov.vic.gov.au/"
    http://www.egov.vic.gov.au/ )
Disability Rights page of HREOC ( HYPERLINK
"http://www.hreoc.gov.au/disability_rights/index.html"
    http://www.hreoc.gov.au/disability_rights/index.html )
Adobe Accessibility ( HYPERLINK "http://www.adobe.com/accessibility/"
    http://www.adobe.com/accessibility/ )
Apple accessibility ( HYPERLINK "http://www.apple.com/accessibility/"
    http://www.apple.com/accessibility/ )
Microsoft accessibility ( HYPERLINK "http://www.microsoft.com/enable/"
    http://www.microsoft.com/enable/ )
Guidelines and Standards
W3C Accessibility Guidelines ( HYPERLINK "http://www.w3.org/TR/WCAG10/"
    http://www.w3.org/TR/WCAG10/ )
Whole of Victorian Government Website Standards ( HYPERLINK
"http://www.egov.vic.gov.au/index.php?env=-categories:m1050-1-1-8-s&reset=1"
    http://www.egov.vic.gov.au/index.php?env=-categories:m1050-1-1-8-s&reset=1 )
Disability Discrimination Act (Advisory notes for Web) ( HYPERLINK
"http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html"
    http://www.humanrights.gov.au/disability_rights/standards/www_3/www_3.html )
Tools
Vischeck ( HYPERLINK "http://vischeck.com/vischeck/vischeckURL.php"
    http://vischeck.com/vischeck/vischeckURL.php )
HTML Validator ( HYPERLINK "http://w3.validator.org/"                 w3.validator.org )
CSS Validator ( HYPERLINK "http://jigsaw.w3.org/css-validator/validator-uri.html"
    http://jigsaw.w3.org/css-validator/validator-uri.html )
Juicy Studio ( HYPERLINK "http://juicystudio.com/"            http://juicystudio.com/ )
Web Accessibility Toolbar ( HYPERLINK
"http://www.visionaustralia.org.au/ais/toolbar/"     http://www.visionaustralia.org.au/ais/toolbar/
  )
Firefox Web Developer Toolbar ( HYPERLINK "https://addons.mozilla.org/firefox/60/"
    https://addons.mozilla.org/firefox/60/ )
Web Accessibility Toolbar for Opera ( HYPERLINK
"http://www.paciellogroup.com/resources/wat-about.html"
    http://www.paciellogroup.com/resources/wat-about.html )