A Clipboard Fallback for Copying a Quote Reference

A 'Copy reference' button feels trivial until it fails. Clipboard access can be refused, unavailable in some contexts, or simply slow. If the button then shows nothing, the customer has no reference and may not realise. This article proposes an interaction spec so the reference stays reachable whatever the copy action does. All behaviour described is a conditional design suggestion.

Principle

The reference should be visible text first, and the copy button should be a convenience on top. A customer should never need the button to obtain the value.

Copy result and manual selection spec

Use this as a template you could adapt.

Element 1: the reference shown as plain text in a single selectable element, in a clear typeface that separates similar characters where practical. Element 2: a button labelled 'Copy reference'. Element 3: a status line near the button, readable by assistive technology as a polite announcement.

States and messages:

Idle: no status text. Working: button stays enabled, no message, to avoid flicker. Success: status reads 'Reference copied.' and clears after a few seconds. Failure: status reads 'Copy did not work. The reference is selected below, press and hold or use your keyboard copy shortcut.' The reference text is then programmatically selected and focused. Unknown: if no success or failure signal arrives within a short wait you choose, treat it as failure.

The key rule is that unknown counts as failure. Telling a customer 'copied' when nothing was confirmed is worse than a cautious fallback.

Branching choices

Branch A: automatic selection on failure. Simple and fast, but on some touch devices programmatic selection may not show the handles, so the message must still explain how to copy. Branch B: reveal a read only text field with the reference preselected. More robust for selection, at the cost of a layout change that you must test. Branch C: also offer 'Show reference in large text' for customers reading it aloud or typing it elsewhere.

Pick one primary branch and say why in the spec. Branch B is a reasonable default if you cannot confirm that selection behaves well on your target devices.

Hypothetical worked example

A customer finishes a fictional quote and sees the reference 'Q-4F7K-29B'. They press Copy. The copy request is refused. The page shows the failure message, selects the reference and moves focus there. The customer holds down on the text, copies it manually and pastes it into an email. Nothing about the quote was lost, and the page never claimed success.

Second case: the customer has a keyboard only setup. After failure, focus lands on the reference and the keyboard copy shortcut works without any pointer. Confirm that focus is visibly outlined.

Stop conditions

Stop and redesign if the fallback ever hides the reference, if the status line announces success after a failure, if focus moves somewhere the customer cannot see, or if the reference can only be reached after the failed action. Also stop if the reference text is rendered inside an image or a component that blocks selection.

Acceptance checks

With copying deliberately blocked in a test setup, the failure message appears and the reference is selectable.
With copying working, only the success message appears, and it clears.
With the status delayed past your wait, the failure path is used.
The reference characters can be distinguished in your chosen typeface, such as zero versus the letter O, and the spec records the check.
The spec is tried with a screen reader and a keyboard alone on at least one device each, and the notes name them.
The reference is also available somewhere that does not depend on the page, such as a confirmation message you control, if your process includes one.

Write the exact messages into the spec so wording is reviewed once rather than improvised by each developer. Keep them short, plain and honest about what happened.