Feedback placement
==================

Spec: descriptive guidance, not a checkable rule.
It carries no forbidden and instead pair, and no `jig check` detector applies to it directly.
Section: Components and layout

Read this before building any pattern that reports something to the user. The most common error in generated UI is not bad styling, it is putting a message in the wrong place — usually a toast, because toasts are easy.

| The message is… | Goes | Never |
| --- | --- | --- |
| About one field | Inline, adjacent to that field, persistent | A toast |
| About one submission, blocking it | Summary above the form **and** inline per field | A toast |
| Result of an action the user just took, non-blocking | Toast, 4–6s, dismissible | A dialog |
| About the whole page or account state | Banner at the top of the content region, persistent | A toast |
| Requiring a decision before continuing | Dialog | A banner |
| A background failure the user did not cause | Banner, persistent, with a retry | A toast |

**Rules**
- A toast is for something already done. If the user must act, it is not a toast.
- Anything a user might need to re-read is not a toast. Errors are re-read.
- Never stack more than one toast. Replace, or aggregate into a banner.
- Every error message says what happened **and** what to do next (`F-37`). "Something went wrong" is not a message, it is an apology.
- Errors are announced to assistive technology: `role="alert"` for immediate, `aria-live="polite"` for summaries (`E-35`).