accessible modal windows

Accessible modal

windows

What is a modal window?

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.

Different types of modal window

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

Modal alerts

Modal dialogs

Modal lightboxes

Modeless windows

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?

Keyboard only

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.

Screen reader

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.

General user

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.

Hyperlinks

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.

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

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

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

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

Buttons

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

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

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

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

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

Inputs

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

Images

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

<!-- alt attribute -->!<a href="#id-name">!! <img src="a.gif" !! alt="Add bank account - Added info">!</a>!

Hiding and showing modal

windows

1. Hiding the modal window

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

<!-- hiding modal window -->!<div!! style="display:none">!! ...!</div>!

2. Showing the modal window

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

<!-- aria-hidden -->!<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”.

<!-- all other content -->!<div!! aria-hidden="true">!! ...!</div>!!<!-- modal window -->!<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.

Initial focus

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.

Initial focus

2. Add “dialog” role

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

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

3. Adding a label

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

<!-- adding aria labelledby -->!<div!! style="display:block"!! aria-hidden="false"!! 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”.

<!-- adding aria labelledby -->!<div!! style="display:block"!! aria-hidden="false"!! 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.

<!-- help info -->!<a href="#id-name">!! <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.

CLICK

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

TAB

Actions inside modal window

Mouse

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

CLICK

CLICK

CLICK

CLICK

CLICK

CLICK

CLICK

TAB keystroke

Users should be able to use TAB keystrokes to navigate to any focusable element inside the modal window while it is open.

TAB

TAB

TAB

TAB

TAB

TAB

TAB

SHIFT + TAB keystroke

Users should be able to use SHIFT + TAB keystrokes to navigate backwards to any focusable element inside the modal window while it is open.

SHIFT + TAB

SHIFT + TAB

SHIFT + TAB

SHIFT + TAB

SHIFT + TAB

SHIFT + TAB

SHIFT + TAB

ENTER and SPACE keystrokes

Users should be able to use ENTER or SPACE keystrokes on relevant elements while inside the modal window - especially if they are button elements.

ENTER

ENTER

SPACE

SPACE

ARROW keystrokes

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.

TAB

ARROW

Users should be able to use ARROW keystrokes to change select menu options.

Option 1 - applesARROW

Option 2 - pearsARROW

Option 3 - bananasARROW

ESC keystroke

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

ESC

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.

<!-- adding aria role -->!<div!! style="display:block"!! aria-hidden="false"!! 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>!</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.

Submit

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”

Close window

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”

A question on tab order

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.

Simple modal windows

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

1

2

3

Complex modal windows

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.

1

2

3

4

5

6

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.

After modal dialog closes

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.

ENTER

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”

Thanks to…

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