Problem
A completion appears after the cursor, in the same line, in the same font, in the place where the viewer’s own next words would go. It has to be legible enough to judge and unmistakable enough that nobody ever believes they wrote it.
Solution
Render the suggestion inline in a lighter weight of the same typeface, after the insertion point, and accept it with Tab. Those three choices are close to universal because each one is doing work: inline because the value is seeing it in its actual position, lighter because the state has to be visible without reading, and Tab because it’s adjacent to typing and unclaimed in most text contexts.
Contrast is the hard constraint and the one most implementations get wrong. Grey text has to be light enough to read as provisional and dark enough to be read at all, and the window between those is narrow. Pushed too light it fails accessibility guidance outright and becomes unusable for anyone with low vision, in bright light, or on a poor display. Pushed too dark it stops reading as a suggestion, and someone eventually ships a document with a completion they never accepted. The honest resolution is to carry the state in something other than contrast alone, whether that’s a subtle background, an italic, or a marker in the gutter.
Timing is the second constraint, and HAX guideline 3 names it directly: time services based on context. A completion offered on every keystroke is chaos, because it changes while the viewer is still forming the sentence it’s trying to finish. Debouncing to a pause in typing produces far fewer and far better suggestions. The related failure is the suggestion that vanishes the instant the viewer looks at it, dismissed by a keystroke before it could be evaluated.
Accept needs gradations. All-or-nothing is a poor fit for a three-line suggestion whose first clause is right. Word-by-word acceptance, usually on a modifier plus the right arrow, turns a rejected suggestion into a partially useful one and is the difference between a tool that helps experienced writers and one they turn off.
Prose and code behave differently enough to be worth separating. Code has strong structural cues, an established completion tradition, and readers who already scan for shape. Prose completion sits in the same faculty the writer is using to compose, so it interrupts more and has to be quieter and rarer to be tolerable.
Acceptance rate is the obvious metric and misleading on its own, since a suggestion accepted and then rewritten cost more than none at all. Retention of accepted text is the number that means something.
Use when
The next few words are predictable from strong context, and the viewer is producing text in a place where a wrong guess is cheap to dismiss.
Don’t use when
The writing is short, deliberate, or high-stakes. A subject line, a legal clause, or a commit message gets no benefit and carries the full risk of an unnoticed accepted completion.
Trade-offs
Ghost text is the least interruptive way to offer help and the easiest to accept by accident, and those are the same property. Making it more visible makes it more intrusive to people who didn’t want it. It also shapes what gets written: a writer offered a plausible continuation tends to take it, so the tool’s voice leaks into the work in a way nobody consented to sentence by sentence. Every suggestion costs an inference whether or not anyone reads it. Per unit of value, nothing else here is as expensive.
Checklist
- Does the suggestion meet contrast requirements while still reading as provisional?
- Is the provisional state carried by anything other than colour?
- What triggers a suggestion, and how long is the pause before it appears?
- Can part of a suggestion be accepted?
- What dismisses it, and can it be recovered after an accidental dismissal?
- Does a multi-line suggestion shift the content below the cursor?
- What does a screen reader announce, and when?
- Is it disabled in fields where an accidental accept would be expensive?
- Is retention of accepted text measured, or only acceptance?
- Can the viewer turn it off in one place they can find?
Compare
GitHub Copilot presents a completion whole rather than streaming it, accepts on Tab and supports partial acceptance by word. The suggestion is an object to evaluate rather than a process to watch. Google Docs applies the same mechanic to prose with far shorter and rarer suggestions, conceding that prose tolerates less interruption than code. Notion mostly avoids the pattern in favour of explicit invocation at the cursor. Ambient help goes, and nothing ever appears unasked. Superhuman scopes it tightly to email, where the context is strong, the phrasing is formulaic, and a wrong guess costs one keystroke to clear.
Related
Inline assist is the explicit version, invoked on a selection rather than offered unprompted. Suggestion diff is how larger changes get proposed when ghost text is too small a container. AI entry point covers how an ambient feature announces itself. Streaming response is the deliberate opposite choice about whether to show output as it arrives. Response actions is the equivalent control row where output is a chat turn.