Web Accessibility Handbook Introduction

Version 1.8 Page 1

Web Accessibility Handbook Table of Contents

Table of Contents

1. Introduction ............................................................................. 3

2. What Is Web Accessibility .......................................................... 4

3. Why Websites Need to be Accessible ........................................... 5

4. Myths About Web Accessibility .................................................... 6

5. How Persons with Disabilities Use Websites .................................. 7

6. Top 10 Concerns from Persons with Disabilities ............................. 9

7. Accessibility Guidelines ............................................................ 20

8. WCAG 2.1 Success Criteria – Level A ......................................... 22

9. WCAG 2.1 Success Criteria – Level AA ....................................... 52

10. Five Testing Techniques for Web Accessibility ............................. 72

11. Web Accessibility Related Resources .......................................... 75

12. Glossary ................................................................................ 76

Appendix A: WCAG 2.1 Success Criteria – Level AAA ......................... 78

Appendix B: WCAG 2.1 Criteria Checklist for Developers ................... 106

June 2022

Version 1.8 Page 2

Web Accessibility Handbook Introduction

1. Introduction
To enable all people, including persons with disabilities, to live independently
and participate in all aspects of life, we should take every opportunity to
make information accessible to all.

1.1 Equal Opportunities for Persons with Disabilities

With the rapid growth of the Internet, ensuring that websites are accessible
to persons with disabilities is now an essential consideration to enable their
full integration into society.

This is also in line with the spirit of the United Nations’ Convention on the
Rights of Persons with Disabilities, which came into force for the People’s
Republic of China, including the Hong Kong Special Administrative Region
(HKSAR), on 31 August 2008.

1.2 Promoting Web Accessibility for Persons with Disabilities

Over the years, the HKSAR Government has been actively promoting web
accessibility to help persons with disabilities access online information and
services and enhance their user experience.

Since 1999, the Government has promulgated accessibility guidelines and

best practices for the design of government websites. The guidelines are also
available to the public as a reference for making their websites accessible.
The latest version of the guidelines is available at:
https://www.webforall.gov.hk

1.3 Web Accessibility Handbook

This Handbook is designed for senior executives and managers to better

understand the importance of web accessibility and show how it can be
successfully implemented.

Version 1.8 Page 3

Web Accessibility Handbook What is Web Accessibility

2. What Is Web Accessibility

Some organisations may consider their websites to be “accessible” when the
websites are easily found by search engines. However, the core principle of
web accessibility is not about whether people “can find you”, it is about
designing sites for everyone, no matter who they are or how they access the
Internet. It specifically addresses the needs of persons with disabilities, and
ensures acceptable ease of use for all levels of ability.

The question you need to ask is:

“Can ALL people, including persons with disabilities, access the

information that your website provides?”

By adopting relevant guidelines when designing websites to cater for the

needs of persons with disabilities, you are making your website more user-
friendly, maximising your customer base and showing that you are an
organisation that cares.

Version 1.8 Page 4

Web Accessibility Handbook Why Websites Need to be Accessible

3. Why Websites Need to be Accessible

There are many reasons why websites need to be accessible.

3.1 Social Responsibility

Everyone has a responsibility to treat persons with disabilities the same as

we treat persons without disabilities. This is especially important for websites,
as they often enable these people to live a more independent life and
maximise their potentials in a knowledge society. In some cases a website
is the only way for persons with disabilities to access up-to-date information.

3.2 Legal Responsibility

The Disability Discrimination Ordinance (Cap 487) has created a legal duty
for organisations to ensure their services are available to everyone
regardless of disability. This principle is applicable to information and
services provided through websites.

3.3 Access to Hidden Markets

Effective web accessibility allows:

 Government websites to reach more citizens.

 Corporate websites to reach and retain more online customers.

3.4 Rank More Prominently in Search Result

Adopting web accessibility design is in effect making websites more

accessible not only to persons with disabilities but also the search engines.
Many of the features making a website accessible, such as enforcing proper
coding of the webpages and presenting the contents in a clear and structured
manner, are inherent characteristics of a search engine friendly website.
Therefore, the more accessible your website is, the more effective your
search performance is, and the more potential customers you can reach.

3.5 Lower Costs

Attention to web accessibility guidelines on all website projects saves time

and money in the long term, especially when new releases of systems are
rolled out.

Building accessible websites requires good coding techniques that in turn

lead to websites that are easier to maintain and are compatible with different
web browsers and devices such as smart phones and tablets.

Version 1.8 Page 5

Web Accessibility Handbook Myths About Web Accessibility

4. Myths About Web Accessibility

There are many myths with regards to web accessibility. Some of these are
outlined below and a good understanding of them will help you drive web
accessibility in your organisation.

Myth 1: Persons with Disabilities Do Not Use Websites

Many people assume that persons with disabilities do not use websites.

In fact the complete opposite is the case.

Persons with disabilities often use websites more than persons without
disabilities. Websites have been a great enabler for these people to live a
more independent life by shopping and socialising online.

Myth 2: Accessible Websites Are Boring

Designers are fearful that building an accessible website will lead to a website
that is boring. This is not necessarily the case.

Web accessibility relies upon good coding techniques as well as simple design.

Simple design does not necessarily mean boring design.

Myth 3: Web Accessibility Is Expensive

Many people think building an accessible website is expensive and resist this
process.

In fact building an accessible website in general can save you money in the
long term through better programming discipline and good coding techniques.

These techniques lead to websites that are simpler to maintain and use with
a range of browsers and devices.

Version 1.8 Page 6

Web Accessibility Handbook How Persons with Disabilities Use Websites

5. How Persons with Disabilities Use Websites

Most people think about visually impaired persons when it comes to
accessibility, however there are many different types of disabilities and
hence many different techniques that persons with disabilities can use to
access websites.

Disabilities fall into four major categories:

In addition, there are many others who have temporary disabilities, for
example, a wounded arm. Such injuries can make accessing websites just
as difficult as it is for persons with permanent disabilities.

Examples of disabilities and the ways to overcome the constraints are

outlined below.

5.1 Visual Impairment

In this case people either cannot see at all or have difficulty in seeing a
computer screen.

It is critical that websites are designed to work with screen readers and
screen magnifiers. It is also important that colours are visible to persons with
colour blindness.

Version 1.8 Page 7

Web Accessibility Handbook How Persons with Disabilities Use Websites

5.2 Physical Impairment

In this case the person generally does not have the ability to access a website
with a keyboard or a mouse in a normal way. This kind of impairment varies
from someone who has dexterity problems and finds a mouse difficult to use,
to someone who is not able to use a mouse or keyboard at all because of
missing limbs. People with epilepsy may react to flashing images.

It is important to make buttons large enough for easy clicking, and not to
place important items too close together, otherwise wrong item might be
clicked by mistake.

Additionally, it is important to ensure the website works with assistive

technologies such as voice control software, which allow a person to access
a website using voice commands.

5.3 Hearing Impairment

With the increase in the usage of videos and audios on the web, it is
important to consider how this impacts people who cannot hear. If
information is conveyed in audio format, it is necessary to ensure there is an
alternative way to access this information.

This can be as simple as providing a text transcript of the audio content or

subtitles on the video. A text transcript has an added advantage for persons
with visual impairment as well.

5.4 Cognitive and Learning Impairment

Although it is difficult to define cognitive impairment, it generally refers to

persons with specific learning difficulties or mental illness. These people have
greater difficulty in performing mental tasks than average persons.

Although they do not require any special tools when browsing websites, they
may find it more difficult than average persons to interpret the content. This
should be kept in mind when developing contents for websites.

Version 1.8 Page 8

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6. Top 10 Concerns from Persons with Disabilities

6.1 Unable to Skip Adobe Flash and Moving Objects

Affected Group: All Persons with Disabilities

Website owners should first question the need for Adobe Flash and moving
objects, which often frustrate all people using websites.

If deemed essential, coding techniques that allow users to skip past these
items should be implemented.

Developers may also adopt cascading style sheet techniques that allow
important items to be presented first within the code and hence be read first
by screen readers.

Ensure users can skip past other blocks such as lengthy navigation bars.

The large Flash element on this example blocks the users from getting to the
main content.

Include a mechanism such as adding a “Skip to Content” button at the

beginning of a webpage to rectify the issue in cases where Adobe Flash or
moving objects must be used.

Version 1.8 Page 9

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.2 Small Font Sizes or Insufficient Colour Contrast

Affected Group: All Persons with Disabilities

Design websites with larger font sizes and use high contrast colour schemes.

It is a good practice to provide functions within a website that allow users to

enlarge the font size.

In addition, ensure websites are built so that built-in browser text size tools

work as they should.

Version 1.8 Page 10

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.3 No Alternatives for Non-text Information

Affected Group: Persons with Seeing Difficulties

Alternatives should always be provided for non-text information.

Images should contain descriptive text alternatives that effectively describe

the images.

Video content should include text transcripts that can be interpreted by screen
readers.

Consider the photo below. If you have this photo on your website, how would
you communicate what this photo is to a visually impaired person using screen
readers?

Screen readers will read the text alternative of the image. Ensure text
alternatives are meaningful and suitably descriptive.

The text alternative for this image might read “Photograph of Hong Kong
Harbour and Hong Kong Island skyline on a sunny day”.

Version 1.8 Page 11

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.4 Website Structure is Too Complicated to Understand

and/or Navigate Using Assistive Tools

Affected Group: Persons with Seeing Difficulties and Hearing Difficulties

Complex website structures make a website difficult to use for persons with
and without disabilities. Try to adopt the simplest structure as far as possible
to convey your content.

Compare the two examples of webpage layout below.

The one on the left has five content areas in a less ordered structure and has
13 additional links.

The one on the right has four content areas in an ordered structure and six
additional links.

While it is sometimes difficult to reduce the number of items on your

webpages, you can make your webpages simpler, for example, with fewer
links, so that it will be easier for persons with disabilities to access your
content.

Version 1.8 Page 12

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.5 Difficulties in Browsing Websites with Background Audio

Affected Group: Persons with Seeing Difficulties

Sound that plays automatically on websites can be annoying to some people,

and it is particularly so for people who are trying to listen to screen readers.

Ideally, background sound playing should be user-initiated, or at least there

is a convenient navigation option to turn off website audio.

Version 1.8 Page 13

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.6 Websites with Outdated Text Versions

Affected Group: Persons with Seeing Difficulties

Text versions of websites are often neglected, particularly as website changes

take place over time.

Webmasters should pay the same amount of attention to maintain these

sections as they do with other sections.

Version 1.8 Page 14

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.7 For Time-limited Functions, the Time Allowed is Too Short

Affected Group: Persons with Restricted Movement

Ideally extend the time limits on websites to ensure users have adequate time
to interact with the web content.

If this cannot be achieved, provide a simple mechanism that allows users to

extend the time limit in the middle of a process.

Version 1.8 Page 15

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.8 Volume Bars are Difficult to Control

Affected Group: Persons with Restricted Movement

Design larger volume bars so that interactions with these items using a mouse
are easier.

In addition, keyboard shortcuts should be provided for adjusting volume.

Typical volume sliders, as illustrated below, are difficult to use because the
portion that needs to be clicked is small and must be moved in subtle
increments in order to adjust volume.

A better approach is to use individual buttons for increasing and decreasing

volume as these can be clicked rather than slid to change volume.

This also makes it easier to assign keyboard shortcuts to each button.

Version 1.8 Page 16

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.9 Ambiguous Links for Screen Readers

Affected Group: Persons with Seeing Difficulties

Many websites use links such as “More information” or “Learn more” and have
these links for various pieces of content. Although this works for sighted users,
people using screen readers will be confused about which link is which. They
may discover there are several “More information” links but not know what
the links point to.

Websites should use description links in this case. Instead of just stating “More
information”, a link should state “More information about product XYZ” so that
the user knows where the link will go to just by reading the text.

Note how the links below effectively describe what the links are about and
any user will easily be able to understand the difference between the three
links.

Version 1.8 Page 17

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

6.10 Difficulties in Accessing Portable Document Format (PDF)

Affected Group: All Persons with Disabilities

PDF documents should only be used for certain situations, in particular when
you have a piece of content that you would like people to download and read
offline. In this way, PDF documents can be helpful for persons with disabilities
because they can download and read them with the assistive functions built
into PDF reading software.

We have to ensure that PDF documents are accessible to assistive

technologies, such as screen readers in a correct reading order. We should
produce a PDF document from a text-based source document and
alternative text should be provided for images (except for decorative
images), so that it is readable by Braille devices used by persons with visual
impairments. Image-based documents, such as TIF files produced by
scanning, should be converted into text-based documents with Optical
Character Recognition (OCR) software prior to producing the PDF document.

PDF documents also need to be correctly structured and tagged so as to be

accessible. Software such as Adobe Acrobat has many features that allow
structure and tagging to be checked and adjusted within a PDF document.
The techniques of making accessible PDF document is available at
www.w3.org/WAI/WCAG21/Techniques/#pdf

Any content that you would like people to read online should be delivered as
standard HTML webpages rather than PDF documents.

Version 1.8 Page 18

Web Accessibility Handbook Top 10 Concerns from Persons with Disabilities

This screen illustrates a common problem with PDF documents that have been
scanned by scanners without OCR processing. Although they appear as text
to a non-disabled person, they are not text that assistive technology can use.

PDF documents should be converted in such a way that they are text that
screen readers can convert to speech if required.

Version 1.8 Page 19

Web Accessibility Handbook Accessibility Guidelines

7. Accessibility Guidelines
7.1 World Wide Web Consortium (W3C)
Web Content Accessibility Guidelines (WCAG)

Out of the need to support the creation of websites that work for persons with
disabilities, the World Wide Web Consortium (W3C) put together the
W3C Web Accessibility Initiative (WAI). This brings together people from
industries, disability organisations, governments, and research labs from
around the world to develop guidelines and resources to help make the web
accessible to persons with disabilities. The Web Content Accessibility
Guidelines (WCAG) is developed with a goal of providing a single shared
standard for web content accessibility. (www.w3.org/WAI/standards-
guidelines/wcag/)

The WCAG documents explain how to make web content more accessible to
persons with disabilities. WCAG 2.0 (published on 11 December 2008) and
WCAG 2.1 (published on 5 June 2018) are both existing standards. WCAG 2.1
extends WCAG 2.0 by adding 17 new success criteria.

At first glance the guidelines can appear quite complex. However, the
guidelines are logical and with some effort, any website developer can
understand how to use and comply with these guidelines. The most important
thing to understand is that the guidelines consist of four parts as follows:

Structure of WCAG 2.1

Version 1.8 Page 20

Web Accessibility Handbook Accessibility Guidelines

The 78 success criteria vary in importance as follows:

Notes:
 For Level A conformance (i.e. the minimum level of conformance), the
webpage must satisfy all Level A Success Criteria.
 For Level AA conformance, the webpage must satisfy all Level A and
Level AA Success Criteria.
 For Level AAA conformance, the webpage must satisfy all Level A, Level
AA and Level AAA Success Criteria.

7.2 The Guidelines on Dissemination of Information through

Government Websites

The HKSAR Government has, since 1999, incorporated web accessibility

requirements in the Guidelines on Dissemination of Information through
Government Websites. From 2013 onwards, government websites except
archive materials are required to validate to W3C WCAG 2.0 Level AA
conformance. Besides, government bureaux/departments are advised to
adopt WCAG 2.1 Level AA standard, where appropriate, when carrying out
major revamp of websites or establishing new websites. We consider that
level A achieves a minimum level of accessibility only. On the other hand,
while level AAA provides the highest standard of accessibility, conformance
to Level AAA may require substantial resources from the organisations under
certain circumstances. To achieve the right balance, Level AA conformance
would generally enable persons with disabilities to use a website. We also
encourage websites to incorporate Level AAA features to further enhance
accessibility.

Version 1.8 Page 21

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8. WCAG 2.1 Success Criteria – Level A

8.1 WCAG 2.1 Success Criterion 1.1.1 − Non-text Content

All content on a website must be able to be represented in text so that it can

be read by screen readers. For example, images must have a text description.

This does not need to be done for Captcha or for images that are for
decoration only and do not convey meaning.

Before Rectification

Screen readers are unable to read images without meaningful text

descriptions.

After Rectification

For all images, a text description that can be read by the screen reader should
be included. The text description should enable the person reading the
webpage to know what the image is about and what it is supposed to illustrate.
WCAG 2.1 Reference:
https://www.w3.org/WAI/WCAG21/Understanding/non-text-content

Version 1.8 Page 22

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.2 WCAG 2.1 Success Criterion 1.2.1 − Audio-only and Video-

only (Prerecorded)

Make prerecorded audio or video accessible by providing alternatives that

present essentially the same information to people who cannot access the
original piece. For example, visually impaired persons cannot access video
and need a way to get this information.

Before Rectification

The example shows a video on its own. This will not be accessible for visually
impaired persons.

After Rectification

The video has included an option to download a transcript of the video that
visually impaired persons will be able to listen to using screen readers.
WCAG 2.1 Reference:
https://www.w3.org/WAI/WCAG21/Understanding/audio-only-and-video-
only-prerecorded

Version 1.8 Page 23

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.3 WCAG 2.1 Success Criterion 1.2.2 − Captions (Prerecorded)

Provide captions for audio tracks so that they are accessible by persons with
hearing impairments. Captions not only present the content of a conversation
but also important cues and surrounding noises.

Before Rectification

When an audio is embedded in a webpage, the audio is only usable by people

who can hear.

After Rectification

Text captions as shown in the example above should be provided so that a

person with hearing difficulties can still access the content of the audio.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/captions-prerecorded

Version 1.8 Page 24

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.4 WCAG 2.1 Success Criterion 1.2.3 − Audio Description or

Media Alternative (Prerecorded)

When a video with audio is uploaded onto a website, a visually impaired

person will be able to hear the audio but will not be able to see the picture.
As a result he/she will only have access to part of the information. Websites
should either provide additional audio that explains what is happening in the
picture or provide a text transcript that explains both the audio and what is
taking place in the picture.

Before Rectification

With video as shown in the example above, a visually impaired person will be
able to hear the audio but will not be able to see the picture. He/She needs
some other ways to know that there is a picture of a person on this screen.

After Rectification

A simple solution to this is to provide a text version that includes dialogue and
also explains what is appearing on the screen.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/audio-description-or-
media-alternative-prerecorded
Version 1.8 Page 25
Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.5 WCAG 2.1 Success Criterion 1.3.1 − Info and Relationships

Users who are not disabled can view the layout of a webpage and quickly
determine its structure and hierarchy. Persons with visual impairments cannot
see this layout. The website needs to provide appropriate markup to illustrate
this structure to screen readers so that it is accessible to persons with visual
impairments. The links should be categorised into different groups so that
screen readers are able to determine their relationship.

Before Rectification

In this example, there are no headings for the content, links and table
columns. This is an example of poor structure and relationships as someone
using screen readers will not be able to get a good overview of the content.

After Rectification

By adding headings and structure to the webpage, persons with visual

impairments will be able to get a good overview of the content through the
headings for each of the sections and be able to understand the relationships
between the content.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

Version 1.8 Page 26

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.6 WCAG 2.1 Success Criterion 1.3.2 − Meaningful Sequence

If the content needs to be read in a certain order to make sense, ensure the
webpage is written/coded in a way which indicates this order.

Before Rectification

In this example, the webpage has been built in such a way that the screen
readers will read the two headings first and then the content.

After Rectification

If the webpage is correctly coded, the reading order will be more logical. In
this case each piece of content follows its respective heading.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence

Version 1.8 Page 27

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.7 WCAG 2.1 Success Criterion 1.3.3 – Sensory Characteristics

Do not rely solely on sound, shape, size or visual location to provide

instructions for understanding content. For example, if instructions say “to
submit, click the button to the right”, a visually impaired person will not know
where that button is.

Before Rectification

In the example above, it is only clear to a person who can see the webpage
that he/she needs to click the green arrow. This will not be clear to a visually
impaired person.

After Rectification

The correct way to do this is to label the button and ensure clear instructions
are in place to tell people which button to use and how to use it.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics

Version 1.8 Page 28

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.8 WCAG 2.1 Success Criterion 1.4.1 − Use of Colour

Do not rely solely on colours to convey information. It is impossible to be sure

that everybody perceives colours in the same way (for example the visually
impaired or those who are colour blind), and what may seem obvious to one
person may be missed by another.

Before Rectification

In the example above, the three lines are of different colours, however, a
colour blind or visually impaired person may not be able to detect this colour
difference.

After Rectification

By making the items have different shapes, someone who cannot perceive
colours can differentiate between these items through the different shapes in
the graph.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/use-of-color

Version 1.8 Page 29

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.9 WCAG 2.1 Success Criterion 1.4.2 − Audio Control

Audio that plays automatically on a webpage is very distracting to persons

with disabilities using screen readers. Either ensure there is no background
audio unless specifically selected by a user or allow the user to easily turn off
the audio.

Before Rectification

In the example above, the video will begin playing automatically in five
seconds. This is very common on news websites. Ideally the video should only
play when the user initiates it. If that is not possible, a link can be added to
turn off the audio.

After Rectification

In this example, we have included a link to turn off the audio at the beginning
of the webpage so users will find it easily when they first come to this webpage.
They can then turn off the audio if they choose.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/audio-control

Version 1.8 Page 30

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.10 WCAG 2.1 Success Criterion 2.1.1 − Keyboard

Ensure all content and functions can be accessed via a keyboard. For example,
ensure content and functionalities are accessible through the Tab key or the
Enter key.

Before Rectification

In the webpage above, people using a keyboard may not be able to navigate
to the help function provided.

This extract from the HTML code shows that it can only be accessed with a
mouse.

After Rectification

The code needs to be changed to allow users to access all content and
functions with a keyboard.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/keyboard

Version 1.8 Page 31

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.11 WCAG 2.1 Success Criterion 2.1.2 − No Keyboard Trap

Often people with disabilities can only use a keyboard to control a webpage.
Ensure the keyboard can be used to control or dismiss dialogue boxes, popups
or other windows.

Before Rectification

Websites often have popup windows, such as for help content as shown in
this example. A keyboard user may become trapped in the popup without an
easy way to return to the main content.

After Rectification

By incorporating a Close button in the popup window, users can escape the
trap of that window by using the Tab key to move to the Close button and
press Enter.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap

Version 1.8 Page 32

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.12 WCAG 2.1 Success Criterion 2.1.4 − Character Key

Shortcuts

For keyboard shortcuts using letter, punctuation, number or symbol

character, at least one of the following is true:
 Turn off: User can turn off the shortcut;
 Remap: User can remap the shortcut to include one or more
non-printable keyboard characters (e.g. Ctrl, Alt); or
 Active only on focus: The shortcut is active only on focus.

Before Rectification

The character “e” is used as a shortcut key for archiving the email. When a
speech input user reads “e” as one of the input texts, the archive function is
automatically initiated.

After Rectification

A function is added for users to turn off the shortcut key feature. The speech-
input user is now able to input the text without invoking the shortcut key
function.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts

Version 1.8 Page 33

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.13 WCAG 2.1 Success Criterion 2.2.1 − Timing Adjustable

Ideally ensure processes on a website are not time dependent. If they are,
ensure persons with disabilities can either adjust or stop the time limit so they
can have enough time to complete their task.

Before Rectification

This example warns a person that time is about to expire.

After Rectification

A better approach is to allow the person to extend the time.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable

Version 1.8 Page 34

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.14 WCAG 2.1 Success Criterion 2.2.2 − Pause, Stop, Hide

For content that moves automatically for more than five seconds or is updated
automatically, there needs to be a way to stop this movement and stop the
webpage from updating, blinking or scrolling.

Before Rectification

In the example above, the webpage is designed to update automatically as

content changes, which can be very frustrating for people using screen
readers.

After Rectification

By providing a function to turn off the auto updating, the webpage will be
much easier for persons with disabilities to use.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide

Version 1.8 Page 35

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.15 WCAG 2.1 Success Criterion 2.3.1 − Three Flashes or

Below Threshold

Ensure all flashing items are dimmed, and cover only a small area of the
screen or the flash rate is three times per second or less. Otherwise, this may
cause problems for people who suffer from epilepsy.

Before Rectification

In this example, the traffic light image is flashing too fast, and is too bright
and covers a large part of the screen. This content can cause seizures in
people prone to this problem.

After Rectification

It is better to replace flashing content with static content, or ensure the object
flashes in only a small portion of the screen or the flash rate is less than three
times a second.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/three-flashes-or-
below-threshold

Version 1.8 Page 36

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.16 WCAG 2.1 Success Criterion 2.4.1 − Bypass Blocks

Ensure users have the ability to skip past repetitive blocks of content (e.g.
the navigation at the top of the webpage). Add a link that goes directly to the
main content at the top of each webpage.

Before Rectification

With such a webpage, people using screen readers will need to read all the
navigation information before getting to the target content. People who
navigate using only a keyboard will require many keystrokes before getting
to the target content.

After Rectification

By adding a “Skip to content” link at the top of each webpage, persons with
disabilities will be able to click that link and bypass the navigation information
to get to the main content.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks

Version 1.8 Page 37

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.17 WCAG 2.1 Success Criterion 2.4.2 − Page Titled

Give webpages a title that accurately describes what the content is about.
This will help persons with disabilities differentiate the webpages in their
browser history.

Before Rectification

It is quite common to see webpages with inaccurate titles such as this one
where the webpage is simply named “Home”. This can easily be confused with
other Home page.

After Rectification

A proper title such as this one will accurately describe what this webpage is
about.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/page-titled

Version 1.8 Page 38

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.18 WCAG 2.1 Success Criterion 2.4.3 − Focus Order

When writing the HTML code for a webpage, make sure the content is coded
in a logical order. It will then be communicated in a logical manner when read
by screen readers. This is particularly important for web forms.

Before Rectification

In this example, the form has been coded so that the focus order goes from
First Name, to Address, to Phone, then to the Submit button. This is not
intuitive to a user.

After Rectification

With proper coding, the focus order of the form can move in a much more
logical manner.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/focus-order

Version 1.8 Page 39

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.19 WCAG 2.1 Success Criterion 2.4.4 − Link Purpose (In

Context)

Write descriptive link text to ensure the purpose of each link can be
understood by the text alone, or by the link text and the context.

Before Rectification

In the example above, the link “Yes” is ambiguous and does not really convey
much meaning.

After Rectification

Link labels should be more descriptive and self-explanatory as shown in the

rectified version above.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context

Version 1.8 Page 40

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.20 WCAG 2.1 Success Criterion 3.1.1 − Language of Page

Ensure the primary language of a webpage is defined within the HTML code.
The correct speaking language will be loaded by screen readers to read the
words in the webpage.

The example above is written in Chinese. When using screen readers, it is

important for the tool to know the language of the webpage.

Before Rectification

After Rectification

In order for the screen reader to work correctly, the above language
specification must be included in the HTML code.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/language-of-page

Version 1.8 Page 41

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.21 WCAG 2.1 Success Criterion 3.2.1 − On Focus

When an item on a webpage receives focus, such as by using the Tab key in
the keyboard, ensure it does not change the context. For example, by
displaying a dialogue box when a person tabs to a field.

Before Rectification

In this example, a field receives focus, and a help dialogue box describing the
field and providing options opens. As a keyboard user tabs through the
webpage, the dialogue opens, moving the keyboard focus away from the
control every time the user attempts to tab past the field.

After Rectification

Instead, the webpage should allow the user to activate “Help” only at their
choice rather than forcing them to read “Help” with each tabbed field.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/on-focus

Version 1.8 Page 42

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.22 WCAG 2.1 Success Criterion 3.2.2 − On Input

Changing a setting on a webpage should not cause a change of context such

as opening a popup window or refreshing content. In addition, users should
not be taken away from a webpage when changing something without warning.

Before Rectification

It is common to see drop down menus on webpages that, when changed,

cause the form to be automatically submitted. This can make the website very
difficult to use for persons with disabilities.

After Rectification

This option is much better as it gives the user control over when to submit
the form.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/on-input
Version 1.8 Page 43
Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.23 WCAG 2.1 Success Criterion 3.3.1 − Error Identification

If a user makes a mistake, use text to show him/her where and what he/she
has done wrong, and how he/she can fix it.

Before Rectification

In the screen on the above, an error has been identified without any
information on where the error is and what needs to be fixed.

After Rectification

This is made accessible by telling the user where the error has occurred and
what he/she needs to do to fix the error.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/error-identification
Version 1.8 Page 44
Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.24 WCAG 2.1 Success Criterion 3.3.2 − Labels or Instructions

To help persons with disabilities avoid making mistakes, it is good to provide

simple instructions and cues for entering information into forms. For example,
use labels, instructions and examples.

Before Rectification

The above screen is a typical “Contact Us” form. However, there is no

information on what format to use to enter the phone number.

After Rectification

By adding default instructions to the fields, a visually impaired person can

complete each field easily.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions

Version 1.8 Page 45

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.25 WCAG 2.1 Success Criterion 4.1.1 − Parsing

Ensure the webpage is written/coded correctly. For example, implement

complete start and end tags for all elements. This ensures that the screen
reader accurately reads the webpage.

Before Rectification

After Rectification

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/parsing

Version 1.8 Page 46

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.26 WCAG 2.1 Success Criterion 4.1.2 − Name, Role, Value

Ensure all elements on a webpage have a “Name”, “Value” and “Role”

assigned to them. This can generally be achieved by writing correct HTML
coding according to relevant standards. If this is not done correctly, screen
readers will read the wrong role for an element. In the example below, the
screen readers will consider the button as an image. This makes the website
confusing for visually impaired persons.

Before Rectification

With the code snippet above, an image is used for a button. In this case, a
wrong role is used for an element and the element is missing a name.

After Rectification

With proper HTML coding, the role is used, and the input element is of the
button type. In addition, a unique name has been given to the element. In
this way, the screen readers will communicate to the user that the element is
in fact a button and this in turn makes it easier for the user to know he/she
may need to click that button.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

Version 1.8 Page 47

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.27 WCAG 2.1 Success Criterion 2.5.1 – Pointer Gestures

Complex gestures, such as swiping, dragging a slider or two-finger pinching

for zooming, can be performed through simpler actions like taps or long
presses.

Before Rectification

The dragging of a slider requires a precise path of the user's pointer

movement to control the volume.

After Rectification

Buttons are added as an alternative way for users to adjust the volume with
simple clicks.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html

Version 1.8 Page 48

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.28 WCAG 2.1 Success Criterion 2.5.2 – Pointer Cancellation

Functions are completed by the up-event (e.g. release the mouse button or
remove the finger from the screen) and either one of the following
mechanisms is available:
 To abort the function before completion; or
 To undo the function after completion.
There is exemption when the down-event is essential such as in the piano
keyboard emulation program.

Before Rectification

When the user makes a donation by clicking

the confirm button, the donation is confirmed
before the user releases the mouse button.
There is no way for the user to abort the
function after he/she has pressed the mouse
button.

After Rectification

The donation will be confirmed only if the user presses and releases the mouse
button at the clickable area. If the user wants to abort the function after
pressing the mouse button, he/she can drag the mouse pointer out of the
clickable area, then release the mouse button.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancellation.html

Version 1.8 Page 49

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.29 WCAG 2.1 Success Criterion 2.5.3 – Label in Name

All visible text labels must match their programmatic names to facilitate users
using speech-to-text technologies to interact with the content based on an
intuitive visual label.

Before Rectification

When a speech-input user speaks a command “Click Buy”, the speech input
does not activate the button control because the programmatic name that is
enabled as a speech-input command does not match with the visible text
label.

After Rectification

The programmatic names are exactly the same as the visual text labels of the
buttons, so that the speech-input user can activate the control by speaking
the visual text label.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html

Version 1.8 Page 50

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level A

8.30 WCAG 2.1 Success Criterion 2.5.4 – Motion Actuation

Functions triggered by moving a device (e.g. shaking or tilting) or by

gesturing towards the device (e.g. a camera can interpret the gesture and
activate a function) should be able to be operated by more conventional user
interface components.

Before Rectification

To view a 360-degree photo, users are required

to either move the device around to change the
view or tap and drag on the photo. Users with
mobility difficulties are difficult to perform these
actions.

After Rectification

Navigation buttons are added as an

alternative for navigation. Users can either
move the device around to change the view
or click the navigation buttons to perform the
same function.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/motion-actuation

Version 1.8 Page 51

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9. WCAG 2.1 Success Criteria – Level AA

9.1 WCAG 2.1 Success Criterion 1.2.4 − Captions (Live)

Ensure all audios and videos that are presented “live” have captions.

Before Rectification

When an audio is embedded in a webpage as shown above, the audio is only

usable by people who can hear.

After Rectification

Text captions should be provided so that persons with hearing impairments

can still have access to content from the audio as shown in the example
above.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/captions-live

Version 1.8 Page 52

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.2 WCAG 2.1 Success Criterion 1.2.5 − Audio Description

(Prerecorded)

Provide a descriptive audio track in addition to the prerecorded video so that

visually impaired persons can still use the webpage without the video.

Before Rectification

When providing a video for users on a webpage, it is important to make sure

that an audio description of this video is also present so people who cannot
view the video can still understand the content.

After Rectification

An audio description of the video should be provided so visually impaired

persons may listen to the description and understand what the video is about.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/audio-description-
prerecorded

Version 1.8 Page 53

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.3 WCAG 2.1 Success Criterion 1.3.4 – Orientation

Unless a specific display orientation is essential, the content should be able

to be viewed or operated in either portrait or landscape orientations.

Before Rectification

Users are unable to change the orientation of the

video clip as the video player restricts its display
orientation to landscape.

After Rectification

Persons with physical disabilities may mount

the device on a wheelchair in a fixed
orientation. By not restricting the display
orientation, users can view the content in the
orientation that suits them best.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/orientation.html

Version 1.8 Page 54

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.4 WCAG 2.1 Success Criterion 1.3.5 – Identify Input Purpose

Autocomplete attribute techniques should be used for each input field to

make form filling easier, especially for people with cognitive disabilities.

Before Rectification

The user is required to input personal information from scratch.

After Rectification

Enabling the autocomplete attribute improves the browser’s ability to

pre-populate form fields with user-preferred values. It allows the user to
complete the form easily.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/identify-input-
purpose.html

Version 1.8 Page 55

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.5 WCAG 2.1 Success Criterion 1.4.3 − Contrast (Minimum)

Design text and images so that they have a contrast ratio of at least 4.5:1
between the background and the foreground to make it easy to read.

Before Rectification

In this example, the white text on the pink background has poor contrast,
making it hard to read.

After Rectification

When higher contrast text is used, the text is much easier to read. There are
colour contrast checkers available online that can assist web developers to
check the contrast of their webpages.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum

Version 1.8 Page 56

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.6 WCAG 2.1 Success Criterion 1.4.4 − Resize text

Ensure all text can be resized up to 200% without the loss of content or
functionality. In this way, persons with mild visual impairments can read the
content without using assistive technologies such as a screen magnifier.

Before Rectification

In the screen above, there are no functions to resize the text.

After Rectification

By adding a function to change the text size in the masthead, text size can
be easily resized. Alternately, ensure websites are built so that built in
browser text size tools work as they should. Developers should also be
mindful of using proper cascading style sheet (CSS) techniques to ensure
the CSS works with the built in browser resize functions.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/resize-text

Version 1.8 Page 57

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.7 WCAG 2.1 Success Criterion 1.4.5 − Images of Text

Where possible, do not use images to display text. Accessibility tools like
screen readers cannot read text inside an image and will have to rely on the
image alt tag. In addition, text in images cannot be resized by browsers
when a user chooses to use larger fonts.

Before Rectification

The heading on the webpage above has the risk of being read incorrectly by
some screen readers or other assistive tools.

After Rectification

This text heading above does not use an image, thus increasing the chance
of it being read correctly by screen readers or other assistive tools. Any visual
design applied to this text is achieved through cascading style sheets (CSS).

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/images-of-text

Version 1.8 Page 58

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.8 WCAG 2.1 Success Criterion 1.4.10 – Reflow

When a webpage is zoomed, the content is presented without loss of

information and functionality, and without requiring horizontal scrolling.

Before Rectification

When users zoom in to enlarge the size of the content, they have to scroll
both horizontally and vertically to view the content.

After Rectification

By using responsive web design, the page layout is changed automatically

when it is zoomed, so that horizontal scrolling is not required.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

Version 1.8 Page 59

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.9 WCAG 2.1 Success Criterion 1.4.11 – Non-Text Contrast

All non-text content (e.g. graphics, diagrams, buttons, checkboxes, radio

buttons or input fields), which deliver important information, should have a
minimum 3:1 colour contrast ratio against adjacent colour.

Before Rectification

The grey textboxes on the white background have poor colour contrast,
making it harder for persons with low vision to identify.

After Rectification

Dark border is applied to the textboxes so that they can be identified easily.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Version 1.8 Page 60

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.10 WCAG 2.1 Success Criterion 1.4.12 – Text Spacing

Ensure the content or functionality will not be lost if user overrides the setting
for spacing between paragraphs, lines, words or characters.

Before Rectification

h1 {line-height:150px}
h2 {line-height:100px}

The line height of header (h1) and sub-header (h2) texts is defined using
absolute values (i.e. number of pixels). When the user zooms in to enlarge
the content of the webpage, the header and sub-header texts are cut off and
become unreadable.

After Rectification

h1 {line-height:100%}
h2 {line-height:100%}

The line height of h1 and h2 is defined using relative values (i.e. percentage).
When the page is zoomed by the user, the line height of h1 and h2 is changed
accordingly such that the content can be displayed clearly.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html

Version 1.8 Page 61

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.11 WCAG 2.1 Success Criterion 1.4.13 – Content on Hover or

Focus

If additional content appears on focus/hover, you should ensure all of the

following:
 Dismissible: User can dismiss the additional content with the keyboard
without moving focus/hover, e.g. via the escape key;
 Hoverable: User can move the pointer over the additional content
without making the additional content disappear; and
 Persistent: The additional content remains visible until the hover or
focus trigger is removed, or the user dismisses it, or its information is
no longer valid.

Before Rectification

When user activates the

“Support” menu via keyboard, a
mega menu is displayed, which
covered part of the main content.
User is unable to view the content
unless he/she moves the mouse
pointer away from the mega
menu.

After Rectification

Function is added for user to

close the mega menu by
pressing Escape key without
moving the mouse pointer.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-
focus.html

Version 1.8 Page 62

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.12 WCAG 2.1 Success Criterion 2.4.5 − Multiple Ways

Ensure there is more than one way to access a webpage, for example, by
using a search function, site map, standard navigation, etc.

Before Rectification

The only way to navigate around this website is through the main navigation.

After Rectification

In this image, a search function and a site map have been included for users
to have multiple methods available to locate the required information.
Something like a site map would also be helpful to users who have learning
disabilities or have difficulties in concentrating for a long period of time.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/multiple-ways

Version 1.8 Page 63

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.13 WCAG 2.1 Success Criterion 2.4.6 − Headings and Labels

Headings and labels must be accurate descriptions of the accompanying

content.

Before Rectification

The heading “Cats” shown above does not accurately describe the purpose
of the content beneath it.

After Rectification

The image above however shows a more detailed heading that accurately
describes the content. This would assist users using a screen reader.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels

Version 1.8 Page 64

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.14 WCAG 2.1 Success Criterion 2.4.7 − Focus Visible

When a “text field” is selected, ensure it is clear that the focus has been
moved into the “text field”. For example, ensure the cursor is easily visible
within the field so that users know where to begin typing.

Before Rectification

In the image above, there is no way to determine which field has the focus.

After Rectification

This image ensures that the vertical bar is visible. This shows that the focus
is currently on the second field, and this helps those users with low vision or
visual impairments determine where they are on a webpage.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/focus-visible

Version 1.8 Page 65

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.15 WCAG 2.1 Success Criterion 3.1.2 − Language of Parts

Write content so that the language of all passages and phrases can be clearly
understood. This will enable screen readers to pronounce each item in the
correct language.

Before Rectification

In the example above, the majority of the website is in English. However,

a small section is in German. In this case, it is essential to define this
change in language, so that screen readers can detect the change and
pronounce correctly.

After Rectification

The image above shows how this code should look like so that the screen
readers can detect and pronounce the words using the proper languages.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts

Version 1.8 Page 66

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.16 WCAG 2.1 Success Criterion 3.2.3 − Consistent

Navigation

Where navigations or links are on multiple webpages, ensure they are

presented consistently across all pages.

Before Rectification

The style is not consistent across multiple webpages. This could be confusing
for visually impaired persons.

After Rectification

The example above shows the correct method to ensure the navigation is
consistent across multiple webpages.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/consistent-navigation

Version 1.8 Page 67

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.17 WCAG 2.1 Success Criterion 3.2.4 − Consistent

Identification

For all items that have the same functionality, ensure they use the same
label. For example, a "Buy Now" button on one webpage should be identically
labelled as a "Buy Now" button on another webpage so that the user knows
these buttons would perform the same function.

Before Rectification

In the example above, there are two buttons each having a different label.
This could cause confusion for some users, especially for those using screen
readers, who may not be able to take note of the similarities between these
two buttons.

After Rectification

The two “Buy Now” buttons are consistent above and it is clear that both
would perform the same function.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/consistent-
identification

Version 1.8 Page 68

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.18 WCAG 2.1 Success Criterion 3.3.3 − Error Suggestion

When a user makes an error and the solution can be identified automatically,
always provide the user with a suggestion to fix the error.

Before Rectification

The example above shows an error message that is not helpful enough
because it is located at the bottom of the webpage, and does not provide an
adequate description of what needs to be corrected.

After Rectification

In contrast, this example shows a message that is located at the top of the
webpage and provides a good explanation of what needs to be corrected.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/error-suggestion

Version 1.8 Page 69

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.19 WCAG 2.1 Success Criterion 3.3.4 − Error Prevention

(Legal, Financial, Data)

If a user has to submit data that have legal or financial consequences, make
sure the system allows the user to check and confirm his/her information
before submitting, or reverse the transaction after submitting.

Before Rectification

This screen indicates the last step of a transaction, in which the user is forced
to place the order without a confirmation process.

After Rectification

It is better to allow the user to first confirm and give him/her the option to
change any of the details before the final submission.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/error-prevention-
legal-financial-data

Version 1.8 Page 70

Web Accessibility Handbook WCAG 2.1 Success Criteria – Level AA

9.20 WCAG 2.1 Success Criterion 4.1.3 – Status Messages

For any visible status message (e.g. error or success message subtly added
to a page), users should be informed by means of assistive technology tools
even though the status message is not in focus. One possible way to
implement this criterion is to define the Accessible Rich Internet Application
(ARIA) role (status, alert) or Live Regions.

Before Rectification

A spinning logo with “searching” status message appears after user initiates
the search function. However, screen reader cannot read out the status
message because it is not in focus.

After Rectification

By assigning appropriate ARIA role to the status message, the screen reader
is able to read out the message to inform users about the content change
even though the status message is not in focus.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html

Version 1.8 Page 71

Web Accessibility Handbook Five Testing Techniques for Web Accessibility

10. Five Testing Techniques for Web Accessibility

To ascertain web accessibility, testing is the key to finding and understanding
issues to be rectified along the way. Five techniques for web accessibility
testing are outlined below.

10.1 Code Scanning

Many accessibility issues can be detected automatically using software tools.

These tools should be used to test the webpage coding during the
development stages and when performing a web accessibility audit of a
website.

After completing code scanning and when all identified issues are rectified,
carry out other forms of testing as mentioned below to check for items that
cannot be tested automatically.

Example Tools:
 AChecker
 Axe DevTools
 Total Validator
 WAVE

10.2 Visual Review

A great deal can be learnt about the accessibility of a website just by visual
browsing while having in mind the following questions:
 Can the content be easily read?
 Can the forms for collecting input be used effectively?

We suggest paying particular attention to anything visual that might not

work well for persons with visual impairments, for example:
 Is the text too small?
 Does it use pale coloured text on a pale background, making the text
hard to read?

A simple look at a website can reveal many potential web accessibility issues
for persons with disabilities.

Some recommended approaches that should be included in a visual review

are:
 Turn off cascading style sheets (CSS). This is how your website will
often be interpreted by screen readers. Does the content have a logical
flow and structure?
 Try using the built in browser text enlargement functions. Do they
work?

Version 1.8 Page 72

Web Accessibility Handbook Five Testing Techniques for Web Accessibility
 Try moving around the webpages using just a keyboard. Can we
access all the links and functions?

Example Tools:
 Colour Contrast Analyser
 WCAG Contrast Checker
 Web Developer (Firefox plugin)

10.3 Manual Testing with Screen Readers

An easy way to experience how persons with visual impairments use a

website is to simply turn off the monitor and attempt to use the website with
screen readers.
 Navigate the website and determine just how much information we
can access through the screen readers.
 Try reading the headings, navigations, images, and also test more
complex features such as input forms and tables.

Example Tools:
 JAWS
 NVDA
 VoiceOver
 Windows Light

10.4 Testing with Other Tools

Other than screen readers, persons with disabilities may use a variety of
other tools to interact with a website. Two particular types of widely used
tools are:

Screen Magnification Tools – these commonly used tools allow people to

zoom into sections of a screen and change the contrast levels.
 Test a website with these tools and rectify issues found.

Voice Control Tools – some severe motor disabilities leave using voice
commands as the only means to interact with a website. People speak into
a microphone with commands such as “next link”, “go”, etc.
 Testing using these tools reveals issues which are difficult to identify
through the other methods.

Version 1.8 Page 73

Web Accessibility Handbook Five Testing Techniques for Web Accessibility

Example Tools:
 ZoomText Magnifier
 Dragon NaturallySpeaking

10.5 Human Testing

The most thorough approach to ensure web accessibility is to test a website

with persons with various disabilities to learn what areas are difficult for them
to access. As this testing method requires more time and resources, it is best
to first undertake the above four types of testing methods to rectify as many
web accessibility issues as possible, and then use human testing at later
stages of a project to uncover more subtle issues.

Some organisations supporting persons with disabilities can help by

providing free or affordable human testing services. These
organisations include Direction Association for the Handicapped,
Hong Kong Blind Union, Hong Kong Sign Language Association, the
Hong Kong Society for the Blind and Retina Hong Kong. Website
owners may contact these organisations for assistance.

Version 1.8 Page 74

Web Accessibility Handbook Web Accessibility Related Resources

11. Web Accessibility Related Resources

Web Content Accessibility Guidelines version 2.0 (WCAG 2.0)
https://www.w3.org/TR/WCAG20/

Web Content Accessibility Guidelines version 2.1 (WCAG 2.1)

https://www.w3.org/TR/WCAG21/

Quick reference to WCAG 2 requirements and techniques

https://www.w3.org/WAI/WCAG21/quickref/

Understanding WCAG 2.1

https://www.w3.org/WAI/WCAG21/Understanding/

Techniques and Failures for WCAG 2.1

https://www.w3.org/WAI/WCAG21/Techniques/

PDF Techniques for WCAG 2.1

https://www.w3.org/WAI/WCAG21/Techniques/#pdf

Web Accessibility Evaluation Tools List

https://www.w3.org/WAI/ER/tools/

Web Accessibility Initiative (WAI)

https://www.w3.org/WAI/

The Hong Kong Disability Discrimination Ordinance

https://www.elegislation.gov.hk/hk/cap487

The Hong Kong Equal Opportunities Commission

https://www.eoc.org.hk

Version 1.8 Page 75

Web Accessibility Handbook Glossary

12. Glossary

Term Description

Abbreviation Shortened form of a word, phrase or name.

Acronym An abbreviation made from the initial letters of a name

or phrase that contains several words. Many acronyms
can be pronounced as words. Defined differently in
different languages.

“alt” tag An attribute of an HTML tag that provides information

about an element in text form

Assistive A range of hardware devices such as modified keyboards

technology and software such as screen readers that assist and
enable persons with disabilities to use devices such as
computers more effectively.

Audio Audio narration that is added to the soundtrack to

description explain important details that cannot be understood from
the main soundtrack alone. During pauses in the track,
audio descriptions of video provide information about
actions, characters, scene changes and on-screen text
for people who are visually impaired.

Breadcrumb A trail of links most often found at the top of a piece of

content within a webpage. The trail of links shows the
location of the page within the website and gives a
means for the user to link to pages above it.

Browser Any software that retrieves and renders Web content for
users.

Captcha A type of technology aimed at checking whether the

submission of a form is being done by a person or a
computer. These usually involve entering some sort of
distorted but still legible text or number displayed on the
screen.

Captions Synchronised transcripts of dialogue and important

sound effects. Captions provide access for persons with
hearing impairments.

Cascading style A way to define the style of a webpage, separate to the

sheet - CSS content through an external file.

Changes of A change in the browser window, or focus off a particular

context item; or even a change of content that changes the
meaning of what was previously being viewed.
It should be noted that a change in content is not always
a change of context. Small changes in content, such as
an expanding outline do not change the context.

Version 1.8 Page 76

Web Accessibility Handbook Glossary

Term Description

Code The language used to instruct computer software and

hardware to perform certain functions

Extended audio Audio descriptions that are added to an audio/visual

descriptions presentation by pausing the video so that there is time
to add an additional description of what is going on, or
what just took place. This technique is only used when
the message in the video would be lost without the
additional audio description.

Flash A proprietary multimedia platform owned by Adobe

Systems, used to add animation, video and interactivity
to webpages.

Function / Perform or is able to perform one or more actions in

Functionality response to user input.

HTML Hypertext Mark-up Language (HTML) is the “language”

used to produce websites.

Live audio-only A live presentation that contains only audio (no video
and no interaction)

Masthead The portion at the top of most webpages. The term

comes from the masthead of a newspaper which refers
to the brand and name of a newspaper displayed at the
top of the front page. On a webpage the masthead
generally includes the logo and main navigation of the
website.

Parsing Parsing is the process a web browser goes through to

display a webpage. The browser analyses the code and
then displays the webpage accordingly. If the code is not
correct, the browser may not display the webpage
correctly. Screen readers also have to parse code and
may not read a webpage correctly if the code is not
correct.

Session When a person visits a website, the server acknowledges

that someone is using the website and assigns the
persona period of time or session. In this way a website
can keep track of stored items such as shopping carts. If
a person stays idle on a website for too long – generally
30 minutes – the session will expire and the website will
consider the person as a new visitor.

Version 1.8 Page 77

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA

Appendix A: WCAG 2.1 Success Criteria – Level AAA

A.1 WCAG 2.1 Success Criterion 1.2.6 − Sign Language
(Prerecorded)

Sign language is a method universally used by people beset with hearing

impairment to access audio content. This provides the ability to reflect
emotion, intonation and other audio information that may be limited when
using captions.

Before Rectification

Simply having the video with a transcript or captions may not be enough for
all users.

After Rectification

A more reliable method is to translate this information through sign language

as is seen in the image above.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/sign-language-
prerecorded
Version 1.8 Page 78
Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.2 WCAG 2.1 Success Criterion 1.2.7 − Extended Audio
Description (Prerecorded)

If the content of a video is complex, the audio within the video may not
effectively explain what is taking place in the visual. Some visually impaired
persons listening to the audio will miss out on important content. To rectify
this, provide an extended audio description which describes in detail what is
taking place in the visual. Often in these cases the visual may need to pause
while the audio description plays.

An extended audio description may state things like "The person is now doing
X in the video. Now the person is doing Y."

Before Rectification

In the example above, there is a risk that a user has not enough time to
understand all the information before the video moves onto the next point
because they cannot see the visual.

After Rectification

This example shows how the system can handle this by temporarily pausing
the video and providing audio to explain the situation.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/extended-audio-
description-prerecorded

Version 1.8 Page 79

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.3 WCAG 2.1 Success Criterion 1.2.8 − Media Alternative
(Prerecorded)

This success criterion is meant to target at users with impaired hearing and
vision. This “alternative” is not like a caption or a subtitle. Instead, full
descriptions are provided for all visual information, including visual context,
actions and expressions of actors, and any other visual materials. In addition,
non-speech sounds (laughter, off-screen voices, etc.) are described, and
transcripts of all dialogues are included. The media alternative is generally
provided in text so it can be read using assistive technologies.

Before Rectification

When video content is displayed as above, a visually impaired person will

only hear the audio and a hearing impaired person will only see the pictures.

After Rectification

To improve accessibility, a text version is added. However, this text version

is more than a transcript of the audio. It also describes what is taking place
within the video.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/media-alternative-
prerecorded

Version 1.8 Page 80

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.4 WCAG 2.1 Success Criterion 1.2.9 − Audio-only (Live)

For live audio, offer an alternative that contains equivalent information. For
example, make speech notes available if a speech is being delivered.

Before Rectification

This live presentation is not accessible to people beset with hearing

impairment.

After Rectification

The image above shows that a simple link directing users to the speech notes
means that all users can access this content.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/audio-only-live

Version 1.8 Page 81

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.5 WCAG 2.1 Success Criterion 1.3.6 – Identify Purpose

The purpose of user interface components, icons and certain sections can be
identified by user agents. For example, Accessible Rich Internet Application
(ARIA) landmarks should be used to identify regions of a page, so that
assistive technologies can be used to make the content more
understandable.

Before Rectification

Without setting the ARIA landmark roles, assistive technologies cannot easily
recognise different regions of the webpage to provide customisation for the
user.

After Rectification

The ARIA landmark roles are assigned to identify different regions of the
page. Assistive technologies can help the user by adding icons or changing
the styles of individual webpage components.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/identify-purpose.html

Version 1.8 Page 82

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.6 WCAG 2.1 Success Criterion 1.4.6 − Contrast (Enhanced)

Previously it was mentioned that having a contrast ratio of 4.5:1 is sufficient.

This is the case for Level AA. Level AAA increases this ratio to 7.1:1 by using
darker text on a lighter background or vice versa.

Before Rectification

The text colour and background indicated in the contrast checker above do
not comply with Level AAA.

After Rectification

This text and background colour combination complies with Level AAA with
the use of the contrast ratio above.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced

Version 1.8 Page 83

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.7 WCAG 2.1 Success Criterion 1.4.7 − Low or No Background
Audio

Ideally, do not place background sounds in audio clips. If this cannot be

avoided, provide a clearly labelled function to enable the user to turn the
audio off and ensure the foreground sound is approximately four times as
loud as the background sound.

Before Rectification

The background audio has a high chance of overpowering the actual dialogue.
This becomes an issue for persons with hearing impairments.

After Rectification

An effort should be made to reduce the background sound as much as

possible. At the bare minimum, make sure that if a background sound does
exist, it is four times as quiet as the foreground sound/dialogue.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/low-or-no-
background-audio

Version 1.8 Page 84

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.8 WCAG 2.1 Success Criterion 1.4.8 − Visual Presentation

When there is a block of text, ensure the user can select the foreground and
background colours. Besides, ensure the text is not “fully justified” and is
less than 80 characters long. In addition, ensure there is at least a space
and a half between each line and that the space between each paragraph is
1.5 times larger than the space between each line.

Before Rectification

The paragraph in the image above is not easily accessible as it does not meet
the criteria mentioned.

After Rectification

The second image shows how to make a paragraph accessible. This helps
many users who have learning difficulties as there is enough space between
each line and also the space is even.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/visual-presentation

Version 1.8 Page 85

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.9 WCAG 2.1 Success Criterion 1.4.9 − Images of Text (No
Exception)

To achieve the highest accessibility rating, do not use text in images unless
it is purely decorative, or the text as an image is central to the idea being
communicated.

Before Rectification

The heading of the webpage above is an image and would not comply with
Level AAA.

After Rectification

Here the image has been replaced with text and now complies with Level
AAA.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/images-of-text-no-
exception

Version 1.8 Page 86

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.10 WCAG 2.1 Success Criterion 2.1.3 − Keyboard (No
Exception)

With no exception, all content must be operable from a keyboard.

Before Rectification

In this situation the system only allows a user to use his/her “mouse” to
create the drawing. This is not accessible to persons with restriction in body
movement who cannot use a mouse.

After Rectification

In this situation the system allows the user to create a picture using the
keyboard and also provides instructions on how to achieve this. This is
helpful for persons with restriction in body movement.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/keyboard-no-
exception

Version 1.8 Page 87

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.11 WCAG 2.1 Success Criterion 2.2.3 − No Timing

Design content such that timing is not an essential part of the event or
activity.

Before Rectification

After Rectification

It is always advisable that no “time limit” is placed on a webpage.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/no-timing

Version 1.8 Page 88

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.12 WCAG 2.1 Success Criterion 2.2.4 − Interruptions

Users must be provided with a function to turn off updates except in

emergencies.

In this way, persons with attention deficit disorders can focus on the content
without distraction. In addition, people using screen readers will not have
content updated while they are listening, thereby preventing confusion.

Before Rectification

If this promotion is an auto-rotating element, a user who has learning

disabilities or low vision may not be able to read all the content before it
automatically rotates.

After Rectification

The button allows a user to pause the rotation if required.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/interruptions

Version 1.8 Page 89

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.13 WCAG 2.1 Success Criterion 2.2.5 − Re-authenticating

If a user is logged into a system, and his/her “session expires”, he/she must
be able to log in again without losing any of his/her previously entered data.

Before Rectification

The example above shows a scenario where a user will lose his/her data, as
the system has not remembered the user’s details at step 4.

After Rectification

The correct technique is to ensure after the user logs in again, the data
entered is not lost.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/re-authenticating

Version 1.8 Page 90

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.14 WCAG 2.1 Success Criterion 2.2.6 – Timeouts
Users should be informed about the duration of inactivity which will cause
the page to time out and result in data loss, unless the data is preserved for
more than 20 hours when the user does not take any actions.
Note: If the transaction involves collection of personal data, please ensure
the handling and protection of personal data complies with the Personal Data
(Privacy) Ordinance. For more information about the Personal Data (Privacy)
Ordinance, please refer to the following link:
https://www.pcpd.org.hk/english/data_privacy_law/ordinance_at_a_Glance
/ordinance.html

Before Rectification

Users are not warned of the

duration of inactivity that could
cause a timeout and data loss.
After the page is idled for a certain
period of time, the application
prompts timeout and all the input
data are lost.

After Rectification

A message is clearly shown at

the top of the page indicating
that inactivity for more than
an hour will trigger the
timeout process.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/timeouts

Version 1.8 Page 91

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.15 WCAG 2.1 Success Criterion 2.3.2 − Three Flashes

Ensure there is nothing on a website that “flashes” for more than three times
per second irrespective of its size. Otherwise, this may cause problems for
people who suffer from epilepsy.

Before Rectification

In this example, the traffic light image is flashing too fast and is large in size.
This can cause seizures.

After Rectification

It is better to replace flashing content with static content that does not
change.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/three-flashes

Version 1.8 Page 92

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.16 WCAG 2.1 Success Criterion 2.3.3 – Animation from
Interactions

Users should be allowed to disable the motion animation triggered by

interaction, unless the animation is essential to the functionality or the
information being conveyed.

Before Rectification

Animation on the top banner is triggered when users scroll down the
webpage. However, the website does not allow users to disable the
non-essential animation in the banner. Users with vestibular disorders
(motion sickness) may feel sick when reading the web content.

After Rectification

A function is provided for users to disable all non-essential animations.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/animation-from-
interactions.html

Version 1.8 Page 93

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.17 WCAG 2.1 Success Criterion 2.4.8 − Location

Provide a way for the users to determine their location within a website at
all times. For example, use “breadcrumbs” so that users will be able to
quickly determine where they are within a website.

Before Rectification

In the example shown above, there is no way of knowing where you are
within the website. For a user who is visually impaired, it is very easy to get
disorientated whilst navigating a website.

After Rectification

In this example, notice how a “breadcrumb” trail is included. This allows

users to always know where they are within the website.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/location

Version 1.8 Page 94

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.18 WCAG 2.1 Success Criterion 2.4.9 − Link Purpose (Link
Only)

Make sure that the purpose of each link can be recognised from the link text
alone.

Before Rectification

The button “Find out more” only briefly describes the purpose of this link.

After Rectification

This image shows a link button which clearly describes its purpose, i.e. “Find
out more about Customer Experience Testing”, instead of just “Find out more”
as shown in the “Before Rectification” image above.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-link-only

Version 1.8 Page 95

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.19 WCAG 2.1 Success Criterion 2.4.10 − Section Headings

Use section headings such as titles, headings and subheadings, to break up

content into smaller chunks. This helps users digest the content more easily,
and makes it easier for all users to navigate quickly through the information.

Before Rectification

The example above has a large piece of text. This could be difficult to read
by some users who may have learning disabilities. Besides, for people using
screen readers, this is a long piece of text to read.

After Rectification

By breaking the information into sections, it would be easier to understand.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/section-headings

Version 1.8 Page 96

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.20 WCAG 2.1 Success Criterion 2.5.5 – Target Size

The sizes of target (e.g. button) are at least 44 by 44 Cascading Style Sheets
(CSS) pixels, except when:
 Equivalent: The target is available through an equivalent link or control
on the same page that is at least 44 by 44 CSS pixels;
 Inline: The target is in a sentence or block of text;
 User Agent Control: The size of the target is determined by the user
agent and is not modified by the author;
 Essential: A particular presentation of the target is essential to the
information being conveyed.

Before Rectification

Buttons are too small and difficult

to tap.

After Rectification

The size of buttons is larger than 44

by 44 CSS pixels, so that users can
tap the buttons easily.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/target-size.html

Version 1.8 Page 97

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.21 WCAG 2.1 Success Criterion 2.5.6 – Concurrent Input
Mechanisms

Websites should not restrict the use of input modalities (e.g. keyboard,
mouse, touchscreen, voice input) available on a platform, unless the
restriction is essential, or is required to ensure the security of the content,
or to respect user settings.

Before Rectification

The webpage only accepts input by keyboard.

After Rectification

The webpage accepts more than one kind of input mechanism, including
keyboard, mouse and touchscreen. Users are allowed to switch between
input mechanisms when necessary.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/concurrent-input-
mechanisms.html

Version 1.8 Page 98

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.22 WCAG 2.1 Success Criterion 3.1.3 − Unusual Words

If words or phrases are used in an unusual or restricted way, including

unusual expressions or jargons, ensure there is a way for users to identify
the corresponding definitions. One example of how this can be done is to
make sure the expanded version of an acronym is explained for screen
readers.

Before Rectification

In the example above, users could not identify the definition of the term
“web accessibility”.

After Rectification

In this example, some words are linked to a glossary. This is a good method
to ensure all users understand the unusual terms.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/unusual-words

Version 1.8 Page 99

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.23 WCAG 2.1 Success Criterion 3.1.4 − Abbreviations

Wherever abbreviations are used, provide a way for the user to understand
what these abbreviations stand for and their meaning. What may seem
obvious to one person may be meaningless to another.

Before Rectification

The acronym “UCC” should not be coded like the example displayed above.
A screen reader will try to read the letters U-C-C like a word which may be
difficult to understand.

After Rectification

When an acronym is used, ensure the code is written as shown above. In

this way, screen readers will not read the letters “UCC”, it will read the full
version of the abbreviation, that is “Unified Communications and
Collaboration”.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/abbreviations

Version 1.8 Page 100

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.24 WCAG 2.1 Success Criterion 3.1.5 − Reading Level

Make text simple and easy to understand. For example, use short and
common words in sentences. If possible, provide a summary for the content.
This will help those users who may have learning difficulties such as dyslexia.

Before Rectification

The above example shows some content with complexity.

After Rectification

Wherever possible, try to make all content as simple as possible with minimal
complexity. If possible, use less words and images to make reading easier,
just like the example here.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/reading-level

Version 1.8 Page 101

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.25 WCAG 2.1 Success Criterion 3.1.6 − Pronunciation

If there are words having different meanings when using different

pronunciation, provide a clear explanation of the pronunciation.

In the example below, the word “minute” may mean either “The button was
so minute I could not see it.” (meaning “small”) or “I need a minute to think
about it.” (meaning “60 seconds”). If such instances arise, ensure the
meaning is clear from the context, or provide additional information that
shows which pronunciation should be used so as to avoid ambiguity.

Before Rectification

There could be some confusion over which meanings of the word “minute” is
referred to, as there is no context provided.

After Rectification

The example above shows how the content can be expanded to ensure there
is no confusion.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/pronunciation

Version 1.8 Page 102

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.26 WCAG 2.1 Success Criterion 3.2.5 − Change on Request

Items such as slideshows may automatically change context. In this case,

ensure functions are available for users to control this automated change.

Before Rectification

The example above shows a webpage having live updates of news items.
Persons with vision impairments or specific learning difficulties may not have
enough time to read all the news items before the automatic update with the
latest news items.

After Rectification

In this example, users who have difficulties in reading the news items within
the time limit are provided with the option to request an update or pause the
update.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/change-on-request

Version 1.8 Page 103

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.27 WCAG 2.1 Success Criterion 3.3.5 − Help

Make sure users can always access the help functions which specifically
address what they are trying to do. They should not be expected to have to
wade through webpages of help text.

Before Rectification

Users could have difficulties in looking for “Job Number” without a specific
help function.

After Rectification

It is important to have help functions that specifically relate to the content

the users are currently viewing. The above example shows how this can be
achieved.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/help

Version 1.8 Page 104

Web Accessibility Handbook Appendix A: WCAG 2.1 Success Criteria
– Level AAA
A.28 WCAG 2.1 Success Criterion 3.3.6 − Error Prevention (All)

Error prevention provides safeguards against errors that are made by users.
Providing users with functions to review and correct information allow users
to detect mistakes before making submissions.

Before Rectification

In this screen indicating the last step of a transaction, users are forced to
submit their details without a “confirmation” step.

After Rectification

It is better to allow users to first confirm the detailed information, and

provide them with an option to change any of the details before making the
final submission.

WCAG 2.1 Reference:

https://www.w3.org/WAI/WCAG21/Understanding/error-prevention-all

Version 1.8 Page 105

Web Accessibility Handbook Appendix B: WCAG 2.1 Criteria Checklist
for Developers

Appendix B: WCAG 2.1 Criteria Checklist for

Developers
How to Use this Checklist

Begin by following the steps below for Level A compliance, then repeat the
steps for Level AA – and if necessary repeat again for Level AAA. Following
this checklist will enable websites to be tested in the most efficient way.

1. Review each of the criteria and “check off” all the success criteria
that DO NOT APPLY to the website, using the N/A column.
 For example, if a website does not have any audio or video content,
then criterion 1.2.1 can be marked N/A and the Visual Review and
Assistive Technology (AT) Test can be skipped.
 Other items marked as skipped can be ignored for that test as it is
not possible to determine compliance with that test.

2. Scan website with a code scanning tool focusing on each of the items
in the Code Scan column.
 Note that code scan tools often report items that may not require
fixing. Web developers should investigate each item found to
determine if it is in fact a real issue.

3. Perform Visual Review by checking all items listed in the

visual review column.

4. Test using various Assistive Technology (AT) tools such as

screen readers, screen magnifiers and voice controls.

Version 1.8 Page 106

Web Accessibility Handbook Appendix B: WCAG 2.1 Criteria Checklist
for Developers

B.1 WCAG 2.1 Level A Checklist

Level A Success Criteria N/A Code Scan Visual Review AT Tests

1.1.1 Non-text Content

1.2.1 Audio-only and Video-only (Prerecorded) Skip

1.2.2 Captions (Prerecorded) Skip

1.2.3 Audio Description or Media Alternative

Skip
(Prerecorded)

1.3.1 Info and Relationships

1.3.2 Meaningful Sequence Skip

1.3.3 Sensory Characteristics Skip

1.4.1 Use of Colour Skip Skip

1.4.2 Audio Control Skip

2.1.1 Keyboard

2.1.2 No Keyboard Trap Skip

2.1.4 Character Key Shortcuts* Skip

2.2.1 Timing Adjustable Skip

2.2.2 Pause, Stop, Hide Skip

2.3.1 Three Flashes or Below Threshold Skip Skip

2.4.1 Bypass Blocks Skip

2.4.2 Page Titled

2.4.3 Focus Order Skip

2.4.4 Link Purpose (In Context) Skip

2.5.1 Pointer Gestures* Skip Skip

2.5.2 Pointer Cancellation* Skip Skip

2.5.3 Label in Name*

2.5.4 Motion Actuation* Skip Skip

3.1.1 Language of Page Skip Skip

3.2.1 On Focus Skip

3.2.2 On Input Skip

3.3.1 Error Identification Skip

3.3.2 Labels or Instructions Skip

4.1.1 Parsing Skip Skip

4.1.2 Name, Role, Value Skip Skip

*Note: New success criteria in WCAG 2.1

Version 1.8 Page 107

Web Accessibility Handbook Appendix B: WCAG 2.1 Criteria Checklist
for Developers

B.2 WCAG 2.1 Level AA Checklist

Level AA Success Criteria N/A Code Scan Visual Review AT Tests

1.2.4 Captions (Live) Skip

1.2.5 Audio Description (Prerecorded) Skip

1.3.4 Orientation* Skip

1.3.5 Identify Input Purpose* Skip

1.4.3 Contrast (Minimum) Skip Skip

1.4.4 Resize text Skip Skip

1.4.5 Images of Text Skip Skip

1.4.10 Reflow* Skip Skip

1.4.11 Non-Text Contrast* Skip Skip

1.4.12 Text Spacing* Skip Skip

1.4.13 Content on Hover or Focus* Skip Skip

2.4.5 Multiple Ways Skip Skip

2.4.6 Headings and Labels Skip Skip

2.4.7 Focus Visible Skip Skip

3.1.2 Language of Parts Skip Skip

3.2.3 Consistent Navigation Skip

3.2.4 Consistent Identification Skip

3.3.3 Error Suggestion Skip

3.3.4 Error Prevention Skip

4.1.3 Status Messages* Skip

*Note: New success criteria in WCAG 2.1

Version 1.8 Page 108

Web Accessibility Handbook Appendix B: WCAG 2.1 Criteria Checklist
for Developers

B.3 WCAG 2.1 Level AAA Checklist

Level AAA Success Criteria N/A Code Scan Visual Review AT Tests
1.2.6 Sign Language (Prerecorded) Skip Skip

1.2.7 Extended Audio Description (Prerecorded) Skip

1.2.8 Media Alternative (Prerecorded) Skip

1.2.9 Audio-only (Live) Skip

1.3.6 Identify Purpose* Skip

1.4.6 Contrast (Enhanced) Skip Skip

1.4.7 Low or No Background Audio Skip

1.4.8 Visual Presentation Skip Skip

1.4.9 Images of Text (No Exception) Skip Skip

2.1.3 Keyboard (No Exception) Skip Skip

2.2.3 No Timing Skip Skip

2.2.4 Interruptions Skip Skip

2.2.5 Re-authenticating Skip Skip

2.2.6 Timeouts* Skip Skip

2.3.2 Three Flashes Skip Skip

2.3.3 Animation from Interactions* Skip

2.4.8 Location Skip

2.4.9 Link Purpose (Link Only) Skip

2.4.10 Section Headings

2.5.5 Target Size* Skip Skip

2.5.6 Concurrent Input Mechanisms* Skip Skip

3.1.3 Unusual Words Skip

3.1.4 Abbreviations Skip Skip

3.1.5 Reading Level Skip

3.1.6 Pronunciation Skip

3.2.5 Change on Request Skip

3.3.5 Help Skip

3.3.6 Error Prevention (All) Skip

*Note: New success criteria in WCAG 2.1

Version 1.8 Page 109