Creating accessible modals and autocompletes

Before we look at modals, a
quick overview of the term
“non-native widgets”.

Let’s start with the term
“widgets”.

The W3C defines “Widgets” as:
“user-interface objects that
enable users to perform a
function”.

How about a
simpler explanation?

Widgets can be simple objects
such as a check box.

They can also be complex
objects such as drop-downs,
date pickers or even grids.

Basically, any self-contained
UI component.

What about the term “non-
native”?

“Non-native” means that the
widget has not been built using
native HTML elements.
(Elements that were designed for that purpose).

Let’s use an example of a
simple drop-down menu.

Choose an option
Favourite fruit
Label associated with dropdown

Choose an option
Favourite fruit
Dropdown

A native method would be to
use the <select> and <option>
elements.

<label for="fruit">Favourite fruit</label>
<select id="fruit">
<option>Choose an option</option>
<option>Apple</option>
<option>Apricot</option>
<option>Avocado</option>
</select>

The <select> and <option>
elements have semantic
meaning.

The W3C defines the <select>
element as an “option
selector”.

The <option> element is
defined as a “selectable
choice”.

These elements are understood
by all of the different
accessibility APIs associated
with browsers.

For example, the <select>
element has a role of
“combobox”.

There are also a range of  
pre-defined keystrokes that  
can be used to interact with
these elements.

However, <option> elements
are impossible to style with
CSS.

So, developers often choose
non-native alternatives  
for drop-downs, to provide
them with more control.

One common method is to use
the <button> and <ul>
elements.

Favourite fruit
Apple

Apricot

Avocado
List

<button>Favourite fruit</button>
<ul>
<li>Apple</li>
<li>Apricot</li>
<li>Avocado</li>
<li>Banana</li>
</ul>

This is an example of a non-
native widget, as elements are
being used in a different way
to their defined purpose.

How is “non-
native”relevant here?

Well, this “non-native” concept
is relevant for modals and
autocompletes.

While it is possible to build
modals and autocompletes
using native HTML elements,
most developers don’t.

So, these widgets often end up
being non-native.

For example, there is a
<dialog> element designed for
modal dialogs.
https://www.w3.org/TR/html52/interactive-
elements.html#the-dialog-element

<dialog open>
<p>Hello world</p>
</dialog>

However, this element is
reasonably new and has
limited support across devices
and Assistive Technologies.

There is also a <datalist>
element designed for simple
autosuggests.
https://www.w3.org/TR/html52/sec-forms.html#the-
datalist-element

<label for="choice">Choose a flavor:</label>
<input list="flavors" id="choice">
<datalist id="flavors">
<option value="Chocolate">
<option value="Coconut">
<option value="Mint">
<option value="Strawberry">
<option value="Vanilla">
</datalist>

But this element has limited
functionality and doesn’t suit
the needs of most autosuggest
widgets.

So, it’s often easier and more
practical for developers to
choose the dark side.

On top of this, a lot of
developers these days don’t
know about basic semantic
markup.

So, they don’t even choose the
dark side. They start there!

In many cases, non-native
widgets need a lot of work in
order to be accessible.

1. Non-native widgets must be
given a role so that their
function is understood.

2. Users must be notified of
dynamic changes to the
widget (i.e. has it changed
state?).

3. In some cases, additional
instructions may be needed so
that users can learn how to use
the widget.

4. All functionality must be
accessible via keystrokes
only.

5. Keystrokes should be
intuitive, and follow keystroke
methodologies used on native
elements.

So… that is the end of my 
“non-native widgets” rant…

Let’s dive into
accessible modals.

A modal is a function that
requires the user to perform
some sort of action before
proceeding.

Generally, modals are separate
“windows” that sit over the
top of the parent page.

Account name:
Choose an account
Account number:
Submit
xGreyed out background (in some cases)

Account name:
Choose an account
Account number:
Submit
xModal window

Account name:
Choose an account
Account number:
Submit
xClose button

Account name:
Choose an account
Account number:
Submit
x
Main heading inside modal

Account name:
Choose an account
Account number:
Submit
x
2 x Inputs and their labels

Account name:
Choose an account
Account number:
Submit
x
Submit button

The following are a short list of
common modal accessibility
problems.

In reality, we could spend the
rest of this presentation just
listing known problems…
but let’s not.

1. The modal is not accessible
via keyboard-only.

This means that keyboard-only
users may not be able to
access, interact with or close
the modal.

2. Keyboard-only users are able
to use TAB outside of the
modal window while the
modal is still active.

users can get trapped outside
the modal.

And screen reader users
assume that the modal has
been dismissed - even though
it still sits on top of the page.

3. The modal is available to
screen readers even when it is
not triggered.

This means that the modal
information is announced to
screen reader users at
inappropriate times.

4. When the modal is triggered,
screen reader users are not
informed of its role or
purpose.

This means that screen reader
users may have no idea where
they are or what task they are
supposed to perform.

5. Focus is often sent to the top
of the parent page after a
modal window has been closed.

users have to navigate back to
the relevant area themselves.

So, how can we build an
accessible modal?

When a modal is triggered,
some developers set the initial
focus on the first focusable
element inside the modal.

For example, focus may be
placed on the first form
control.

Account name:
Choose an account
Account number:
Submit
x
Focus on first form control

This means that Assistive
Technology users may not be
able to determine the overall
purpose of the modal.

Instead, I prefer to set focus on
the modal window itself. At
least for modals where the
purpose is not immediately
clear.

Account name:
Choose an account
Account number:
Submit
xFocus on modal window

Then additional context can be
provided via a label.
(Described in step 3)

A role should be provided on
the parent container.

This role is announced to
Assistive Technology users,
informing them about the
widget’s function.

Avoid using a role with a value
of alertdialog unless the
modal has a critical purpose.

The alertdialog value should
only be used to notify the user
of urgent information that
demands the user's
immediate attention.

A label should be used to
inform Assistive Technology
users of the modal window’s
purpose.

One way to achieve this is to
point an aria-labelledby
attribute at the main heading
inside the modal.

<div
role="dialog"
aria-labelledby="modal-label">
<h1 id="modal-label">Choose account</h1>
</div>

4. Add a
description
(optional)

A description can also be added
to provide a more detailed
description of the modal’s
purpose.

This can be achieved by
pointing an aria-describedby
attribute at the first
paragraph of text inside the
modal.

<div
role="dialog"
aria-labelledby="modal-label"
aria-describedby="modal-description">
<h1 id="modal-label">Choose account</h1>
<p id="modal-description">Description here</p>
</div>

If there is no headings or
paragraphs within the modal,
hidden information can be
used instead.

Users should be able to use TAB
and SHIFT + TAB to move
forwards and backwards
through focusable elements.

Users should not be able to use
TAB to move focus outside the
modal.

Focus should cycle through
focusable elements within the
modal only.

Users should be able to use
standard keystrokes on any
form elements inside the
modal.
(Radios, checkboxes, selects and buttons).

Users should be able to use ESC
to close the modal and return
to the parent page.

For some important actions,
screen reader users may need
to be given additional
information to let them know
what will happen.

“Submit. Your data will be
added to the bank balance
table”

<button aria-label="Submit. Your data will be added to
the bank balance table">
Submit
</button>

“Close and return to bank
information”

When the modal window has
been closed (via, ESC, close or
submit function):

Focus should be set on the
relevant component of the
parent page.

The user should not be sent to
the top of the parent page
unless there is a good reason!

For simpler modals, especially
on close, focus can be sent
back to the trigger function.

If the modal causes
information to be dynamically
added to the parent page
below, focus should be sent to
this newly added
information.

Ideally, this newly added
information should be
announced to Assistive
Technologies.

“$1200.34 added to your bank
balance”

Regardless of whether you use
some or all of these
suggestions, you should
always conduct your own
tests.

And remember: 
context is everything.

The Incredible Accessible
Modal Window, Version 4
http://gdkraus.github.io/accessible-modal-dialog/

Bootstrap V4 modal
https://getbootstrap.com/docs/4.3/components/
modal/

Van11y modal
https://van11y.net/downloads/modal/demo/
index.html

Part 2:
Accessible 
Autocompletes

“Autocomplete” is a software
function that provides
relevant suggestions based on
input by the user.

For this presentation, we’re
going to focus on an example
autocomplete associated with
searching for towns in
Australia.

Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest search component
Label

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Input

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Clear mechanism

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Submit button

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Drop-down suggestions list

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Scroll bar (if needed)

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Results area below

How do we make an
autocomplete widget
accessible?

Some of this is going to sound
awfully familiar…

Keyboard-only users should be
able to perform any of the
following actions…

1. Use the TAB keystroke to
move focus into the search
input field from a previous
element with focus.

Diagram showing input in focus
TAB

move focus from the search
input to the “clear” button.

Adaminaby, NSW
Diagram showing clear button in focus
TAB

3. Use the ENTER keystroke to
trigger the “clear” button.

Adaminaby, NSW
Diagram showing selected clear button
ENTER

Note: When the “clear” button
has been triggered, the search
input field should be cleared
and focus should shift to this
field again.

Diagram showing focus move for clear button back to search input

move focus from the clear
button to the submit button.

Adaminaby, NSW
Diagram showing focus move form the clear button to the submit button
TAB

5. Use the ENTER keystroke to
trigger the submit button.

Adaminaby, NSW
Diagram showing selected submit button
ENTER

Note: When the submit button
has been triggered, focus
should shift to the first search
result below the autocomplete
search widget.

Bell, NSW
Bell is a small rural and residential village in the
Blue Mountains region of New South Wales.
Bells Beach, VIC
Bells Beach is a coastal locality of Victoria,
Australia iand a renowned surf beach.
Bell
Diagram showing focus move from submit button to first search result

6. Use the DOWN ARROW
keystroke to move focus from
the search input field to the
first item in list of
autocomplete suggestions.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing focus move from input to first suggestion
DOWN ARROW

7. Use the UP ARROW and DOWN
ARROW keystrokes to navigate
backwards and forwards
through suggestions.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing second selection in focus and arrows to indicate focus can move backwards or forwards
DOWN ARROW
UP ARROW

8: Users should not be able to
DOWN ARROW past the last
suggestion option.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing last selection in focus and red cross to indicate focus cannot go forward
DOWN ARROW

9. Some developers allow DOWN
ARROW keystrokes to loop from
the last suggestion directly
back to the initial input box.

However, I have found that
some users find this
confusing. They may not be
aware that they have returning
to the input field.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing last selection in focus and red cross to indicate focus cannot jump to search input
DOWN ARROW

I prefer to follow the default
<select> behaviour where
focus loops through all
options only.
From last back to first etc.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing last selection in focus and focus jumping to the ﬁrst option
DOWN ARROW

10. Use the ENTER keystrokes to
select an autocomplete
suggestion.

ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing selected suggest option
ENTER

Note: When the ENTER
keystroke has been triggered,
focus should shift back to the
search input field.

Armadale, WA
Diagram showing focus move from selected suggestion to search input ﬁeld

11. Use the ESC keystroke to
close the suggestion list and
return focus to the initial input
(i.e. if none of the suggestions
are relevant).

ar
Diagram showing focus returning to input
ESC

There are a wide range of
different ways to mark up an
accessible auto-suggest widget.
Here are some suggestions.

The <label> and <input>
elements are the core of the
search button.

In our example, one <button>
element will be used to “clear”
user input.

And a second <button>
element will be used to submit
the form.

The <ul> allows us to display
the list of suggestions when
appropriate.

The <div> element allows us to
provide hidden instructions
for screen reader users.

In order to explicitly associate
the <label> element with the
<input> element, we should
use for and id attributes.

<label for="search">Search towns in Australia</label>
<input
id="search"
>

The <input> element’s type
attribute could be set to a value
of "text" and not "search".

Some browsers, like Chrome
and Safari will display an
<input> type of "search" with
a native “clear” button at the
right side of the input.

Other browses like Firefox, do
not show this function at all.

Chrome
Firefox
Safari
Diagram showing Chrome and Safari’s clear button. Firefox has no clear button.

More importantly, this native
“clear” button often cannot be
accessed via the TAB
keystroke, so it is inaccessible
for many Assistive Technology
users.

So, it is better to use a separate
<button> element for clearing
the field.

The aria-describedby attribute
can be used to provide basic
instructions on the use of the
widget for Assistive
Technologies.

This points to a matching ID
value inside the hidden <div>
element below.

<input
id="search"
type="text"
aria-describedby="instructions"
>
<div id="instructions" aria-live="assertive"
style="display: none;">
When autocomplete options are available, use up and
down arrows to review and enter to select.
</div>

The aria-owns attribute
defines a “parent/child
contextual relationship to
assistive technologies that is
otherwise impossible to infer
from the DOM”.

In other words, we can define
the <input> element as the
parent, and the <ul> element
as the child element.

The aria-expanded attribute
allows us to inform assistive
technologies when the
autocomplete dropdown 
is present (expanded).

The aria-expanded attribute
should be initially set to
"false".

This value needs to
dynamically change to "true"
as soon as the autocomplete
suggestions are present.

Directly after the input, we
need two <button> elements.

The first <button> should be a
type of "button" and allow
users to clear the input.

The second <button> should be
a type of "submit" and allow
users to submit the form.

You may want to use icons
instead of text for one or both
of the buttons. In this case we
are using “clear” and “search”
icons.

Diagram showing clear and search icons

However, if you user icons
instead of text, you will need to
provide additional context for
Assistive Technologies.

In this case, we can use aria-
label attributes to provide
hidden labels for both
buttons.

After the two button elements,
we need to add the <ul>
element which will be used to
display the autocomplete
suggestions.

The role attribute can be set
with "listbox".

This informs assistive
technologies that the element
is a widget that allows the
user to select one or more
items from a list of choices.

To make sure the element
cannot be brought into focus
before it is triggered, we can
set the tabindex attribute to
"-1".

This value needs to
dynamically change to "0" as
soon as the autocomplete
suggestions are present.

To make sure the element is
initially hidden we can set the
style attribute to
"display:none".

This value needs to
dynamically change to
something like
"display:block" as soon as the
autocomplete options are
triggered.

Each of the <li> elements can
be given a role attribute with
a value of "option".

This informs assistive
technologies that they are
selectable items in a
select list.

<ul
id="results"
role="listbox"
tabindex="-1"
>
<li role="option">apple</li>
<li role="option">banana</li>
<li role="option">pear</li>
</ul>

Each of the <li> elements
needs to have an aria-
selected attribute initially set
to "false".

<ul
id="results"
role="listbox"
tabindex="-1"
>
<li role="option" aria-selected="false">apple</li>
<li role="option" aria-selected="false">banana</li>
<li role="option" aria-selected="false">pear</li>
</ul>

This value needs to
dynamically change to "true"
if the individual option is
selected.

<ul
id="results"
role="listbox"
tabindex="-1"
>
<li role="option" aria-selected="true">apple</li>
<li role="option" aria-selected="false">banana</li>
<li role="option" aria-selected="false">pear</li>
</ul>

After the <ul> element, we
have the <div> element, which
has the instructions for
assistive technologies.

As mentioned before, the ID
value allows us to point the
<input> element to this <div>
element via the aria-
describedby attribute.

The <div> element needs to be
visually hidden, but still
available to screen readers.

This can be achieved by setting
it “off-left” using CSS. So, we
can give it a pretend “off-left”
class here.

The aria-live attribute is set
to "assertive". This informs
assistive technologies as soon
as anything inside this element
is dynamically changed.

We need this because the
instructions will dynamically
change as soon as the
autocomplete options are
triggered.

<div
id="instructions"
class="off-left"
>
When autocomplete results are available use up and
</div>

<div
id="instructions"
class="off-left"
>
6 options available. Use up and down arrows to review
and enter to select.
</div>

The instructions should also
immediately change as users
type if the number of
suggestions changes.

<div
id="instructions"
class="off-left"
>
3 options available. Use up and down arrows to review
and enter to select.
</div>

As mentioned before, this is
just one method that could be
used.

Before deciding, make sure you
check out different methods
and test them - with real
users, and across different
assistive technologies.

Haltersweb Accessible
Autocomplete
https://haltersweb.github.io/Accessibility/
autocomplete.html

Vision Australia Autocomplete
http://www.visionaustralia.org/digital-access-autocomplete

jQuery accessible autocomplete list
(with some ARIA)
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Alphagov Accessible Autocomplete
examples
https://alphagov.github.io/accessible-autocomplete/examples/

OpenAjax Combobox with aria-
autocomplete="inline"
http://oaa-accessibility.org/examplep/combobox2/

Anyone who is designing or
building web apps has to deal
with non-native widgets.

Modals, autocompletes,
dropdowns, date pickers,
sortable tables… the list is
endless.

The key message here is that
non-native widgets can
present a range of barriers.

However, these barriers can
always be resolved. It just takes
a bit more time and effort.

Russ Weakley
Max Design

Site: maxdesign.com.au

Twitter: twitter.com/russmaxdesign

Slideshare: slideshare.net/maxdesign

Linkedin: linkedin.com/in/russweakley

Creating accessible modals and autocompletes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Creating accessible modals and autocompletes

Similar to Creating accessible modals and autocompletes (20)

More from Russ Weakley

More from Russ Weakley (16)

Recently uploaded

Recently uploaded (20)

Creating accessible modals and autocompletes