An open modal must keep keyboard focus inside it
Rule
dialog-focus-contained· Component patterns (best practice) · impact serious · Live only (static → incomplete)
Why it matters
aria-modal="true" tells assistive technology to ignore the rest of the page, but it does nothing to the Tab order — only script can do that. When a cookie banner or modal declares itself modal and does not hold focus, Tab walks straight out into the page behind it. Sighted keyboard users then operate controls they cannot see, and screen-reader users are told the background does not exist while their focus is standing in it. The engine Tabs through the live page and reports a modal whose Tab sequence leaves it.
How to fix
While the dialog is open, keep Tab and Shift+Tab within it: wrap focus from the last control back to the first and vice versa, move focus into the dialog when it opens, and restore it to the trigger on close. A native <dialog> opened with showModal() gets this from the browser.
Example
<div role="dialog" aria-modal="true" aria-label="Cookies"><button>OK</button></div><a href="/x">Behind</a>
<dialog open aria-label="Cookies"><button>OK</button></dialog>
WCAG success criteria
2.1.1 Keyboard — Level A
All functionality must be operable through a keyboard alone (composite widgets need roving tabindex or aria-activedescendant so every control is reachable and operable).
Standards
This rule contributes to the following standards:
WCAG A EN 301 549
| Standard | Criteria |
|---|---|
| EN 301 549 | 9.2.1.1 |