Confirm Dialog

Accessibility

Import ConfirmDialog, ConfirmDialogConfirmation, ConfirmDialogVariant from @prepared911/ui/blocks/confirm-dialog.

The surface is AlertDialog's: a modal native dialog with role="alertdialog", named by the title heading and described by the description. The page behind it is inert.
Focus starts on the cancel, the least destructive action, in both variants. Tab cycles inside the dialog. Closing returns focus to the trigger, or to the element that was focused before it opened.
Escape and the cancel dismiss without running onConfirm. A backdrop press does nothing.
While an async confirm is pending, the confirm Button is aria-busy and shows a spinner with its label, the cancel Button is disabled, and Escape does not close the dialog. With pendingLabel, a polite status region announces it and it names the confirm Button.
A failed confirm, or a confirm whose close the caller vetoes, leaves the dialog open and moves focus back to the confirm Button if it lost focus. The caller's error is a role="alert" line, announced when it appears.
The spinner is static under prefers-reduced-motion. The surface's own motion is Dialog's.
Forced colors: the surface edge and the Buttons use system colors through Dialog and Button.

Typed confirmation

The field is a labelled text input. Its name is the whole sentence the label reads: the instruction, the phrase, and the closing words. The phrase sits in a code run with dir="auto", so it keeps its own order inside a sentence of the other direction.
Focus starts in the field, not on the cancel, because the confirm cannot be pressed until the person has typed. Tab then reaches the cancel, and the confirm once it is available.
While the text does not match, the confirm Button is disabled and described by the same sentence (aria-describedby points at the label), so a screen reader reading the Button hears what to type. The description is removed on a match.
A mismatch is not an error. The field carries no aria-invalid and shows no error line, because the person is still typing.
With matchedLabel, the polite status region announces when the text first matches, and clears when it stops matching. A pending confirm announces the pending label in the same region.
Enter confirms once the text matches. Enter that ends an input method composition does nothing, so a person typing Hebrew, Japanese or Chinese does not confirm by committing a word.
The field is read-only, not disabled, while a confirm is pending, so focus stays where it was.
The browser's autocomplete, autocorrect, autocapitalize and spellcheck are off for the field, so a phrase typed exactly is not rewritten.
The field frame, its focus border, forced colors and reduced motion are Input's. The label sits 8px above the field. At 200% text the label wraps and the field and both actions stay inside the surface.

Page translation

The phrase to type is translate="no". The typed text is compared with phrase as passed, so a translated phrase on screen would never match what the user types (ADR 0019 §7).

Confirm Dialog / API and Development

Takeover dialog / Usage

On this page

Typed confirmation

Page translation

Confirm Dialog

Accessibility

Import ConfirmDialog, ConfirmDialogConfirmation, ConfirmDialogVariant from @prepared911/ui/blocks/confirm-dialog.

The surface is AlertDialog's: a modal native dialog with role="alertdialog", named by the title heading and described by the description. The page behind it is inert.
Focus starts on the cancel, the least destructive action, in both variants. Tab cycles inside the dialog. Closing returns focus to the trigger, or to the element that was focused before it opened.
Escape and the cancel dismiss without running onConfirm. A backdrop press does nothing.
While an async confirm is pending, the confirm Button is aria-busy and shows a spinner with its label, the cancel Button is disabled, and Escape does not close the dialog. With pendingLabel, a polite status region announces it and it names the confirm Button.
A failed confirm, or a confirm whose close the caller vetoes, leaves the dialog open and moves focus back to the confirm Button if it lost focus. The caller's error is a role="alert" line, announced when it appears.
The spinner is static under prefers-reduced-motion. The surface's own motion is Dialog's.
Forced colors: the surface edge and the Buttons use system colors through Dialog and Button.

Typed confirmation

The field is a labelled text input. Its name is the whole sentence the label reads: the instruction, the phrase, and the closing words. The phrase sits in a code run with dir="auto", so it keeps its own order inside a sentence of the other direction.
Focus starts in the field, not on the cancel, because the confirm cannot be pressed until the person has typed. Tab then reaches the cancel, and the confirm once it is available.
While the text does not match, the confirm Button is disabled and described by the same sentence (aria-describedby points at the label), so a screen reader reading the Button hears what to type. The description is removed on a match.
A mismatch is not an error. The field carries no aria-invalid and shows no error line, because the person is still typing.
With matchedLabel, the polite status region announces when the text first matches, and clears when it stops matching. A pending confirm announces the pending label in the same region.
Enter confirms once the text matches. Enter that ends an input method composition does nothing, so a person typing Hebrew, Japanese or Chinese does not confirm by committing a word.
The field is read-only, not disabled, while a confirm is pending, so focus stays where it was.
The browser's autocomplete, autocorrect, autocapitalize and spellcheck are off for the field, so a phrase typed exactly is not rewritten.
The field frame, its focus border, forced colors and reduced motion are Input's. The label sits 8px above the field. At 200% text the label wraps and the field and both actions stay inside the surface.

Page translation

The phrase to type is translate="no". The typed text is compared with phrase as passed, so a translated phrase on screen would never match what the user types (ADR 0019 §7).

Confirm Dialog / API and Development

Takeover dialog / Usage

On this page

Typed confirmation

Page translation