How do you make a modal fully accessible
Making an Accessible Modal
A modal dialog should be usable by everyone, including keyboard-only and screen reader users. Accessibility requires handling focus, roles, labels, and keyboard interaction properly.
- 1
Focus Management – Move focus into the modal when it opens and return it to the triggering element when it closes.
- 2
Focus Trap – Keep focus inside the modal while it is open, preventing users from tabbing into the page behind it.
- 3
Keyboard Support – Allow closing with the Escape (Esc) key, and ensure all interactive elements are reachable with Tab/Shift+Tab.
- 4
ARIA Roles – Use
role="dialog"orrole="alertdialog"to announce the modal as a dialog to screen readers. - 5
Accessible Labels – Provide a clear label using
aria-labelledby(for the modal title) andaria-describedby(for extra instructions or content). - 6
Background Inertness – Hide or mark the page content outside the modal as inert/inaccessible while the modal is open.
These practices ensure users can navigate, understand, and dismiss the modal without confusion or barriers.
- 1
Always return focus to the element that opened the modal.
- 2
Ensure modal content is concise and focused on a single task.
- 3
Don’t rely on color or visuals alone—make instructions text-based as well.
- 4
Test with a screen reader and keyboard to confirm expected behavior.
Scenario Questions
0-2 years experience
- 1You need to add a modal to a simple page. Walk me through the HTML and ARIA attributes you'd include to make it accessible.
- 2If a user presses Escape while the modal is open, what should happen and how would you implement that behavior?
- 3What happens to screen‑reader focus when the modal opens, and how do you ensure it returns correctly when the modal closes?
2-5 years experience
- 1We have a modal that sometimes fails to trap focus when we load content via AJAX. How would you debug and fix that?
- 2Our design wants the modal to be dismissible by clicking outside, but we also need to meet WCAG 2.1. How would you decide which interactions to allow?
- 3Explain why you might choose role='alertdialog' instead of role='dialog' for a confirmation modal, and when each is appropriate.
5-8 years experience
- 1We're building a component library used across many teams. How would you design the modal's accessibility API to be reusable and prevent common pitfalls?
- 2In a large SPA, many modals can be rendered conditionally. How do you keep focus management reliable without causing costly reflows?
- 3If a modal contains a form with validation errors, how would you announce those errors to assistive tech while keeping focus inside the modal?
8+ years experience
- 1Our legacy codebase has dozens of custom modals built without proper ARIA. Outline a migration plan to make all modals accessible without breaking existing features.
- 2How would you influence cross‑team standards for modal accessibility when different teams use varying UI frameworks and release cycles?
- 3Discuss the trade‑offs between building a fully accessible modal from scratch versus adopting a third‑party library, considering long‑term maintenance and legal compliance.
Follow-up Questions
- Can you sketch the minimal HTML/JS you’d write for focus trapping?
- What would you do if a screen reader still read background content after the modal opens?
- How would you verify your solution works across major browsers and assistive technologies?