Modals
A modal is a dialog that takes the page away from the reader: it lays a scrim over everything behind it, puts one decision in front of them, and stays until they answer. The four here are the four things a dialog is normally raised to say, something failed, something is about to be destroyed, something finished, something is worth knowing.
Alignment carries the difference. The two that ask for a decision set the icon beside the text, because the reader's eye should land on the title and the buttons; the two that only announce centre the tile over the words, because there is nothing to weigh. The don't-show-again checkbox is a promise, not decoration, if the choice isn't stored somewhere the reader's next session can see, the dialog is lying to them. And a modal that opens over another modal is a design that has run out of room: flatten it into steps in one dialog, or give the second thing a page.
Error Modal
Best for
A problem the reader has to acknowledge before carrying on
Anatomy
Tinted status tile beside the text · title · description · Don't-show-again checkbox · Cancel/Continue
This workspace is over its seat limit
Two people were added after the plan's twenty seats were taken. Nobody has lost access yet.
Warning Modal
Best for
Destructive actions that need a deliberate confirmation
Anatomy
Tinted status tile beside the text · title · description · Don't-show-again checkbox · Cancel/Continue
Deleting this component cannot be undone
Forty-one screens still place it. They will fall back to the unstyled element.
Success Modal
Best for
Confirming something finished, with the icon over the words
Anatomy
Centred status tile · title · description · Don't-show-again checkbox · Cancel/Continue
Orvain UI 2.4 is published
Every project on the library sees it from now on. Older versions stay available for a year.
Information Modal
Best for
Announcements the reader only has to read
Anatomy
Centred status tile · title · description · Don't-show-again checkbox · Cancel/Continue
Maintenance on Sunday at 02:00 UTC
Editing will be read-only for about twenty minutes. Nothing already saved is affected.
Using Modals
Reach for it when
- A destructive action you want someone to confirm deliberately
- An error that has to be acknowledged before the app can carry on
- A short form that would lose the reader's place if it took over the page
- Announcing a change that has already happened behind the scrim
Reach for something else when
- Anything the reader does not have to answer: a toast says it and leaves
- Long or multi-section forms: give them a page or a side panel so the work can be saved
- Prompts fired on load before anyone has done anything: put that inline or in a banner
Where it shows up
Destructive confirmations
Deleting a component other screens still place, or removing a member with work assigned. The dialog's job is to name the consequence in its description, not to ask a generic are-you-sure.
Limit and billing blocks
A workspace over its seat count, an upload past its size, a plan that has to change before the action can finish. The reader cannot carry on, so a dialog is the right place to say so.
Release announcements
A library version published, a feature turned on for everyone. Centred, read-only, one button to dismiss, and a checkbox so the person who has seen it does not see it every session.
Maintenance notices
Scheduled downtime that turns editing read-only. A dialog is right when the notice lands mid-session and changes what the person can do next; if it can wait, a banner carries it instead.
Questions
What accessibility does a modal dialog need?
The dialog needs a dialog role and an accessible name from its title, focus moved into it when it opens, focus kept inside while it is open, and focus returned to whatever opened it when it closes. Escape must dismiss anything that is not a blocking error. Content behind the scrim should be inert so a screen reader does not wander into it.
Can a modal open another modal?
Avoid it. Stacked dialogs bury a scrim under more scrim, leave the reader unsure which Escape they are pressing, and make focus order hard to reason about. If a decision needs a second decision, make it a step inside the same dialog, or close the first and open the second in its place. A picker inside a dialog should open in flow, not as a new layer.
Premium components,
free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
Orvain MCPModals
A modal is a dialog that takes the page away from the reader: it lays a scrim over everything behind it, puts one decision in front of them, and stays until they answer. The four here are the four things a dialog is normally raised to say, something failed, something is about to be destroyed, something finished, something is worth knowing.
Alignment carries the difference. The two that ask for a decision set the icon beside the text, because the reader's eye should land on the title and the buttons; the two that only announce centre the tile over the words, because there is nothing to weigh. The don't-show-again checkbox is a promise, not decoration, if the choice isn't stored somewhere the reader's next session can see, the dialog is lying to them. And a modal that opens over another modal is a design that has run out of room: flatten it into steps in one dialog, or give the second thing a page.
Error Modal
Best for
A problem the reader has to acknowledge before carrying on
Anatomy
Tinted status tile beside the text · title · description · Don't-show-again checkbox · Cancel/Continue
This workspace is over its seat limit
Two people were added after the plan's twenty seats were taken. Nobody has lost access yet.
Warning Modal
Best for
Destructive actions that need a deliberate confirmation
Anatomy
Tinted status tile beside the text · title · description · Don't-show-again checkbox · Cancel/Continue
Deleting this component cannot be undone
Forty-one screens still place it. They will fall back to the unstyled element.
Success Modal
Best for
Confirming something finished, with the icon over the words
Anatomy
Centred status tile · title · description · Don't-show-again checkbox · Cancel/Continue
Orvain UI 2.4 is published
Every project on the library sees it from now on. Older versions stay available for a year.
Information Modal
Best for
Announcements the reader only has to read
Anatomy
Centred status tile · title · description · Don't-show-again checkbox · Cancel/Continue
Maintenance on Sunday at 02:00 UTC
Editing will be read-only for about twenty minutes. Nothing already saved is affected.
Using Modals
Reach for it when
- A destructive action you want someone to confirm deliberately
- An error that has to be acknowledged before the app can carry on
- A short form that would lose the reader's place if it took over the page
- Announcing a change that has already happened behind the scrim
Reach for something else when
- Anything the reader does not have to answer: a toast says it and leaves
- Long or multi-section forms: give them a page or a side panel so the work can be saved
- Prompts fired on load before anyone has done anything: put that inline or in a banner
Where it shows up
Destructive confirmations
Deleting a component other screens still place, or removing a member with work assigned. The dialog's job is to name the consequence in its description, not to ask a generic are-you-sure.
Limit and billing blocks
A workspace over its seat count, an upload past its size, a plan that has to change before the action can finish. The reader cannot carry on, so a dialog is the right place to say so.
Release announcements
A library version published, a feature turned on for everyone. Centred, read-only, one button to dismiss, and a checkbox so the person who has seen it does not see it every session.
Maintenance notices
Scheduled downtime that turns editing read-only. A dialog is right when the notice lands mid-session and changes what the person can do next; if it can wait, a banner carries it instead.
Questions
What accessibility does a modal dialog need?
The dialog needs a dialog role and an accessible name from its title, focus moved into it when it opens, focus kept inside while it is open, and focus returned to whatever opened it when it closes. Escape must dismiss anything that is not a blocking error. Content behind the scrim should be inert so a screen reader does not wander into it.
Can a modal open another modal?
Avoid it. Stacked dialogs bury a scrim under more scrim, leave the reader unsure which Escape they are pressing, and make focus order hard to reason about. If a decision needs a second decision, make it a step inside the same dialog, or close the first and open the second in its place. A picker inside a dialog should open in flow, not as a new layer.
Related blocks
All blocksPremium components, free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
