# Comment forms that post with no preview, edit or delete
Source: https://easeweb.dev/learn/comment-review
Topics: Forms > Every form submission can be checked or undone (WCAG 3.3.6)
The fix: Either make the comment form's button lead to a preview, with Edit and Post Comment, so nothing is public until the writer has seen it, or show Edit and Delete under the writer's own comment until a stated time. The second passes too, but the slip is public until the writer notices it.
Test with: keyboard, screen reader, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-all.html https://www.w3.org/WAI/WCAG22/Techniques/general/G98 https://www.w3.org/WAI/WCAG22/Techniques/general/G164 https://www.w3.org/WAI/WCAG22/Techniques/general/G168 https://api.drupal.org/api/drupal/core%21modules%21comment%21help_topics%21comment.configuring.html.twig/10 https://wordpress.org/plugins/simple-comment-editing/
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.
## What happens
A recipe blog runs on WordPress, and under each recipe is the comment form WordPress gives every blog. The example keeps the parts that matter here: a box for the comment, a Name field and a Post Comment button. It is drawn to be quick, and for most comments it is: write, press, done.
A reader has made the tomato soup and wants to pass on a tip. They mean two teaspoons of salt, but they write "2 tablespoons", an easy slip between two words that look so alike. They press Post Comment. The blog doesn't hold comments for approval, so it appears in the thread at once, under their name, for everyone who reads the recipe. A minute later they read it back and see the slip. There is no Edit link and no Delete link under it, and nothing on the page says how to change it: the only way is to write to the blog's owner and wait. In the meantime, the next person to make the soup may follow the tip.
## Why it fails
Success criterion 3.3.6, Error Prevention (All), is level AAA. For any page that asks people to submit information, at least one of three things must be true. The submission can be reversed; the data entered is 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. 3.3.4 asks for the same at AA, but only for legal commitments, financial transactions, changes to data people keep on the site, and test answers. A comment is none of these, so it is left to 3.3.6.
The form does check its fields: an empty comment or a missing name brings back an error. Read word for word, that is the criterion's second way, and a strict reading could stop there. But WCAG defines an input error as information the form doesn't accept, and "2 tablespoons of salt" is accepted, so the check never reaches the slip the criterion is there to prevent. The sufficient techniques that 3.3.6 points to are those of 3.3.4, used on every form: a step to review and correct the answers before submitting (G98), a stated time within which a submission can be changed or cancelled (G164), a checkbox in addition to the submit button (G155), a way to recover what was deleted (G99), and a request to confirm before going on (G168). None of them is validation, and this form offers none of them.
WordPress gives visitors who comment neither a preview before posting nor an edit after; plugins add a time-limited edit. Drupal, for comparison, has a setting in core that makes a preview required before a comment is saved.
## Who is affected
A comment is public, carries the writer's name, and stays under the recipe for as long as the recipe does. On a recipe, a how-to or a product page, other people act on what it says. The people most likely to slip may also be the ones who find it hardest to ask a site's owner for a correction by email.
## What automation and AI miss
Each field has a label, the button has a name, and the form passes every automated check. Whether a comment can be previewed, edited or deleted depends on what the server does after Post Comment, and a scanner never posts on a live site. EaseWeb's audit has no check for it, because the markup of a form says nothing about what happens to its submission. A code assistant asked to "prevent errors" on this form may add `minlength` and `maxlength` to the comment box, which stops a one-word comment but not "tablespoons".
## Before: Post Comment publishes at once
```html recipe.html
Comments
```
- The server publishes the comment as soon as the form arrives.
- Nothing shows the comment back before it is public.
- Once it is posted, its writer has no way to edit or delete it.
## After: a preview in the thread before the comment is posted
```html recipe.html
Comments
```
```html recipe-with-preview.html
Comments
```
1. Make the form's button "Preview comment", and have it save the comment as a draft that nobody else can see.
2. Send back the same recipe page, opened at the draft: the comment in the thread, where it will appear, marked as a preview only its writer can see. The recipe and the comments before it stay on the page, so the tip is read where others will read it.
3. In the form's place, put Post Comment, and Edit your comment, which brings the form back with the comment and the name kept, so fixing the slip takes one change, not a new comment.
4. Publish only from Post Comment.
This fixes the Before and passes 3.3.6 with a way to review, confirm and correct the comment before it is final, as G98 describes.
## After: Edit and Delete under your own comment, until a stated time
```html recipe.html
Comments
```
```html recipe-editing.html
Comments
```
```html recipe-deleting.html
Comments
```
1. When the comment is posted, set a key for it in a cookie, so the site knows which browser wrote it.
2. Under the comment, say until when it can be edited or deleted, as a time of day.
3. Until then, show that browser an Edit link and a Delete link, each named for what it acts on.
4. Let Edit turn the comment into its own form, in its place in the thread, with its text in the box, so fixing the slip takes one change and the replies around it stay in view.
5. Ask before deleting, under the comment itself: deleting what someone wrote is itself a step 3.3.4 covers, so Delete shows a question with Delete comment and Keep it.
The comment is public at once, but it can be corrected or withdrawn, so this fixes the Before and passes 3.3.6, with the stated time of G164. It is not enough on its own: the slip is public until its writer notices it, and the next reader may follow it in the meantime. It holds only while the time is long enough to notice a slip in, and only on the browser that posted the comment: someone who posts from a phone and reads the thread on a laptop can't fix it there.
## Which option to use
Both pass 3.3.6. Use the preview: it is the only one that stops the slip before anyone else reads it, and it works for every commenter, signed in or not, on any device. Add Edit and Delete as well when you can: they catch the slips people only notice later, once they see the comment in the thread. On their own, they leave the mistake in public until it is found.
## Implementation decisions
Keep the draft on the server between the preview and the post, not only in the page. Then the Back button, Edit your comment and a reload all come back with the comment and the name in place, as [checkout forms that ask for the same address twice](/learn/redundant-entry) explains for longer forms.
A comment held for moderation, as WordPress holds one by default from someone with no approved comment yet, doesn't do the job either, although WordPress shows it to its writer with "Your comment is awaiting moderation." and, when the browser hasn't saved their details, "This is a preview; your comment will be visible after it has been approved." The writer can see it but not change it, and a moderator approves it as it was written.
A preview under the box that updates as people type, as some forums draw it, shows how formatting will look. It shows the same words beside the box they were typed in, and nothing comes between the press and the post, so it doesn't do the job of the separate step.
Choose the edit window for the people who need it. One comment-editing plugin for WordPress gives visitors five minutes by default, which is short for someone who reads slowly or only notices a slip when they come back. A site with accounts can tie the comment to the account, so the writer can edit it from any device, for longer or with no limit. When a comment changes after replies have come in, say so beside it ("Edited"), so the replies still make sense.
Deleting is covered at AA by 3.3.4, because it removes data. A page that asks first, or an Undo straight after, does that job; see [confirmation dialogs that don't read out their question](/learn/confirmation-dialogs) and [toasts that vanish before you can read or undo them](/learn/toast-timing). For payments, legal agreements and changes to stored data, the same choices are required at AA: see [checkouts that take payment with no review or undo](/learn/error-prevention).
## Verify the fix
1. Post a test comment with a deliberate slip, such as tablespoons for teaspoons, and go as far as the site lets you before it is public. Confirm the comment is shown to you, as others will see it, before it counts, or that you can change it afterwards.
2. From the preview, use Edit your comment. Confirm the form comes back with the comment and the name kept, and that the next preview shows the corrected comment.
3. Where there is an edit window, confirm its end is stated as a time beside your comment, then edit the comment and delete a second one with a keyboard alone, and confirm Delete asks first.
4. With a screen reader, confirm the whole comment is read before Post Comment under the preview, or that Edit and Delete come straight after your posted comment and say what they act on.
5. At 400% zoom or on a phone, confirm the whole comment and the button that publishes it can be read together, or one straight after the other.
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the comment system, its plugins or its theme change.
## Limits
This is a starting pattern, not a guarantee for every form. The example is a blog comment; reviews, forum posts, messages, contact forms and sign-ups need the same choice at the press that sends them. Telling people that their comment was posted, by sight and by screen reader, is a separate failure: see [form success and error messages that are never announced](/learn/form-results). 3.3.6 is AAA, and W3C doesn't recommend asking for AAA across a whole site, but a public comment is where a mistake is cheap to prevent and awkward to live with. Test the complete flow, including any email the site sends, with the people and tools your readers rely on.
---
Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)
Sam, just now
Lovely soup. I'd add 2 tablespoons of salt at the end.