Accessibility built into a Modal component

WHAT THIS TESTS Whether you make accessibility a default property of the component so consumers get it for free, and whether you know the specific requirements of an accessible dialog.

A GOOD ANSWER COVERS Build a11y into the Modal so no consumer has to remember it. Give the container role dialog and aria-modal true. Label it: point aria-labelledby at the modal's title element, or use aria-label. On open, move keyboard focus into the dialog, typically to the first focusable element or the close button, and trap Tab and Shift+Tab so focus cycles within the modal and never reaches the page behind it. On close, return focus to the element that triggered the modal so keyboard users are not dumped at the top of the page. Support Escape to dismiss. Make the rest of the page inert or aria-hidden so screen readers do not wander into background content. Ensure the close control has an accessible name.

COMMON WRONG ANSWERS Leaving accessibility to each consuming team guarantees inconsistency and gaps. Adding only role=dialog without focus management still strands keyboard and screen-reader users. Forgetting to restore focus on close, or not trapping focus, lets users tab into hidden content. Hiding the background visually but not from assistive tech.

LIKELY FOLLOW-UPS How do you trap focus reliably? Track focusable elements and intercept Tab at the boundaries, or use the inert attribute on siblings. What about nested modals? Maintain a focus stack. How do you test it? Keyboard-only and screen-reader passes plus automated axe checks.

ONE CONCRETE EXAMPLE A user opens a confirmation modal with the keyboard. Focus jumps to the Cancel button; Tab cycles only between Cancel and Confirm and never escapes to the page. The dialog announces its title because aria-labelledby references the heading. Pressing Escape closes it and focus returns to the original trigger button, so the user continues exactly where they were.