Search topics
AI rewrite buttons that replace text with no preview or undo
An "Improve with AI" button on a profile writes its version over the person's saved About text at once, so promises they never made go live and their own words can't be brought back.
about.value = text; The problem
People who can't easily spot what a rewrite changed, or recall what they first wrote, have their own words replaced and saved, with no chance to compare them first or bring them back.
A site for freelancers gives each person a public profile, and clients read its About text before they get in touch. The page saves as you go. A bookkeeper has written their own: "I do the books for small shops and cafés, part-time, in the evenings. I reply to messages within two days." Under the box is a button, "Improve with AI".
They press it, hoping for tidier sentences. The box now says: "Experienced bookkeeper helping small businesses thrive. Available any time, I reply to every message within the hour." It reads well, and it has already been saved. It also says two things they never said: that they are available any time, and that they reply within the hour. Their own text is gone. There is no Undo, and in Chrome, Ctrl+Z leaves the new text where it is. Clients now read promises the bookkeeper can't keep, and to get their words back they have to remember them and type them again.
Success criterion 3.3.4, Error Prevention (Legal, Financial, Data), is level AA. It covers pages that change or delete user-controllable data: data people can see and change themselves, such as the name and address on their account, or the About text on their profile. When a page changes that data, at least one of three things must be true. The change can be reversed; the entries are checked for input errors and people can correct them; or there is a way to review, confirm and correct the information before it is final. The button does none of them.
W3C's Understanding page for 3.3.4 says it doesn't ask for a confirmation every time someone saves. When people type and save, the change is the one they made, and they have seen it. Here the change is written by software, and the person meets it only after it has replaced their text in storage. Two of W3C's sufficient techniques for 3.3.4 fit this change: a step to review and correct the answers before submitting (G98), which W3C lists for legal transactions and tests, and a way to recover deleted information (G99), which it lists for actions that delete information. Checking for input errors, the criterion's second way, can't help: the rewrite is valid text, and only the person can tell it says something else.
The browser can't help either. Ctrl+Z undoes what someone typed into a field. When a script sets the field's value, there is nothing for it to take back: in Chrome, the rewrite stays. The old text has also left the server, so a reload brings back only the new one.
On a public profile, the rewrite is what clients read and what they hold the person to. A promise to reply within the hour has to be kept, or explained to each client who expected it.
4 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People with dyslexia, or with memory or attention difficulties, may not spot which phrases in a fluent new paragraph now promise something else, or remember their own wording well enough to type it again.
- Without vision Screen reader users meet the new text only by reading the whole box again, and nothing says which words changed, so a changed promise is easy to miss.
- Limited vision People who zoom in see a few words of the box at a time, so comparing the new paragraph with one that is gone means reading it all again from memory.
- Limited manipulation People who type with a switch, voice input or one finger spend far longer on their words, and an unwanted rewrite with no undo costs them all of it again.
The button has a name, the text box has a label, and the page passes every automated check. Whether a rewrite can be compared or undone shows only once the button is pressed, and the result depends on a model and a server. EaseWeb's audit flags AI writing buttons beside a text box (ew:ai-rewrite-manual-check) for a person to try in a test account; it never presses them, since on a live site that would change someone's text. Nothing in the Before's code is wrong to a linter or a type checker. Whether people can get their words back is a question about the product, and a code assistant asked to add the button isn't asked it.
Try it
Press Improve with AI, then try to get your own words back.
Read what the new text promises. Could you keep what you wrote, or see both before it was saved?
Broken Can you fix this?
Your profile
The fix
Show the rewrite beside the person's text and change nothing until they choose, or keep their words and a Restore button.
- 1Never let an AI button replace saved text with no way to compare it first or bring the original back.
- 2Show the rewrite next to the person's own words, or keep their words where one press restores them.
- 3Name each choice by what it does: Use this version, Keep mine, Restore my text.
<label for="about">About you</label><textarea id="about" name="about">I do the books for small shops and cafés, part-time, in the evenings. I reply to messages within two days.</textarea><button type="button" id="improve">Improve with AI</button>Show the rewrite, and change nothing until it is chosen
<label for="about">About you</label><textarea id="about" name="about">I do the books for small shops and cafés, part-time, in the evenings. I reply to messages within two days.</textarea><button type="button" id="improve">Improve with AI</button><div id="suggestion" hidden> <h2>Suggested by AI</h2> <p id="suggested-text"></p> <p>Your text above stays as it is until you choose. Check that this still says what you mean.</p> <button type="button" id="use">Use this version</button> <button type="button" id="keep">Keep mine</button></div>Why this fix: Read the order back before it is final
One press changes the saved profile. Nothing shows the new text beside the old one before it counts, nothing asks the person to choose, and the old text is kept nowhere, so there is nothing to undo.
The rewrite appears under the box as a suggestion, and the box keeps the person's own words, so both can be read, one after the other, before anything changes. Nothing is saved until "Use this version" is pressed; "Keep mine" closes the suggestion and leaves the profile as it was. Either way, focus goes back to the text box, so people carry on from where their text is.
Both pass 3.3.4. Use the suggestion: nothing the person wrote changes, or reaches clients, until they choose, and they choose with both versions in front of them. Restore is not enough on its own, because the rewrite is public until someone notices it. Keep a Restore button as well when a rewrite can be applied in other ways, such as from a menu or a shortcut, so every way in has a way back. A dialog that asks "Replace your text?" before the rewrite is written isn't enough here: W3C accepts a confirmation for a delete (G168), but this one asks people to approve text they haven't seen.
Put the suggestion straight after the button in the page, so the next Tab or arrow press reaches it. The wait while the model writes, and saying that the suggestion is ready, are their own failures: see loading spinners that screen readers never announce and status messages that are shown but never announced.
Marking what changed helps people compare, especially when only a few words differ. Mark it with more than colour, such as bold or an underline, and keep the plain text of the suggestion as the thing that is used.
A summary or other generated text that should sit beside the person's text, such as a summary of meeting notes, goes in its own field or above the notes. Never write it into the notes themselves.
Some editors show a suggestion as grey text in the box and accept it with a key. If yours does, insert the accepted text with document.execCommand('insertText', false, text) rather than setting the value: in our test in Chromium, Ctrl+Z then brought back what was there before. Setting the value, or calling setRangeText(), left the new text in place after Ctrl+Z in the same test. MDN marks execCommand as deprecated, so keep the call in one place you can replace. Keep a Restore or a suggestion step as well, since Ctrl+Z is gone once the page is reloaded.
Don't put Restore in a toast. A toast that removes itself takes the only way back with it; see toasts that vanish before you can read or undo them. The same care applies to payments and other data a slip would cost people: see checkouts that take payment with no review or undo.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Design ideas
An AI rewrite can look new and still leave the choice with the person.
Four more ways to draw the moment after the AI button, and two fashionable ones that fail. Press their buttons and Tab to them: four keep the person’s own words within reach, and two lose them.
In the design file
- Draw the screen just after the AI button is pressed, with the person’s own text still in view.
- Name each button by what it does, such as Use this version, Keep mine or Restore my text.
- Mark changed words with a strike-through and an underline, not colour alone, and keep the text on each tint at 4.5:1 or more.
- Draw the phone layout, with both versions and every button reachable.
- Put the way back where the change was made, and never on a timer.
Passes
- About you
Part-time, in the evenings.Available any time. I reply withintwo daysthe hour.Tracked changes in the box Removed words struck through on a pale red, new words underlined on a pale green, with Accept and Reject at the end. The person sees exactly which promises changed; the text is 6.44:1 and 6.49:1 on its tint. - About youAvailable any time. I reply within the hour.A Mine | AI switch on the box Both versions are kept for good, one tap apart, so comparing is a tap and nothing is lost. The selected one is what clients read, so the AI version is public until the person switches back.
- About you
Live: Part-time, in the evenings. I reply within two days.
Draft · AI Available any time. I reply within the hour.Rewrite as a draft The AI’s text goes into a draft with a Draft badge, 6.95:1 on its yellow, and the live profile keeps the person’s words until they publish. Suits anything public: profiles, listings, posts. - About youAvailable any time. I reply within the hour.“Edited with AI” and its versions A quiet line under the box opens the earlier versions, each with Restore. Light at rest, and every change can be taken back; the line stays until the person edits the text.
Fails
- About youPart-time, in the evenings. I reply within two days.Shimmer that turns into the new textWCAG 3.3.4 The sweep shows that something changed, and it stops, but the old text is gone and already saved: nothing to compare and no way back.
Rule of thumb: Move to show a change, then stop
- About youPart-time, in the evenings. I reply within two days.Undo in a toastWCAG 3.3.4 “Rewritten with AI · Undo” slides in and goes after 5 seconds, and the way back goes with it. Anyone slower to read the new text, or to reach the toast, keeps the rewrite.
Verify the fix
5 checks, no mouse.
Test with: Keyboard, Screen reader, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the AI feature, its prompt or the editor changes.
Limits
This is a starting pattern, not a guarantee for every product. The example is a profile's About text; drafts, listings, messages, notes and documents need the same care wherever an AI button writes into text that is kept. A suggestion step only helps people who read it: the model can still be wrong in ways the person doesn't notice. Whether AI-written text must be labelled for its readers is outside WCAG. Test the complete feature, including the shortcuts and menus that apply a rewrite, with the people and tools your users rely on.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.