Accessible modal windows

A modal window is a window
that forces the user to interact
with it before they can go back to
using the parent page.

Generally, modal windows are
designed to sit over the top of
the parent page. In some cases,
the parent page is greyed out so
that users can visually focus on the
modal dialog only.

Diﬀerent types of
modal window

Modal windows can be used for
all sorts of different roles such
as:

Modal windows should not be
mistaken for modeless windows.

Modeless windows are secondary
windows that stay active on the
user's screen until dismissed.
Modeless windows can be
minimised or hidden behind other
windows.

Unlike a modal window, a
modeless window will allow the
user to continue working with
the application while the modeless
window is still open.

What makes an
accessible modal
window?

Users must be able to navigate
through the modal window as
needed using keyboard-only.

Users should be able to close the
modal window using keyboard-
only.

Users should not be able to TAB
outside of the modal window
until the modal window has been
closed.

There should be no hidden
keystrokes as users move through
the modal window.

All relevant components should be
identified to screen reader users
as they are accessed.

Screen readers should be notified
of changes as they occur.

Focus should be placed on
relevant areas as changes occur.

The process should be easy to
understand for any type of user -
keyboard only user, screen reader
user, general user.

Informing users
before modal
window spawning

If a modal window spawns from a
focusable element, screen reader
users should be given additional
information to let them know
what will happen.

This can be done using a range of
different methods, depending on
the element that is used.

For hyperlinks, we could add
additional information using the
“title”, aria-labelledby, or “aria-
label” attributes. Or we could
place the addition information
inside the link and then hide it.

!
<a href="#id-name" !
! title="Added info">!
! Add bank account!
</a>!

!
! aria-label="Add bank account - Added
info">!
! Add bank account!
</a>!

!
! aria-labelledby="info1">!
! Add bank account!
</a>!
<p id="info1" class="hidden">!
! Added info!
</p>!

!
<a href="#id-name">!
! Add bank account!
! <span class="hidden">Added info</span>!
</a>!

For <button> elements, we
could use any of these same
techniques.

!
<button id="id-name" !
! title="Added info">!
! Add bank account!
</button>!

!
! aria-label="Add bank account - Added
info">!
! Add bank account!
</button>!

!
! aria-labelledby="info1">!
! Add bank account!
</button>!
<p id="info1" class="hidden">!
! Added info!
</p>!

!
<button id="id-name">!
! Add bank account!
! <span class="hidden">Added info</span>!
</button>!

For <input> elements, we could
use any of these same techniques -
except the hidden method as we
cannot place HTML markup inside
input elements.

For <img> elements, we could
use any of the above techniques or
even add info into the “alt”
attribute.

!
! <img src="a.gif" !
! alt="Add bank account - Added info">!
</a>!

Hiding and
showing modal
windows

Initially, we need to hide the
modal dialog content so that is
not seen by sighted users or heard
by screen reader users.

!
<div!
! style="display:none">!
! ...!
</div>!

When a user triggers the modal
window, we need to use
JavaScript to switch the values
within these two attributes.

The “display” value needs to
change from “none” to “block”.

!
<div!
! style="display:block">!
! ...!
</div>!

When the modal window becomes
active, the rest of the page -
everything apart from the modal
window container, could then be
set with aria-hidden=“true”.

!
<div!
! aria-hidden="true">!
! ...!
</div>!
!
!
<div!
! style="display:block">!
! ...!
</div>!
!

Notifying screen
readers when
arriving at modal
window

When a modal window is
spawned, we need to provide a
range of information to screen
reader users.

1. Setting focus on the
modal window

The first thing we need to do
when a modal window spawns is
set the initial focus to the modal
window element itself.

This is important because we are
going to give the window a label
as well as potentially adding
additional descriptive information.

If we set focus on an element
inside the window, such as the
first form control, the label and
additional information will not
be heard by screen reader users.

We need to inform screen reader
users that this modal window is a
“modal dialog”. We can do this by
adding role=“dialog”.

!
<div!
! style="display:block"!
! aria-hidden="false"!
! role="dialog">!
! ...!
</div>

We need to provide a label for
the modal dialog, so screen
reader users know its purpose.

We can do this by linking the
modal dialog container to the
primary <hn> element using
“aria-labeledby”.

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

Now the heading will be
announced to screen reader
users when the modal dialog is
spawned.

4. Adding optional
additional information

In some circumstances, such as
complex modal dialogs, we may
need to provide a more detailed
description of the purpose of the
modal dialog.

We can provide additional
information by linking the modal
dialog container to some
descriptive content using “aria-
describedby”.

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

Ideally, this content should be
hidden or placed at the end of
the modal dialog content, after
all other content in the source.

Otherwise it can be read-aloud
twice in quick succession by
screen readers, which can be
confusing for some users.

5. Working with older
Assistive Technologies?

What about older assistive
technologies that may not
support some of the more
advanced ARIA attributes?

If this is an issue, other simpler
options may need to be
considered.

One simple option would be to
provide a special focusable
element, such as a link, that
comes before all others.

This could be presented as a
simple “Information” icon that
sits in the top left corner of the
window.

We could then add a description
of the modal window to this link.

!
! <img src="a.gif" alt="Help">!
! <span class="tooltip">Added info</span>!
</a>!
!

This method could be useful for
both screen reader users and
general users, as the information
could be made visible as a
tooltip on focus.

Actions outside
the modal window

Users should not be able to
mouse-click on any focusable
element outside the modal
window while it is open.

Users should not be able to use
TAB keystrokes to focus on any
focusable element outside the
modal window while it is open.

Users should be able to mouse-
click to enable any focusable
element inside the modal window
while it is open.

Users should be able to use TAB
keystrokes to navigate to any
focusable element inside the

Users should be able to use
SHIFT + TAB keystrokes to
navigate backwards to any
focusable element inside the

ENTER or SPACE keystrokes on
relevant elements while inside the
modal window - especially if they
are button elements.

When inside form controls,
ARROW keys are generally used to
allow users to navigate user-
entered text within the form
control.

An example might be a user
entering data into a <textarea>
element. The user can navigate
within their entered text using
ARROW keys to move to previous
and next characters, next line etc.

However, some form controls use
ARROW keys to allow users to
choose options within a set of
choices.

For example, radio buttons and
select menus allow users to
navigate through choices using
ARROW keys.

So, users should be able to use
ARROW keystrokes to change
radio button options.

ARROW keystrokes to change
select menu options.

Users should be able to use the
ESC key to close modal.

Modal windows
and screen reader
“read” mode

Screen readers generally operate
in one of two modes: ‘read’ mode
and ‘form’ mode.

In “read” mode, users can read
and navigate the page. Users
cannot interact with form controls

In “form” mode, users can interact
with form controls. Users cannot
read and navigate the page.

In some cases, modal windows
may include important content
that is not form-related. In these
cases, screen reader users need to
be able to operate in “read” mode.

This means that screen reader
users must be able to navigate
though content using all of the
standard “read” mode keys.

In these cases, we could wrap a
new element around all the
content within the window and
set it with role=“document”.

The “document” role informs
screen readers of the need to
augment browser keyboard
support so that users can navigate
and read any content within the
“document” region.

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

Adding meaning to
important actions

For some important actions inside
the modal window, screen reader
users should be given additional
information to let them know
what will happen.

As screen reader users are
submitting form data, they
should be informed that:

1. they will be taken back to the
parent page.

2. where this data will be
submitted when they return to
the parent page.

ENTER
“Submit and return to bank
balance information. Your
data will be added to the
Balance table”

As screen reader users focus on
the “Close” function, they should
be informed that closing will
take them back to the parent
page.

ENTER
“Leave form and return to
bank balance information”

Is it better to present to “Close”
button before any form controls in
tab order, or after any form
controls.

A lot will depend on the
complexity and amount of
content inside the modal window.

For simple modal windows, it may
be easier to place the “Close”
button last in tab order.

For complex modal windows,
where users may want to go back
to the parent page quickly without
having to TAB through the whole
window, it may be better to place
the “Close” button first in tab
order.

On sites where there are
numerous different modal dialogs,
the most important thing is
consistency. Decided on a method
and use it for all modal windows
so that it becomes predictable.

When the modal window is closed,
if users are being taken back to
the parent page:

1. Focus should be placed on the
relevant component of the parent
page. The most common practice
is to move focus back to the
element that invoked the dialog.

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

2. The user should be informed
where they are and what change
has occurred.

Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut laoreet dolore magna aliquam
erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip vel eum iriure dolor in
hendrerit in vulputate.
Accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum
dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat.
Heading here
Another thing here
Add your bank balance
Another heading
$1,200.34
Focus
“Bank balance $1200.34 added
to bank information table”

A huge thanks to Roger Hudson,
Steve Faulkner and James
Edwards for their advice and
feedback on these slides.

Russ Weakley
Max Design
!
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Linkedin: linkedin.com/in/russweakley

Accessible modal windows

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Accessible modal windows

Similar to Accessible modal windows (20)

More from Russ Weakley

More from Russ Weakley (19)

Recently uploaded

Recently uploaded (20)

Accessible modal windows