Modal UI Design: Sizing, Hierarchy and Footer Actions

A modal dialog places one decision or task above the rest of the interface. That visual separation is valuable only when the dialog remains focused. An oversized container with competing actions is not clearer simply because the background is dimmed.

Decide what belongs inside the dialog

Write the dialog's purpose in one sentence. Confirming an irreversible change, editing a short record, and reviewing a long document have different space needs. If the task needs extensive navigation or several unrelated sections, a dedicated page or side panel may be a better visual container.

Use the Flexbox Playground to explore the relationship between heading, content, and footer actions. Try long labels and a narrow width immediately. This reveals whether the footer can wrap cleanly without squeezing the primary action.

Define a single focal task and a clear completion point. Supporting details should help that task rather than advertise unrelated features. The WAI modal dialog pattern explains required interaction behavior; visual design does not replace focus management, naming, or dismissal handling.

Size from the content outward

Choose dialog width according to the information inside it. A two-sentence confirmation should not inherit the width of a complex editor. Start with a narrow and a medium variant, perhaps around 28rem and 40rem, then verify that each has a meaningful use rather than introducing a dozen arbitrary presets.

Keep space between the dialog and viewport edges. On short screens, the available height matters as much as width. A centered dialog with a fixed height can place the heading or actions outside the visible area. Let content flow and provide a deliberate scroll strategy.

Use a clear internal rhythm: a title, optional concise explanation, task content, and actions. The title should name the operation or object rather than simply saying Notice. Keep explanatory copy close to the relevant controls instead of placing every instruction beneath the title.

Be restrained with decorative imagery. A large illustration may push the only decision below the fold without making it more understandable. If the image contributes information, give it room; otherwise, reserve the limited area for the task itself.

Implement bounded dimensions and natural flow

A native dialog can provide the base element, but it still needs to be opened and managed correctly. This CSS focuses on dimensions and internal arrangement. It assumes a header, content region, and action group within the dialog.

.task-dialog {
box-sizing: border-box;
inline-size: min(40rem, calc(100% - 2rem));
max-block-size: calc(100dvh - 2rem);
padding: 1.5rem;
border: 1px solid #c6ceda;
border-radius: .875rem;
overflow: auto;
}
.task-dialog::backdrop { background: rgb(15 23 42 / .55); }
.dialog-actions {
display: flex;
justify-content: flex-end;
flex-wrap: wrap;
gap: .75rem;
margin-block-start: 1.5rem;
}

Read MDN's dialog reference for native behavior and APIs. Do not assume adding a backdrop makes a generic container behave like a modal dialog. Use the platform or a well-tested implementation for the behavioral layer.

Choose either whole-dialog scrolling or a clearly bounded inner content region. Mixing both without a reason produces nested scrollbars that make the footer difficult to find. A sticky internal footer requires an opaque surface and enough clearance that the last content line remains readable.

Establish action and dismissal hierarchy

Give the primary action the clearest emphasis and a specific label. Archive project is more informative than OK. A secondary Cancel action should remain easy to find, especially when the primary operation changes or removes data.

Place the close control where people can locate it without scanning the content. Do not let it overlap a long heading. If both a close icon and Cancel exist, keep their consequences consistent. If dismissing would discard work, communicate that behavior rather than implying that every exit is harmless.

For destructive confirmations, use content that names the affected object and the consequence. A red button does not explain whether deletion is reversible. Avoid decorative warning treatments so large that they visually separate the action from its explanation.

Keep footer ordering consistent within the product, while checking logical reading and focus order. On narrow screens, stacked actions may need full width. Do not reverse their visual order with CSS in a way that creates a surprising keyboard sequence.

Review difficult content and small viewports

Test long headings, multiline field errors, enlarged text, and the on-screen keyboard. The dialog must remain usable when the content grows after validation. Fixed wrapper heights often look correct initially and fail as soon as a message appears.

Check contrast between the dialog and its contents with the Contrast Checker. The dimmed background should establish separation without being the only signal that the dialog is active. Avoid transparent content surfaces that let the underlying page interfere with reading.

Review the dialog within the actual application frame. A page with a persistent header, chat widget, or notification layer may expose stacking problems that an isolated component preview conceals. Use the UI Design collection for related component decisions while keeping the modal's own rules focused.

A complete review also includes keyboard entry, movement, and return to the launching control. The WCAG quick reference helps identify relevant requirements, but manual interaction remains necessary. Record the scroll policy, width variants, action placement, and dismissal consequences alongside the visual examples.

Show at least one populated form dialog rather than only a confirmation. Include enough content to reach the maximum height, then verify that the heading remains discoverable and the final action is reachable. The visual composition should still make sense after scrolling, not only at its opening position.

Specify submission and recovery states

For an edit-project dialog, sketch four states alongside the initial layout: submitting, successful completion, recoverable failure, and an expired permission. During submission, retain the action label or show a clear progress label without changing the button width dramatically. Prevent duplicate submission while keeping the current task understandable.

On a recoverable error, preserve the entered values and place the explanation near the affected content. An error banner above the title can be missed when the dialog is scrolled downward. Decide whether the user needs an inline field correction, a general retry action, or an explanation that the task can no longer be completed.

For example, if another teammate deletes the project during editing, repeating Save cannot resolve the problem. Present the changed situation and a safe route back to the application. Review these states at the narrowest supported width: additional text should extend the chosen scroll region rather than cover the footer or silently push Cancel outside the dialog.

Key takeaways

• Keep each modal focused on one task or decision.
• Choose width from content and bound height to the viewport.
• Make actions, dismissal, and consequences explicit.
• Use one deliberate scrolling strategy.
• Validate real behavior as well as visual hierarchy.