A modal is a window that is overlaid either on a web page or on another window where the parent window is inert. The primary difference between a modal and a non-modal is that the window or page under the modal cannot be accessed until it is closed while the window or page under a non-modal can be accessed even when it is active.
The content under the modal is usually obscured or dimmed to represent that it cannot be accessed. If the user tries to access the obscured content the modal may be automatically closed. Users are expected to navigate only within the modal until it is closed. So maintaining the keyboard focus within the modal as long as it is opened is important. In a way the content authors have to trap the keyboard focus within the modal until it is closed. In certain situations though the keyboard focus does not move to the parent window screen reader may be able to access the parent content. This can be solved using the aria-modal property introduced in WAI ARIA 1.1. Content authors used to depend on aria-hidden state before the introduction of aria-modal property.
Secondly, the button that initiates the modal should allow the users to know that the button invokes a modal dialog. This can be done with aria-haspopup property. Set aria-haspopup=”dialog” to the initiating button.
Once the modal is opened the focus should move to the modal reading out the title of the window. The title of the window can be made to be read by the screen reader either by focusing to the title content or by referring the title with aria-labelledby property.
The modal initiating element mostly button should be navigable and actionable with a keyboard.
Once the modal is opened, all the interactive elements in the modal must be keyboard operable.
User should not be able to navigate away from the modal until it is closed.
A close or cancel button for an informative modal should be provided to close the modal. Alternately the user should be able to close the modal with the Escape key. If the escape key is the only way for a keyboard only user to close the modal same has to be informed as an instruction. In case the modal allows the user to submit a form the successful submission should close the modal.
Whatever the way the user closes the modal focus should return to the triggering element.
Once the user open the modal focus should be on the modal. It can be either on the visible title or on the first interactive element depending on the modal type.
The user focus should be trapped within the modal until it is closed.
Once the modal is closed the focus must be triggering back to the initiating element.
- Check if the user is able to navigate and activate the button that initiates the modal. 1.1 Keyboard
- Screen reader should announce the role of the initiating element (button) and that it has a modal opening property. NVDA at the time of this writing announces submenu. 4.1.2 Name, Role, Value
- When the user activates the button, the modal has to open and the keyboard focus must shift to the modal. Announcing the title of the modal is a best practice. 2.4.3 Focus Order
- User focus should not come out of the modal until it is closed. Check this with both keyboard and mouse. 2.4.3 Focus Order
- Check if the modal has a mechanism to close it without submitting if it has a form. Having a close or cancel button or allow the user to close the modal with a hit of Escape key. 2.1.1 Keyboard
- If the hitting Escape key is the only way of closing the modal provide an instruction that informs the user. 3.3.2 Labels or Instructions.
- Once the user closes the modal, check if the focus is triggering back to the initiating button on the parent window. 2.4.3 Focus Order
Example Implementation of Modal Windows
Try it yourself.