Whole page
Dialog or pop-up is hard to use with a keyboard
WCAG 2.2 success criterion 2.4.3 Focus Order (Level A)
- WCAG 2.2
- 2.4.3 Focus Order
- Also maps to
- 4.1.2 Name, Role, Value
- Level
- A
- Default severity
- Needs review
- Available in
- Free
Updated for Lumtera 1.2.2 and Lumtera Pro 1.1.1.
Why does it matter?
Newsletter pop-ups, mobile menus and lightboxes are where keyboard and screen reader users most often get lost. If focus stays behind the pop-up, they keep tabbing through a page they cannot see; if it has no name or cannot be closed with Escape, they may not know what opened or how to leave.
Who it affects: Keyboard, screen reader and low-vision users — every visitor meets the page title, language, landmarks, keyboard focus, target sizes and zoom settings on every page.
What does Lumtera flag?
Found by the widget tests (review mode's Keyboard tab, "Test menus and pop-ups"). Lumtera opens each dialog it finds a trigger for, including the Navigation block's mobile overlay and Elementor and Divi pop-ups, and checks it. For review: the dialog has no name (ARIA asks for one; whether its absence fails WCAG is debated), focus does not move into it within half a second, it is not marked as modal, Escape does not close it, or focus does not go back to the button that opened it. A combobox labelled by a <label> element counts as named. A tip reminds you to check by hand that Tab stays inside it.
Check ID page-dialog, as shown in review mode and saved results.
How do I fix it in WordPress?
Use the <dialog> element opened with showModal(), or a container with role="dialog", aria-modal="true" and aria-labelledby pointing at its heading. Move focus into it when it opens, close it on Escape, and move focus back to the button that opened it. For pop-up plugins and page builders, look for an accessibility setting, or ask the author.
Example
<div class="popup">
<h2>Join our newsletter</h2> …
</div>
<div class="popup" role="dialog" aria-modal="true" aria-labelledby="popup-title">
<h2 id="popup-title">Join our newsletter</h2> …
</div>
How do I check the fix?
- Reload the page in review mode and run the Keyboard tab again (or Test menus and pop-ups for menus, dialogs and tabs). The finding disappears once the page passes.
- Load the page and press Tab: a "Skip to content" link should appear first, and you should always see where focus is, even under a sticky header. Pinch-zoom on a phone, and check the browser tab shows a meaningful title.
Check your pages with Lumtera
This check is free. Open any post, choose Accessibility in the admin bar, then the Keyboard tab: Lumtera numbers every Tab stop and checks the page with the keyboard, theme, menus and footer included, one page at a time. Lumtera Pro's Page checks screen (Lumtera → Checks → Page checks) runs the same menu and pop-up tests on every page you select, at desktop width and, with "Also check at phone width", again at 390 pixels, and saves the results with the page; scheduled checks have no browser, so they do not run them.
Related checks
-
WCAG 2.4.4 · AError
Link has no text
-
WCAG 4.1.2 · ANeeds review
Link does not go anywhere
-
WCAG 4.1.2 · AError
Button has no text
-
WCAG 4.1.2 · AError
Form field has no label
-
WCAG 4.1.2 · AError
Embedded frame has no title
-
WCAG 4.1.2 · ANeeds review
Embedded frames share the same title
Start with the free plugin today
All 69 content checks and 33 whole-page checks, fixes you approve with undo, and the site report — free, with no account and no page limits.