Short description

A full screen modal that temporary blocks interaction with the main view of a site and set the actual task in focus.

When and how to use it

Use a takeover modal when a task needs the full attention from a user, for example when making a payment. Heavier tasks such as a multi step wizard also benefit from the focused experience of removing not needed UI chrome of the original site.

Behaviour

• It should cover the whole viewport whilst its own content is centered, both vertically and horizontally.
• If triggered from a link/button, the modal should originate from that point until filling the whole viewport to communicate hierarchy.

Button placement

This example is from an centered empty state message (hybrid) where the primary button is placed to the right.

See examples and full accessibility guide on W3’s ARIA pattern guide for Modals

Tabbing order

Make sure the modal is announced, and that the focus and tabbing order is limited to the modal. The user should not be able to reach content outside of the modal without exiting the modal (same as for mouse-users). 

Heading structure

A modal’s main header always be a H2. While it is not wrong to make it a H1 since it is technically a new context, it is still experienced by the user as within the same context as the triggering page. Hence a H1 might be confusing. All following headers within the modal should descend below H2 as on a main page.

Navigation

Some modals include navigation. This could be pagination, Previous/next buttons for modals with several steps etc. Putting these in a <nav> element allows the user to find the navigation buttons more conveniently. If you cannot use <nav> in your context, aria role="navigation" can be used as a fallback.

Review

Result from the latest accessibility review of the component (Chlorophyll): 2024-07-31

• Contrast: ok
• Colour-blindness: ok
• Code + aria: ok
• Touch + keyboard: ok
• Dark-mode: n/a
• Focus: ok
• Reader: ok

Specification