Modal Dialogs That Respect People: Focus, Motion and Restraint in React

A modal is a request for someone's full attention

Every other component on a page waits its turn. A modal does not. It dims everything else, takes the keyboard, stops the scroll and says: deal with this first.

When a modal works, it is because the interruption was earned. Someone clicked "Delete project" and the page asks them to confirm. Someone pressed "Sign in" and a small panel appears without throwing away the page they were reading. When a modal fails, it is usually because it showed up uninvited, could not be closed, or forgot where the person was when it disappeared. This guide is about avoiding those failures, using a few of today's additions to the Uncode catalog as examples.

Decide whether it should be a modal at all

Before thinking about animation or focus, ask a simpler question: does this task really need to block the rest of the page? A good test is whether the person would lose anything by having the content inline instead.

Modals earn their place in three situations. The first is a decision that must happen before anything else, like confirming something destructive. The second is a short, self contained task that would be awkward to navigate away for, like signing in or sharing a link. The third is a focused view of something already on the page, like opening a card into a larger detail view. If your use case is none of these, a drawer, an inline panel or a separate page is probably kinder.

Confirmations: match the layout to the weight of the decision

Not every confirmation deserves the same amount of ceremony. Discarding an empty draft is a quick yes or no. Deleting a workspace with a year of history is not. The Alert Dialog Layout family is a nice illustration of this idea: it ships five confirmation layouts that share one panel style but arrange the content differently. A compact one puts the icon, the question and both buttons on a single line. A centered one stacks a large icon, a title, a short explanation and full width buttons, which reads well on a phone. A split one adds a tinted band across the top so a warning is impossible to miss.

A few habits make confirmations clearer whatever the layout. Write the title as the actual question, "Delete this project?", rather than a generic "Are you sure?". Label the buttons with the verb that will happen, "Delete" and "Cancel", instead of "Yes" and "No", so nobody has to reread the question to know what a button does. Say what cannot be undone in plain words. And keep the destructive button visually distinct from the safe one, without making it the only thing on screen that looks clickable.

Uncode UI

Build with AI, not against it.

Over 1,400 React and Tailwind components that run live in the browser, with a prompt ready to paste into Claude, Cursor or v0. Plus a community of people building real sites with AI.

Create a free account Browse components Join the community

Focus is the part people feel even when they cannot see it

For keyboard and screen reader users, a modal lives or dies on focus management. Three things have to happen. When the dialog opens, focus moves inside it, ideally to the first useful control or to the panel itself. While it is open, Tab and Shift+Tab cycle through the controls inside the dialog instead of wandering off into the dimmed page behind it. When it closes, focus returns to the element that opened it, so the person continues exactly where they were.

The Center Morph Modal handles all three in a compact way. On open it waits one animation frame, finds the first focusable element in the panel and focuses it. A keydown listener catches Tab at the edges of the panel and wraps focus around. On close, the cleanup function focuses the trigger again by its id. It also renders the dialog with role="dialog", aria-modal="true" and an accessible label, and the trigger announces aria-haspopup and aria-expanded, so assistive technology knows a dialog is involved before it even opens.

If you use a headless library such as Radix or Base UI, most of this comes for free, and that is a good reason to use one. If you write your own, as many animated modals do, test it with the keyboard alone at least once.

Always leave a way out

People should be able to close a modal in the ways they expect. Escape should close it, unless closing would lose work, in which case it should ask first. Clicking the dimmed backdrop usually should close it too. A visible close button matters for touch and for anyone who does not know the shortcuts. The Auth Modal keeps all three: an X in the corner, a backdrop that dismisses on click, and a panel small enough that the page behind stays recognisable.

Scroll locking is the other half of leaving the page intact. When the dialog is open, the page underneath should not scroll, otherwise a wheel gesture inside the panel ends up moving the content behind it. The simplest approach is to set overflow: hidden on the body when the modal opens and restore the previous value when it closes.

Motion should explain where the dialog came from

Animation in a modal has a job: to show where the panel came from and where it goes when it leaves. A dialog that grows out of the button that opened it, or unfolds from the center of the screen, tells people that this is a temporary layer on top of the page, not a new page. The Center Morph Modal does this with an animated clip-path that opens from a small rounded rectangle in the middle to the full panel, then folds back the same way on exit. The content never resizes, only the visible window over it, which keeps text crisp during the motion.

Keep it short. Opening animations around a quarter to half a second feel responsive. Closing can be a little faster, because by then the person has made their decision and wants the page back.

Respect reduced motion as well. Both of the animated dialogs above read useReducedMotion from Framer Motion and switch to a quick fade when the system setting asks for less movement. That keeps the change of state visible without the travel. If you build your own, the same idea works with a prefers-reduced-motion media query in CSS.

Sign in dialogs and the trust problem

Authentication is one of the most common reasons to open a modal, and it carries a special responsibility: people are about to type something sensitive. A few details help them trust the panel. Keep the page behind visible but dimmed, so it is obvious they have not been sent somewhere else. Show where they are signing in, by name, in the header. Put the terms and privacy links right under the form instead of hiding them.

For full page sign in screens, the same principles apply at a larger scale. The Split Login uses a calm two column layout with a quote on one side and a single clear action on the other, and the Sign In Card puts a glass card with traveling light beams over a deep violet background. Both keep the actual controls plain: one obvious primary action, readable fields where there are fields, and a visible password toggle on the card. Decoration lives around the form, never inside it.

A short checklist before you ship a modal

Run through these before a dialog goes live. Is a modal really the right pattern, or would an inline panel do? Does focus move in on open, stay inside while open, and return to the trigger on close? Do Escape, the backdrop and a visible close button all work? Is the page behind locked from scrolling, and restored correctly afterwards? Are the title and buttons written as the actual question and actions? Does the animation stay under half a second and fall back to a fade under reduced motion?

If the answer to all of them is yes, your modal is asking for attention politely. If you want to start from a working base, the dialogs mentioned here are in the catalog, and you can pull any of them straight into your editor through Uncode Connect, then adapt the copy and colors to your product.