Web Accessibility for Developers

Web Accessibility for

Developers

Essential Skills for Web Developers

DIGITAL EDUCATION STRATEGIES, THE

CHANG SCHOOL

GREG GAY AND IGOR KARASYOV

THE CHANG SCHOOL, RYERSON UNIVERSITY

TORONTO
Web Accessibility for Developers by Ryerson University, The Chang School is licensed
under a Creative Commons Attribution-ShareAlike 4.0 International License, except
where otherwise noted.
Introduction

Learning Outcomes

Welcome to Web Accessibility for Developers. We are glad that you

are here and are taking the time to learn some very important,
marketable developer skills!
By the time you complete this book, you should be able to:

• Test web interactivity with a screen reader to ensure

accessibility.
• Identify the differences between static and dynamic WAI-ARIA.
• Describe both graceful degradation and progressive
enhancement development methods.
• State when and when not to use WAI-ARIA.
• Explain the limitations of WAI-ARIA.
• Apply WAI-ARIA landmarks and live regions to web content.
• Create accessible progress bars, suggestion boxes, and tooltips
with WAI-ARIA.
• Build accessible sliders, accordions, tab panels, and carousels
with WAI-ARIA.
• Implement effective design patterns for accessible menu bars,
tree menus, and sortable lists with WAI-ARIA.

Suggested Prerequisites

This book is intended for web developers.

To get the most out of this book, you should have the following
prerequisite knowledge:

Introduction | 1
 • JavaScript: You should have a functional understanding of the
JavaScript scripting language and be familiar with using jQuery
and jQuery plugins. Though you can follow along with basic
knowledge of JavaScript and jQuery, it will be easier to
understand if you are comfortable writing (or, at least, copying
and pasting) JavaScript code and making adjustments.
• HTML: You should have at least a functional understanding of
HTML 5. Though most of the HTML in this book will be
provided, you’ll need to understand how it is used to produce
the widgets you’ll be working on.
• Git Version Control: We strongly recommend a GitHub
account (and a basic understanding of how it is used) in order
to participate in the activities found in this book. Details will be
provided in the book if you need to set up an account, and
basic Git commands will be covered.

Suggested Technology

You will need the following applications to complete the activities in

this book:

• ChromeVox Screen Reader: Required for testing assignment

submissions prior to submitting.
• FireFox Developer Edition: Optional, but includes the FireBug
Developer Tools, which are more helpful for debugging than
the default developer tools included with various browsers.
• Git: (Optional) Though you can edit activity files and send
them to a web server, you’ll be better off installing Git or a Git
Client and working from your own local development
environment.
• Plain Text Editor: Required for editing HTML and JavaScript,
which is much easier with a good, colour-coded text editor,

2 | Introduction
 such as Visual Studio Code, Sublime Text, or Atom.

Suggested Readings

Suggested Reading:

• Accessible Rich Internet Applications (WAI-ARIA) 1.1

• WAI-ARIA Authoring Practices 1.1

You might also look ahead to the next version by reviewing WAI-
ARIA 1.2, currently available as an editor’s draft.
These readings are more references than they are readings. At
a minimum, scan through these documents to understand what
they contain and refer back to them when you encounter scenarios
where WAI-ARIA could or should be used.

Disclaimer

The information presented in this book is for instructional purposes

only and should not be construed as legal advice on any particular
issue, including compliance with relevant laws. We specifically
disclaim any liability for any loss or damage any participant may
suffer as a result of the information contained. Furthermore,
successful completion of activities in this book does not result in
formal accreditation or recognition within or for any given field or
purpose.

Introduction | 3
Getting the Most Out of This
Book
We highly recommend reading this book online. While the book is
available for download in various formats (ePub, HTML, and PDF),
the interactive elements in the readings and activities are best
viewed here in Pressbooks.
Throughout the book, you’ll see the various coloured boxes
described below to help you organize how you engage with the
content.

Toolkit

Throughout the book, we identify items that should be added to

your WAI-ARIA Developer Toolkit, which you will collect during
the course of the book. These items will include links to resource
documents and online tools used during development activities, as
well as software or browser plugins that you may need to install.
These will be identified in a green Toolkit box like the following:

Toolkit: Provides useful tools and resources for your future

reference.

Key Points

Important or notable information is highlighted and labelled in Key

Point boxes such as the one that follows. These will include “must

Getting the Most Out of This Book | 1

know” information, as well as less obvious considerations and
interesting points.

Key Point: Essential information and interesting points.

Try This

Brief activities are highlighted in in the Try This boxes.

These activities are designed to get you thinking or give you
firsthand experience with something you’ve just read about.

Try This: Usually a quick activity to help you understand a

topic being discussed.

Suggested Reading

Links listed in these Suggested Reading boxes act more as

references than readings. At a minimum, scan through these
documents to understand what they contain and refer back to
them when you encounter scenarios where WAI-ARIA could or
should be used.

Suggested Reading: Links to various web resources for

optional reading on the topics being discussed.

2 | Getting the Most Out of This Book

Activity Elements

When the widget coding activities are introduced in Chapter 4, each

of the elements in the example activity are described using the
Activity Element box.

Activity Element: A brief description of each section of an

activity.

Self-Tests

The first few chapters include Self-Tests, which will help reinforce
key topics discussed in a unit. For questions that have multiple
answers, be sure to select all the correct answers and none
of incorrect answers in order for the question to be marked
“correct.” Multiple answer questions can be challenging, and they
typically require a thorough understanding of the topic in question
to answer correctly. Questions will only reference topics covered
in the book itself. They will not test your knowledge of content
referred to on external resource sites that may be linked from the
book.

Try This: Skip ahead to the end of the book and read through
the Book Recap for a high-level summary of the topics
covered in the book.

Getting the Most Out of This Book | 3

Who Should Read This Book
Web developers should read this book.
As much as we would like to teach WAI-ARIA to everyone —
including how it is used to make web interactivity accessible to
people with disabilities — the topic is very much a technical one.
While you do not necessarily need to be a web developer to
understand where and when WAI-ARIA should be used, in order to
implement it, you must be able to write code or, at a very minimum,
be able to read code and understand what it is doing.
Non–web developers can still benefit from the information
provided in this book, but they will likely find the activities very
challenging without the prerequisite background knowledge. This
background knowledge is beyond the scope of this book, so we
will not be able to help with basic HTML formatting or JavaScript
programming. The focus here is on using WAI-ARIA, not on using
HTML and JavaScript.
If you are not currently interested in code details but still want
to learn about web accessibility or if you want to go beyond coding,
we recommend two ebooks that are based on our less technically
focused courses on the same subject.

Suggested Reading:

• Digital Accessibility as a Business Practice

• Professional Web Accessibility Auditing Made Easy

Who Should Read This Book | 1

Accessibility Statement
Though we attempt to make all elements of the book conform with
international accessibility guidelines, we must acknowledge a few
accessibility issues that are out of our control or are done on
purpose to demonstrate barriers.

• Some external resources may not conform with accessibility

guidelines.
• Though possible to navigate the JSFiddle code samples
embedded in the book, JSFiddle itself is a complex interface
that can be difficult to navigate with a screen reader. Working
in JSFiddle is not a requirement for the book but has been
provided as a place to experiment with the code samples
provided.
• The rendered JSFiddle embedded examples found under the
result tab are intentionally made inaccessible.
• Prior to each embedded JSFiddle is a hidden bypass link to skip
over the fiddle iframe.
• The JSFiddle interface will extend beyond the width of a mobile
screen and, thus, require scrolling.
• Throughout the widget descriptions in chapters 4 to 6, we
present code examples embedded from PasteBin. Though the
code itself is readable with a screen reader, the highlighted
solutions they contain are not distinguishable from other code
in these samples when listening with a screen reader. Where
possible, we have described the changes in the text preceding
these code samples.
• The GitHub website, which contains the book files used with
activities in the book and is relatively accessible, can be
difficult to navigate and use with a screen reader.
• Third-party video content may not be captioned or may be
captioned poorly.

2 | Accessibility Statement
BACKGROUND

Background | 3
Types of Disabilities and
Barriers
In order to understand why web accessibility is necessary, it is
helpful to have a basic understanding of the range of disabilities
and their related barriers with respect to the consumption of web
content.

Key Point: Those who have taken our other courses will have
encountered this content already. Read again or skim for a
refresher.

Not all people with disabilities encounter barriers on the Web, and
those with different types of disabilities encounter different types
of barriers. For instance, if a person is in a wheelchair they may
encounter no barriers at all in web content. A person who is blind
will experience different barriers than a person with limited vision.
Different types of disabilities and some of their commonly
associated barriers are described here.
Watch the following video to see how students with disabilities
experience the Internet.
Video: Experiences of Students with Disabilities (1:59)

Types of Disabilities and Barriers | 5

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=813

© Jared Smith. Released under the terms of a Standard YouTube License. All rights

reserved.

In this video, David Berman talks about types of disabilities and

their associated barriers.
Video: Web Accessibility Matters: Difficulties and Technologies:
Avoiding Tradeoffs (9:52)

6 | Types of Disabilities and Barriers

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=813

© davidbermancom. Released under the terms of a Standard YouTube License. All rights

reserved.

People Who Are Blind

People who are blind tend to face many barriers in web content,
given the visual nature of the Web. They will often use a screen
reader to access their computer or device and may use a refreshable
Braille display to convert text to Braille.
Common barriers for this group include:

• Visual content that has no text alternative

• Functional elements that cannot be controlled with a keyboard
• Overly complex or excessive amounts of content

Types of Disabilities and Barriers | 7

 • Inability to navigate within a page of content
• Content that is not structured
• Inconsistent navigation
• Time limits (insufficient time to complete tasks)
• Unexpected actions (e.g., redirect when an element receives
focus)
• Multimedia without audio description

For a quick look at how a person who is blind might use a screen
reader like JAWS to navigate the Web, watch the following video.
Video: Accessing the web using screen reading software (3:07)

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=813

© rscnescotland. Released under the terms of a Standard YouTube License. All rights

reserved.

8 | Types of Disabilities and Barriers

People with Low Vision

People with low vision are often able to see web content if it is
magnified. They may use a screen magnification program to
increase the size and contrast of the content to make it more visible.
They are less likely to use a screen reader than a person who is
blind, though, in some cases they will. People with low vision may
rely on the magnification or text customization features in their
web browser, or they may install other magnification or text reading
software.
Common barriers for this group include:

• Content sized with absolute measures so is not resizable

• Inconsistent navigation
• Images of text that degrade or pixelate when magnified
• Low contrast (inability to distinguish text from background)
• Time limits (insufficient time to complete tasks)
• Unexpected actions (e.g., redirect when an element receives
focus)

See the following video for a description of some of the common

barriers for people with low vision.
Video: Creating an accessible web (AD) (4:39)

Types of Disabilities and Barriers | 9

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=813

© Centre for Inclusive Design. Released under the terms of a Standard YouTube License.

All rights reserved.

People Who Are Deaf or Hard of Hearing

For most people who are deaf the greatest barrier on the Web
is audio content that is presented without text-based alternatives.
They encounter relatively few barriers on the Web otherwise. Those
who are deaf and blind will face many more barriers, including those
described for people who are blind. For those who communicate
with American Sign Language (ASL) or other sign languages, such
as langue de Signes Quebecoise (LSQ), the written language of a
website may produce barriers similar to those faced when reading
in a second language.

10 | Types of Disabilities and Barriers

 Common barriers for this group include:

• Audio without a transcript

• Multimedia without captions or a transcript
• Lack of ASL interpretation (for ASL/Deaf community)

People with Mobility-Related Disabilities

Mobility-related disabilities are quite varied. As mentioned earlier,

one could be limited to a wheelchair for getting around and face
no significant barriers in web content. Those who have limited use
of their hands or who have fine motor impairments that limit their
ability to target elements in web content with a mouse pointer
may not use a mouse at all. Instead, they might rely on a keyboard
or perhaps their voice to control movement through web content
along with switches to control mouse clicks.
Common barriers for this group include:

• Clickable areas that are too small

• Functional elements that cannot be controlled with a keyboard
• Time limits (insufficient time to complete tasks)

People with Some Types of Learning or Cognitive

Disabilities

Learning and cognitive-related disabilities can be as varied as

mobility-related disabilities, perhaps more so. These disabilities can
range from a mild reading-related disability to very severe cognitive
impairments that may result in limited use of language and difficulty
processing complex information. For most of the disabilities in this

Types of Disabilities and Barriers | 11

range, there are some common barriers and others that only affect
those with more severe cognitive disabilities.
Common barriers for this group include:

• Use of overly complex/advanced language

• Inconsistent navigation
• Overly complex or excessive amounts of content
• Time limits (insufficient time to complete tasks)
• Unstructured content (no visible headings, sections, topics,
etc.)
• Unexpected actions (e.g., redirect when an element receives
focus)

More specific disability-related issues include:

• Reading: text justification (inconsistent spacing between

words)
• Reading: images of text (not readable with a text reader)
• Visual: visual content with no text description
• Math: images of math equations (not readable with a math
reader)

Everyone

While we generally think of barriers in terms of access for people

with disabilities, there are some barriers that impact all types of
users, though these are often thought of in terms of usability.
Usability and accessibility go hand-in-hand. Adding accessibility
features improves usability for others. Many people, including those
who do not consider themselves to have a specific disability (such as
those over the age of 50) may find themselves experiencing typical
age-related loss of sight, hearing, or cognitive ability. Those with
varying levels of colour blindness may also fall into this group.

12 | Types of Disabilities and Barriers

 Some of these usability issues include:

• Link text that does not describe the destination or function of

the link
• Overly complex content
• Inconsistent navigation
• Low contrast
• Unstructured content

To learn more about disabilities and associated barriers, read the

following:

Suggested Reading: How People with Disabilities Use the

Web

Types of Disabilities and Barriers | 13

Why Learn About Accessible
Web Development

Key Point: Those who have taken our other courses, or read
our other books, will have read through this content already.
Read again or skim for a refresher.

Curb Cuts

Curb cuts are a great example of universal design. Originally, curb

cuts were added to sidewalks to accommodate those in wheelchairs,
so they could access the road from the sidewalk and vice versa.
However, curb cuts are helpful for many people — not just those
in wheelchairs — including a person pushing a baby stroller, a
cyclist, or an elderly person using a walker. The addition of a smooth
gradient ramp allows anyone, who may have difficulty stepping or
who may be pushing something, to smoothly enter the sidewalk via
a ramp, rather than having to climb a curb. Although curb cuts were
initially designed to help those in wheelchairs, they have come to
benefit many more people.
From a web accessibility perspective, most of the accessibility
features you might add to a website will have that so-called “curb
cut effect.” For example, the text description one might include
with an image to make the image’s meaning accessible to a person
who is blind also makes it possible for search engines to index the
image and make it searchable. It allows a person on a slow Internet
connection to turn images off and still get the same information. Or,
it allows a person using a text-based browser (on a cell phone for
instance) to access the same information as those using a typical

14 | Why Learn About Accessible

Web Development
visual browser. Virtually every such feature that might be put in
place in web content to accommodate people with disabilities will
improve access and usability for everyone else.

Key Point: Think of accommodations to improve web

accessibility for people with disabilities as “curb cuts.” These
accommodations will very likely improve usability for
everyone.

The Business Case for Web Accessibility

Video: The Business Case for Accessibility (3:29)

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=818

Why Learn About Accessible Web Development | 15

Karl Groves wrote an interesting series of articles in 2011 and 2012
that looked at the reality of business arguments for web
accessibility. He points out that any argument needs to answer
affirmatively at least one of the following questions:

1. Will it make us money?

2. Will it save us money?
3. Will it reduce risk?

He outlines a range of potential arguments for accessibility:

• Improved search engine optimization: Customers will be able

to find your site more easily because search engines can index
it more effectively.
• Improved usability: Customers will have a more satisfying
experience, thus spend more on or return more often to your
site.
• Reduced website costs: Developing to standard reduces bugs
and interoperability issues, reducing development costs and
problems integrating with other systems.
• People with disabilities have buying power: They won’t spend
if they have difficulty accessing your site; they will go to the
competition that does place importance on accessibility.
• Reduced resource utilization: Building to standard reduces
use of resources.
• Support for low bandwidth: If your site takes too long to load,
people will go elsewhere.
• Social responsibility: Customers will come if they see you
doing good for the world and you are thinking of people with
disabilities as full citizens.
• Support for aging populations: Aging populations also have
money to spend and will come to your site over the less
accessible, less usable competition.
• Reduced legal risk: You may be sued if you prevent equal
access for citizens/customers or discriminate against people

16 | Why Learn About Accessible Web Development

 with disabilities.

What accessibility really boils down to is “quality of work,” as Groves

states. When approaching web accessibility, you may be better off
not thinking so much in terms of reducing the risk of being sued or
losing customers because your site takes too long to load. Rather, if
the work that you do is quality work, then the website you present
to your potential customers is a quality website.
If you’d like to learn more about business cases, here are a few
references:

Suggested Reading:

• Developing a Web Accessibility Business Case for Your

Organization (W3C)
• Chasing the Web Accessibility Business Case (Karl
Groves, 2012), Part 1
• Chasing the Web Accessibility Business Case (Karl
Groves, 2012), Part 2
• Chasing the Web Accessibility Business Case (Karl
Groves, 2012), Conclusion
• 2 Seconds as the New Threshold of Acceptability for
eCommerce Web Page Response Times (Akamai, 2009)
• Releasing Constraints: The Impacts of Increased
Accessibility on Ontario’s Economy (Summary)
• Releasing Constraints: Projecting the Economic Impacts
of Increased Accessibility in Ontario (Full Report)

Why Learn About Accessible Web Development | 17

AODA Background
Video: AODA Background (3:05)

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=820

For those reading this book from Ontario, Canada, we’ll provide
occasional references to the Accessibility for Ontarians with
Disabilities Act (AODA). For those reading this book from outside
Ontario, you might compare AODA’s web accessibility requirements
with those in your local area. They will be similar in many cases and
likely based on the W3C WCAG 2.0 Guidelines. The goal in Ontario
is for all obligated organizations to meet the Level AA accessibility
requirements of WCAG 2.0 by 2021, which, ultimately, is the goal of
most international jurisdictions.
The AODA provided the motivation to create this book. All

18 | AODA Background
businesses and organizations in Ontario with more than 50
employees (and all public sector organizations) are now required
by law to make their websites accessible to people with disabilities
(currently at WCAG 2.0 Level A). Many businesses still don’t know
what needs to be done in order to comply with the new rules. This
book hopes to fill some of that need.
The AODA has its roots in the Ontario Human Rights Code,
introduced in 1990. It essentially made it illegal to discriminate
based on disability (among other forms of discrimination). The
development of the AODA began in earnest in 1994 with the
emergence of the Ontarians with Disabilities Act (ODA). Its aim
was to legislate the removal and prevention of barriers that inhibit
people with disabilities from participating as full members of
society, improving access to employment, goods and services, and
facilities. The act was secured as law in 2001.
With the election of a new government in 2003, the movement
that brought us the ODA sought to strengthen the legislation. The
Accessibility Standards Advisory Council was established and the
AODA was passed as law in 2005, and, in July 2011, the Integrated
Accessibility Standards Regulation (IASR) brought together the five
standards of the AODA covering Information and Communication,
Employment, Transportation, and Design of Public Spaces, in
addition to the original Customer Service standard.
The AODA sets out to make Ontario fully accessible by 2025, with
an incremental roll-out of accessibility requirements over a period
of 20 years. These requirements span a whole range of accessibility
considerations — from physical spaces to customer service, the
Web, and much more.
Our focus here is on access to the Web. The timeline set out in
the AODA requires government and large organizations to remove
all barriers in web content between 2012 and 2021. The timeline
for these requirements is outlined in the table below. Any new or
significantly updated information posted to the Web must comply
with the given level of accessibility by the given date. This includes

AODA Background | 19
both Internet and Intranet sites. Any content developed prior to
January 1, 2012, is exempt.

Level A Level AA

• January 1,
2016
(except live
captions
and audio
description)
• January 1, 2012 (except live
Government • January 1,
captions and audio description)
2020
(including
live
captions
and audio
description)

• January 1,
• Beginning January 1, 2014, new
2021
websites and significantly
Designated (except live
refreshed websites must meet
Organizations* captions
Level A (except live captions and
and audio
audio description)
description)

*Designated organizations means every municipality and every person

or organization as outlined in the Public Service of Ontario Act 2006 Reg.
146/10, or private companies or organizations with 50 or more
employees, in Ontario.

For more about the AODA you can review the following references:

Suggested Reading:

◦ History of the Ontarians with Disabilities Act.(ODA)

(David Lepofsky)
◦ Integrated Accessibility Standards Regulation

20 | AODA Background
◦ Reg. 146/10: Public Bodies and Commission Public
Bodies – Definitions

AODA Background | 21
About WCAG and
WAI-ARIA
Before we get into the main part of the book, some background
information on the relevant W3C specifications will help provide
some context for why developers should learn to use WAI-ARIA
when they are developing custom interactivity for the Web.

WCAG

The Web Content Accessibility Guidelines (i.e., WCAG 2.0 and the
recent WCAG 2.1, pronounced wuh-kag) is the primary specification
adopted around the world and describes how web content should
be created so it will be accessible to people with disabilities. WAI-
ARIA can help developers create content that conforms with
recommendations in WCAG. WCAG is covered in more detail in
another book, so we will just provide a basic introduction here. For
those who are not already familiar with WCAG, follow the link to the
W3C WCAG Specification for details.

Suggested Reading:

• The Web Content Accessibility Guidelines (WCAG 2.0)

• The Web Content Accessibility Guidelines (WCAG 2.1)

WCAG revolves around four principles that help group guidelines

22 | About WCAG and WAI-ARIA

with common characteristics. The acronym POUR can be used to
remember the principles, described below.
Content must be:

1. Perceivable: It must be possible to perceive web content

through multiple senses so that those who have lost a sense
are able to perceive the content through another sense. Some
good examples of making content perceivable are alternative
text with images, so people who are blind can perceive images,
and captions with audio or video, so people who are deaf are
able to perceive sounds and speech.
2. Operable: Content needs to operate with both a mouse and a
keyboard. There are many people who are unable to use a
mouse effectively or not at all. When content is not keyboard
operable, most people who are blind (among others) will
experience barriers. Some good examples include using
onKeyPress alongside onClick for JavaScript, and using both
:hover and :focus in CSS so effects are possible with both
mouse and keyboard.
3. Understandable: Content needs to be understood by a range
of people, which includes people with cognitive disabilities,
sensory disabilities, people reading in a second language, and
even typical able users. Some good examples include making
link text meaningful (“click here” tells one nothing about the
link’s destination) and consistent navigation elements (so users
only have to learn the navigation structure of a website once).
4. Robust: Content needs to work across multiple platforms, and
it needs to continue to work into the future as technology
evolves. This generally means developing content based on
standards. And, when non-standard uses of HTML etc. are
provided, a standard version is available as a backup. Some
uses of WAI-ARIA fall into this category of guidelines.

WCAG also introduces conformance levels. Conformance levels can

be thought of in terms of their importance toward removing

About WCAG and WAI-ARIA | 23

barriers with Level A being the most important. It is helpful to think
of levels as things you must do, should do, and could do.

• Level A: These issues must be resolved or some group will not

be able to access the content. The issues at this level represent
significant barriers that may not be overcome with
workarounds. An example of a Level A barrier is missing
alternative text to describe an image. There is little a person
who is blind can do on their own to understand the content of
an image without a text description.
• Level AA: These issues should be resolved or some group will
find it difficult to access or use the content. These issues can
often be circumvented with some effort but will make using or
understanding web content more effortful. An example of a
Level AA barrier is not being able to follow the focus of the
cursor when navigating through content with a keyboard. For a
person with low vision navigating with a keyboard, or a fully
able keyboard user for that matter, navigating through content
can be very difficult if he or she cannot see where the cursor is
located and is unable to tell when to press the Enter key to
activate a link or button.
• Level AAA: These issues could be resolved to improve usability
for all groups. Web content may be technically accessible, but
usability can be improved by resolving these issues. An
example of a Level AAA barrier would be presenting acronyms
or abbreviations without providing their full wording. For a
person who is blind, an acronym pronounced by a screen
reader may sound like gibberish. For a fully able user who is
not familiar with a short form, an acronym or abbreviation may
have no useful meaning, at least not without having to search
out the meaning elsewhere.

Level AA is the generally accepted level of conformance most

websites should aim for, with perhaps a few Level AAA items
addressed. Very few websites will comply at Level AAA, apart from

24 | About WCAG and WAI-ARIA

the most basic of sites. Level AAA compliance is generally
unattainable, and in some cases undesirable.
The following suggested readings provide links to additional
WCAG related resources.

Suggested Reading:

• Understanding WCAG 2.0 (see Success Criteria and

Techniques)
• How to Meet WCAG 2

WAI-ARIA

This book focuses on the WAI-ARIA specification and how it is

used to ensure interactive web content is accessible to people with
disabilities. The acronyms stand for Web Accessibility Initiative,
the W3C subgroup that developed the specification, and Accessible
Rich Internet Applications, the specification itself. It is typically
referred to as WAI-ARIA, rather than ARIA, to distinguish it from
other uses of the acronym. WAI-ARIA can be used to help
developers create widgets, applications, and web interactivity in
general that meet WCAG recommendations.
The WAI-ARIA specification was initially released as a
recommendation in March 2014 (WAI-ARIA 1.0). WAI-ARIA 1.1 was
released in December 2017, and is the current stable version, with
WAI-ARIA 1.2 in the works, available as an editor’s draft.
WAI-ARIA itself is not a solution on its own for making interactive
web content accessible. It is generally used with JavaScript, which
dynamically injects WAI-ARIA attributes into HTML to provide
semantics that are recognized by assistive technologies and

About WCAG and WAI-ARIA | 25

understandable by end users. For example, if a series of nested lists
are assembled as a menu, WAI-ARIA menu attributes can be added
to replace the list semantics with menu semantics.
For now introduce yourself to WAI-ARIA, if you are not already
familiar, by scanning over the specification to develop a general
understanding of why it is needed, how it is used, and when to use it.
We will go into much more detail as we proceed through the book.

Suggested Reading:

• Accessible Rich Internet Application (WAI-ARIA 1.1)

• WAI-ARIA 1.2 Editor’s Draft

26 | About WCAG and WAI-ARIA

1. INTRODUCTION

1. Introduction | 27
Objectives and Activities

Objectives

By the end of this unit, you will be able to:

• Save a local copy of the book files

• If you are using this book as part of a course, get set up to
submit assignments, on GitHub, raw.githack.com, or your own
web server (optional)

Activities

• Set up a site for future book assignments and submit a URL to

it (optional)

Objectives and Activities | 29

Submitting Coding
Assignments and Using
GitHub
Note: If you are using this book as part of a course, please read on.
Otherwise, submitting coding assignments is not required.

Most assignments in this book are various inaccessible web page

widgets that we will ask you to make accessible by rewriting their
code (HTML, CSS, or JavaScript). If you are using this book as part
of a course, you will need the link to a live web page with your
solution. Before the code is reviewed, the page will be checked for
accessibility (using ChromeVox and other tools).
It is your decision where you want to host the pages that you
will submit for review. If you have your own domain and server
space, you can upload completed assignments there and submit
the URL. Another option is to submit the URL of a file on GitHub
to GitHack (https://raw.githack.com), then submit the URL to the
output it generates as your assignment submission.
Feel free to download the book files from our repository now, or
if you are going to use GitHub, keep reading for instructions how to
fork it to your own account.
If you don’t have a website, we recommend using GitHub as your
platform for submitting assignments. Below we describe GitHub and
GitHub Pages. If you are familiar with using GitHub or you have your
own web server, you can skip the rest of this page, or just scan it.

30 | Submitting Coding Assignments

and Using GitHub
Set Up a GitHub Account

If you do not already have one, you should create a GitHub account.
For any developer, it is an invaluable tool for sharing and
collaborating on code development. A GitHub account is free.
Though you can download the book files from GitHub, then unzip
them and work from a local directory on your hard drive, we
recommend creating a fork of the book files to your own account,
and cloning your fork into a local directory. Follow the link below to
set up an account, then read on.

Toolkit: Join GitHub

Set Up a Local Git Environment

Depending on the operating system you are using, there are specific
versions of Git for each platform. You may choose to use a Git client,
or you may choose to use Git from the command line. Here we will
present command line options. If you choose to use a client, see
the documentation associated with the client for details on cloning,
committing, pulling, and pushing.
If you are going to use a client, instead of working from a
command line, for Windows and Mac users, we suggest installing
SourceTree. GitHub Desktop is a good alternative if you prefer to
use an Open Source client. Feel free to choose another Git client if
you like.

Toolkit: Download SourceTree, or GitHub Desktop if you

need a desktop Git client application.

For Linux users you can use your system’s package manager to

Submitting Coding Assignments and Using GitHub | 31

install Git for command line use. On Ubuntu for instance, at the
command prompt you can run apt-get as the root user to install
Git:
#> sudo apt-get install git

Suggested Reading: For more about Git setup on Ubuntu see

the tutorial on DigitalOcean:

If you are using another Linux distribution, use Google to find

details on installing Git on your version of Linux.

Suggested Reading: For details on installing Git, see the

GitBook.

Assignment Submissions via GitHub

Most of the assignments for this book require submitting a URL to

a publicly accessible version of the widgets that are the focus of the
book activities.
If you need a place to post your activity assignments, GitHub
Pages can be a good option. Or, you may just prefer to use GitHub
Pages to organize your files, so they are not cluttering your web
server. You will create a fork of the book files (learnaria.github.io),
rename the repository to create your own version, and either
upload it to a site of your choosing, or use GitHub Pages. The GitHub
Pages option is outlined here.

Suggested Reading: Using GitHub Pages.

If you choose to use GitHub Pages, follow these steps to create a

copy of the files under your own GitHub account.

32 | Submitting Coding Assignments and Using GitHub

 1. Logged into GitHub, find your way to the book files, and
fork that repository. The fork button is at the top right of
the GitHub screen while viewing a repository. This creates
a copy of the repository under your own GitHub account
where you will work from.
2. After you have forked the book files, go into the settings
for that repository and change the name from
learnaria.github.io to [username].github.io, where
username is your GitHub account username. This will
automatically create your GitHub Pages website at
https://[username].github.io.
3. Now you will want to create a clone of your forked book
files repository on your computer, through which you will
do your work. From the command line issue the following
command to create a clone of the forked version of the
book files you created, where [username] is your GitHub
account username. You can also copy the https link from a
field that opens when you click on the “Clone or
download” button in your repo.#>git clone
4. If you are using SourceTree, click on “+ New Repository”
and choose “Clone from URL” and enter the above URL
into the “Source URL” field. Set the “Destination Path” to
your preferred work directory.

Suggested Reading: Cloning a repository.

You should now have a copy of the book files available locally that
you can edit and commit back as your assignment updates, which
become part of your GitHub Pages website.
Note that it can take a few seconds or a minute for changes
committed to your GitHub Pages repository to actually show up on
the website.

Submitting Coding Assignments and Using GitHub | 33

If You Already Have a GitHub Pages Site

To add the files to an existing GitHub Pages site, open the settings
for the forked repository you created. In the GitHub Pages section
shown in the screenshot below, choose the Source (typically, the
master branch) and click Save. This will create a subdirectory under
your existing GitHub Pages site with the name of the forked
repository (i.e., learnaria.github.io).
You may want to rename the repository to something shorter
(e.g., learnaria) before enabling it in GitHub Pages. This would
produce a URL to the book files something like:
https://[username].github.io/learnaria/
Figure: A
screenshot of
the GitHub
Pages
settings

Basic Git Commands

You do not need to be an expert Git user, but you should know a few
basic commands if you are working from a command prompt. The
commands you’ll likely use are the following

git status (displays a list of changed and untracked files)

git add [filename] (prepares a files for committing)

34 | Submitting Coding Assignments and Using GitHub

 git commit -m “[message]” (describe the nature of the
commit)
git push [origin master] (sends the committed change to
your GitHub repository master branch)
git diff [filename] (shows the changes in a file)

Of course there are many other potential commands, but these are
the most common. If you are using a Git client, like SourceTree,
these commands will be clickable in the UI buttons and menus. For
more about using Git from the command line, see the Git Book.

Suggested Reading: The Git Book.

What the Book Files Look Like

Here is what to expect once you have successfully set up the book
files. You’ll note that the widgets are inaccessible. Your job
throughout the book will be to fix the accessibility of each widget.

Submitting Coding Assignments and Using GitHub | 35

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=172

36 | Submitting Coding Assignments and Using GitHub

Activity 1: How to Submit
Assignments

How to Submit Assignments

If you are submitting assignments, the first task in the book is to

get setup to submit assignments. This can be done through GitHub
Pages (recommended), another public location on the Web, or
on GitHack.
Refer back to Using GitHub in this Book for details on getting set
up with GitHub Pages.

Alternatives to GitHub Pages

• If you choose not to use GitHub Pages for your assignments,

submit the URL to the index.html file of your copy of the book
files at an alternate location where you have set up your files.
• Or, submit the URL to the index.html file of your GitHub
repository generated through raw.githack.com.

Activity 1: How to Submit

Assignments | 37
Requirements

If you are taking a course that uses this textbook, your instructor
will provide information on how and where to submit the URLs to
your various assignment submissions.

Grading Rubric

Criteria Points
URL to Course Files:
10.0
URL submitted to your copy of all the course files either in
pts
GitHub Pages or on a web server of your choosing.
Total Points: 10.0

38 | Activity 1: How to Submit Assignments

Introduction to the jQuery
Plugin
Though we have chosen to focus the book around jQuery, much
of what you’ll learn in this book will be applicable to JavaScript
in general and to other JavaScript frameworks you may be using
in your work. Much of the effort in the book will be on creating
device independent code (works with keyboard and mouse) and
using script to inject WAI-ARIA into HTML as needed to dynamically
manage roles, states, and properties of various interactive widgets
and applications you’ll be introduced to.
Throughout the book you will be building a jQuery-ARIA plugin.
We will first provide some background in the first few chapters,
then introduce static WAI-ARIA, then move into building the plugin
in Chapter 4 up until the end of the book.
As you go through the book you will be building pieces of the
library one widget at a time. At the end of the book, when you have
submitted all of the assignments, we will provide you with a link to
the full library that you can continue to use and build upon.

Disclaimer

When creating this book and the jQuery plugin, we have optimized
plugin widgets to work with ChromeVox, the screen reader you’ll
be introduced to shortly. You may find some inconsistencies in
functionality and presentation when using NVDA or JAWS (i.e., other
screen readers). Compatibility or limitations across screen readers
will be discussed throughout the activities within the book.

Introduction to the jQuery

Plugin | 39
Other WAI-ARIA Libraries
Though we’ll focus on using the open source WAI-ARIA jQuery
library we have created for this book, there are a couple other
resources you can review that provide similar capabilities.

Toolkit: jQuery UI Accessibility Enhancements. Developed by

Hans Hillen at the Paciello Group.

Toolkit: Accessible MooTools Widgets. Developed by

Fraunhofer as part of an AEGIS project (no longer available
through the creator).

The above libraries have been pulled apart and set up as individual
demos. These demos can be found through The Chang School’s
Distance Education website, as part of a set of resources for a local
workshop run at the university.

Toolkit: WAI-ARIA Workshop Resources

Another great resource for WAI-ARIA code and examples is the

W3C’s WAI-ARIA Authoring Practices site. Within the
documentation are many demonstrations of how WAI-ARIA can be
used. We will typically follow the best practices recommended by
W3C, though, we may vary from those on occasion when more
practical solutions are possible. These variations will be
documented in the code comments.

Toolkit:

40 | Other WAI-ARIA Libraries

• WAI-ARIA Authoring Practices 1.1
• ARIA Techniques for WCAG 2.0
• Using WAI-ARIA

Other WAI-ARIA Libraries | 41

ChromeVox Screen Reader
Install and Setup
We introduce you to ChromeVox early on, so you’ll have an
opportunity to practice using the screen reader we will be using
throughout the book. It will be a key tool in your toolkit that you’ll
use to test your work, and it will be the tool the instructors use
when marking assignments.
Though there are other more popular screen readers, like JAWS
and NVDA to name a couple, for day-to-day screen reader testing,
ChromeVox (particularly the ChromeVox Plugin for the Chrome web
browser) is our screen reader of choice because it is simple to install
and configure, easy to use, free and open source, and works across
computer platforms.
Another reason ChromeVox works well for accessibility testing is
its good support for WAI-ARIA. WAI-ARIA is still a relatively new
technology, and, as of mid-2018, it is still being supported
inconsistently across available browsers and screen readers. When
developing for the Web, do use WAI-ARIA as it is intended to be
used as documented in the WAI-ARIA specification and test it with
ChromeVox. You will still want to test with JAWS or perhaps NVDA
for production testing, as these are more likely to be used by blind
users. For this book, however, we will only be using ChromeVox.
While a relatively small number of screen reader users currently
use ChromeVox, it is a highly effective tool for developers when
testing web content. Also, ChromeVox is tailored to work with
features of Google Drive, so even for users of other screen readers,
ChromeVox may be preferable when working with Google Docs,
Sheets, and Slides, etc.

Toolkit: Visit the Chrome store while using the Chrome web

42 | ChromeVox Screen Reader

Install and Setup
 browser to install the ChromeVox screen reader. It will be a
key element of your Toolkit.

How to Set Up the ChromeVox Screen Reader

1. Open the Chrome web browser (install Chrome, if needed).

2. Type “Chromevox” into Chrome’s address bar, or into Google
search.
3. Follow the ChromeVox link to the Chrome Web Store (the first
link in the search results).
4. Click the “Add to Chrome” button.
5. In the dialog box that opens, click “Add extension.”
6. Now installed, find the ChromeVox icon near the top right of
Chrome to review its options.
7. In the Options, set the ChromeVox modifier key to Alt or Ctrl
or both (referred to here as CVox).
8. In the Options, choose your preferred voice from the Voices
menu.
9. Done, turn ChromeVox on or off by pressing and holding the
modifier key then pressing the letter “A” twice (i.e., CVox + A +
A).

If you would rather see ChromeVox installed, the video below

describes how to install and begin using ChromeVox.
Video: Installing ChromeVox

ChromeVox Screen Reader Install and Setup | 43

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=190

ChromeVox Testing and Associated Key

Commands

Toolkit: Download the ChromeVox_Key_Commands file

(Word), outlined in the table below, print it or keep it nearby
when completing the first few activities.

Key Point: Be sure you have the modifier key set in

44 | ChromeVox Screen Reader Install and Setup

ChromeVox Options, or you are going to have difficulty with
the activities.
*The ChromeVox modifier key (i.e., Cvox) is set in Chrome’s
Settings > Extensions > ChromeVox > Options, typically set to
Alt or Ctrl.

Key Point: When you are navigating with ChromeVox, it will

add its own highlighting around elements when they receive
focus. Test for focus visibility (WCAG 2 Guideline 2.4.7) when
ChromeVox is not running. For a complete list of key
commands see the ChromeVox Options, accessible through
the ChromeVox button that gets added to Chrome in the top
right corner of the browser during installation. Default
commands are listed and can be changed if needed.

ChromeVox Screen Reader Install and Setup | 45

 Keyboard
Task Task Description
Command
Toggle
To turn ChromeVox on or off without having
ChromeVox Cvox+A+A
to go into the ChromeVox Settings
On/Off
Stop
Stop ChromeVox from reading Ctrl
Reading

When a web page loads, ChromeVox will

read the element that takes focus on the
page. Use the Cvox+Arrow keys to read Cvox+Up
Default
through content. Listen to the spoken and Down
Reading
output and note any inconsistencies from Arrows
what one might expect to hear based on
what is visible on the screen.
When a page has loaded, press the Tab key
to navigate through operable elements of
the page like links and forms. Listen to the
output when these elements are in focus,
Tab and note any elements that are clickable but Tab, Shift +
Navigation not focusable with the keyboard. Tab

Also listen for hidden elements such as

bypass links or other elements that are not
visible but are read aloud by ChromeVox.
Step through all the headings on a page.
Cvox+L+H
Navigate Note whether all headings are announced as
then Up/
through expected. Note the heading level announced.
Down
Headings Are they sequenced to create semantic
Arrows
structure (i.e., nested in the proper order)?
Cvox+L+;
Step through the landmarks, key navigation
Navigate (semi-colon)
points on a page. Are all areas of the page
through then Up/
contained in a landmarked region? Note any
Landmarks Down
missing landmarks.
Arrows

List the links and navigate through them Cvox+L+L

using the Arrow keys, listen for then Up/
List Links
meaningfulness, or listen for context when Down
links are otherwise meaningless. Arrows
Navigate to forms on a page, then press the Cvox+L+F
Navigate
Tab or F keys to listen to each of the fields. then Up/
through
Are fields announced effectively, including Down
Forms
required fields? Arrows

46 | ChromeVox Screen Reader Install and Setup

 Cvox+L+T
then Up/
Down
Navigate to Tables on a page, press Enter to
Arrows then
go to a table, press Up/Down Arrow keys to
Enter to
move through cells in sequence (left to right,
select Table
Navigate top to bottom), press Ctrl+Alt+Arrow to
through move to adjacent cells, press Ctrl+Alt and 5
Cvox+Arrow
Tables on the number pad to list column and row
to move
headers where applicable. Note whether
within table
header cells are read or not. Are Fieldset
Cvox+TH
labels announced, where applicable?
to
announce
headers

ChromeVox Screen Reader Install and Setup | 47

Activity 2: Set Up and Use
ChromeVox

Set Up and Use ChromeVox

Key Point:

• If you are blind and use a screen reader other than

ChromeVox, complete the activity using your preferred
screen reader. Be sure to state the name of the screen
reader you are using.
• If you are not blind, regardless of whether you use
another screen reader to test accessibility for instance,
please use ChromeVox. What’s important is how
ChromeVox interacts with the book files you will be
updating in the activities of this book.

In this activity, you will navigate through

a website using only a keyboard. Describe how the screen reader
behaves. For a challenge, navigate with your monitor turned off (or
darkened so you can’t see what you are doing). The aim of this
48 | Activity 2: Set Up and Use
ChromeVox
exercise is to discover how WAI-ARIA is making elements on the
page understandable by listening alone, and to introduce screen
reader review into your website testing regimen.
Refer back to ChromeVox Screen Reader Install and Setup and set
up ChromeVox, if you have not already.

Requirements

Open the Web Accessibility Auditing Showcase website.

Navigate the homepage only with your monitor darkened and
without using your mouse. Describe what the screen reader
announces as you pass through the following elements:

• Left side menu

• Carousel at the top of the content area of the page
• Accordion on the right
• Tab panel in the centre of the page
• Landmarks present on the page (list them)

Also, answer the following questions:

• Are you able to navigate effectively?

• What difficulties did you experience, if any?
• What could be improved, if anything, to make navigation more
effective?

Activity 2: Set Up and Use ChromeVox | 49

Grading Rubric

Criteria Points
Good descriptions provided for each element listed 5.0 pts

Three questions answered effectively 5.0 pts

Total Points: 10.0

50 | Activity 2: Set Up and Use ChromeVox

WAI-ARIA and HTML 5
WAI-ARIA was released as a complement to HTML5. Its main
purpose is to give developers more freedom to build custom web
content, web applications, and interface controls created with
HTML, JavaScript, and Ajax. WAI-ARIA provides a framework for
adding semantics that make it possible for assistive technology
users to understand and operate these custom elements.
Most HTML has built-in semantics and does not generally need
WAI-ARIA. However, when HTML is being used in a non-standard
way, like making a button out of a <div> , then WAI-ARIA can be
added to that <div> to make it appear as a button to a screen
reader by adding the following: Add the role of “button”
(i.e., role="button" ), add a null tabindex value
(i.e., tabindex="0" ), which makes it focusable, then define its
state using the aria-pressed attribute, which is updated with
JavaScript when the button is pressed. In the case of an actual
<button> element, these properties are all already defined, so
there is no need to use WAI-ARIA.

<div role="button" aria-pressed="false" tabindex="0">Press Me</

Though WAI-ARIA is typically used with HTML5, it can also be used

with XHTML and HTML4. You may find, however, that HTML
validators see WAI-ARIA as broken markup in older versions of
HTML, but don’t worry about that. Any WAI-ARIA related errors that
a validator might identify in older HTML can generally be ignored
(assuming it has been used correctly). By now though, you should be
using HTML5. If you are retrofitting older code, then go ahead and
add WAI-ARIA to it. If you are developing something new, then go
with HTML5.

WAI-ARIA and HTML 5 | 51

Self-Test 1

Complete the following questions to test your understanding of

some key lessons in the Introduction and Chapter 1.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=205

52 | Self-Test 1
2. INTRODUCTION TO
WAI-ARIA

2. Introduction to WAI-ARIA | 53
Objectives and Activities

Objectives

By the end of this unit, you will be able

to:

• Explain how WAI-ARIA works

• Distinguish between static vs. dynamic WAI-ARIA
• Identify WAI-ARIA roles, states, and properties
• Recognize browser and screen reader support for WAI-ARIA
• Compare and contrast graceful degradation vs progressive
enhancement
• Outline the WAI-ARIA taxonomy

Activities

• WAI-ARIA Scavenger Hunt (Showcase)

Objectives and Activities | 55

What is WAI-ARIA?

W3C definition of WAI-ARIA

“WAI-ARIA provides a framework for adding attributes

to identify features for user interaction, how they relate
to each other, and their current state.”

Source: W3C

WAI-ARIA provides web authors with the following:

• Roles to describe the type of widget presented, such as

“menu”, “treeitem”, “slider”, and “progressmeter”
• Roles to describe the structure of the web page, such as
headings, regions, and tables (grids)
• Properties to describe the state widgets are in, such as
“checked” for a check box, or “haspopup” for a menu.
• Properties to define live regions of a page that are likely to
get updates (such as stock quotes), as well as an
interruption policy for those updates — for example,
critical updates may be presented in an alert dialog box
and incidental updates occur within the page
• Properties for drag-and-drop that describe drag sources
and drop targets
• A way to provide keyboard navigation for the web objects
and events, such as those mentioned above

Source: W3C

56 | What is WAI-ARIA?
Some elements of the framework can be used on their own to add
accessibility to web content (e.g., landmarks). More often, they are
combined with scripting that is used to dynamically add or remove
WAI-ARIA attributes depending on the context.
WAI-ARIA provides semantics for custom widgets and web
applications that can be understood by assistive technologies (ATs)
and conveyed to users in a “human understandable” form. For
example, HTML list markup might be used to create a navigation
bar with menus and submenus. Without WAI-ARIA a screen reader
would simply recognize the navigation bar as a collection of nested
lists. Adding WAI-ARIA menu attributes (e.g., menubar, menu,
menuitem, aria-haspopup, aria-expanded) can give the nested list
a whole new meaning, more easily understood as a means of
navigation than the list would be understood.

W3C definition of semantics

“The meaning of something as understood by a

human, defined in a way that computers can process a
representation of an object, such as elements and
attributes, and reliably represent the object in a way
that various humans will achieve a mutually consistent
understanding of the object.”

Source: W3C

This definition of semantics in programming is much like the

common definition of the word: “the meaning, or an interpretation
of the meaning” (dictionary.com). Semantics in the context of web
accessibility refers to the defining of meaning as it applies to
functional elements of web content, and how that functionality is
conveyed to assistive technology users, especially, screen reader
users.

What is WAI-ARIA? | 57
When and When Not to Use WAI-ARIA

WAI-ARIA is supposed to be used when semantics are required to

make a web application or widget understandable. For example, if
you are using a <div> to create a checkbox, along with some
scripting you can assign the WAI-ARIA role “checkbox” to that
<div> to make it appear as a checkbox.
That said though, when there is a native HTML element available,
like a checkbox, it is almost always better to use the native version
than creating your own. The native version will already have all
the associated semantics by default. Since the native versions are
standardized, they are more likely to be supported across browsers
and assistive technologies.
For native HTML elements, it is not necessary to use WAI-ARIA.
For an HTML <form> element for instance, there is no need to
include role="form" with the element. There are a few
exceptions to this rule, however. For some of the newer HTML5
elements, like <nav> and <main> for instance, it does not hurt
to include the WAI-ARIA equivalent role="navigation" and
role="main" in these elements for the time being, to
accommodate some of the inconsistent support for these elements
across browsers and ATs. HTML validators will still give you
warnings about the redundant roles, but you can safely ignore these.
You should also be careful when using WAI-ARIA with HTML
elements that already have semantics. For example, if you use <h3
role="button">something</h3> , the semantics associated
with the heading will be overridden, thus, potentially breaking the
structure of a document. In a case like this, a better approach would
be to wrap the heading in a <div> then assign role="button"
to the <div> to preserve the structural semantics of the heading,
as seen in the examples below.

58 | What is WAI-ARIA?
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=259

What is WAI-ARIA? | 59
Roles, States, and Properties
The semantics described earlier are created by adding roles, states,
and properties to HTML elements.

Roles

W3C definition of roles

“Main indicator of type. This semantic association

allows tools to present and support interaction with the
object in a manner that is consistent with user
expectations about other objects of that type.”

Source: W3C

Examples of roles include menu, alert, banner, tree, tabpanel,

textbox, and so on. Once assigned to an element, roles must not
change over time or with user input. If, for instance, you wanted
to change from a “menubar” while viewing in full screen mode to a
toggle “menu” when viewed on a mobile device, the entire block of
markup would change, rather than switching menubar for menu.
Roles are categorized into six groupings. Here are the groups with
a few examples of each type:

• Abstract role (not to be used by authors in content, the base

for the WAI-ARIA ontology)
• Widget roles (e.g., button, link, menuitem)
• Document structure roles (e.g., article, feed, list, table)

60 | Roles, States, and Properties

 • Landmark roles (e.g., banner, navigation, main, complementary)
• Live region roles (e.g., alert, log, timer)
• Window roles (e.g., alertdialog, dialog)

Roles are typically added to HTML elements using the role attribute
as follows. In the example below, an unordered list is given a role
of menubar . Typically, this is used when creating a horizontal
navigation bar across the top of a user interface. Each list item is
given a role of menuitem .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=267

Suggested Reading: Here is the full list of roles in WAI-ARIA

1.1.

States

W3C definition of states

“A state is a dynamic property expressing

characteristics of an object that may change in response
to user action or automated processes. States do not
affect the essential nature of the object, but represent

Roles, States, and Properties | 61

 data associated with the object or user interaction
possibilities. See: clarification of states versus
properties.”

Source: W3C

States are used along with roles, typically, to define its functional
status. States are much like properties, though they typically change
while an application or widget is being used (e.g., aria-checked
changes between true and false). Properties typically do not change
(e.g., aria-labelledby keeps the same value). States and
properties are all “aria-” prefixed, unlike roles.
Here are a few examples of states:

• aria-busy
• aria-checked
• aria-expanded
• aria-disabled
• aria-hidden

Properties

W3C definition of properties

“Attributes that are essential to the nature of a

given object, or that represent a data value associated
with the object. A change of a property may significantly

62 | Roles, States, and Properties

 impact the meaning or presentation of an object.
Certain properties (for example, aria-multiline) are less
likely to change than states, but note that the frequency
of change difference is not a rule. A few properties, such
as aria-activedescendant, aria-valuenow, and aria-
valuetext are expected to change often. See clarification
of states versus properties.”

Source: W3C

Properties, as mentioned above, are much like states in how they

are used along with roles. However, unlike states that change,
properties tend to remain the same (though this is not a rule).
Intuitively, you may notice the changing nature of states listed
above, and the static nature of properties listed below.
Here are a few examples of properties:

• aria-describedby
• aria-atomic
• aria-autocomplete
• aria-colcount
• aria-colspan
• aria-controls

Suggested Reading: See the WAI-ARIA Specification for a

full list of states and properties.

Roles, States, and Properties | 63

Static vs. Dynamic
WAI-ARIA
Even if you don’t use JavaScript, there is a good amount you can
do with static WAI-ARIA to improve the accessibility of a website or
web application. You may have already gathered from the discussion
of states and properties that some WAI-ARIA can be written right
into the HTML of a web page (e.g., properties and landmarks).
Others need to be dynamically updated based on user input or
context (e.g., states and some properties).
Some of the static WAI-ARIA attributes you are likely to use are
listed below, with their descriptions from W3C.

Global Static Properties

• aria-describedby: Identifies the element (or elements) that

describes the object.
• aria-labelledby: Identifies the element (or elements) that labels
the current element.
• aria-label: Defines a string value that labels the current
element.
• aria-controls: Identifies the element (or elements) whose
contents or presence are controlled by the current element.
• aria-owns: Identifies an element (or elements) in order to
define a visual, functional, or contextual parent/child
relationship between DOM elements where the DOM
hierarchy cannot be used to represent the relationship.
• aria-details: Identifies the element that provides a detailed,
extended description for the object.

64 | Static vs. Dynamic WAI-ARIA

Below is an example of some of these attributes in action. Though
this example would need some scripting to handle the submenu
opening and closing, and dynamically updating aria-expanded to
false when the submenu is closed, and update the active element
referenced in aria-activedescendant , you can get an idea of
the semantics that are being applied to make the nested list
announce itself as a menu. Watch or listen to the screen reader
output in the video that follows the code box below to understand
how the WAI-ARIA attributes are read. Examine the code in the code
box to understand what WAI-ARIA is being used to produce that
output.

Static vs. Dynamic WAI-ARIA | 65

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=272

How Does the Above Markup Work?

1. Navigating with the Tab key, focus first goes to the

"menu_container" div, which is made keyboard focusable
with the tabindex="0" attribute.

66 | Static vs. Dynamic WAI-ARIA

2. There the screen reader reads the content of the “chooser” div,
identified by aria-details , describing what the menu is
used for. This div is hidden from view but available to screen
readers. This div could be made visible to make it available for
everyone.
3. Next, the “offerings” UL receives focus, also made focusable
with tabindex="0" .
4. There, the screen reader reads the content of the “navhowto”
div, identified by aria-describedby , explaining how to
navigate the menu. This div is hidden from view for most users.
5. Next, using the Arrow keys as instructed by the “navhowto” div,
the ‘Home’ menuitem takes focus, announcing “menubar
expanded with submenu, Home, menu”. Probably a little more
verbose in this case than it needs to be, but that’s how
ChromeVox handles menu items.
6. Using the Down Arrow key, focus is moved to the “Courses”
menu item, announcing “Courses, menu expanded with
submenu.” The aria-haspopup attribute is what causes a
screen reader to announce a submenu.
aria-expanded="true" causes the screen reader to
announce that the menu is expanded.
7. Using the Down Arrow, focus moves into the submenu,
announcing “Menu with two items, Economics, menuitem 1 of
two.” The submenu is announced as a menu of its own,
identified by adding role="menu" to the UL containing the
two submenu items.
8. Finally, using the Down Arrow, the screen reader announces
“Computer Science, menuitem two of two.”

Here’s a video that shows how ChromeVox would read out the menu
described above:
Video: Example Menu with WAI-ARIA (0:33)

Static vs. Dynamic WAI-ARIA | 67

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=272

Most of the WAI-ARIA elements described in the above series of

steps can be used statically by typing the attributes right into the
HTML. The aria-activedescendant would typically be
dynamically updated with script as the menuitems are selected.
The aria-expanded would also be updated dynamically
switching between true and false when the submenu is toggled
opened or closed.
Here are some more static WAI-ARIA attributes, which we’ll look
at in a little more detail later in the book.

Widget Static Attributes

• aria-haspopup: Indicates the availability and type of

68 | Static vs. Dynamic WAI-ARIA

 interactive popup element, such as menu or dialog, that can be
triggered by an element.
• aria-modal: Indicates whether an element is modal when
displayed
• aria-readonly: Indicates that the element is not editable but is
otherwise operable.
• aria-required: Indicates that user input is required on the
element before a form may be submitted.

Live Static Regions

• aria-live: Indicates that an element will be updated and

describes the types of updates the user agents, assistive
technologies, and user can expect from the live region.
• aria-atomic: Indicates whether assistive technologies will
present all, or only parts of, the changed region based on the
change notifications defined by the aria-relevant attribute.
• aria-relevant: Indicates what notifications the user agent will
trigger when the accessibility tree within a live region is
modified.

Toolkit: For a full list of roles, see section 1 in the The ARIA
Role Matrices.

Static vs. Dynamic WAI-ARIA | 69

Browser and Screen Reader
Support for WAI-ARIA
Because WAI-ARIA is relatively new, its support across browsers and
assistive technologies is still somewhat inconsistent. That should
not, however, discourage you from using it. Be aware that
workarounds may be needed in some cases, at least for the short
term as browsers and assistive technologies progress to implement
support for the full WAI-ARIA specification.
For now, it is advisable to test WAI-ARIA implementations across
multiple browsers and screen readers.
Look over the following references and add them to your Toolkit.

Toolkit:

• WAI-ARIA Screen Reader Compatibility (Dec 27, 2017)

Note: This resource does not include ChromeVox.
• WAI-ARIA Browser Compatibility
• ARIA Alert Support
• User Agent Support Notes for ARIA Techniques

70 | Browser and Screen Reader

Support for WAI-ARIA
Graceful Degradation vs.
Progressive Enhancement
Given the range of support for WAI-ARIA across current screen
readers and browsers, strategies like graceful degradation and
progressive enhancement are useful for accommodating varying
implementations and ensuring that tools developed with WAI-ARIA
are accessible regardless of support.
Depending on your situation, one development method may be
preferable over the other, though in general progressive
enhancement is preferred over graceful degradation. That is,
creating base functionality that works for everyone is preferred,
rather than providing enhancements when they are supported by
the browser and/or assistive technology. Graceful degradation, on
the other hand, starts with the enhancement, then provides
alternatives where the enhancements are not supported. While they
may sound equivalent, the latter typically requires less effort, even
though it is more of a Band-Aid solution to correct an
incompatibility. The former takes a little more effort and is more
about providing enhancements when they are supported while
always providing a base functionality that works for everyone.

Definitions

In his article, “Graceful degradation versus progressive

enhancement,” Christian Heilman provides some useful definitions
that help distinguish between the two methods:

Graceful Degradation vs. Progressive

Enhancement | 71
 “Graceful degradation – Providing an alternative
version of your functionality or making the user aware
of shortcomings of a product as a safety measure to
ensure that the product is usable.”

“Progressive enhancement – Starting with a baseline

of usable functionality, then increasing the richness of
the user experience step by step by testing for support
for enhancements before applying them.”

“Degrading gracefully means looking back whereas enhancing

progressively means looking forward whilst keeping your feet on
firm ground.”

Suggested Reading: These definitions come from: Graceful

degradation versus progressive enhancement (Christian
Heilman, CC-BY NC-SA).

When to Use Which Method with WAI-ARIA

Though progressive enhancement and graceful degradation are

development methods that might be followed on any web project,
here, we talk about them as they relate to the use of WAI-ARIA.
Support for WAI-ARIA is improving constantly, but there are still
many inconsistencies between browsers and assistive technologies.
And there will still be those using older assistive technologies that

72 | Graceful Degradation vs. Progressive Enhancement

were around before WAI-ARIA support was added. Because assistive
technologies tend to be expensive, users tend to upgrade less often,
thus it is important to support technologies that may be five years
old or somewhat older.
Browsers, on the other hand, are typically free, and readily
available. However, that does not necessarily mean developers can
rely on users having the latest or even a current browser. It is
not uncommon, particularly in large organizations, to restrict
employees’ ability to upgrade their own systems.
A simple example of progressive enhancement (though it could
also be seen as graceful degradation) is in within–web page
navigation for screen reader and keyboard-only users. Before the
advent of WAI-ARIA landmarks, the way to provide this within-
page navigation was to provide bypass links, which would typically
be located at the top left of the page. These bypass links lead to
strategically placed anchors, often next to navigation elements and
at the top of the main content area. These links are standard HTML
and will work for everyone. WAI-ARIA landmarks are relatively new,
though support for them in current browsers and assistive
technologies is good. But, given some users will be using older
technologies, at least for the short term, it is advisable to provide
landmarks as an enhancement and continue using bypass links to
ensure there is always a way to navigate effectively through web
content.
Similarly, when using the newer HTML elements that may not be
supported by current assistive technologies, it is a good idea to use
redundant roles, at least in the short term. For example, <nav>
and <main> are new HTML elements, which are supposed to be
equivalent to the navigation and main WAI-ARIA roles. However, not
all ATs support the new tags at present. Thus, it’s advisable to use
redundant roles with these elements, as seen in the markup below,
even though HTML validators will flag them as a warning.

Graceful Degradation vs. Progressive Enhancement | 73

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=275

74 | Graceful Degradation vs. Progressive Enhancement

Validating WAI-ARIA
There are a number of tools that can be used to validate WAI-ARIA
to ensure it is being used correctly. Watch the following video for a
quick look at WAI-ARIA validation with Lighthouse and aXe. Install
these tools in your browser, so you have them available for testing
as you complete the activities in the coming chapters.
Video: WAI-ARIA Validation

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=281

Toolkit:

Validating WAI-ARIA | 75
 Web-Based Validator

• W3C HTML Validator (validates WAI-ARIA as part of

HTML5)

Chrome

• Chrome Developer Tools (comes with Chrome)

• Lighthouse (extends Chrome Developer Tools with an
Audit tab)
• ARIA Validator
• aXe (for Chrome)

Firefox

• aXe (for Firefox)

76 | Validating WAI-ARIA
WAI-ARIA Taxonomy
In addition to the full list of WAI-ARIA attributes in the specification,
the visual presentation of that list in the WAI-ARIA taxonomy can be
helpful in understanding the relationships between elements. This
image can also help those who are visual learners to see how WAI-
ARIA is organized. Click on the thumbnail below to open the full
visual taxonomy.

Figure: WAI-
ARIA
taxonomy
thumbnail.
Click to open
full-sized
image.

Also, see the SVG version of the WAI-ARIA taxonomy

A UML-XMLversion and an RDF version are also available to
import into systems that support those formats.

Suggested Reading: A representation or the WAI-ARIA

taxonomy as a cheat sheet.

WAI-ARIA Taxonomy | 77
Activity 3: WAI-ARIA
Scavenger Hunt

WAI-ARIA Scavenger Hunt

The overall goal of this book is to provide the tools and knowledge
needed to make web interactivity accessible to screen reader users.
In this activity, you will use ChromeVox and code review to identify
WAI-ARIA used throughout the Web Accessibility Auditing
Showcase home page.

Requirements

Although we have only touched on the details of WAI-ARIA, in this

activity, you will be spending some time examining the homepage
of the Web Accessibility Auditing Showcase website. Use a
combination of the following to determine how the WAI-ARIA
elements are being used:

• Test with ChromeVox to hear what WAI-ARIA sounds like with

a screen reader.
• Review the source code.

78 | Activity 3: WAI-ARIA Scavenger

Hunt
For full marks on this activity, list at least five static and five
dynamic WAI-ARIA enabled elements in your answer. Include a brief
description for each. Here’s a few made-up examples of what you
might report in your findings:

• aria-describedby : used in the outer div of the side menu,

to announce instructions on how the side menu works with a
keyboard
• tabindex="0" : used to give keyboard access to the custom
buttons in the User Survey
• role="menu" : used to make the main navigation list appear
as a menu to screen readers

Finally, here is the Web Accessibility Auditing Showcase website.

Review only the home page.

Key Point: There is static and dynamic WAI-ARIA used in this

page. You may View Source to find any static WAI-ARIA being
used. Use your browser’s Inspect tool to find dynamic WAI-
ARIA. Interact with the site to produce changes to the
dynamic WAI-ARIA, and note those changes.

Note: Not all ARIA-related markup starts with the “aria-” prefix.
Scan through the WAI-ARIA documentation introduced in this unit
for a listing of all potential WAI-ARIA markup you might come
across. Also, not all accessibility enhancements are WAI-ARIA. For
example, alt is an accessibility feature of the HTML img element.
You can mention these other accessibility features; however, they
will not count toward your mark on this activity.

Activity 3: WAI-ARIA Scavenger Hunt | 79

Grading Rubric

Criteria Points
At least five instances of static WAI-ARIA being used in the page 5.0
are listed. pts
At least five instances of dynamic WAI-ARIA being used in the 5.0
page are listed. pts

Total Points: 10.0

80 | Activity 3: WAI-ARIA Scavenger Hunt

Self-Test 2

Answer the following questions to test your understanding of key

lessons in this unit.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=289

Self-Test 2 | 81
3. BASIC WAI-ARIA

3. Basic WAI-ARIA | 83
Objectives and Activities

Objectives

By the end of this unit, you will be able to:

• Identify WAI-ARIA landmarks

• Describe common static roles
• Create accessible alerts and feedback
• Use WAI-ARIA to add keyboard access
• Identify when and where to use WAI-ARIA application and
presentation roles
• Use live regions for live updating information

Activities

• Update the landmarks book file with appropriate landmarks

• Provide live alerts for screen readers when feedback or error
messages are presented

Objectives and Activities | 85

WAI-ARIA Landmarks
WAI-ARIA landmarks are used to define regions on a web page.
They provide a means for assistive technology users to effectively
navigate the various areas of a page. WAI-ARIA landmarks should be
used with other means of within-page navigation, such as bypass
links and page headings. These two latter means of navigating have
been around for much longer, and many will continue to use these
elements as their primary method of moving around within a web
page.
There are eight landmark roles.
Follow the links below to read about each type of landmark:

• banner
• complementary
• contentinfo
• form
• main
• navigation
• region
• search

In the following short video, you will see how ChromeVox interacts
with landmarked regions for the next activity coming up in this unit.
Use it as a model for implementing your own landmarks. Aim to have
your activity submission operate the same as it does in the video.
Video: WAI-ARIA Landmarks Demo (1:07)

86 | WAI-ARIA Landmarks
 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=303

To help visualize landmarked regions, the figure below presents

well-defined areas on the page, each of which serves a different
purpose. Banner areas, the element that contains the content of
each banner region, would be assigned role="banner" . The
menu on the left would have its container assigned
role="navigation" , as would other navigation bars or menus if
they were present. The main content area, assigned role="main" ,
is where the primary content of the page appears. There should only
be one main region. The region on the right containing secondary
information, assigned role="complementary" , is where you
might find advertising or related resources. And, finally, the
container around the footer area would be assigned
role="contentinfo" . This is where details such as copyright, a
privacy statement, contact information, etc., would be located.
Websites may be laid out in a multitude of ways; this particular

WAI-ARIA Landmarks | 87
layout is just an example. The landmarks assigned to any given
region should reflect the function of that particular region,
regardless of where it might appear on the page. If advertising were
spread across a region at the bottom of the page, for example, then
that region would be assigned role="complementary" .
Example of landmarked regions of a web page:

Custom Regions

While most of the landmarks are relatively self-explanatory in terms

of what they should contain, role="region" needs some
explanation. This landmark role can be used to contain specific
information that is not effectively described by one of the other

88 | WAI-ARIA Landmarks
landmark roles and is important enough that a user might want to
navigate directly to that area of the page. When it is used, it must
be accompanied by aria-label or aria-labelledby if there is
an existing element on the page that describes the region (such as a
heading).
For example, you may want to define a specific area on each
page where contact information or a contact form is located. The
following markup might be used to define a “contact region.”

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=303

Other Considerations When Using Landmarks

• The whole page defined in regions: When landmarks are used,

it is considered best practice to contain all information
presented on a page within a region, so no information is
orphaned outside the defined regions.
• Duplicate roles: For landmarks that may be used for multiple
regions, such as role="navigation" , these regions should
be distinguished from one another. For instance, use aria-
label or aria-labelledby to describe a “main
navigation” bar and a “content menu.” Both are considered
navigation features, even though they serve different purposes.

Suggested Reading:

WAI-ARIA Landmarks | 89
 • Using ARIA landmarks to identify regions of a page
• Page Regions (WAI Web Accessibility Tutorials)
• ARIA Landmarks Example

90 | WAI-ARIA Landmarks
Common Static WAI-ARIA
Much of the WAI-ARIA introduced so far is static. That is, it can
be written directly into HTML elements as attributes, their values
typically do not change, and they do not require scripting to control
their behaviour. Landmarks and roles, for example, are all static.
Anyone who knows how to read and write HTML can make use of
these attributes by simply adding them to HTML elements. WAI-
ARIA properties are also typically static, though not always.
As discussed earlier, static WAI-ARIA often consists of properties
given to define specific characteristics of an HTML element that
has a particular functional role. For example, a nested list may be
defined as a menu using role="menubar" to define the top-level
list and role="menu" to define sublists.
List items in the top-level list that have a nested sublist would
be given the attribute aria-haspopup="true" (or aria-
haspopup="menu" ). Thus, when encountered by assistive
technology, a list item with this attribute will announce that a
submenu is present (e.g., “menu with submenu” when using
ChromeVox).

Try This: Using ChromeVox, navigate through the menu bar

widget example below, created by Hans Hillen at the Paciello
Group, to hear how submenus are announced. Open this
demo in a new window.

Frequently Used WAI-ARIA Attributes

You have already been introduced to a few static attributes. Those

and a handful of others you are likely to use regularly are listed

Common Static WAI-ARIA | 91

here. This is not a full list. Follow the links and read through their
descriptions.

• aria-describedby
• aria-labelledby
• aria-label
• aria-required
• aria-controls
• aria-details
• aria-haspopup
• aria-live
• aria-owns
• aria-relevant
• aria-roledescription

92 | Common Static WAI-ARIA

WAI-ARIA Alert and
Message Dialogs
Providing feedback after a user completes an action is a critical
accessibility feature. Feedback can be an error message when
something has gone wrong. Additionally, it can be a confirmation
or warning, after which a user has to make a decision before
proceeding. Or, it could be completion feedback that is presented
after a particular action has occurred to indicate it was successful.
The latter is often overlooked by developers. However, for people
using a screen reader, notification that an action was successful
can be as important as providing error messages. When completion
feedback is provided, screen reader users do not need to search
through the content of the screen to be sure the action they just
completed was successful — the process can be quite time-
consuming.
In each type of feedback, it is critical that messages be easy
to access. The best strategy for making feedback accessible is to
use the WAI-ARIA alert or alert-dialog roles. These are both types
of live regions. When the content of the container element with
role="alert" changes, the content that appears is automatically
read aloud by screen readers. A WAI-ARIA alert has an implicit
aria-live="assertive" and aria-atomic="true" (to be
covered in more detail in the section on live regions). This means
that, when the message appears, it will interrupt whatever the
screen reader is in the middle of reading, and the entire content of
the element will be read, as opposed to just the new content added
(i.e., aria-atomic="false" ).

Try This: In the following example of a WAI-ARIA alert, start

ChromeVox, then press the “Say Something” button to hear

WAI-ARIA Alert and Message

Dialogs | 93
 how ChromeVox handles the message that appears. Examine
the script and HTML below to see how it was done.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=308

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=308

alert vs. alertdialog

Error, warning, and completion feedback will typically be created

with role="alert" , while confirmation feedback will often use
role="alertdialog" . Use role="alert" when no user input

94 | WAI-ARIA Alert and Message Dialogs

is needed. Use role="alertdialog" when user input is
expected, with focus sent to the dialog. At least one element in the
dialog must be focusable when using role="alertdialog" .
Watch and listen to the following video to understand how
ChromeVox handles WAI-ARIA alerts.
Video: WAI-ARIA Alerts (1:09)

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=308

Suggested Reading: Using ARIA role=”alert” or Live Regions

to Identify Errors

WAI-ARIA Alert and Message Dialogs | 95

Modal Dialogs

Modal dialogs interrupt users and require an action. They are

appropriate when users’ attention needs to be directed toward
important information.
Modal dialogs are defined using role="alertdialog" and
aria-modal="true" . Be aware what WAI-ARIA is used for
modals, and be aware that when a modal dialog is displayed, focus
must be sent to the dialog, and it must remain in the dialog until
whatever interaction is complete (e.g., clicking the confirmation
button) and the dialog closes. When the dialog closes, focus must be
returned to the location from where the dialog was opened.

Dialogs

Dialogs are used like modal dialogs are, except it is still possible to
interact with the other content of the page. These are defined using
role="dialog" .

Suggested Reading:

• Using the Dialog Role (Mozilla)

• Modal and Nonmodal Dialogs: When (and When Not) to
Use Them

96 | WAI-ARIA Alert and Message Dialogs

Using Tabindex
As you may know, the HTML tabindex attribute is a way to order
the path the cursor takes as users use the Tab key to navigate
through a website or web application. In general, however, you want
to avoid using tabindex in this way, particularly when it disrupts the
default tab order, which may end up creating confusion when the
cursor does not follow an expected path (i.e., left to right, top to
bottom). That’s not to say don’t ever use them, but be careful.
With HTML5 and the introduction of WAI-ARIA, tabindex="0"
is added to make it possible for developers to add keyboard
accessibility to an element that would not normally have keyboard
functionality. For example, it might be used to make a <div>
focusable. Likewise, tabindex="-1" is added to remove keyboard
accessibility from an element. The two are likely to be used with
scripting to dynamically add and remove keyboard access to
elements when focus needs to be strategically placed within a
widget or web application. When the tabindex attribute is used
in this way, it is referred to as a roving tabindex .

Try This: Take a look at the tab panels throughout the

Showcase site to see how the tabs in the tabpanels toggle
between values “-1” and “0” to control which tab has focus,
using your browser’s Inspect feature. This demo works better
on a wide screen, before responsiveness kicks in. Either
reduce the zoom level, or drag your browser window wider
until the menu appears at the side, instead of above the
content.
Open demo in a new window.

You can also use tabindex="0" in a static way when context is

needed to describe how to use a menu, for instance. A <div> can

Using Tabindex | 97
be wrapped around the menu, given tabindex="0" to make it
focusable, so, when a user navigates to the <div> , it announces
instructions for using the keyboard to navigate within the menu.
The following example demonstrates using tabindex , along with
aria-label , to provide context information. If you navigate
through the Showcase site above with ChromeVox, you’ll notice this
strategy with the side menu, announcing how to operate the menu
with a keyboard.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=310

98 | Using Tabindex
Keyboard Interaction
Keyboard access is perhaps the most important accessibility feature
that can go into a website, widget, or web application. However, it is
often overlooked by developers, who are typically mouse users and
may not have keyboard usability as a part of their testing regimen.
People who are blind are typically unable to use a mouse, so any
feature that relies on a mouse alone to function will likely be
inaccessible to them. Fortunately, it is relatively easy to include
keyboard access. It’s more a matter of remembering to add it when
mouse access is added.
The following is a simple example of including both mouse and
keyboard events when defining interaction for a widget or web
application. Examine the JavaScript to see how mouse and keyboard
events are handled, then under the Result tab, try operating the
button with a keyboard and mouse while using ChromeVox. How
you go about implementing both mouse and keyboard doesn’t really
matter, as long as it is possible to interact with both.
You may notice some inconsistencies in ChromeVox support for
the live region used to present the messages in the example, more
specifically the aria-atomic attribute. Live regions will be
covered more thoroughly later in this unit.

Keyboard Interaction | 99
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=312

Predictability, Consistency, and Convention

Here we will introduce the basics of keyboard interaction, and we’ll

go into greater detail when we start looking more closely at
particular widgets and design patterns as they are introduced in the
chapters that follow.
As the heading for this section suggests, keyboard interaction
needs to be predictable, consistent, and should follow convention.
That is, users should have a good idea of the path that the focus
will follow (predictable). When navigating with the Tab key, that
path should be the same throughout an application or website
(consistent). Finally, it should be like it is in other applications,
websites, or operating systems (convention).

100 | Keyboard Interaction

 Suggested Reading: Developing a Keyboard Interface

Take for example a combo box (aka, a select menu). Regardless of

the operating system being used, combo boxes work the same way.
If you are developing a widget out of divs that function like a combo
box, it should operate like a standard HTML combo box.
Conventional keyboard interaction for a combo box:

• Tab to navigate into the combo box

• While in focus, tab to navigate beyond the combo box
• While in focus, Shift + Tab to navigate before the combo box
• While in focus, Down Arrow to show next option
• While in focus, Up Arrow to show previous option
• While in focus, Alt + Down Arrow to display options list
• While options list is open, Alt + Up Arrow to close the options
list
• While options list is open, Esc to close the options list and
return to default state
• While an option is in focus, Enter to select that option

When developing a custom combobox — typically, a text box and

list of options — a grid, a tree, or a dialog are combined into a
functional unit that should operate like a standard HTML select
menu. Functionality in addition to that described above may be
added to the custom combobox, e.g., to add autocompletion. As
the user types letters into the text box, options beginning with the
string type are displayed below as a list or the first option with
those letters is displayed inline in the text box.

Try This: Using your keyboard, try the keyboard interactions

described above to confirm whether or not the combobox
functions in a conventional way. Try it with a few different

Keyboard Interaction | 101

 browsers and notice any variations in how different browsers
handle combobox interaction.

An interactive or media element has been

excluded from this version of the text. You can
view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=312

Suggested Reading: For detailed discussion of combobox

design patterns, see: WAI-ARIA Authoring Practices 1.1
(Combo Boxes)

Toolkit: For a list of design patterns, and keyboard interaction

conventions, review the following widget development best
practices. Scan for now. They will be covered more
thoroughly in later chapters of the book.

• Combobox
• Grid
• Listbox
• Menu or menu bar
• Radiogroup
• Tabs
• Toolbar
• Tree View

102 | Keyboard Interaction

Application and Presentation
Roles
The application and presentation roles in WAI-ARIA change the way
assistive technologies interact with web content. Both have “use
with caution” warnings. Their use and where and when to use them
are described here.

Application Role

The application role is used when there is not a corresponding

widget interaction pattern available to provide semantics for a
custom widget.
Imagine, for instance, a file manager application embedded in a
web page, which does not have widget roles specifically defined. It
may have many of the functions a typical file manager might have on
a Windows, Mac, or Linux system. It might have the typical File, Edit,
and View menus that most applications have, including browsers.
Those menus in the file manager should function like these same
menus in other applications. When the application role is used in
a container containing the embedded file manager, keystrokes are
intercepted and repurposed to operate the file manager, instead of
the browser and the assistive technology.
When in the file manager application, this behaviour may be
desirable. But, defined with the application role, all of the standard
screen reader shortcut keys are also disabled, so the user is no
longer able to navigate the pages by headings, or landmarks, for
instance, while inside the application. This may be fine in such a
case because the screen reader user will likely temporarily want

Application and Presentation

Roles | 103
shortcut keys to file manager functions, and not those of the
browser or screen reader.
If, however, the application role is used to contain a carousel
widget, for example, then browser and assistive technology
functionality may be unnecessarily disabled, potentially creating
barriers. A carousel widget typically has limited functionality. For
example, carousels may contain scripted Arrow keys to move back
and forth between slides, between headings within each slide for
added structure, or link to another section of the site presented in a
slide. In such cases, screen reader users would be unable to navigate
through the slides by listing headings or links, using their screen
reader’s default heading and link list functionality. By removing the
application role, the scripted next/previous link, as well as the
heading and the links could be used to navigate the carousel.
The bottom line is to use the application role carefully. Be sure it
is not creating more barriers than it is intended to prevent.

Presentation Role

Much like the application role disables default keyboard

functionality, the presentation role (and its synonym
role="none" ), theoretically, removes the default semantics from
children of the element it applies to.
So, for instance, if you have a list with role="presentation" ,
it should not announce as a list, and its list items should not
announce as list items. However, nested lists within those
suppressed list items will announce as usual.
There are a couple of intended exceptions where the presentation
role will not remove default semantics:

• When role="presentation" is not applied to elements

that have tab focus, such as links, form elements, and elements
that have tabindex defined, or

104 | Application and Presentation Roles

 • Where an element has been modified with any of the 21 global
states or properties

Where role="presentation" is applied to a parent element,

all of its child elements should inherit that role, but not all of its
grandchildren. For example, if <ul role="presentation"> is
used then the semantics for each of its <li> elements will be
ignored. But, if an <li> contains a sublist, that list would be
announced as usual.
It should be noted that current support for the presentation role
is spotty across browsers and assistive technologies, and you are
likely to find it not all that useful if you’re trying to develop with
cross browser compatibility. Typically, tables, images, and headings
are affected by the presentation role, while other elements like
lists, forms, and links are not, or only partially affected. If you are
trying to hide elements completely from screen readers, you might
consider using either aria-hidden or CSS display:none .
Three common uses for role="presentation" include:

1. Hiding a decorative image. It is equivalent to giving the image

null alt text.
2. Suppressing table semantics for tables used for layout in
circumstances where the table semantics do not convey
meaningful relationships.
3. Eliminating semantics of intervening orphan elements in the
structure of a composite widget, such as a tablist, menu, or
tree as demonstrated in the example above.

Source: WAI-ARIA Authoring Best Practices

There are also a number of WAI-ARIA roles that act like the
presentation role, and these suppress the default semantics for the
elements to which they are applied. For instance, if a tablist
is created from a <ul> , and role="tab" is applied to each of
the list items within that <ul> , their default listitem role will

Application and Presentation Roles | 105

be replaced with the tab role, without the need to set them as
presentational.
The following JSFiddle examples have been created for cross
browser testing of the presentation role. Navigate through each
example with ChromeVox + Chrome. If you have them available, also
navigate them with JAWS + IE and NVDA + FF to understand the
varied support for the presentation role. Below, the fiddle is a listing
of support for current versions of these screen readers.

106 | Application and Presentation Roles

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=314

Application and Presentation Roles | 107

Screen Reader Output from the Above Demo

NVDA (2018.1.1) + Edge (41.16299.248.0)

By keyboard, only the link is announced. Mouseover, though, and all

elements are announced.

• Link: not announced

• List: not announced or keyboard focusable
• Headings: not announced or keyboard focusable
• Table: not announced or keyboard focusable
• Image: not announced or keyboard focusable
• Form: “Combo box opt three collapsed”

NVDA (2018.1.1) + FireFox (59.0.2)

• Link: announces as usual

• List: values announced but not bullets or the list itself
• Headings: announce as usual
• Table: not announced.
• Image: not announced
• Form: announces opts but not the combobox

JAWS (18) + Edge (41.16299.248.0)

• Link: focusable, but not announced

• List: not focusable, not announced
• Headings: does not announce first heading, but does announce
second heading
• Table: not announced
• Image: not announced

108 | Application and Presentation Roles

 • Form: not focusable, not announced

ChromeVox (53.0.2784.5)

• Link: focusable, but not read (using Tab key) Announces as

usual when using CVOX + Arrows
• List: Skips over list (using Arrow key) except when link receives
focus first, then Arrow key announces the numbers in the list.
Announces numbers but not as a list when using CVOX +
Arrows
• Headings: Does not announce the first heading, but does
announce the second (Arrows and CVOX+Arrows)
• Table: not announced.
• Image: reads alt text “Ryerson Chang School” both Arrow and
CVOX + Arrow
• Form: focusable, not announced (using Tab key), Arrow keys
announces “Combobox. Opt 3, 3 of 3.”

Suggested Reading:

• WAI-ARIA Presentation Role

• PowerMapper: Screen Reader Compatibility (Updated
Dec 2017)
• Mozilla: ARIA Test Cases

Application and Presentation Roles | 109

Live Regions
Live regions are used to present changes in web content that occur
after a web page has loaded. Typical uses include presenting news
feeds, feedback and error messages, or live chat output to screen
readers, which would otherwise not know about this content
changing or being added to a web page already rendered. Live
regions can also be used to announce feedback and error messages
when a page loads, so screen reader users do not need to search
through a web page to find feedback. It reads automatically when a
page finishes loading.

Types of Live Regions

A typical live region can be created by adding aria-

live="polite" to any element in which content is updated after
a web page has loaded. The “polite” value indicates the priority
of the content being updated. In this case, a screen reader will
wait for a break in its audio output before announcing the change
that occurred. You may also use aria-live="assertive" to
interrupt whatever the screen reader is reading, and instead read
the changed content before continuing. Typically, “assertive” should
be avoided. Only use it in cases where critical information is being
updated, such as an error message or critical feedback.
Normally, aria-live would not be used to present feedback
or error messages, though it is possible. Instead role="alert" ,
introduced earlier, would be used. Using role="alert" creates
an assertive live region that interrupts a screen reader to present
its content. They can be used within rendered content to present
messages without reloading the page, or they can be used after a
page loads, to present the message before any of the other content
on the page is read.

110 | Live Regions

 In addition to the commonly used role="alert" , there are
other less commonly used roles that also act as live regions. These
are:

• role=”log”
• role=”marquee”
• role=”timer”
• role=”status”

Here is the full list of live region attributes:

• aria-live: polite, assertive, off

• aria-relevant: additions, removals, text, all
• aria-atomic: true, false
• aria-busy: true, false
• role=”alert”
• role=”log”
• role=”marquee”
• role=”timer”
• role=”status”

Suggested Reading: More details on these other Live Region

Roles can be found in the WAI-ARIA 1.1 specification.

Care When Using Live Regions

There are a few cases where using a live region ( aria-live ) to

read changing content can create a barrier. Take, for instance, a
carousel that presents a series of panels that rotate at a particular
frequency. It can be helpful to set up a carousel as a live region, so
as each panel slides into view, a screen reader reads the content.
However, this behaviour could present a barrier, interfering with the

Live Regions | 111

screen reader when it is focused elsewhere, reading other content
on the page. If a live region is used with a carousel, it should only
be active when the carousel has focus. While typically a live region
is created as a static WAI-ARIA attribute, in this case, it should be
dynamically added on focus and dynamically removed on blur.
For carousels, it is also important to consider the rate at which
panels rotate, ensuring that screen readers have enough time to
read the content of the panel before rotating on to the next. This
timing can be difficult to predict. It depends on the amount of
content on each panel, which can vary significantly, and the rate at
which users have their reading rate set on their screen reader. One
solution to this issue may be to make the carousel manually rotate
when it has focus so users can proceed to the next panel only when
they are ready.
Another case where live regions can be problematic is with
timers. Timers counting by seconds can essentially render the rest
of the content on a page unusable for a screen reader user. As the
screen reader announces every second, it interrupts the reading of
the other content on a page. Timers that increment each minute, for
instance, would not have this problem.
Other places where live regions may be problematic are with very
active news or Twitter feeds. Though live regions can be useful
for this type of updating content, if there is a constant stream of
updates or updates occur frequently, screen reader users may have
difficulty comprehending other page content with the frequent
interruptions.

Try This: To experience the aggravation of a constantly

updating live region, open ChromeVox and give focus to the
timer below. In this case, the timer is in an iframe, so you can
simply set focus outside the iframe to stop it from reading.
If the timer were embedded in the content of the page itself,
you would not have this option, and the rest of the page would

112 | Live Regions

become unusable with a screen reader. The only option would
be to leave the page.

An interactive or media element has been

excluded from this version of the text. You can
view it online here:

Key Point: Be aware of potential barriers that can be created

when live regions are used with high-frequency content
updates.

Live Regions | 113

Activity 4: WAI-ARIA
Landmarks and Alerts

WAI-ARIA Landmarks and Alerts

Landmarks were added to the WAI-ARIA

specification as a way of providing easy navigation within a web
page for assistive technology users. Prior to landmarks, bypass links
were often used (and still are) that would allow a screen reader user
to jump from the top of a page, typically, to an anchor strategically
placed further down the page. In the first part of this activity you
will add a set of landmark roles to a website user interface (UI).
Live regions were introduced in WAI-ARIA as a way to present
changing content to assistive technology users. Feedback messages
are good candidates for a live region, so the content of a feedback
message is read to the user automatically when it appears without
the need to search the page to determine whether an action
completed successfully or, alternately, if an action produced an
error message. The WAI-ARIA “alert” role is a type of live region
ideal for presenting error or success feedback messages. In Part 2
of this activity, you’ll add role="alert" to the error messages
when the form in the landmarks.html file is submitted with missing
or invalid required fields, and when it is submitted successfully.

114 | Activity 4: WAI-ARIA Landmarks

and Alerts
 In your copy of the book files, open and edit the landmarks.html
file. When you have completed both parts of the activity, commit
the file back to your GitHub Pages repository, or upload it to the
location you have chosen to post your activity files for marking or
submit a GitHack URL.

Requirements

Part 1: Landmarks

Add the appropriate landmark roles to elements within the page. Be

sure all content within the page is contained within a landmarked
region and, depending on the type of content on the page, apply the
correct landmark for that type of content.
When you have added all the appropriate landmarks, test the file
with ChromeVox (keys: Cvox + L + semicolon) to be sure they are all
functioning properly.

Part 2: Live Error and Feedback Messages

The form on the page has three required fields. If you submit the
form without valid input for these fields, an error message is
generated below each field that has invalid input. Add
role="alert" to the first error message, so, when it appears, it
is automatically read by ChromeVox along with sending focus to
the first field in error so it can be corrected. Do the same for the
feedback message that appears when the form is submitted without
errors.
HINT: look in join.lib.js in the book files.

Activity 4: WAI-ARIA Landmarks and Alerts | 115

Grading Rubric

Criteria Points
Content Contained: 2.0
All content is contained within a landmarked region. pts
Correct Landmarks: 3.0
Appropriate landmarks have been used for each region. pts

Messages Announced:
The first Error/Feedback message is announced when the form
is submitted with and without invalid input. When the first 4.0
required field is corrected, the next Error/Feedback message is pts
announced, and so on, so any field with invalid content is read
aloud.
Landmarks Distinguishable:
Landmark regions with the same role are distinguishable from 1.0 pts
each other.
Total Points: 10.0

116 | Activity 4: WAI-ARIA Landmarks and Alerts

Self-Test 3

Answer the following questions to test your understanding of key

lessons in this unit. This quiz is not being marked.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=321

Self-Test 3 | 117
4. INTERACTIVE WAI-ARIA
(BASIC)

4. Interactive WAI-ARIA (Basic) | 119

Objectives and Activities

Objectives

By the end of this unit, you will be able to:

• Identify elements of an accessible suggestion box

• Describe the function of accessible tooltips
• Identify the elements of an accessible progress bar

Activities

• Create the following accessible elements:

◦ Suggestion box
◦ Tooltips
◦ Progress bar

Objectives and Activities | 121

Toggle Buttons (Activity
Example)
The remainder of the book is hands-on. You’ll be taking inaccessible
widgets, like the example of toggle buttons described here, and
making them accessible by adding appropriate WAI-ARIA and
keyboard operability. The toggle buttons widget demonstrated here
is provided as an example for the ten widgets you will be working on
over the next three chapters, describing the Activity Elements you
will find in each exercise.

Activity Element: Following the short introduction to the

widget above, a list of the WAI-ARIA roles, states, and
properties used with the widget are listed.

Roles, states, and properties for toggle buttons

• role="button"
• tabindex="0"
• aria-label="[button name]"
• aria-pressed="[true|false]"

Activity Element: Where available, a Suggested Reading is

included that provides additional information about
accessibility features for the widget being discussed, often
linking to the W3C WAI-ARIA 1.1 Authoring Practice

122 | Toggle Buttons (Activity

Example)
 documentation, or to a similar resource. These readings are
optional but recommended.

Suggested Reading: Read more about buttons in the WAI-

ARIA 1.1 Authoring Practices.

Activity Element: Each widget will have an inaccessible

JSFiddle version provided, like the one below. You can
examine the JavaScript and HTML to observe how the widget
was created. Under the Result tab, view and try out the
widget to see how it functions. CSS is also provided, though
you will not be working with CSS as part of the activities.
In the JSFiddle here, the accessibility elements are included
but commented out so you can see how the code snippets
below have been applied. In the activities that follow, the
accessibility elements will not be present. Your task will be
to apply the code snippets yourself to make the inaccessible
version provided in the book file accessible.
At the top right, you may choose to “Edit in JSFiddle” and
test the code snippets that will be provided below, to
understand how they add accessibility to the widget. You
can start by uncommenting the accessibility elements for the
toggle buttons, and testing the resulting version with
ChromeVox.

The following JSFiddle presents a typical toggle button. Review the

JavaScript and HTML markup. Test the buttons present under the
Result tab with ChromeVox to understand how it functions without
any accessibility features added (if it functions at all). You can work
in JSFiddle itself by clicking “Edit in JSFiddle” and copying the
accessibility/WAI-ARIA code described below to fix the accessibility

Toggle Buttons (Activity Example) | 123

of the toggle buttons, before completing the Activity on the page
that follows (there is no activity that follows in this example case).

Key Point: The code that appears under the JavaScript tab is
not exactly as it appears in the book files. The
$(document.ready{}) function at the top is copied from the
associated HTML file for the widget, and the contents of
ik_util.js have been appended, so the widget will function in
JSFiddle. You will not need to include these in the JavaScript
file from the book files that you will be editing for each
widget.

124 | Toggle Buttons (Activity Example)

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=324

Activity Element: Following the JSFiddle will be a collection

Toggle Buttons (Activity Example) | 125

 of code snippets hosted in PasteBin. These code snippets can
be applied to the code presented in the JSFiddle and applied
to the code in the book files, which you will be submitting for
marking.

Add a tabindex to each button to make them keyboard focusable,

define the role="button" , and add a label with aria-
label="[button name]" and set the default state to “not
pressed” with aria-pressed="false" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=324

Add in equivalent keyboard access where mouse access is provided,

referencing the onActivate() function, described below, with
jQuery .on('keydown') .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:

Set aria-pressed="[true|false]" for buttons when activated

or deactivated to announce the button’s state to screen readers.

126 | Toggle Buttons (Activity Example)

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=324

Adding Keyboard Operability

Keyboard access for the buttons is fairly simple, with no special key
press events needing to be defined.

Activity Element: When the WAI-ARIA 1.1 Authoring

Practices has a set of recommended keyboard interactions,
they will be reproduced here. Widgets will typically follow
the recommended practice, though in some cases keyboard
interaction may vary.

Toggle Buttons (Activity Example) | 127

 Keyboard Interaction for Toggle Buttons

When the button has focus:

• Space: Activates the button.

• Enter: Activates the button.
• Following button activation, focus is set
depending on the type of action the button
performs. For example:

◦ If activating the button opens a dialog, the

focus moves inside the dialog (see dialog
pattern).
◦ If activating the button closes a dialog,
focus typically returns to the button that
opened the dialog unless the function
performed in the dialog context logically
leads to a different element. For example,
activating a cancel button in a dialog returns
focus to the button that opened the dialog.
However, if the dialog were confirming the
action of deleting the page from which it
was opened, the focus would logically move
to a new context.
◦ If activating the button does not dismiss
the current context, then focus typically
remains on the button after activation, e.g.,
an Apply or Recalculate button.
◦ If the button action indicates a context
change, such as move to next step in a

128 | Toggle Buttons (Activity Example)

 wizard or add another search criteria, then
it is often appropriate to move focus to the
starting point for that action.
◦ If the button is activated with a shortcut
key, the focus usually remains in the context
from which the shortcut key was activated.
For example, if Alt + U were assigned to an
“Up” button that moves the currently
focused item in a list one position higher in
the list, pressing Alt + U when the focus is in
the list would not move the focus from the
list.

Source: W3C WAI-ARIA 1.1 Authoring Practices

Activity Element: Though this widget requires no keyboard

interaction beyond that provided in ik_utils.js to handle
space bar and Enter keys, other widgets will have a custom
function provided here that defines possible keyboard
interactions for those widgets. In most cases, that code can
be copied as is into the widget’s JavaScript file.

No added keyboard interaction is required for the toggle buttons

beyond the standard Space bar and Enter key defined in the
ik_utils.js file. Reference to these key events is added to the
onActivate() function.

Toggle Buttons (Activity Example) | 129

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=324

130 | Toggle Buttons (Activity Example)

Accessible Toggle Buttons in Action

Activity Element: Each widget will have a short video of it

interacting with ChromeVox. When completing the activities,
aim to have your activity submission function as presented in
the video.

The buttons are accessed initially with the Tab key, and the Tab key
is used to move between buttons. The Space bar or Enter keys are
used to activate and deactivate buttons. Aim to have the widget you
edit in the associated activity function like that presented in the
video (there is no associated activity for this example).
Video: Accessible Toggle Buttons

Toggle Buttons (Activity Example) | 131

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=324

132 | Toggle Buttons (Activity Example)

Suggestion Boxes
A suggestion box (aka, combo box or autocomplete box) is a type
of selection menu that helps users enter a correct choice. They are
typically made up of a text entry field and a list of choices based on
a number of characters entered into the text field. In the example
provided here, entering a few characters brings up a list of countries
that contain those characters.
Because the text entry field is a standard form text input field,
it will be accessible by default. No additional coding is required to
make it accessible. What needs the most attention is the list of
choices, which needs to announce itself when it appears and needs
to be keyboard navigable.

WAI-ARIA roles, states, and properties used in a

suggestion box

• role=’region’
• aria-live=’polite’
• aria-describedby='[id of instructions div]’

Suggested Reading: For details on constructing accessible

suggestion boxes, refer to: WAI-ARIA Best Practices: Combo
Box.

The following JSFiddle presents a typical suggestion box. Review

the JavaScript and HTML markup, and test the suggestion box
presented under the Result tab with ChromeVox to understand how
it functions without any accessibility features added. You can work

Suggestion Boxes | 133

in JSFiddle itself by clicking “Edit in JSFiddle”, copying the
accessibility/WAI-ARIA code described below to fix the accessibility
of the suggestion box, before completing Activity 5, on the page that
follows.

134 | Suggestion Boxes

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Define some instructions to make it clear there will be suggestions

appearing when text is entered into the text input field.

Suggestion Boxes | 135

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

When the suggestion box receives focus, generate the instructions

for it by adding the notify() function to the onFocus()
function to produce a live region with the instruction text. This
instruction text is then read automatically when a screen reader
encounters the suggestion box text field.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Within the init() function, create a <div> to use as a live

region, adding aria-live="polite" to announce the list usage
instructions defined above when the text field receives focus. Also,
give it a role="region" so it can be found in the landmarks list.

136 | Suggestion Boxes

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Provide additional instructions when the suggestion box is

populated, adding to the getSuggestions() function.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Adding Keyboard Operability

WAI-ARIA best practices defines all recommended suggestion box

keyboard functionality, listed below. In our example, only the
required keyboard events are included.

Suggestion Box Keyboard Interaction

When focus is in the textbox:

Suggestion Boxes | 137

 • Down Arrow: If the popup is available, moves
focus into the popup:

◦ If the autocomplete behaviour

automatically selected a suggestion before
Down Arrow was pressed, focus is placed on
the suggestion following the automatically
selected suggestion.
◦ Otherwise, places focus on the first
focusable element in the popup.

• Up Arrow (Optional): If the popup is available,

places focus on the last focusable element in the
popup.
• Esc: Dismisses the popup if it is visible.
Optionally, clears the textbox.
• Enter: If an autocomplete suggestion is
automatically selected, accepts the suggestion
either by placing the input cursor at the end of the
accepted value in the textbox or by performing a
default action on the value. For example, in a
messaging application, the default action may be
to add the accepted value to a list of message
recipients and then clear the textbox so the user
can add another recipient.
• Printable Characters: Type characters in the
textbox. Note that some implementations may
regard certain characters as invalid and prevent
their input.
• Standard single line text editing keys
appropriate for the device platform (see note
below).

138 | Suggestion Boxes

• Alt+Down Arrow (Optional): If the popup is
available but not displayed, displays the popup
without moving focus.
• Alt+Up Arrow (Optional): If the popup is
displayed:

◦ If the popup contains focus, returns focus

to the textbox.
◦ Closes the popup.

Note: Standard single line text editing keys

appropriate for the device platform:

1. include keys for input, cursor movement,

selection, and text manipulation.
2. Standard key assignments for editing
functions depend on the device operating
system.
3. The most robust approach for providing
text editing functions is to rely on browsers,
which supply them for HTML inputs with
type text and for elements with the
contenteditable HTML attribute.
4. IMPORTANT: Be sure that JavaScript does
not interfere with browser-provided text
editing functions by capturing key events
for the keys used to perform them.

Source: W3C WAI-ARIA 1.1 Best Practices

Suggestion Boxes | 139

The most significant effort in making the suggestion box accessible
is adding keyboard operability. In our case, we’ll add Up and Down
Arrow operability to the list box. Create a switch that captures the
keypress event. If it’s a Down Arrow, select the next item down
in the list. If it’s an Up Arrow, select the previous item. If it’s any
character key, enter the value in the text field. Add this to the
onKeyUp() function, while integrating the existing functionality in
the function into the default for the switch statement.

140 | Suggestion Boxes

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Suggestion Boxes | 141

Accessible Suggestion Box in Action

Watch the following video to see how ChromeVox interacts with

a suggestion box. When the suggestion box receives focus,
instructions are read. When the second letter is typed into the text
field a list of suggestions appears below. Additional instructions are
provided on how to make a selection from the list. Arrow keys are
used to navigate through the suggestions, and the Enter key is used
to select one of them. Aim to have the suggestion box you update in
Activity 5 on the following page operate and announce like the one
in the video.
Video: Accessible Suggest Box

142 | Suggestion Boxes

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=330

Suggestion Boxes | 143

Activity 5: Accessible
Suggestion Box

Accessible Suggestion Box

Based on the Suggestion Box details on

the previous page, apply what you have learned to the associated
book files to make the suggestion box provided accessible.
Files for this activity include:

• /suggest.html
• /assets/ik_suggest.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the suggestion box by applying the highlighted code
to the /assets/ik_suggest.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated suggestion box with ChromeVox to ensure

144 | Activity 5: Accessible

Suggestion Box
each element described in the marking rubric below is functioning
as suggested.

Requirements

Apply your changes and test to be sure your suggestion box

functions as described. Then, submit the URL of your suggest.html
file located on your GitHub site, on the web server you are using to
host your copy of the book files, or a GitHack URL.

Grading Rubric

Criteria Points
Initial Instructions:
2.0 pts
Instructions are provided when the country field receives focus.
Announce Suggestions Present:
The suggestion list is announced when suggestions are 2.0 pts
available.
Suggestion Instructions
1.0 pts
Instructions are provided when suggestions are available.
Keyboard Access: 5.0
A country selection can be made using only the keyboard pts
Total Points: 10.0

Activity 5: Accessible Suggestion Box | 145

Tooltips
A tooltip is typically used to display some information about its
owning element when a user hovers a mouse pointer over or gives
keyboard focus to an element. Tooltips might include a definition
for a word, perhaps full wording for an acronym or abbreviation, or
maybe instructions on how to operate a tool or widget. There are
many possibilities.
Tooltips are an enhancement for the default “title text” standard
with HTML. They provide much more flexibility in the presentation
and types of information that can be presented than a standard title
text tooltip.

WAI-ARIA roles, states, and properties used in a

tooltip

• role="tooltip"
• aria-hidden:[true|false]
• aria-live="polite"
• tabindex = [0|-1]

Suggested Reading: For details on constructing accessible

tooltips, refer to: WAI-ARIA Best Practices: Tooltips.

The following JSFiddle presents a typical tooltip. Review the

JavaScript and HTML markup. Test the tooltip presented under
the Result tab with ChromeVox to understand how it functions
without any accessibility features added. You can work in JSFiddle
by clicking “Edit in JSFiddle”, copying the accessibility/WAI-ARIA

146 | Tooltips
code described below to fix the accessibility of the tooltip before
completing Activity 6 on the page that follows.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Tooltips | 147
The first thing to add to the init() function, where the tooltip
<span> element is defined, are the WAI-ARIA attributes. First,
define the tooltip with role="tooltip" . Hide the tooltip by
default with aria-hidden="true" . Also, add a live region with
aria-live="polite" , so screen readers automatically read the
tooltip when it appears. Note, the WAI-ARIA 1.1 best practices
recommend using aria-describedby within the owning element
to reference the content of a tooltip, which does not announce as
expected with current versions of Chrome. Instead, we use aria-
live , which announces correctly across all current browsers.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Next, add keyboard focus to the element the tooltip belongs to with
tabindex="0" , and add focus to .on('mouseover') , so both
a mouse hover and keyboard focus open the tooltip.

148 | Tooltips
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Also, further down in the owning element’s definition, add aria-

hidden="false" so the hidden-by-default tooltip becomes visible
when the mouse hover or keyboard focus occurs.

An interactive or media element has been excluded from this

version of the text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Also, added here is aria-hidden="true" to be sure the tooltip

is hidden from screen readers, should a mouseout event close the
tooltip, adding it to .on(mouseout) chained to the element
( $elem ) definition.

An interactive or media element has been excluded from this

version of the text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Adding Keyboard Operability

WAI-ARIA best practices defines keyboard interaction for a tooltip

as follows:

Tooltips | 149
 Recommended Keyboard Interaction for
a Tooltip

Tooltip widgets do not receive focus. A hover that

contains focusable elements can be made using a non-
modal dialog.

• Esc: Dismisses the Tooltip.

Note:

1. Focus stays on the triggering element

while the tooltip is displayed.
2. If the tooltip is invoked when the trigger
element receives focus, then it is dismissed
when it no longer has focus (onBlur). If the
tooltip is invoked with mouseIn, then it is
dismissed with mouseOut.

Source: W3C WAI-ARIA Best Practices 1.1

Keyboard operability for a tooltip or, rather, the owning element is

relatively simple. As a keyboard equivalent for the
.on(mouseout) described above, .on(blur) is chained to the
$elem element and within it aria-hidden="true" hides the
tooltip again, if the mouse pointer is not over the element.

An interactive or media element has been excluded from this

150 | Tooltips
version of the text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Also, if the Esc key is used, add aria-hidden="true" to hide the

tooltip, even if the mouse is hovering, or the owning element has
focus.

An interactive or media element has been excluded from this

version of the text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

Accessible Tooltip in Action

Watch the following video to see how ChromeVox interacts with a

tooltip. The Tab key is used to navigate to the first tooltip, which
opens a live region when its content is read aloud. Pressing the Tab
key once again, move focus to the text input field, and a second
tooltip opens and its content is read aloud. Aim to have the tooltips
you update in Activity 6 on the following page operate and
announce like the one in the video.
Video: Accessible Tooltips

Tooltips | 151
 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=336

152 | Tooltips
Activity 6: Accessible
Tooltips

Accessible Tooltips

Based on the Tooltip details on the

previous page, apply what you have learned to the associated book
files to make the tooltips there accessible.
Files for this activity include:

• /tooltip.html
• /assets/ik_tooltip.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the tooltips by applying the highlighted code to the
/assets/ik_tooltip.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated tooltips with ChromeVox to ensure each

Activity 6: Accessible Tooltips | 153

element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to be sure your
tooltips function as described, submit the URL to your tooltip.html
file on your GitHub Pages site, to the file on the web server you are
using to host your copy of the book files, or to a Githack URL.

Grading Rubric

Criteria Points
Tooltips Open:
Tooltips open when their owning element receives keyboard 3.0 pts
focus or mouseover.

Tooltips Read:
Tooltips read aloud when their owning element receives 3.0 pts
keyboard focus or mouseover.

Tooltips Hides:
2.0 pts
Tooltips hide when focus is removed or on mouseout.

Tooltips Escape:
2.0 pts
Tooltips hide when the Esc key is pressed.

Total Points: 10.0

154 | Activity 6: Accessible Tooltips

Progress Bars
Progress bars are typically implemented when a user has to wait for
a process to complete, whether that may be waiting for an upload
to finish, data to be compiled, a report to be generated, or any other
process that takes more than a few seconds to complete.
For most users, there is generally a visual representation of
progress, such as a status bar or a circular progress indicator. As a
process progresses, a viewer can estimate when it will be complete.
For blind users, however, the visual presentation provides no useful
information, so they will need to be able to retrieve the current
value some other way.

Roles, states, and properties in a progress bar

• role="progressbar"
• tabindex = [0|-1]
• aria-valuenow = "0"
• aria-valuemin = "0"
• aria-valuemax = "[max value define in default
options]"
• aria-describedby = "[instruction ID]"
• role = "region"
• aria-live = "assertive"
• aria-atomic = "additions"
• aria-hidden = "[true|false]"

Suggested Reading: For more about accessible progress

bars, see WAI-ARIA 1.1: Progressbar

Progress Bars | 155

The following JSFiddle presents a typical progress bar widget.
Review the JavaScript and HTML markup and test the progress bar
presented under the result tab with ChromeVox to understand how
it functions without any accessibility features added. You can work
in JSFiddle itself by clicking the Edit in “JSFiddle” at the top, right-
hand side. Copy the accessibility/WAI-ARIA code described below
to fix the accessibility of the progress bar before completing Activity
7 on the page that follows.

An interactive or media element has been excluded from this

version of the text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

WAI-ARIA to Make the Progress Bar Accessible

Key Point: For the exercise in Activity 7: Accessible Progress

Bar, aim to have the progress bar function in ChromeVox,
but, be aware that solutions described here will not work in
other screen readers.

In this example, we have added WAI-ARIA to a progress bar, but due

to limited support for the WAI-ARIA progressbar attributes by
screen readers other than ChromeVox, there is also a workaround
using the jQuery .data() function to output the current value
for users of JAWS or NVDA screen readers. You can refer to the
ik_progressbar_data.js file for the workaround. However,
for Activity 7, be sure to start from the ik_progressbar.js file for the
assignment submission. To experiment with the .data() version
of the progress bar JavaScript file, you can adjust the reference to
the file in the progressbar.html file.
First, as is typical, create some instructions describing how to

156 | Progress Bars

operate the progress bar with a screen reader and keyboard and add
them to the default options.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

Update the init() function to add the required WAI-ARIA. First

set tabindex="-1" to be sure the bar itself is not keyboard
focusable by default, and associate the bar with the instructions
so when the bar does receive focus the instructions are read. Set
some default values for aria-valuemin , aria-valuenow , and
aria-valuemax . Also, add keyboard access to the bar with an
on(keydown) reference to the onKeyDown() function,
described below.
Add to the notifications <div> live region attributes so when
Space/Enter are pressed and the progress percent is added, or if
“Loading Complete!” is added, they are read aloud by the screen
reader.
Finally, create the <div> with instructions referenced by its ID
with aria-describedby added to the bar <div> and hide it by
default.

Progress Bars | 157

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

158 | Progress Bars

Replace the data(value) in the getValue() function, used
to retrieve the current value of the progress bar when the Space
bar or Enter keys are pressed, with an aria-valuenow attribute.
This replaces the .data(value) needed to function with screen
readers other than ChromeVox.

Progress Bars | 159

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

In the setValue() function, add in a tabindex="-1" to remove

keyboard focus from the bar when the max value is reached and
to add the “Loading Complete” message to the notification <div> .
Finally, add either the current value of the progress on keypress
or the max value (if progress is complete) to an aria-valuenow
attribute. This replaces the .data() work-around, which is
needed to function with screen readers other than ChromeVox.

160 | Progress Bars

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

Progress Bars | 161

Adding Keyboard Operability

Keyboard access for a progress bar is relatively simple. There is

typically no mouse or keyboard interaction. One generally waits
and, when progress is complete, continues on with some other
action. For screen reader users, however, they will need to be able
to get the current progress value using a keypress.
To allow the current value to be retrieved, set up the Enter and
Space bar keyboard controls with the onKeyDown() function. This
also triggers the notify() function. When one of those keys is
pressed, it outputs the value to the notification <div> that we have
set up as a live region.

162 | Progress Bars

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

Accessible Progress Bar in Action

Watch the following video to see how ChromeVox interacts with a

progress bar. When the Run Demo button is pressed, instructions
are provided on how to announce progress. Pressing the Space
bar or Enter key announces the percentage progress at any given

Progress Bars | 163

moment. When progress has finished, “Loading Complete” is
announced. Aim to have the progress bar you update in the activity
on the following page operate and announce like the one in the
video.
Video: Accessible Progress Bar

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=341

164 | Progress Bars

Activity 7: Accessible
Progress Bar

Accessible Progress Bar

Based on the Progress Bar details on the previous page, apply what
you have learned to the associated book files to make the progress
bar there accessible.
Files for this activity include:

• /progressbar.html
• /assets/ik_progressbar.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the progress bar by applying the highlighted code to
the /assets/ik_progressbar.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.

Activity 7: Accessible Progress

Bar | 165
 Test your updated progress bar with ChromeVox to ensure each
element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to be sure your
progress bar functions as described, submit the URL to your
progressbar.html file on your GitHub Pages site, to the file on the
web server you are using to host your copy of the course files, or to
a GitHack URL.

Grading Rubric

Criteria
Instructions Provided:
When the progress bar begins running, instructions are provided on how to announce pro
Keyboard Announce Progress:
The keyboard can be used to announce progress percentage.
Announce Complete:
When progress finishes, Loading Complete is announced.
Total Points:

166 | Activity 7: Accessible Progress Bar

5. INTERACTIVE WAI-ARIA
(INTERMEDIATE)

5. Interactive WAI-ARIA
(Intermediate) | 167
Objectives and Activities

Objectives

By the end of this unit, you will be able to:

• Recognize the elements of an accessible slider

• Identify what makes an accordion accessible
• Identify the elements of an accessible tab panel
• Explain the challenges of making a carousel accessible

Activities

• Create the following accessible elements:

◦ Slider
◦ Accordion
◦ Tab panel
◦ Carousel

Objectives and Activities | 169

Sliders
Sliders typically allow users to select a value between minimum and
maximum values by dragging a slider thumb along a slider bar or
track.

WAI-ARIA roles, states, and properties used in a

slider

• tabindex="[0 | -1]"
• role="slider"
• aria-valuemin="[number]"
• aria-valuemax="[number]"
• aria-valuenow="[number]"

Suggested Reading: Additional information about creating

accessible sliders can be found in the WAI-ARIA Best
Practices.

The following JSFiddle presents a typical slider widget. Review the

JavaScript and HTML markup. Test the slider presented under the
Result tab with ChromeVox to understand how it functions without
any accessibility features added. You can work in JSFiddle itself by
clicking the “Edit in JSFiddle” at the top, right-hand side, copying
the accessibility/WAI-ARIA code described below to fix the
accessibility of the slider before completing Activity 8 on the page
that follows.

170 | Sliders
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Define some instructions that describe how to use the slider for
screen reader users.

Sliders | 171
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Add a tabindex="0" to make the slider thumb keyboard

focusable. Assign a role="slider" to the text box so it
announces as a slider instead of a text entry field. Set aria-
valuemin , aria-valuemax , and aria-valuenow values, and
reference the instructions with aria-describedby . Using
.on('keydown') reference the onKeyDown function to add
keyboard operability to the slider.

172 | Sliders
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Create a <div> for the screen reader instructions.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Dynamically set the value of aria-valuenow based on the value

at which the slider thumb is located.

Sliders | 173
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Remove keyboard access from the original text field.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Adding Keyboard Operability

WAI-ARIA authoring practices defines recommended keyboard

functionality for a slider, listed below.

174 | Sliders
Keyboard Interaction for a Slider

• Right Arrow: Increase the value of the slider by

one step.
• Up Arrow: Increase the value of the slider by
one step.
• Left Arrow: Decrease the value of the slider by
one step.
• Down Arrow: Decrease the value of the slider by
one step.
• Home: Set the slider to the first allowed value in
its range.
• End: Set the slider to the last allowed value in its
range.
• Page Up (Optional): Increment the slider by an
amount larger than the step change made by Up
Arrow.
• Page Down (Optional): Decrement the slider by
an amount larger than the step change made by
Down Arrow.

Note:

1. Focus is placed on the slider (the visual

object that the mouse user would move,
also known as the thumb).
2. In some circumstances, reversing the

Sliders | 175
 direction of the value change for the keys
specified above (e.g., having Up Arrow
decrease the value) could create a more
intuitive experience.

Source: W3C WAI-ARIA 1.1 Best Practices

Add keyboard event handling to our slider widget. In our case, we

will add Left and Right Arrow controls for moving the slider thumb
along the slider bar, and End and Home controls for moving the
slider thumb between the start and end of the slider bar.

176 | Sliders
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Sliders | 177
Accessible Slider in Action

Watch the following video of ChromeVox interacting with a

slider. The Arrow keys are used to move the slider thumb along the
slider bar, and the Home and End keys are used to move the slider
thumb between the start and the end of the slider bar. You may
notice that ChromeVox interprets “min” as “minute” rather than min
and max that define the range along the slider bar. Aim to have
the slider you update in the activity that follows on the next page
operate and announce like the one in the video.
Video: Accessible Slider

178 | Sliders
 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=349

Sliders | 179
Activity 8: Accessible Slider

Accessible Slider

Based on the Slider details on the previous page, apply what you
have learned to the associated book files to make the slider there
accessible.
Files for this activity include:

• /slider.html
• /assets/ik_slider.js

Use the code surrounding the highlighted solutions on the previous

page as a guide to find where the fixes should be applied. Repair
the accessibility of the slider by applying the highlighted code to the
/assets/ik_slider.js file.
Note: While we suggest using the highlighted solutions we’ve
provided, you are free to come up with your own solutions as long
as they produce the expected results listed in the marking rubric
below.
Test your updated slider with ChromeVox to ensure each element
described in the marking rubric below is functioning as suggested.

180 | Activity 8: Accessible Slider

Requirements

When you have applied your changes and tested to be sure your
slider functions as described, submit the URL to your slider.html file
on your GitHub Pages site, to the file on the web server you are
using to host your copy of the course files, or to a GitHack URL.

Grading Rubric

Criteria
Slider Focusable:
Slider thumb is keyboard focusable.
Keyboard Operable:
Slider thumb moves using Left and Right Arrow keys, and the Home and End keys.
Min/Max Values Announced:
Minimum and maximum values are announced.

Value Announced:
When the slider moves, its new value is announced.
Total Points:

Activity 8: Accessible Slider | 181

Accordions
Accordion widgets can come in single or multi-select formats, in
which one or multiple panels can be opened at once, respectively.
They are typically used to reduce the space that content occupies
and to reduce scrolling. Accordions are made up of Accordion
Headers and Accordion Panels. The accordion headers control the
display of their associated accordion panel.

The WAI-ARIA roles, states, and properties used in

an accordion

• aria-multiselectable ="(true | false)"

• role="heading"
• role="button"
• aria-controls="[panel id]"
• tabindex="0"
• role="region"
• aria-hidden= "(true | false)"
• aria-expanded= "(true | false)"

Suggested Reading: For details on constructing accessible

accordions, refer to: WAI-ARIA Authoring Practices:
Accordion

The following JSFiddle presents a typical accordion widget. Review

the JavaScript and HTML markup. Test the accordion presented
under the Result tab with ChromeVox to understand how it

182 | Accordions
functions without any accessibility features added. You can work
in JSFiddle itself by clicking “Edit in JSFiddle”, copying the
accessibility/WAI-ARIA code described below to fix the accessibility
of the accordion before completing Activity 9 on the page that
follows.

Accordions | 183
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

First, add the accordion to the landmarked regions by assigning

role="region" to the opening <DL> element when the

184 | Accordions
accordion is initialized, adding the region role to the init()
function.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:

Next, add the aria-multiselectable attribute to the <DL> ,

which will be dynamically set to true or false based on plugin
configuration settings. This lets a user know that more than one
accordion panel can be opened when set to TRUE or only a single
panel when set to FALSE. Refer to the $(document).ready block
in the HTML, where the assignment takes place.

An interactive or media element has been excluded

The semantics of the children of the <DL> element, which was
assigned role="presentation" , will also have their definition
list semantics removed. Add the accordion semantics
role="heading" to assign a heading role to the <DT> elements.
The aria-level attribute might be used to implement nested
accordion panels, but for the purpose of this book a simplified
version is sufficient.

An interactive or media element has been excluded

from this version of the text. You can view it online

Add a <div> inside the header (i.e., DT ) and define its role as a
button. The button is given an aria-controls attribute to define
which of the accordion panels it controls. By default the toggle
state is set to false with aria-expanded="false" to be updated
dynamically when the button is clicked or key pressed. Finally add
tabindex="0" to the button ( <div> ) to make it keyboard
focusable.

Accordions | 185
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

The tabindex will make the button focusable, but it will not make
it clickable. The .on() jQuery function adds a click event to the
button, but a keypress event must also be added. Adding
.on('keydown') activates the onKeyDown function, defined
below, so the accordion headers operate with both a mouse click
and a keypress.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

In the togglePanel() function, before autoCollapse() , add

in the toggle to add and update the aria-expanded attribute for
the panel headers, based on whether the associated panel is visible
or not.

186 | Accordions
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

Within the autoCollapse() function, toggle aria-

expanded="false" and aria-hidden="true" for all accordion
tabs that are not the current one. This ensures only one panel is
open at a time.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

Finally, the accordion panel semantics are added, defining the

<DD> elements that had its semantics removed when
role="presentation" was added to the parent <DL> . Panels
are given a generic role="region" to make the panel browsable
in the landmarks list, set to be hidden by default with aria-
hidden="true" so all panels are closed when the page loads.
Further, tabindex="0" is also added to make the panels keyboard
focusable so the content of the panel is read as the user navigates to
them.

Accordions | 187
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

Adding Keyboard Operability

WAI-ARIA best practices defines all recommended accordion

keyboard functionality, listed below. In our example, only the
required keyboard events are included.

Keyboard Interaction for Accordions

• Enter or Space:

◦ When focus is on the accordion header

for a collapsed panel, expands the
associated panel. If the implementation
allows only one panel to be expanded, and if
another panel is expanded, collapses that

188 | Accordions
 panel.
◦ When focus is on the accordion header
for an expanded panel, collapses the panel if
the implementation supports collapsing.
Some implementations require one panel to
be expanded at all times and allow only one
panel to be expanded; so they do not
support a collapse function.

• Down Arrow (Optional): If focus is on an

accordion header, moves focus to the next
accordion header. If focus is on the last accordion
header, either does nothing or moves focus to the
first accordion header.
• Up Arrow (Optional): If focus is on an accordion
header, moves focus to the previous accordion
header. If focus is on the first accordion header,
either does nothing or moves focus to the last
accordion header.
• Home (Optional): When focus is on an accordion
header, moves focus to the first accordion header.
• End (Optional): When focus is on an accordion
header, moves focus to the last accordion header.
• Ctrl+Page Down (Optional): If focus is inside an
accordion panel or on an accordion header, moves
focus to the next accordion header. If focus is in
the last accordion header or panel, either does
nothing or moves focus to the first accordion
header.
• Ctrl+Page Up (Optional): If focus is inside an
accordion panel, moves focus to the header for

Accordions | 189
 that panel. If focus is on an accordion header,
moves focus to the previous accordion header. If
focus is on the first accordion header, either does
nothing or moves focus to the last accordion
header.

Source: WAI-ARIA Accordion Design Patterns

The following onKeyDown function has been created to add

keyboard operability to the header elements of the accordion,
allowing both Space bar and Enter keys to operate the toggles (i.e.,
headers) that open and close panels, and the Arrow keys to move
between the accordion headers. By default, users can navigate
between headers, and between headers and panels using the Tab
key.

190 | Accordions
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

Accordions | 191
Accessible Accordion in Action

Watch the following video to see how ChromeVox interacts with

an accordion. The Tab key is used to navigate into the accordions,
move between accordion headers, and move between accordion
headers and panels. Arrow keys can also be used to move between
accordion headers, but not from headers to an associated panel.
Aim to have the accordion you update in the activity on the
following page operate and announce like the one in the video.
Video: Accessible Accordions

192 | Accordions
 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=353

Accordions | 193
Activity 9: Accessible
Accordion

Accessible Accordion

Based on the Accordion details on the previous page, apply what

you have learned to the associated book files to make the accordion
there accessible.
Files for this activity include:

• /accordion.html
• /assets/ik_accordion.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the accordion by applying the highlighted code to
the /assets/ik_accordion.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.

194 | Activity 9: Accessible Accordion

 Test your updated accordion with ChromeVox to ensure each
element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to be sure your
accordion functions as described, submit the URL to your
accordion.html file on your GitHub Pages site, to the file on the web
server you are using to host your copy of the book files, or a GitHack
URL.

Grading Rubric

Criteria
Header Focus:
Accordion headers are keyboard focusable.
Headers as Buttons:
Accordion headers are announced as buttons instead of list items.
Open Panels:
Accordion headers open panels with a click or key press.
Expand/Collapse:
Accordions announce expanded when a panel is opened and collapsed when closed.
Panels Focusable:
Accordion panels are focusable with a Tab key press when opened.

Header Navigation:
Navigation between accordion headers with Up and Down Arrow keys, and the Tab key.

Total Points:

Activity 9: Accessible Accordion | 195

Tab Panels
Tab panels, much like accordions, are often used to conserve space
and reduce scrolling. They are typically made up of a tablist that
contains a series of tabs, each tab controlling the display of a panel.
As each tab is activated, its associated panel is displayed and other
panels are hidden. When a tab is selected, it is highlighted to
indicate which tab and panel are active.

WAI-ARIA roles, states, and properties used in a tab

panel

• role="tablist"
• role="tabpanel"
• role="tab"
• aria-hidden="[true|false]"
• tabindex = [0 | -1]
• aria-controls="[panel id]"
• aria-selected="[true|false]"

Suggested Reading: Additional information about creating

accessible tab panels can be found in the WAI-ARIA
Authoring Practices.

The following JSFiddle presents a typical tab panel widget. Review

the JavaScript and HTML markup. Test the tab panel presented
under the Result tab with ChromeVox to understand how it
functions without any accessibility features added. You can work
in JSFiddle itself by clicking “Edit in JSFiddle”, copying the

196 | Tab Panels

accessibility/WAI-ARIA code described below to fix the accessibility
of the tab panel before completing Activity 10 on the page that
follows.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

Tab Panels | 197

In our case, we are generating the tabs for each child <div>
defined in the HTML, though tabs and tab panels could be static
HTML. The tablist is made up of a <ul> and child <li> elements.
We assign role="tablist" to the <ul> to remove its list
semantics and replace it with tab panel semantics.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

Next, we add WAI-ARIA to the panels, assigning

role="tabpanel" to each of the original <div> elements, hide
them by default with aria-hidden="true" , and finally adding
tabindex="0" to make the panels keyboard focusable.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

The tabs themselves are now defined, replacing the list item
semantics with tab semantics adding role="tab" to each of the
<li> elements generated. We also need to define which tab
controls which tabpanel, dynamically generating aria-
controls="[panel_id]" for each of the tabs.

198 | Tab Panels

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

When a tab is selected, we want to remove selection from other

tabs with aria-selected="false" , and remove keyboard access
temporarily by assigning tabindex="-1" to the unselected tabs,
so that that tabpanel becomes next in the tab order, and users can
navigate directly from the tab to the panel without having to pass
through the other tabs in the tablist.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

Likewise, when a tab is selected we assign aria-

selected="true" so screen readers announce the selected tab,
we add tabindex="0" as the roving tabindex to make that tab
focusable.

Tab Panels | 199

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

As the tabs change, hide all the panels with aria-

hidden="true" so screen readers do not see them, then open
the panel the current tab controls with aria-hidden="false" so
screen readers can see the active panel. These are added to the end
of the selectTab() function.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

Adding Keyboard Operability

W3C describes authoring practices for tab panel keyboard

interactions as follows.

200 | Tab Panels

Keyboard Interaction for Tab Panels

For the tab list:

• Tab: When focus moves into the tab list, places

focus on the active tab element. When the tab
list contains the focus, moves focus to the next
element in the page tab sequence outside the
tablist, which is typically either the first focusable
element inside the tab panel or the tab panel
itself.
• When focus is on a tab element in a horizontal
tab list:

◦ Left Arrow: moves focus to the previous

tab. If focus is on the first tab, moves focus
to the last tab. Optionally, activates the
newly focused tab (See note below).
◦ Right Arrow: Moves focus to the next tab.
If focus is on the last tab element, moves
focus to the first tab. Optionally, activates
the newly focused tab (See note below).

• When focus is on a tab in a tablist with either

horizontal or vertical orientation:

◦ Space or Enter: Activates the tab if it was

not activated automatically on focus.
◦ Home (Optional): Moves focus to the first
tab

Tab Panels | 201

 ◦ End (Optional): Moves focus to the last
tab.
◦ Shift + F10: If the tab has an associated
pop-up menu, opens the menu.
◦ Delete (Optional): If deletion is allowed,
deletes (closes) the current tab element and
its associated tab panel. If any tabs remain,
sets focus to the tab following the tab that
was closed and activates the newly focused
tab. Alternatively, or in addition, the delete
function is available in a context menu.

Note:

1. It is recommended that tabs activate

automatically when they receive focus as
long as their associated tab panels are
displayed without noticeable latency. This
typically requires tab panel content to be
preloaded. Otherwise, automatic activation
slows focus movement, which significantly
hampers users’ ability to navigate efficiently
across the tab list. For additional guidance,
see 5.4 Deciding When to Make Selection
Automatically Follow Focus.
2. If the tabs in a tab list are arranged
vertically:

1. Down Arrow performs as Right

202 | Tab Panels

 Arrow is described above.
2. Up Arrow performs as Left Arrow is
described above.

3. If the tab list is horizontal, it does not

listen for Down Arrow or Up Arrow so those
keys can provide their normal browser
scrolling functions even when focus is
inside the tab list.

As usual, the tab panel needs to be keyboard operable to be

accessible to screen readers. The onKeyDown() function is added
to the functions, to add arrow key navigation between tabs, and
between tabs and panels. Tab navigation and Enter keys are enabled
by default and do not need to be defined here.

Tab Panels | 203

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

204 | Tab Panels

 The onKeyDown function is then added to each tab, referenced
with jQuery’s .on('keydown') function, added to the init()
function’s $tab definition.
Now, with keyboard access and WAI-ARIA added to define the
semantics of the tab panel, it should be fully functional for screen
readers.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

Accessible Tab Panel in Action

Watch the following video showing ChromeVox interacting with a

tab panel. The Tab key is used to navigate into the tab panel and to
the first tab. The arrow keys are used to move between tabs and,
when on a tab, the Tab key is used to navigate to the associated
panel. While on a panel, Shift + Tab is used to return to the tablist.
There might also be Up and Down arrows enabled to move between

Tab Panels | 205

tabs and panels, though we have not enabled them here. Aim to have
the tab panel you update in the activity coming up on the next page
operate and announce itself like the one in the video.
Video: Accessible Tab Panel

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=357

206 | Tab Panels

Activity 10: Accessible Tab
Panel

Accessible Tab Panel

Based on the Tab Panel details on the previous page, apply what you
have learned to the associated book files to make the tab panel there
accessible.
Files for this activity include:

• /tabs.html
• /assets/ik_tabs.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the tab panel by applying the highlighted code to the
/assets/ik_tabs.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.

Activity 10: Accessible Tab

Panel | 207
 Test your updated tab panel with ChromeVox to be sure each
element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to ensure your tab
panel functions as described, submit the URL to your tabs.html file
on your GitHub Pages site, to the file on the web server you are
using to host your copy of the book files, or a GitHack URL.

Grading Rubric

Criteria Points
List to Tab Semantics: 2.0
List semantics are replaced with tab panel semantics. pts
Tab Position:
1.0 pts
Focus position in the tablist is announced.
Tab Focus opens Panel:
1.0 pts
When a tab is in focus, its associated panel displays.
Arrow Key Between Tabs: 2.0
Arrow keys can be used to navigate between tabs. pts
Tab Key from Tab to Panel:
2.0
Tab key can be used to move from a selected tab directly to its
pts
associated panel, Shift+Tab to move back to tabs.
Panels Focusable: 2.0
Panels are keyboard focusable. pts
Total Points: 10.0

208 | Activity 10: Accessible Tab Panel

Carousels
Carousels are typically used to present a series of panels or images
that rotate at a particular frequency.

WAI-ARIA roles, states, and properties used in

carousels

• role="region"
• aria-live="polite"
• tabindex="0"
• aria-describedby="[id of div with instructions]"
• aria-hidden="(true|false)"

Suggested Reading: The Carousel Tutorial from the W3C

provides additional details on constructing accessible
carousels.

The following JSFiddle presents a typical carousel widget. Review

the JavaScript and HTML markup. Test the carousel presented
under the Result tab with ChromeVox to understand how it
functions without any accessibility features added. You can work in
JSFiddle itself by clicking “Edit in JSFiddle.” Copy the accessibility/
WAI-ARIA code described below to fix the accessibility of the
accordion before completing Activity 11 on the page that follows.

Carousels | 209
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Though instructions are not always required, they can be helpful

for screen reader users when there is non-standard keyboard

210 | Carousels
navigation. In our case, we’ll add a few words and assign them to
the “instructions” variable in the default settings of the init()
function for the carousel. The instructions will be rendered in its
own <div> and referenced with aria-describedby a little later
in the code.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

We’ll define a few attributes when the carousel is initialized: give

it a role="region" to add it to the landmarks, add a tabindex
to make it keyboard focusable, and reference the ID of the
instructions <div> with aria-describedby . Add keyboard
operability with .on('keydown') and a reference to the
onKeyDown function, described below.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Screen reader users will not need the Next/Previous controls, so

hide them. They will be using the Arrow keys instead, defined in the
onKeyDown function further below.

Carousels | 211
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Hide images from screen readers. Notice that the alt text for
the images are defined in the HTML but left empty so it is not read
in this case. Screen readers will read the figcaptions .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Add screen reader instructions by generating a <div> that

contains the instruction text defined earlier and hide the <div>
by default. The instructions are read when the carousel receives
focus, and the aria-describedby attribute is dynamically added
to reference the instructions.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

212 | Carousels
 Add an aria-live attribute to the stopTimer function. Set its
value to polite so content updating in the live region announces
when a screen reader is not reading elsewhere on the page. The
content of the visible carousel panel is read automatically when it is
in focus, manually navigating between panels with the Arrow keys.

An interactive or media element has been excluded

from this version of the text. You can view it online
Remove the live region when focus on the carousel is removed
in the startTimer function. By doing so, the live region stops
reading when the timer is reactivated onblur , and it does not
interfere with the screen reader reading elsewhere on the page.

An interactive or media element has been excluded

from this version of the text. You can view it online
Hide the active slide from screen readers with aria-
hidden="true" . Then, make the next slide visible to screen
readers with aria-hidden="false" in the gotoSlide
function.

Carousels | 213
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Adding Keyboard Operability

Add keyboard operations for the carousel, pulling keyboard events

from ik_utils.js to use Left and Right arrows for moving between
panels in the carousel, and the Esc key to exit the carousel and
resume automatic rotation.

214 | Carousels
 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

Carousels | 215
Accessible Carousel in Action

Watch the following video to see how ChromeVox interacts with

a carousel. The carousel rotates automatically when focus is
elsewhere on the page. When it receives focus, rotation stops, and
navigation instructions are read. The Left and Right arrow keys are
used to move manually between panels in the carousel while it has
focus. The contents of each panel are read through a live region,
dynamically added to the main container <div> when the carousel
has focus. Using the Tab key while the carousel has focus sends
focus to any focusable element within the panel that is in view, a link
to the person who shared the photo in this case. Aim to have the
carousel you update in the activity on the following page operate
and announce like the one in the video.
Video: Accessible Carousel

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=362

216 | Carousels
Activity 11: Accessible
Carousel

Accessible Carousel

Based on the Carousel details on the

previous page, apply what you have learned to the associated book
files to make the carousel there accessible.
Files for this activity include:

• /carousel.html
• /assets/ik_carousel.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the carousel by applying the highlighted code to the
/assets/ik_carousel.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated carousel with ChromeVox to ensure each

Activity 11: Accessible Carousel | 217

element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to ensure your
carousel functions as described, submit the URL to your
carousel.html file on your GitHub Pages site, to the file on the
web server you are using to host your copy of the book files, or
a GitHack URL.

Grading Rubric

Criteria
Instructions Provided
Screen reader instructions are provided when carousel receives focus.
Carousel Focusable
Carousel panels are keyboard focusable.
Carousel Navigation
Navigate between panels with the Left and Right Arrow keys.
Panels Read Aloud
While the carousel has focus, each panel reads aloud when it comes into view.
Manual while in Focus
When in focus, or while a mouse pointer is hovering over the carousel, panels rotate manu

Rotate when No Focus

When the carousel is not in focus, panels rotate automatically.

Total Points:

218 | Activity 11: Accessible Carousel

6. INTERACTIVE WAI-ARIA
(ADVANCED)

6. Interactive WAI-ARIA
(Advanced) | 219
Objectives and Activities

Objectives

By the end of this unit, you will be able to:

• Describe the elements of an accessible menu bar

• Identify tree menu accessibility features
• Explain how an accessible sortable list functions

Activities

• Create the following accessible elements:

◦ Menu bar
◦ Tree menu
◦ Sortable list

Objectives and Activities | 221

Menu Bars
Menu bars are typically presented horizontally across the top of
a website or web application. They contain links to key areas of
the website or application. They function as toggles that open
submenus or function as both links and toggles. Menu bars remain
in view across the entire website or application.

Roles, states, and properties used in a menu bar

• aria-hidden = [true|false]
• role = "menubar"
• role = "menu"
• role = "menuitem"
• aria-labelledby = "[instruction div id]"
• aria-label = [link text]
• tabindex = [0 | -1]
• aria-haspopup = "true"
• aria-expanded = "[true|false]"
• aria-selected = "[true|false]"

Suggested Reading: For more about accessible menus, see

WAI-ARIA Best Practice 1.1: Menus or Menu Bar.

The following JSFiddle presents a typical menu bar widget with a

variety of sub menus. Review the JavaScript and HTML markup.
Test the menu bar presented under the Result tab with ChromeVox
to understand how it functions without any accessibility features
added. You can work in JSFiddle itself by clicking the “Edit in

222 | Menu Bars

JSFiddle” link at the top, right-hand side, copying the accessibility/
WAI-ARIA code described below to fix the accessibility of the menu
bar before completing Activity 12 on the page that follows.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

First, provide some instructions on how to use the menu with a

keyboard and add them to the default options.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Hide the instructions from screen readers until needed, adding

aria-hidden="true" to the instructions <div> defined when
the menu is initialized.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Add role="menubar" to the top level <ul> in the menu. Make

Menu Bars | 223

that <ul> keyboard focusable with tabindex="0" , so it reads
the instructions while in focus and referenced with aria-
labelledby .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

For all the menu items in the menu bar that have submenus,
add role="menu" to their <ul> and hide them by default using
aria-hidden="true" . This can be located after the
$elem.find('ul:eq(0)') block presented immediately above.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Hide the links in the menu items from screen readers by default
using tabindex="-1" and setting aria-hidden="true" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

224 | Menu Bars

 Set up the menu items throughout the menu using
role="menuitem". Also, remove keyboard access by default with
tabindex="-1" . Next, label each menu item with the text of the
associated link using aria-label="[$link.text]" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

For each of the menu items that has a submenu, add aria-
haspopup="true" to announce the presence of the submenu, and
set its default state to “collapsed” by adding aria-
expanded="false" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

When a menu item is marked selected, also add aria-

selected="true" and add keyboard access back to the menu
item with tabindex="0" .

An interactive or media element has been excluded

from this version of the text. You can view it online

Menu Bars | 225

 here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Add keyboard access back to menu items using tabindex="0" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Reference the keyboard access class, where mouse events are

defined in the onKeyDown function, described below.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

In the showSubMenu function, add aria-expanded="true"

submenus when they are expanded, remove keyboard access from
the submenu container with tabindex="-1" . Then, make the
submenu visible with aria-hidden="false" .

226 | Menu Bars

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

In the hideSubMenu function, set aria-expanded="false" ,

hide submenus with aria-hidden="true" , and remove keyboard
access with tabindex="-1" when a submenu is closed.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

When the collapseAll function is called, to collapse any open

menus, reverse all attributes defining the element as open, reverting
to aria-hidden="true" , aria-expanded="false" and re-
adding keyboard access with tabindex="0" so it can be opened
again.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Menu Bars | 227

Adding Keyboard Operability

Menu bar keyboard functionality can be complex, particularly with

large menus with multiple levels of submenus, and they can include
redundant keys that perform the same function. The W3C defines
suggested keyboard interaction for a menu bar as follows:

Menu Bar Keyboard Interaction

This description of keyboard behaviours assumes the

following:

1. A horizontal menubar containing several

menuitem elements.
2. All items in the menubar have child submenus
that contain multiple vertically arranged items.
3. Some of the menuitem elements in the
submenus have child submenus with items that
are also vertically arranged.

When reading the following descriptions, also keep in

mind these items:

1. Focusable elements, which may have role

menuitem , menuitemradio , or
menuitemcheckbox , are referred to as items.
2. If a behaviour applies to only certain types of
items, e.g., menuitem elements, the specific role
name is used.

228 | Menu Bars

3. Submenus, also known as pop-up menus, are
elements with role menu .
4. Except where noted, menus opened from a
menu button behave the same as menus opened
from a menu bar.

• When a menu opens, or when a menubar

receives focus, keyboard focus is placed on the
first item. All items are focusable as described in
5.6 Keyboard Navigation Inside Components.
• Enter:

◦ When focus is on a menuitem that has a

submenu, opens the submenu and places
focus on its first item.
◦ Otherwise, activates the item and closes
the menu.

• Space:

◦ (Optional): When focus is on a

menuitemcheckbox , changes the state
without closing the menu.
◦ (Optional): When focus is on a
menuitemradio that is not checked,
without closing the menu, checks the
focused menuitemradio and unchecks
any other checked menuitemradio
element in the same group.
◦ (Optional): When focus is on a menuitem
that has a submenu, opens the submenu and
places focus on its first item.

Menu Bars | 229

 ◦ (Optional): When focus is on a menuitem
that does not have a submenu, activates the
menuitem and closes the menu.

• Down Arrow:

◦ When focus is on a menuitem in a

menubar , opens its submenu and places
focus on the first item in the submenu.
◦ When focus is in a menu , moves focus to
the next item, optionally wrapping from the
last to the first.

• Up Arrow:

◦ When focus is in a menu , moves focus to

the previous item, optionally wrapping from
the first to the last.
◦ (Optional): When focus is on a menuitem
in a menubar , opens its submenu and
places focus on the last item in the
submenu.

• Right Arrow:

◦ When focus is in a menubar , moves

focus to the next item, optionally wrapping
from the last to the first.
◦ When focus is in a menu and on a
menuitem that has a submenu, opens the
submenu and places focus on its first item.
◦ When focus is in a menu and on an item
that does not have a submenu, performs the

230 | Menu Bars

 following 3 actions:

1. Closes the submenu and any parent

menus.
2. Moves focus to the next menuitem
in the menubar .
3. Either: (Recommended) opens the
submenu of that menuitem without
moving focus into the submenu, or
opens the submenu of that
menuitem and places focus on the
first item in the submenu.

Note that if the menubar were not

present, e.g., the menus were opened from a
menubutton, Right Arrow would not do
anything when focus is on an item that does
not have a submenu.

• Left Arrow:

◦ When focus is in a menubar , moves

focus to the previous item, optionally
wrapping from the last to the first.
◦ When focus is in a submenu of an item in
a menu , closes the submenu and returns
focus to the parent menuitem .
◦ When focus is in a submenu of an item in
a menubar , performs the following 3
actions:

1. Closes the submenu.

2. Moves focus to the previous

Menu Bars | 231

 menuitem in the menubar .
3. Either: (Recommended) opens the
submenu of that menuitem without
moving focus into the submenu, or
opens the submenu of that
menuitem and places focus on the
first item in the submenu.

• Home: If arrow key wrapping is not supported,

moves focus to the first item in the current menu
or menubar .
• End: If arrow key wrapping is not supported,
moves focus to the last item in the current menu
or menubar .
• Any key that corresponds to a printable
character (Optional): Move focus to the next menu
item in the current menu whose label begins with
that printable character.
• Escape: Close the menu that contains focus and
return focus to the element or context, e.g., menu
button or parent menuitem , from which the
menu was opened.
• Tab: Moves focus to the next element in the tab
sequence, and if the item that had focus is not in a
menubar , closes its menu and all open parent
menu containers.
• Shift + Tab: Moves focus to the previous element
in the tab sequence, and if the item that had focus
is not in a menubar , closes its menu and all open
parent menu containers.

232 | Menu Bars

Note:

1. Disabled menu items are focusable but

cannot be activated.
2. A separator in a menu is not focusable or
interactive.
3. If a menu is opened or a menu bar
receives focus as a result of a context
action, Esc or Enter may return focus to the
invoking context. For example, a rich text
editor may have a menu bar that receives
focus when a shortcut key, e.g., Alt+F10, is
pressed while editing. In this case, pressing
Esc or activating a command from the menu
may return focus to the editor.
4. Although it is recommended that authors
avoid doing so, some implementations of
navigation menu bars may have menuitem
elements that both perform a function and
open a submenu. In such implementations,
Enter and Space bar perform a navigation
function, e.g., load new content, while Down
Arrow, in a horizontal menu bar, opens the
submenu associated with that same
menuitem .
5. When items in a menubar are arranged
vertically and items in menu containers are
arranged horizontally:

Menu Bars | 233

 1. Down Arrow performs as Right
Arrow is described above, and vice
versa.
2. Up Arrow performs as Left Arrow is
described above, and vice versa.

Source: W3C WAI-ARIA 1.1 Authoring Practices

Here we have implemented a subset of the keyboard interaction

W3C recommends in an onKeyDown() function that is called when
event handlers are set up for menu items. These keys include Left
and Right arrows, Up and Down arrows, the Space bar and Enter
keys, and Tab and Esc keys. Copy the following function into the
ik_menu.js file, near the end, to add keyboard operability to the
menu.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Accessible Menu Bar in Action

Watch the following video showing ChromeVox interacting with a

234 | Menu Bars

menu bar. The Tab key is used to navigate into the menu bar, to
the first menu item, and to exit the menu bar. Left and Right arrow
keys are used to move across the top level menu items. Up and
Down arrows are used to move into and out of a submenu and to
move between menu items in a submenu. The Space bar or Enter
key are used to activate a menu item. The Esc key closes the current
submenu. Aim to have the menu bar you update in the activity on
the next page operate and announce itself like the one in the video.
Video: Accessible Menu Bar

A YouTube element has been excluded from this version of the

text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=368

Menu Bars | 235

Activity 12: Accessible Menu
Bar

Accessible Menu Bar

Based on the Menu bar details on the

previous page, apply what you have learned to the associated book
files to make the menu there accessible.
Files for this activity include:

• /menu.html
• /assets/ik_menu.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the menu bar by applying the highlighted code to the
/assets/ik_menu.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated menu bar with ChromeVox to ensure each

236 | Activity 12: Accessible Menu

Bar
element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to be sure your
menu bar functions as described, submit the URL to your menu.html
file on your GitHub Pages site, to the file on the web server you are
using to host your copy of the book files, or a GitHack URL.

Grading Rubric

Criteria Points
Instructions Provided:
Instructions are announced on how to use the menu bar with a 1.0 pts
keyboard, when the menu bar first receives focus.

Menu Bar Semantics: 2.0

List item semantics are replaced with menu semantics. pts
Submenus Announced:
2.0
When a menu item with a submenu receives focus, the presence
pts
of a submenu is announced.

Focus Control:
2.0
Only elements of the menu bar that are in view are able to
pts
receive focus.

Keyboard Operable:
3.0
As described in Adding Keyboard Operability for a menu bar, the
pts
menu bar functions using a keyboard (and mouse).
Total Points: 10.0

Activity 12: Accessible Menu Bar | 237

Tree Menus
Tree menus often have the same underlying HTML structure as a
menu bar, but rather than being arranged in a horizontal layout,
they tend to be arranged vertically.

WAI-ARIA roles, states, and properties used in a tree

menu

• tabindex = [0 | -1]
• aria-labelledby = [instruction div id | title div id]
• aria-hidden = [true | false]
• role = "tree"
• role = "treeitem"
• role = "presentation"
• aria-level = [number of parent ULs]
• aria-setsize = [number of LIs in a level]
• aria-posinset = [position of each LI in a set]
• aria-expanded = [true | false]
• aria-selected = [true | false]

Suggested Reading: For more about accessible tree menus,

see WAI-ARIA 1.1 Authoring Practices 1.1: Tree View

The following JSFiddle presents a typical tree menu widget with

a few submenus. Review the JavaScript and HTML markup. Test
the tree menu presented under the Result tab with ChromeVox
to understand how it functions without any accessibility features
added. You can work in JSFiddle itself by clicking “Edit in JSFiddle” at

238 | Tree Menus

the top, right-hand side, copying the accessibility/WAI-ARIA code
described below to fix the accessibility of the tree menu before
completing Activity 13 on the page that follows.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Tree Menus | 239

 First, define instructions on using the tree menu with a keyboard.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function add keyboard focus to the tree

container by applying tabindex="0" to it, and label the container
with the instructions created above, which gets read by screen
readers when the menu initially receives focus.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function, hide the instructions <div> from

screen readers by default by setting aria-hidden="true" when
the tree menu is initialized.

240 | Tree Menus

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function replace the unordered list

semantics with tree menu semantics using role="tree" , and give
it a title using aria-labelledby to reference the title defined in
the default options.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function, define menu items with

role="treeitem" , remove all keyboard access by default with
tabindex="-1" , set the number of levels in the tree based on
the number of parent ULs with aria-level=[number of ULs] ,
set the number of tree items on a given level with aria-
setsize="[number of LIs in a UL]" , and finally define
the position of each tree item within a level using aria-
posinset="[child LI index]" .

Tree Menus | 241

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function, if a tree item has a submenu UL

that has been opened, set aria-expanded="true" , otherwise set
aria-expanded="false" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function, for each tree item use the text of
the associated span element as its label. To ensure both the label

242 | Tree Menus

and the contents of the span element are not both read, assign
role="presentation" to the span .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the init() function, where mouse onclick

functionality is used, provide equivalent keydown functionality,
here referencing the onKeyDown function, shown below, that
defines the keys to operate the menu.

An interactive or media element has been excluded

from this version of the text. You can view it online

Within the init() function, right after adding keydown

operability, make the first item in the tree menu focusable by adding
tabindex="0" to the first li .

Tree Menus | 243

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Within the selectItem() function, set up a roving tabindex,

while at the same time applying aria-selected=[true |
false] when tree items receive or lose focus.

244 | Tree Menus

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Tree Menus | 245

 In the toggleSubmenu() function, announce the state of
submenus to the screen reader by toggling the aria-
expanded=[true | false] attribute when a menu is opened or
closed.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Adding Keyboard Operability

Much like the menu bar described in the previous activity, keyboard
operability for a tree menu can be complex, with various operations
using multiple key strokes to perform the same function. W3C

246 | Tree Menus

describes potential keyboard operation in the WAI-ARIA Authoring
Practices 1.1, reproduced below.

Tree Menu Keyboard Interaction

For a vertically oriented tree:

• When a single-select tree receives focus:

◦ If none of the nodes are selected before

the tree receives focus, focus is set on the
first node.
◦ If a node is selected before the tree
receives focus, focus is set on the selected
node.

• When a multi-select tree receives focus:

◦ If none of the nodes are selected before

the tree receives focus, focus is set on the
first node.
◦ If one or more nodes are selected before
the tree receives focus, focus is set on the
first selected node.

• Right Arrow:

◦ When focus is on a closed node, opens the

node; focus does not move.
◦ When focus is on a open node, moves
focus to the first child node.

Tree Menus | 247

 ◦ When focus is on an end node, does
nothing.

• Left Arrow:

◦ When focus is on an open node, closes the

node.
◦ When focus is on a child node that is also
either an end node or a closed node, moves
focus to its parent node.
◦ When focus is on a root node that is also
either an end node or a closed node, does
nothing.

• Down Arrow: Moves focus to the next node that

is focusable without opening or closing a node.
• Up Arrow: Moves focus to the previous node
that is focusable without opening or closing a
node.
• Home: Moves focus to the first node in the tree
without opening or closing a node.
• End: Moves focus to the last node in the tree
that is focusable without opening a node.
• Enter: Activates a node, i.e., performs its default
action. For parent nodes, one possible default
action is to open or close the node. In single-
select trees where selection does not follow focus
(see note below), the default action is typically to
select the focused node.
• Type-ahead is recommended for all trees,
especially for trees with more than 7 root nodes:

248 | Tree Menus

 ◦ Type a character: focus moves to the next
node with a name that starts with the typed
character.
◦ Type multiple characters in rapid
succession: focus moves to the next node
with a name that starts with the string of
characters typed.

• * (Optional): Expands all siblings that are at the

same level as the current node.
• Selection in multi-select trees: Authors may
implement either of two interaction models to
support multiple selection: a recommended model
that does not require the user to hold a modifier
key, such as Shift or Ctrl, while navigating the list
or an alternative model that does require modifier
keys to be held while navigating in order to avoid
losing selection states.

◦ Recommended selection model – holding

a modifier key while moving focus is not
necessary:

▪ Space: Toggles the selection state of

the focused node.
▪ Shift + Down Arrow (Optional):
Moves focus to and toggles the
selection state of the next node.
▪ Shift + Up Arrow (Optional): Moves
focus to and toggles the selection
state of the previous node.
▪ Shift + Space (Optional): Selects

Tree Menus | 249

 contiguous nodes from the last
selected node to the current node.
▪ Ctrl + Shift + Home (Optional):
Selects the node with focus and all
nodes up to the first node.
▪ Ctrl + Shift + End (Optional): Selects
the node with focus and all nodes
down to the last node.
▪ Ctrl + A (Optional): Selects all nodes
in the tree. Optionally, if all nodes are
selected, it can also unselect all nodes.

◦ Alternative selection model – moving

focus without holding the Shift or Ctrl
modifier unselects all selected nodes except
for the focused node:

▪ Shift + Down Arrow: Moves focus to

and toggles the selection state of the
next node.
▪ Shift + Up Arrow: Moves focus to
and toggles the selection state of the
previous node.
▪ Ctrl + Down Arrow: Without
changing the selection state, moves
focus to the next node.
▪ Ctrl + Up Arrow: Without changing
the selection state, moves focus to the
previous node.
▪ Ctrl + Space: Toggles the selection
state of the focused node.
▪ Shift + Space (Optional): Selects

250 | Tree Menus

 contiguous nodes from the most
recently selected node to the current
node.
▪ Ctrl + Shift + Home (Optional):
Selects the node with focus and all
nodes up to the first node.
▪ Ctrl + Shift + End (Optional): Selects
the node with focus and all nodes
down to the last node.
▪ Ctrl + A (Optional): Selects all nodes
in the tree. Optionally, if all nodes are
selected, it can also unselect all nodes.

Note:

1. DOM focus (the active element) is

functionally distinct from the selected state.
For more details, see this description of
differences between focus and selection.
2. The tree role supports the aria-
activedescendant property, which provides
an alternative to moving DOM focus among
treeitem elements when implementing
keyboard navigation. For details, see
Managing Focus in Composites Using aria-
activedescendant.
3. In a single-select tree, moving focus may
optionally unselect the previously selected
node and select the newly focused node.

Tree Menus | 251

 This model of selection is known as
“selection follows focus”. Having selection
follow focus can be very helpful in some
circumstances and can severely degrade
accessibility in others. For additional
guidance, see Deciding When to Make
Selection Automatically Follow Focus.
4. If selecting or unselecting all nodes is an
important function, implementing separate
controls for these actions, such as buttons
for “Select All” and “Unselect All”,
significantly improves accessibility.
5. If the nodes in a tree are arranged
horizontally:

1. Down Arrow performs as Right

Arrow is described above and vice
versa.
2. Up Arrow performs as Left Arrow is
described above and vice versa.

Source: WAI-ARIA Authoring Practices 1.1

For the tree menu created here, we’ve added in basic keyboard
operability. Keyboard operation includes: Up and Down, and Left
and Right Arrows for navigating within the tree, and the Enter or
Space bar keys to toggle submenus open or closed. The Tab key
by default enters and exits the tree menu and does not need to be
defined as part of the keyboard operability of the tree menu.

252 | Tree Menus

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

Tree Menus | 253

254 | Tree Menus
Accessible Tree Menu in Action

Watch the following video showing ChromeVox interacting with a

tree menu. The Tab key is used to navigate into the tree menu, to
the first tree item, and to exit the tree menu. The Up and Down
arrows are used to move between tree items. The Space bar or Enter
key are used to expand and collapse a tree item with a submenu.
When a submenu is opened, focus moves to the first tree item in the
menu. Aim to have the tree menu you update in Activity 13 operate
and announce itself like the one in the video.
Video: Accessible Tree Menu

Tree Menus | 255

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=374

256 | Tree Menus

Activity 13: Accessible Tree
Navigation

Based on the Tree Menu details on the

previous page, apply what you have
learned to the associated book files to
make the tree menu there accessible.
Files for this activity include:

• /tree.html
• /assets/ik_treemenu.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied. Repair the
accessibility of the tree menu by applying the highlighted code to
the /assets/ik_treemenu.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated tree menu with ChromeVox to ensure each
element described in the marking rubric below is functioning as
suggested.

Requirements

When you have applied your changes and tested to be sure your
tree menu functions as described, submit the URL to your tree.html
file on your GitHub Pages site, to the file on the web server you are
using to host your copy of the book files, or a GitHack URL.
Activity 13: Accessible Tree
Navigation | 257
Grading Rubric

Criteria Points
Instructions Provided:
When the tree menu receives focus, instructions are 1.0 pts
announced on how to use the menu with a keyboard.
Tree Menu Semantics:
When navigating through the tree menu with a keyboard, 2.0 pts
elements are announced with tree menu semantics.
Tree Submenus:
When a tree menu item with a submenu receive focus, the
2.0 pts
submenu state is announced as expanded when open or
collapsed when closed.
Focus Control:
Only elements of the tree menu that are in view are able to 2.0 pts
receive focus.
Keyboard Operable:
Tree menu functions with a keyboard as described in Adding 3.0 pts
Keyboard Operability for tree menus.
Total Points: 10.0

258 | Activity 13: Accessible Tree Navigation

Sortable Lists
One of the more common types of widgets that present barriers for
screen reader users are drag and drop features. These can be set up
in a grid, where draggable items can be rearranged horizontally or
vertically by clicking on an item and moving it to a new position in
the grid. A drag and drop may also be a sortable list, where items
in a list can be dragged vertically to perhaps position the more
important list items near the top of the list. For drag and drop
elements you may come across on the Web today, the vast majority
only function with a mouse, making them inaccessible to many
people who rely on a keyboard to navigate. Here, we will look at a
sortable list, and the WAI-ARIA and associated keyboard operability
required to make that list sortable while using only a screen reader
and a keyboard.

Role, states, and properties used in a sortable list

• role = “list”
• role = “listitem”
• tabindex = “[0 | -1]”
• aria-labelledby = “[instruction div id]”
• aria-hidden = “[true | false]”

Suggested Reading: 4 Major Patterns for Accessible Drag and

Drop

The following JSFiddle presents a typical sortable list widget. Review

the JavaScript and HTML markup, and test the list presented under

Sortable Lists | 259

the Result tab with ChromeVox to understand how it functions
without any accessibility features added. You can work in JSFiddle
itself by clicking “Edit in JSFiddle” at the top, right-hand side,
copying the accessibility/WAI-ARIA code described below to fix the
accessibility of the menu bar before completing Activity 14 on the
page that follows.

260 | Sortable Lists

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

As usual, create instructions on using the sortable list with a

keyboard. In this case, we also want to determine which modifier

Sortable Lists | 261

key to include in the instructions. For Mac, it will be the Command
key, otherwise it will be the Control key. Here, the standard
accesskey key commands will also work as the modifier and can
potentially be described as well (e.g., Ctrl + Alt on Mac, or Ctrl on
Windows).

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

Assign a redundant role="list" to the opening ul , make the

ul keyboard focusable, and attach the instruction with aria-
labelledby="[instruction div id]" so keyboard navigation
details are announced when the list initially receives focus while
using a screen reader.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

Within the init() function, generate the <div> that will

contain the instructions, and add aria-hidden="true" to hide it
from screen readers by default.

262 | Sortable Lists

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

In the items section of the init() function, where draggable

is defined for each item in the list, add a redundant
role="listitem" , and generate a label for each item that
describes the list item’s current position and that that list item is
“movable.” Finally, set tabindex="0" on the first list item, and
tabindex="-1" on the other list items in order to ensure a list
item is focusable by default.

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

Where the draggable attributes are defined near the end of the
init() function, attach a keydown reference to the
onKeyDown() function to make the list draggable with a keyboard.

Sortable Lists | 263

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

In the resetNumbering() function, update the label for moved

items to reflect their new position in the list using aria-label =
"[new position]" .

An interactive or media element has been excluded

from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

Adding Keyboard Operability

Keyboard operation for a drag and drop sortable list is relatively

simple, compared to the menu bar and tree menu. Essentially, only
the Up and Down arrow keys are needed. The standard operating
system modifier keys, typically used with tabindex (e.g., Crtl + Alt,
Alt, or Ctrl), function as the modifier keys when using them in
addition to the Up and Down arrows to grab, drag, and drop a list
item.
The onKeyDown() function for the sortable list presented
below, defines just up and down arrow key operability, along with

264 | Sortable Lists

a roving tabindex. W3C has not yet created a best practice for
authoring keyboard interaction for drag and drop elements.

Sortable Lists | 265

 An interactive or media element has been excluded
from this version of the text. You can view it online
here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

266 | Sortable Lists

Sortable List in Action

Watch the following video showing ChromeVox interacting with a

sortable list. The Tab key is used to navigate into the list and to exit
the list. The Up and Down arrows are used to move between list
items. On a Mac, the Command key plus Up or Down arrow, selects
a list item and moves it to a new location. On windows the Ctrl key
is used instead of Command, along with the Up or Down arrow keys
to move list items. Aim to have the sortable list you update in the
activity on the next page operate and announce itself like the one in
the video.
Video: Accessible Sortable List

Sortable Lists | 267

 A YouTube element has been excluded from this version of the
text. You can view it online here:
https://pressbooks.library.ryerson.ca/wafd/?p=379

268 | Sortable Lists

Activity 14: Accessible
Sortable List

Based on the Sortable List details on the

previous page, apply what you have learned to the associated book
files to make the sortable list there accessible.
Files for this activity include:

• /sortable.html
• /assets/ik_sortable.js

Use the surroundings of the highlighted code on the previous page

as a guide to find where the fixes should be applied, Repair the
accessibility of the sortable list by applying the highlighted code to
the /assets/ik_sortable.js file.
Note: While we suggest using the highlighted code we’ve
provided, you are free to come up with your own solutions provided
they produce the expected results listed in the marking rubric
below.
Test your updated sortable list with ChromeVox to ensure each
element described in the marking rubric below is functioning as
suggested.

Activity 14: Accessible Sortable

List | 269
Requirements

When you have applied your changes and tested to be sure your
sortable list functions as described, submit the URL to your
sortable.html file on your GitHub Pages site, to the file on the web
server you are using to host your copy of the book files, or a GitHack
URL.

Grading Rubric

Criteria Points
Instructions Provided:
Instructions are announced on using the sortable list with a 1.0 pts
keyboard when it first receives focus.
Movable List Items:
2.0
When navigating through list items, their position is announced
pts
along with an indication they can be moved.
List Items are Sortable:
Using the keyboard operation described in Adding Keyboard 3.0
Operability for sortable lists, list items can be moved without pts
using a mouse.
Moved position: 4.0
When a list items is moved, its new position is announced. pts
Total Points: 10.0

270 | Activity 14: Accessible Sortable List

Book Recap

Chapter 1 Summary

Chapter 1 focused on getting started and providing the background

information on the WAI-ARIA specification. The jQuery plugin being
developed throughout the book was also introduced, and access to
the inaccessible versions of the widgets that make up the plugin,
also known as the book files, was provided on GitHub. You were
also introduced to a MooTools WAI-ARIA library, and another jQuery
library that can also be used to quickly add WAI-ARIA to interactive
web elements.
Though the book is focused on jQuery, the application of WAI-
ARIA with other JavaScript frameworks will be quite similar.
Developers are encouraged to apply what they learn via jQuery to
other libraries they may be working with.
In Chapter 1, you were also introduced to the ChromeVox screen
reader. Though not a screen reader people who are blind would
often use, ChromeVox is an ideal tool for developers to test
accessibility in their day to day development work.

Chapter 2 Summary

In Chapter 2, a more detailed description of WAI-ARIA was provided,

with a discussion of when and when not to use it, understanding
WAI-ARIA roles, states, and properties, as well as differences
between static and dynamic application of WAI-ARIA. Though some
WAI-ARIA can be added directly to HTML as static attributes, in
many cases WAI-ARIA is added dynamically as needed using
JavaScript. We also looked at support across assistive technologies

Book Recap | 271

(AT) and web browsers. Currently (as of February 2019), support is
varied across these technologies but improving constantly.
We also introduced graceful degradation and progressive
enhancement as development methods that can be employed to
ensure that elements that may not yet be supported across all
technologies have alternatives available as fallbacks, ensuring
features are functional regardless of the technology being used.
Despite the variation in support for WAI-ARIA, developers are
encouraged to use it now, with the assumption that support for it
will continue to improve over the coming years.
We also introduced LightHouse and aXe, two tools that can be
used to validate WAI-ARIA to ensure it is being used correctly. These
tools can be added to Chrome, along with ChromeVox introduced
in Chapter 1, to have a collection of accessibility testing tools at
your fingertips when developing for the Web. Finally the WAI-ARIA
Taxonomy was introduced to help participants visualize the
structure and relationships between WAI-ARIA roles, states, and
properties.

Chapter 3 Summary

In Chapter 3, you built upon your understanding of WAI-ARIA with

some practical implementations by looking at landmarks for
implementing within page navigation for screen reader users, alerts
and messages for providing easy access feedback, the new tabindex
values 0 and -1 used to add keyboard access to elements that do
not typically have keyboard access, and development of roving
tabindexes that add and remove keyboard access as needed as users
interact with a widget or application.
We also looked briefly at the WAI-ARIA application and
presentation roles. The application role is typically used with
embedded web applications where keyboard interaction needs to be
intercepted so the application itself is being operated on rather than

272 | Book Recap

interacting with the assistive technology (AT) or the web browser.
When using the application role, care must be taken to not disable
other critical interactions with the web browser or AT and create
unintended barriers when standard functionality becomes disabled.
The presentation role is used to hide elements from screen
readers. They are typically used to hide table semantics when they
are used for layout and to hide away images that are decorative.
In the latter case, the presentation role works much like a null alt
attribute would. Like the application role, care must be taken when
using the presentation role to ensure meaningful information about
the content is not being removed inadvertently.
Finally, we introduced live regions as a way to present updating
information in web content. Typically, a screen reader processes
the HTML of a page when it loads, and when content in the page
changes, such as a newsfeed adding a new headline, they may not
notice that change. Live regions are a way to make that updated
information available to a screen reader, but care must be taken to
ensure that information that updates frequently does not interfere
with a screen reader’s ability to read content elsewhere on the page.

Chapter 4 Summary

In Chapter 4 and the two chapters that follow, the focus moved
to practical implementation of WAI-ARIA, looking at specific
interactions and the types of information that need to be available
to assistive technologies to ensure these interactions are accessible
to users of these AT.
In this unit, we looked specifically at:

• Suggestion Boxes: Instructions were provided on how to use

the suggestion box, which provides suggested terms as letters
are typed in, based on those letters. A live region was added to
announce suggestions, and keyboard access was provided

Book Recap | 273

 through the arrow keys scripted to navigate the suggestion list.
• Tooltips: When a parent element with a tooltip receives focus,
the tooltip appears in a live region and reads out loud. When
focus moves away, the tooltip disappears.
• Progress Bars: Instructions were provided on how to operate
the progress bar with a keyboard to announce the status of the
progress and indicate how far along progress is.

Chapter 5 Summary

In Chapter 5, the widgets got a little more complex. These included:

• Sliders: A slider bar and a slider thumb were created, minimum

and maximum values were set for the slider bar, and an
increment was set for the slider thumb, with each movement
of the thumb moving a specific distance along the slider bar.
Instructions were provided on how to operate the slider, with
arrow keys used to move left and right across the slider bar,
and Home and End keys used to move the slider thumb
between the start and end of the slider bar.
• Accordions: Two types of accordion interactions were
introduced: single or multiple accordion panels. They were
each opened one at a time and opened or closed by toggling
accordion headers with the Enter key or space bar. The Tab
key was used to navigate into an accordion, to navigate from
one header to another, or to navigate from a header to its
associated panel. Arrow keys were also used to navigate
between accordion headers but not to their associated panels.
• Tab Panels: Much like accordions are used to conserve space,
tab panels provide similar functionality, though typically
content is arranged horizontally whereas accordions typically
arrange content vertically. The Tab key is used to navigate into
the tabpanel’s tabs to navigate from tabs to their associated

274 | Book Recap

 panels and to exit the tabpanel. The Left and Right Arrow keys
are used to move between tabs, and when a panel has focus,
Shift + Tab is used to return focus to the tablist. The semantics
of the list used to create the tabpanel are replaced with tab
panel semantics.
• Carousels: Again, carousels are used to conserve space,
presenting a series of slides or panels that contain images and
text. A carousel typically rotates between panels automatically.
When the Tab key is used to enter the carousel, automatic
rotation stops, allowing users to spend as much time as they
need to consume the information on each panel. The Left and
Right Arrow keys are used to move between panels in the
carousel. When the carousel has focus, a live region is created
using the containing <div>, so as each slide comes into view its
content is automatically read. When the Tab key is used to exit
the carousel, the live region is removed and auto-rotation is
restored. Removing the live region ensures the content of the
slides does not continue to read out loud while the user is
navigating other areas of the page.

Chapter 6 Summary

In this final unit, the widgets got more complex yet.

• Menu Bars: Menu bars typically appear as a set of nested lists,

with the top level list arranged horizontally across the top of a
page and sublists acting as submenus. Specific menu bar and
menu WAI-ARIA attributes were used to replace the list
semantics with menu semantics, making them easier to
understand when operating them with a screen reader. The
Tab key is used to enter and exit the menu bar. Arrow keys are
used to move between menu items, the space bar is used to
open a submenu, and Esc is used to close an active submenu.

Book Recap | 275

 • Tree Menu: Tree menus often appear down the side of a page
and include top-level topics and related subtopics that expand
or contract with a toggle. Subtopics may open several levels
deep. The Tab key is used to enter and exit the tree menu, and
Up and Down Arrows are used to move between the menu
items that are displayed. A roving tabindex is used to prevent
focus on menu items that are not being displayed. When a
menu item is accessed that has subtopics, the space bar or the
Enter key can be used to toggle submenus open or closed.
When a menuitem with a submenu receives focus, its state —
expanded or collapsed — is announced by the screen reader. At
any time while in the tree menu, pressing the Tab key exits the
menu.
• Sortable List: The sortable list is a type of drag and drop
widget. Many of these currently found on the Web are difficult
or impossible to use with a keyboard alone, making them
inaccessible to many users. The Tab key is used to enter and
exit the list. Instructions are provided on how to operate the
list using a keyboard. Up and Down Arrows are used to move
up and down through the list. As list items receive focus, they
announce as movable to indicate that they can be rearranged.
Pressing Command, Alt + Ctrl, or just Alt — depending on the
browser and operating system — along with the Up or Down
Arrows, moves an item to an adjacent location in the list,
announcing the new location for that item.

276 | Book Recap

Web Accessibility for
Developers Toolkit

Toolkit Items Collected

Toolkit: Provides useful tools and resources for your future

reference.

• Join GitHub
• SourceTree
• GitHub Desktop
• jQuery UI Accessibility Enhancements
• Accessible MooTools Widgets
• WAI-ARIA Authoring Practices 1.1
• ARIA Techniques for WCAG 2.0
• Using WAI-ARIA
• ChromeVox Screen Reader
• ChromeVox_Key_Commands (Word)
• The ARIA Role Matrices
• WAI-ARIA Screen Reader Compatibility
• WAI-ARIA Browser Compatibility
• ARIA Alert Support
• User Agent Support Notes for ARIA Techniques
• W3C HTML Validator
• Chrome Developer Tools
• Lighthouse
• ARIA Validator
• aXe (for Chrome)

Web Accessibility for Developers

Toolkit | 277
 • aXe (for Firefox)
• Combobox
• Grid
• Listbox
• Menu or menu bar
• Radiogroup
• Tabs
• Toolbar
• Tree View

278 | Web Accessibility for Developers Toolkit

Answer Key: Self-Tests

Self-Test 1

1. What options are there for submitting book assignments? Choose

all that apply.
[Incorrect] a. Upload files to the assignment dropbox in
Pressbooks.
[Correct] b. Submit a URL to your files on GitHub.
[Incorrect] c. Email your assignment to the instructor.
[Correct] d. Submit a URL to your files on a server you have
FTP access to.
[Incorrect] e. Upload files to the assignment DropBox folder.
Feedback: You may submit a URL to your book files either on
GitHub (i.e., GitHub Pages), or on a web server you have FTP
access to.
2. Where can you get a copy of the book files? Choose all that
apply.
[Incorrect] a. Downloading from the book file manager
[Correct] b. Forking and cloning from GitHub
[Correct] c. Downloading from GitHub
[Incorrect] d. Ask the instructor to email them to you
[Incorrect] e. Download them from the assignment DropBox
folder
Feedback: You may download the learnaria.github.io
repository files from github.com, or you may fork the
repository to your own GitHub account and clone them from
there into your own development environment.
3. What prerequisite knowledge is needed to be effective with the
activities in this book? Select all that apply.
[Incorrect] a. No prerequisite knowledge is required.
[Incorrect] b. The ability to write JavaScript

Answer Key: Self-Tests | 279

 [Correct] c. The ability to read and understand JavaScript
[Correct] d. The ability to read and understand HTML
[Incorrect] e. A strong understanding of WCAG 2
Feedback: Coding experience is strongly recommended, but
not absolutely necessary to follow the book. Your ability to
read and understand JavaScript and HTML code will
determine your success with the activities in tis book.
4. When working with ChromeVox, what key or key combination
can be used to stop it from speaking?
[Incorrect] a. Alt
[Incorrect] b. Cvox + Q
[Incorrect] c. Cvox + D
[Correct] d. Ctrl
[Incorrect] e. Cvox + S
Feedback: The most asked question when using ChromeVox
is how to stop it from speaking. Simply press the Ctrl (control)
key to stop it from talking.
5. When working with ChromeVox, what key or key combination
can be used to turn it off, or on.
[Incorrect] a. Esc
[Correct] b. Cvox + A + A
[Incorrect] c. Cvox + Q
[Incorrect] d. Cvox + D
[Incorrect] e. Ctrl + F5
Feedback: The second most asked question is how to turn
ChromeVox on or off without having to find your way through
Manage Extensions. Press Cvox+A+A to turn the screen reader
on or off while using the Chrome web browser.
6. WAI-ARIA is part of HTML5 and will not work when older
versions of HTML are being used.
[Incorrect] a. True
[Correct] b. False
Feedback: WAI-ARIA works fine with older versions of
HTML, though when validating older HTML, it will produce

280 | Answer Key: Self-Tests

 errors or warnings. These errors or warnings can be safely
ignored.
Back to Self-Test 1

Self-Test 2

1. When creating a registration form for a website, it is important

to use role=”form” with the element to ensure screen reader users
understand they are entering a form.
[Incorrect] a. True
[Correct] b. False
Feedback: A form element has its semantics defined by
default, thus does not need a WAI-ARIA role defined. When
using HTML in a standard way, WAI-ARIA should not be used,
with a few exceptions.
2. When talking about WAI-ARIA, we are referring to:
[Incorrect] a. roles, settings, and properties
[Incorrect] b. roles, options, and preferences
[Correct] c. roles, states, and properties
[Incorrect] d. elements, attributes, and functions
[Incorrect] e. elements, options, and preferences
Feedback: WAI-ARIA is made up of HTML attributes that
define roles, states, and properties.
3. Which of the following are not WAI-ARIA roles? Choose all that
apply.
[Incorrect] a. menu
[Incorrect] b. navigation
[Correct] c. aria-label
[Correct] d. tabindex
[Correct] e. aria-describedby
[Correct] f. aria-checked
[Incorrect] g. complementary

Answer Key: Self-Tests | 281

 [Correct] h. footer
[Incorrect] i. banner
Feedback: Any WAI-ARIA attribute that is prefixed with
“aria-” will be a state or property, not a role. The tabindex
attribute is special case, extending tabindex in previous
versions of HTML, but it is not a role. Footer is not defined in
WAI-ARIA.
4. WAI-ARIA Properties tend not to change.
[Correct] a. TRUE
[Incorrect] b. FALSE
Feedback: True. States tend to change. Properties do not.
5. WAI-ARIA States tend not to change.
[Incorrect] a. TRUE
[Correct] b. FALSE
Feedback: False. States do tend to change.
6. Which of the following tend to be used dynamically, with values
updated using scripting? Choose all that apply.
[Incorrect] a. role=”menu”
[Correct] b. aria-disabled=”true”
[Incorrect] c. aria-haspopup=”true”
[Incorrect] d. aria-modal=”true”
[Correct] e. aria-checked=”true”
[Correct] f. aria-expanded=”false”
[Correct] g. aria-hidden=”true”
Feedback: Typically states will be dynamically updated with
scripting (aria-disabled, aria-checked, aria-expanded, aria-
hidden) while properties tend to be static, and do not usually
change (aria-haspopup, aria-modal). Roles also tend to be
static, and do not require updating values with scripting.
7. ______________ starts with a version that works for
everyone, then adds features when they are supported.
[Incorrect] a. Graceful degradation
[Correct] b. Progressive enhancement
Feedback: Progressive enhancements starts with a base

282 | Answer Key: Self-Tests

 version that works for everyone, and are “enhanced” with
additional features where they are supported.
8. Generally, which method is preferred?
[Incorrect] a. Graceful degradation
[Correct] b. Progressive enhancement
Feedback: For broadest support, progressive enhancement
is generally preferred, to ensure that regardless of the
technology a person may be using, there will always be a
functional version available.
Back to Self-Test 2

Self-Test 3

1. Which of the following are landmark roles? Choose all that apply.
[Incorrect] a. menu
[Correct] b. navigation
[Incorrect] c. aria-label
[Incorrect] d. tabindex
[Incorrect] e. aria-describedby
[Incorrect] f. aria-checked
[Correct] g. complementary
[Incorrect] h. footer
[Correct] i. banner
Feedback: Navigation, complementary, and banner are
landmark roles.
2. Which would usually be the best approach to provide
feedback to a screen reader user with a message that an
operation just completed was successful or has failed
presenting an error message?
[Incorrect] a. aria-live=”polite”
[Correct] b. role=”alert”
[Incorrect] c. role=”alertdialog”

Answer Key: Self-Tests | 283

 [Incorrect] d. role=”dialog”
[Incorrect] e. aria-modal=”true”
Feedback: Though you could use aria-live=”polite” to
present feedback, the best approach is usually to use
role=”alert”.
3. Keyboard interaction in web widgets and applications should be
(choose all that apply):

[Correct] a. Predictable
[Incorrect] b. Redundant
[Incorrect] c. Easy
[Correct] d. Consistent
[Correct] e. Conventional
Feedback: Keyboard interaction should be predictable,
consistent, and conventional.
4. Which of the following WAI-ARIA roles, when active, would
disable keyboard access to the file menu in a web browser?

[Correct] a. Application
[Incorrect] b. Menu
[Incorrect] c. Menubar
[Incorrect] d. Navigation
[Incorrect] e. Presentation
Feedback: The Application role would disable the browser’s
file menu.
5. When role=”presentation” is used on an unordered list element,
semantics for which of the following elements would be fully
suppressed? Choose all that apply.
<ul role=”presentation”>…</ul>

[Correct] a. UL
[Correct] b. UL>LI
[Incorrect] c. UL>LI>UL
[Incorrect] d. UL>LI>OL
[Incorrect] e. UL>LI>UL>LI

284 | Answer Key: Self-Tests

 Feedback: Only the semantics of the top level UL and it’s
immediate children will be suppressed. That is, the first level
UL and its first level child LIs.
6. Which of the following create live regions that announce
changes in the content to screen readers? Choose all that apply.

[Correct] a. role=”alert”
[Correct] b. aria-live=”polite”
[Correct] c. role=”timer”
[Correct] d. role=”log”
[Incorrect] e. role=”live-region”
Feedback: All except the last choice will create live regions.
role=”live-region” is not a WAI-ARIA role or live region.
7. Which of the following would be good candidates for a live
region? Choose all that apply.
[Incorrect] a. A timer counting down by seconds
[Correct] b. A dynamically injected feedback message
[Correct] c. A news feed from a local news provider
[Correct] d. A twitter feed that receives occasional updates
[Correct] e. A chat application, for communicating in real time
Feedback: A timer may also be a live region, but counting
down by seconds may make the content on the page it is
embedded in unusable. A timer counting down by minutes
(e.g., minutes until the end of a quiz) would be a better
candidate.
Back to Self-Test 3

Answer Key: Self-Tests | 285

Acknowledgements
This book was made possible with a grant from The Government of
Ontario’s Enabling Change Program. Content was written by Greg
Gay, with help from the team at Digital Education Strategies at
The Chang School, Ryerson University, and the original code and
the jQuery library used to create the activities for the course were
written by Igor Karasyov.

286 | Acknowledgements