User activates a clear trigger: button, link, or an icon with an accessible label (e.g., “Edit”, “Compare offers”). The trigger must be obvious and reachable by keyboard and touch.

When the modal opens, move focus into the modal to the most important interactive element (first input, primary action, or modal title). Announce the modal to assistive tech with a clear title and role.

While open, trap focus inside the modal so Tab/Shift+Tab cycle through modal controls only. Keep background content inert (not interactive) and dimmed visually.

User initiates close via close button, backdrop click, or Escape key. At this point, start a close sequence rather than instantly removing UI.

Set a short isClosing state to play the exit animation. During this time: disable inputs and actions inside the modal, keep focus inside the modal until animation completes, and show any “saving” indicator if the close was triggered by a submit.

After the animation finishes, remove the modal from view and return focus to the original trigger. Update the visible state of the page (e.g., updated profile fields or selected plan).

Clear any temporary state used by the modal (form fields, error messages, timers). If an operation was pending, display a confirmation or error message outside the modal as needed.

User clicks the edit icon next to the field they want to change (name, birthdate, address, email or phone). The trigger should be labeled with the field it edits (e.g., “Edit name”).

The modal shows only the inputs needed for that edit type (for clarity). The first input receives focus automatically for quick editing.

Provide live validation feedback:

• Required fields show an inline message when empty.
• Email format is validated immediately.
• Phone uses a simple format check and shows an example format.
• Postal code and city are validated together when possible. Always show clear, friendly error messages and guidance to fix them.

Disable the submit button while validation errors exist. If certain checks are asynchronous (like an email uniqueness check), show a small inline spinner and block submission until the check completes.

When the user submits:

• Disable form inputs and the submit action.
• Show a spinner or “Saving…” state.
• Play the modal close exit animation once the save succeeds (go into isClosing state).

After a successful update, close the modal with animation, return focus to the edit trigger, and show a persistent confirmation message (toast or inline banner) that the profile was updated.

If save fails:

• Keep modal open and re-enable inputs.
• Show a clear error message (why it failed and what to try).
• Allow the user to retry or cancel.

User clicks “Compare levels” or similar. The modal opens centered and shows a side-by-side view of plans or coverage levels.

Include contextual toggles inside the modal (e.g., 100% santé vs classic) so users can change the comparison mode and see differences immediately.

Users can select or highlight a preferred plan directly in the modal. Make the selection action prominent and reversible while the modal is open.

If choosing the plan will change a critical application state, require explicit confirmation (a “Confirm selection” action). Avoid silently making permanent changes on modal close.

Once confirmed, close the modal with an exit animation, update the main UI to reflect the selected plan, and show a confirmation message.

Optionally display a brief summary on the main page after close (e.g., “You selected Plan X — click to view details”), so the user sees the result of their action at a glance.

When closing is requested, switch to an isClosing state rather than immediately removing the modal. This lets the exit animation play and avoids abrupt UI jumps.

While isClosing is true, disable form inputs and action buttons to prevent double actions or weird state transitions.

Do not move focus back to the trigger until after the exit animation finishes; otherwise keyboard users can end up navigating content incorrectly.

If a user prefers reduced motion, skip or shorten animations and close immediately — still honour isClosing semantics nominally.

Pick a consistent exit duration (e.g., 200–260ms). Use the same duration across open/close to feel predictable. If an operation includes waiting for a backend response, show a saving indicator and only proceed to the close animation once the operation completes.

If the window loses focus or the browser navigates during isClosing, ensure cleanup still happens (temporary state cleared and user informed if an update was pending).

Each modal should have a clear title. That title must be exposed to assistive technologies so users know the purpose of the dialog.

Support keyboard-only operation: Tab/Shift+Tab cycle focus inside the modal, Enter activates primary actions, Escape closes the modal.

When opening, focus the first meaningful control. When closing, return focus to the element that triggered the modal.

Provide an obvious close button with an accessible label (e.g., “Close edit dialog”). Backdrop clicks should also close when appropriate, but never be the only way to close.

When saving completes or fails, announce the result (toast or inline message) and ensure screen readers can detect it.

Honor the user’s OS-level reduced-motion preference by reducing or eliminating animations.

Ensure high color contrast for text and that interactive controls meet recommended touch target sizes.

Run basic checks locally (required fields, simple format checks for email/phone/postal code). Provide instant inline feedback so users fix issues before submit.

For checks that require server knowledge (unique email, phone verification), run an asynchronous check and surface results inline before final submission.

Disable the submit action whenever validation fails or pending checks are running.

On success, show a confirmation message after the modal closes. On failure, keep the modal open and display a helpful error with actions to retry or cancel.

Disable submit controls while a request is in-flight and show progress to avoid duplicate requests or duplicate state changes.

When the change affects billing, plan selection, or irreversible state, require a second confirm step (e.g., “Confirm and update”) and give a brief summary of what will change.

After the backend confirms success, update all visible UI in the page to match. If the backend returns an updated canonical value, use it; do not trust only the local input.