Diese Seite erscheint auf Englisch und Ukrainisch; unten steht die englische Fassung.
Asking before Save and Send
For developers, in code: which press is held and asked about, which runs inline, how to mark a safe button and the one button that saves, and the three submit policies.
The assistant fills in fields at once and holds the press that commits them. This page is about that press: what counts as one, how the visitor agrees, and the markup that tells the assistant which buttons are harmless and which one saves.
The held press
A batch of steps that ends in a consequential press — Save, Send, Order, Delete, anything the visitor cannot undo — runs its data entry and stops at the press. The assistant then asks, with the button’s own name («Shall I press “Send”?»), and the widget draws two chips: Yes, press “Send” and No, don’t. The visitor can also answer in their own words or out loud; the server judges the reply. Only a yes replays the press — and only on the same screen: if the visitor has moved, nothing happens and the assistant says so.
A press given as its own command — «send it» — is not held; the visitor is pressing through the assistant.
What is a press, and what is a choice
The widget decides from standard ARIA, so a page marked up for a screen reader gets this for free:
| Element | Treated as | Why |
|---|---|---|
| a button, a link, a submit | a press — held when bundled | acts on the world |
role="tab", or anything inside role="tablist" |
a choice — runs inline | changes what is being edited |
role="option", role="radio", role="menuitemradio", anything with aria-selected or aria-checked |
a choice | one of a set |
a button with aria-pressed inside role="group", radiogroup, tablist, toolbar, listbox or menu |
a choice | a segment of a segmented control |
a standalone button with aria-pressed (Publish, Mute) |
a press | ARIA’s «button that performs an action» |
a disclosure with aria-expanded |
runs inline | the controls it hides are not on the screen until it opens |
A press inside a batch of choices and fills changes nothing about the fills: they still land. Only the press itself waits.
data-sa-risk="safe" — a harmless button
Mark a button whose press the visitor can undo by looking away — Add a row, Open a
dialog, Show more — and the assistant may press it inline, bundled with fills, without
asking. Works on a wrapper (<p-button data-sa-risk="safe">). Never on Save, Send or Delete.
The attribute only ever downgrades a press to safe; nothing makes a press more consequential than
the assistant already assumes.
data-sa-commit — the one button that saves
Mark the control that commits the form: the Save button, or a switch that stores itself the moment
it moves. The assistant treats it as a consequential press whatever the operation — which is the
only way an auto-saving toggle can be held for consent at all — and under the auto policy it is
what gets pressed once a batch of fills has landed.
- Exactly one per screen. With two the assistant asks which, rather than guess.
- Works on a wrapper, but only for a button or link: a marked ancestor speaks for what the
assistant presses, never for what it types into.
data-sa-commiton a<form>does not turn every field into a save point. - A form with no commit button at all (autosave, live search) has no consent point; changes simply land. If that worries you on a page, switch page actions off there.
The three submit policies
The owner picks one on the widget’s Page actions tab, and the server enforces it.
| Policy | A press bundled with fills | After a batch of pure fills |
|---|---|---|
off — Fill only (never click) |
never pressed; the fills land, the press is dropped and the assistant says so | nothing |
confirm — Click with confirmation (the default) |
held and asked about | the assistant says what is unsaved and asks whether to press the commit control |
auto — Save automatically |
pressed, no question | the marked data-sa-commit control is pressed once the fills landed; without a marked control, nothing is pressed |
auto is not «no consent»: the owner gave it once, in the panel, for their own site. It is meant
for an application whose users expect Save to happen, not for a public form.
What the assistant is told back
The result of a batch names what did not happen first: a dropped step, a held press, a field
that was already at that value (unchanged), a field whose previous text is now gone
(replaced), and what the batch put on the screen or removed (new rows, new controls). A batch
that only pressed tabs leaves nothing to save and is not nagged about saving.
A marked list’s own buttons
Inside a declared list (Lists and variants) the add
button is marked data-sa-add and is pressed by the widget itself, as many times as the row
number needs; a row’s delete keeps its consent gate like any other press.