Search topics
Comment forms that post with no preview, edit or delete
A recipe blog's comment form publishes a comment the moment Post Comment is pressed, with no preview first and no way to edit or delete it after.
The problem
People who slip when they read, type or dictate publish the mistake under their own name, with no chance to see it first or correct it after.
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.
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.
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.
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 can read tablespoons as teaspoons, or tbsp as tsp, and people with memory or attention difficulties may not notice a slip as they type. Seeing the comment set out on its own, as others will, is where a slip shows.
- Limited manipulation Dictation can write a word that was never said, and a tremor or a switch can add a key. With no preview, the first time people see what the software wrote is in public.
- Without vision Checking a comment inside the text box means moving through it line by line. Once it is posted, a screen reader user may not hear the slip until they read the thread back, by which time it can't be changed.
- Limited vision Zoomed in, only a few words of the box are in view, so a slip a few lines up is out of sight when Post Comment is pressed.
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".
Try it
Your tip says tablespoons where you meant teaspoons. Post it, then try to put it right.
Does anything show you the comment before it is public, or let you edit or delete it after?
Broken Can you fix this?
Comments
Alex, 2 days ago
Made this twice now. Roasting the tomatoes first is worth it.
The fix
Let people check a comment first, or fix it after.
<h2>Comments</h2><ol class="comments"> <!-- The new comment, public as soon as Post Comment is pressed --> <li id="comment-1042"> <p><b>Sam</b>, just now</p> <p>Lovely soup. I'd add 2 tablespoons of salt at the end.</p> </li></ol><form method="post" action="/comments"> <label for="comment">Comment</label> <textarea id="comment" name="comment" required></textarea> <label for="author">Name</label> <input id="author" name="author" required autocomplete="name"> <button type="submit">Post Comment</button></form>What is wrong3 points
- 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.
A preview in the thread before the comment is posted
<h2>Comments</h2><ol class="comments"> <!-- The new comment, public once Post Comment is pressed under its preview --> <li id="comment-1042"> <p><b>Sam</b>, just now</p> <p>Lovely soup. I'd add 2 tablespoons of salt at the end.</p> </li></ol><form method="post" action="/comments/preview"> <label for="comment">Comment</label> <textarea id="comment" name="comment" required></textarea> <label for="author">Name</label> <input id="author" name="author" required autocomplete="name"> <button type="submit">Preview comment</button></form>How it is fixed4 steps
- Make the form's button "Preview comment", and have it save the comment as a draft that nobody else can see.
- 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.
- 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.
- 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.
Why this fix: Read the order back before it is final
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.
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 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 and toasts that vanish before you can read or undo them. 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.
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 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. 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.
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.
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.