We'd like to set Google Analytics cookies to learn how people use the Knowledge Base, so we can improve it. We set them only if you accept.

Skip to main content
Digital Accessibility Knowledge Base

focus-kept-within-the-modal

Web validation

Keyboard focus must remain within an open modal dialog and not move to the page content behind it.

When a modal dialog is open, keyboard focus should stay inside it. Pressing Tab or Shift+Tab should keep focus on the dialog's controls and never land on the page content behind the dialog. If focus escapes to the background while the dialog is open, keyboard and screen reader users can end up interacting with content that is meant to be inactive, which makes the dialog unreliable and confusing to operate.

Pass Patterns

The background is made inert

While the dialog is open, the rest of the page is marked inert, so none of it can receive focus. Tab moves only among the dialog's controls, because there is nothing focusable behind the dialog.

HTML
<!-- The rest of the page, made inert while the dialog is open -->
<main inert>
    <a href="/">Home</a>
    <button>Menu</button>
</main>


<div role="dialog" aria-modal="true" aria-labelledby="title">
    <h2 id="title">Edit profile</h2>
    <button>Close</button>
    <input type="text" placeholder="Name" />
    <button>Submit</button>
</div>

A focus trap keeps Tab inside the dialog

When the background is not made inert, a script keeps focus in by moving it from the last focusable element back to the first, and from the first back to the last on Shift+Tab, so Tab does not reach the page content behind the dialog.

JavaScript
const focusable = modal.querySelectorAll(
    'a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
const first = focusable[0];
const last = focusable[focusable.length - 1];
// On Tab at the last element, move focus to first.
// On Shift+Tab at the first element, move focus to last.

Fail Patterns

Focus escapes to the background

The background is still active and there is no focus management, so pressing Tab from the last control moves focus to a control behind the dialog.

HTML
<!-- The rest of the page is still focusable -->
<main>
    <a href="/">Home</a>
    <button>Menu</button>
</main>


<div role="dialog" aria-modal="true">
    <button>Close</button>
</div>

Try It Yourself

Using a keyboard

  1. Open the modal dialog.
  2. Press the Tab key repeatedly, then Shift+Tab.
  3. Observe where focus goes.

Expected results: Focus stays on the dialog's controls and does not move to the page content behind it. (Reaching the browser's own toolbar or address bar is acceptable.)

Actual results: Focus moves out of the dialog and onto the page content behind it.

Using a screen reader

New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers

  1. Load the page and open a screen reader.
  2. Open the modal dialog.
  3. Navigate using Tab.

Expected results: Tab keeps focus on the dialog's controls.

Actual results: Navigation moves onto the page content behind the dialog.

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. When a modal dialog is open, the only meaningful focus order is within the dialog. If focus escapes to the page content behind it, users reach controls that are out of sequence with the task they are working on and meant to be inactive, so the focus order no longer preserves operability.

Why is this issue marked as Serious?

When focus escapes a modal, keyboard and screen reader users can interact with content that should be inactive, lose their place, or be unable to finish a task, so it is rated serious.

Is it a problem if focus can reach the browser's own interface?

No. What matters is that focus does not move to other content in the page behind the dialog. It is acceptable for Tab to reach the browser's own interface, such as the address bar or toolbar. That is exactly what a native <dialog> opened with showModal() allows. Looping focus strictly within the dialog is also fine, so both approaches meet this check.

Does this check whether every control in the dialog is reachable?

No. This check only confirms that focus does not leave the dialog for the page behind it. Whether every control inside the dialog can be reached, and in a sensible order, is a separate concern covered by focus-order checks.

Do native dialog elements handle this automatically?

Yes. A native <dialog> opened with showModal() keeps focus out of the inert page content on its own, while still allowing the user to reach the browser's interface. This check is mainly about custom modals built with role="dialog" and scripted focus management.

Why does this check require human review?

Correct focus behavior depends on how the dialog is coded and how it feels to operate. A reviewer opens the dialog, tabs through it, and confirms that focus never moves to the page content behind it.

Standards and Regulations

StandardSuccess CriterionReference
WCAG 2.22.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 5499.2.4.3 Focus OrderSame as the WCAG text.
508 Trusted Tester2.4.3-focus-order-meaning, 4.FThe focus order preserves the meaning and operability of the web page.

Personas impacted by this issue

Learn More