Feedback at the trigger

A copy button with a corner toast, a resizing inline label, and a width-reserved inline label.

002 · MicrointeractionsSupportedStarted 2026-10-01 · updated 2026-10-01

Demo width

Full768375

Loading demo…

Principles

An action should confirm its result at the triggering control, without shifting the layout, and announce the outcome to assistive technology.

EmpiricalRensink et al. (1997)Changes outside the focus of attention are difficult to notice, even when large; distant feedback may go unseen.
StandardW3C (2024)Status messages must be announced to assistive technology without moving keyboard focus.

Hypothesis

If copy confirmation replaces the button label in place, with reserved width and an aria-live region, the feedback should be 0 px from the trigger, should not shift adjacent elements, and should be announced. A toast is hundreds of pixels away, and a changing-width label shifts neighbors.

Measured by: Measure center-to-center distance from the trigger to feedback, adjacent-button displacement, button width change, presence of confirmation in a live region, area of content obscured by toast, and layout-shift score.
Falsified if: Falsified if variant C shifts neighboring elements or fails to announce its result, or if variant B does not shift them.

Implementation

A · Corner toast: Button label remains unchanged; confirmation appears in a bottom-right role=status element.
B · Inline label: Button text changes from Copy to Copied; its width follows its content.
C · Width-reserved inline label: All labels occupy the same grid cell, keeping the button as wide as the longest label; a hidden aria-live region announces the result.

All variants copy the same command and have a neighboring View options button. Confirmation remains visible for two seconds.

Copy failure has a separate state: the toast recommends selecting text manually, whereas variant C automatically selects the command text and announces it.

The instrument activates Copy from the top of the page without accessing the visitor's clipboard. Toast overlap depends on scrolling; the first instrument measured after scrolling to the Measure button and reported no overlap, even though the toast obscured the last card at the top position.

The demo uses a fixed-height frame so the toast appears in the demo viewport corner rather than at the document bottom.

Observations

Feedback position and displacement

Run the demo instrument twice per width; results were identical. Distance and obscured-area figures are reported as 1280 / 375 px.

Chromium 154 (Playwright, headless), 2026-10-01, 1280×800 and 375×812

Variant	Feedback distance	Neighbor displacement	Button width change	Announced	Content obscured
A · Corner toast	966 / 419 px	0 px	0 px	yes, role=status	461 / 10 155 px²
B · Inline label	10 / 10 px	20,2 px	+20,2 px	no	—
C · Reserved inline label	0 / 0 px	0 px	0 px	yes, aria-live	—

Only C met all three conditions. The toast was announced, but it appeared nearly 1,000 px from the button on desktop and obscured 10,155 px² of content at 375 px. The unreserved inline label shifted the adjacent button 20 px and was not announced.

Displacement not captured by CLS

Perform a real click (trusted Playwright input) on Copy in variant B, then inspect the browser's layout-shift entries.

Chromium 154 (Playwright, headless), 2026-10-01, 1280×800

Metric	Value
View options button displacement	20,2 px
Layout shift entry score	0,0001
hadRecentInput	true, excluded from CLS

A click-triggered shift is excluded from CLS, and the score is tiny because only a small element moved. CLS cannot flag variant B's issue; this movement must be measured directly on neighboring elements.

Success and failure states

Perform real clicks with clipboard permission granted, then repeat with the Simulate copy failure option.

Chromium 154 (Playwright, headless), 2026-10-01, 1280×800

Case	Result
C success	Copied label; live region announces 'Command copied'; clipboard contains the command
C failure	Failed label; live region announces 'Copy failed; command text selected'; text is selected
A failure	Toast: 'Copy failed. Select the command text manually.'

Both variants provide a recovery path on failure; C immediately prepares a manual copy by selecting the command text.

Findings

Supported

Replacing a button label in place while reserving its width put confirmation exactly where attention was focused (0 px), caused no layout shift, and remained announced. Toasts were announced too; their weakness was distance (419–966 px from the button) and obscured content on narrow screens. A width-unreserved label shifted neighboring content 20 px without registering as CLS.

Limitations

Announcements were checked in DOM live regions, not with actual screen readers (VoiceOver, NVDA, TalkBack).
Reserving the longest label's width makes the button wider than its current content; longer translations would enlarge it further.
One action type (copying) and one confirmation duration (2 seconds).
Chromium only.

Evaluation

Usability: All three variants are shown side by side and can be tried directly. Failure simulation reveals the error state without using the clipboard.
Accessibility: C announces via a hidden polite live region; inactive labels are hidden from its accessible name and focus stays on the button. B intentionally does not announce its result. axe-core 4.10: zero violations.
Responsive: No overflow at 375 px. There the toast expands with the screen and obscures 22 times as much content as on desktop.
Performance: The only animation is a 150 ms toast fade inside motion-safe. Demo JavaScript is about 154 KB.
Craft: The copy icon changes to a checkmark and green only as reinforcement; the text still changes. The cost of reserving width is visible: C's Copy button is wider than A/B.

Area: Microinteractions