Exploring modals for internal systems

[jamesmckechnie]

Exploring modals for internal systems

The idea of the modal is to encourage the user to consider an action which has potentially destructive consequences. It allows user to confirm this action without being taken away from the page they are on. The use of this stemmed from multiple different scenarios:

• User needs to confirm they want to take an action that could cause them to lose information they have added onto a form before it has been saved.

• User needs to confirm that they want to permanently delete something.

This is an experimental pattern and should be thoroughly researched to match the specific needs of the service

Modals should be avoided in most cases. They are hard to make accessible and do not work well in mobile views. Though with some work they can overcome some of these issues, especially on internal systems that do not use mobile devices.

User research

Usability testing is yet to be carried out on this pattern.

Accessibility

Whilst there are known accessibility issues relating to this, some background research has been carried out to explore way that they can be made as accessible as possible.

Implementation:

Modal box should be used in conjunction with a greyed-out background - #C4C4C4 and 75% opacity - which should cover the entire page behind the modal.

jQuery simple and accessible modal window, using ARIA

https://a11y.nicolas-hoffmann.net/modal/

Notes on making an accessible modal:

To create a modal that is accessible, there must be some functionally to include:

https://www.w3.org/TR/wai-aria-practices/#dialog_modal
https://bitsofco.de/accessible-modal-dialog

1. Markup the Dialog and Dialog Overlay Appropriately
   Dialogs should have an appropriate role and label

2. On Dialog Open, Set Focus
   When first opened, focus should be set to the first focusable element within the dialog

3. On Dialog Close, Return Focus to the Last Focused Element
   When the dialog is closed, focus should be returned to the element that opened it

4. While Open, Prevent Mouse Clicks Outside the Dialog
   Users should not be able to click on elements outside the dialog window

5. While Open, Prevent Tabbing to Outside the Dialog
   User navigating with a keyboard should not be able toTAB out of the dialog content

6. Allow the ESC Key to Close the Dialog
   When the dialog is open, pressing the ESC key should close it

Other accessibility risks

Keyboard users

When using the keyboard to navigate a web page and a modal opens, keyboard focus stays on the background page. Pressing the Tab key to navigate will keep moving keyboard focus on the elements in the background page.

While the overlay doesn't allow mouse and touch users to interact with the rest of the page, keyboard users can still interact with it because keyboard focus is still there. This defeats the whole purpose of a modal dialog.

Screen zoom

A user using the zoom function on a browser may not see the modal dialogue appear. Depending on where they are on the page, they may only see the page dim and not see the modal window appear unless focus can been set to the dialogue.

Screen reader

Screen reader users might not even be aware a modal dialog opened: keyboard focus is still on the control that activated the modal and from a blind person perspective, nothing happened.

Low digital literacy and or cognitive impairments

When it comes to cognitive impairments, there's a new whole world of potential accessibility barriers to take into considerations. Just a couple examples:

modal dialogs may look like a "page" and users might try to use the browser's "back" button to go back to the main page
users might try to bookmark the content of a modal that looks like a page, just to realize that it won't work as expected