modal-background-not-inert
Web validation
A modal dialog asks users to finish or dismiss a task before returning to the rest of the page. While it is open, the content behind it, the main context, is usually dimmed visually. It must also be inert: keyboard focus and screen readers should not be able to reach it. When elements outside the modal remain available, keyboard users can tab onto them and lose their place, and screen reader users can accidentally move into the page behind the dialog. This makes it hard to complete the task in the modal, and users may receive mixed information from both the modal and the main window.
Pass Patterns
Native <dialog> opened with showModal()
A native <dialog> opened with showModal() makes the rest of the page inert automatically, for both keyboard focus and screen readers.
<header>…</header>
<main>…</main>
<footer>…</footer>
<dialog id="edit-dialog" aria-labelledby="edit-title">
<h2 id="edit-title">Edit profile</h2>
<button>Close</button>
</dialog>
<script>
document.getElementById("edit-dialog").showModal();
</script>Custom modal with aria-modal and an inert main context
A custom role="dialog" modal needs both aria-modal="true" and an inert attribute on everything outside it.
<div inert data-scope="page_content">
<header>…</header>
<main>…</main>
<footer>…</footer>
</div>
<div role="dialog" aria-modal="true" aria-labelledby="edit-title">
<h2 id="edit-title">Edit profile</h2>
<button>Close</button>
</div>Fail Patterns
Main context remains available behind a custom modal
The custom modal is visually on top, but the page content behind it is not inert, so keyboard focus and screen readers can still reach it.
<div data-scope="page_content">
<header>…</header>
<main>…</main>
<footer>…</footer>
</div>
<div role="dialog" aria-labelledby="edit-title">
<h2 id="edit-title">Edit profile</h2>
<button>Close</button>
</div>Try It Yourself
Using a keyboard
- Open the modal dialog.
- Press Tab and Shift+Tab repeatedly.
- Watch whether focus ever lands on the page content behind the dialog.
Expected results: Focus stays within the dialog (or reaches only the browser's own interface).
Actual results: Focus moves onto links, buttons, or fields behind the dialog.
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Load the page and open a screen reader.
- Open the modal dialog.
- Use the screen reader's reading commands to move past the end of the dialog, and try its headings or landmarks list.
Expected results: The screen reader stays within the dialog, and its lists show only the dialog's content.
Actual results: The screen reader reads, or lists, content from the page behind the dialog.
Inspecting the browser dev-tools
- Open the modal dialog.
- In your browser's dev tools, check whether it is a native
<dialog>opened withshowModal(). - If it is a custom
role="dialog", check that it hasaria-modal="true"and that all content outside it is inside an element with theinertattribute.
Expected results: The dialog is a native modal <dialog>, or a custom dialog with aria-modal="true" and an inert main context.
Actual results: Content outside the custom dialog is not inert.
FAQ
How does this issue relate to 2.4.3 Focus Order?
SC 2.4.3 requires that focusable components receive focus in an order that preserves meaning and operability. While a modal dialog is open, the only meaningful place to work is the dialog. If the main context stays available, focus and screen reader navigation can move to controls that are out of sequence with the user's task and meant to be inactive.
Why is this issue marked as Serious?
When the main context is not inert, keyboard and screen reader users can lose their place, act on content that should be unavailable, or receive mixed information from the modal and the page behind it. This can stop them from completing the modal's task, so it is rated serious.
Is visually dimming the background enough?
No. Dimming only tells sighted users that the background is unavailable. Keyboard focus and screen readers ignore visual styling, so the main context must also be made inert, either with a native <dialog> opened with showModal() or with the inert attribute.
Do I need both inert and aria-modal?
For a native <dialog> opened with showModal(), neither is needed, because the browser handles it. For a custom role="dialog" modal, use both: inert on everything outside the dialog removes it from keyboard focus and the accessibility tree, and aria-modal="true" tells assistive technology that the dialog is modal.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 2.4.3 Focus Order (A) | If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. |
| EN 301 549 | 9.2.4.3 Focus Order | Same as the WCAG text. |
| 508 Trusted Tester | 2.4.3-focus-order-meaning, 4.F | The focus order preserves the meaning and operability of the web page. |