These kinds of updates are really more suited to ajaxy sites where users are not on a traditional form and they are not hitting a submit button. Think how sometimes (usually when there were errors) sites like Facebook, Twitter and StackOverflow have messages like that, often after a problem.
They are too much for any traditional form, because the setup is simpler: users know if they don't hit Submit again, nothing changes. They know if they hit Submit and the page refreshes, something happened. If they get a success message, they know it worked.
Always let people know that the form was successfully filled in! Bringing them back to the form, whether the form is still filled in with their values or not, may allow them to assume it did not submit and they may resubmit.
I am a fan of allowing the back button to take the user back to the form if they wish, but your server will need to use something like the PRG system (POST, Response, GET). This prevents accidental resubmission of the form. Otherwise usually if the user does hit the back button, many browsers will pop up an alert stating the page needs to be resubmitted or some such.
While this is valid (meaning, it matches what many other forms do and so users have experience with this), I prefer what ralph proposed, and having error messages above and outside the form are considered best practice by the likes of WebAIM.
If the page is long and the form is not right near the top, OR if the form is long (your form seems short-to-middle, so I guess this one's up to you), it's most accessible (not only to the blind) to list the errors near the top of the page (as in, a ul) which users can click (if the page is long) to jump directly to the problem input itself. The error message is clear in what was wrong, ideally. Then when the user is at the form itself, the problem input (and label and optional message) are clearly distinct from the correct ones. Colour is one way to make them stand out, but an additional message next to or after or before the problem input can also be nice.
All the information, even the bad input, are still filled in (some sites will not send back credit card data or passwords for security reasons if they are sending back via GET so if users must refill these in make this also obvious).
So, on my long long long insurance forms, my setup was so:
- The page title was changed to something like "Problem! Form not submitted!"
- The h1's title remained whatever it was, so the user was clear they had not moved on to the next form (since there were 3 forms). But you could change it to a warning red colour if that still offers plenty of contrast on your page.
- The skip link to general content I had on all other pages went to the same place (main content) but the text now mentioned that the form contained errors. The first element of the main content was now (after the h1) the error list.
- The error list should have been explicit but unfortunately I had to work with these generic, generated things the backender came up with. Saying the text is "too long" and "the limit is 1024 characters but your message is 2000 characters" is clear and works.
- Because the page and the form were long, the error list had actual links, because when the server sent back the bad form with all the inputs still filled in with user session, it also added skip link destinations within the form. You could do it much simpler than we did and just add id's or use the input's existing id's instead. A 10 question form may not need any skip links at all. Besides, those don't work in webkit anyway. Arg.
- For us, the skip destination was a big red bar with white error text repeating the error message right above the problem input. Again for you I think this is overkill, but you certainly want some kind of highlight of the input who is bad. If the error message is not contained within a form control (is not an input or label or legend) then you want to associate the error with the input or label using aria-describedby.
- At the bottom, outside of the form (so right after the submit button) we added a message stating something like, "if you are having trouble you can call us at [tel] between [times] or email us at [email]" which many people reported when they called that this was very helpful. Again, these were semi-complicated and long insurance forms so again not something you necessarily need to do.
The errors should not only be clear but ideally don't tell the user they are wrong and stupid, even if they are.
"Oops! Your message is more than 1024 characters. Please shorten your message to 1024 characters or less." Something like that.
Those ones are kinda hard and it's nice to have some JS that shows the user how many characters they have in a text area while they type. Meaning listening for an onkeyup event. It's possible to make these accessible to screen reader users (twitter with EasyChirp works, you can hear how many characters you have left after every keystroke) using ARIA attributes.
I am so very very frustrated that Youtube's search is so, so crappy, because I would have LOVED to find the demo someone uploaded of trying to sign up to either a Google Account or specifically Gmail with a screen reader (I think it was JAWS) and not hearing the error messages the form generated next to the inputs. It was such a very good video and I simply cannot find it and wish I had bookmarked it. ARG. Youtube's search is one of the worst I've ever seen... I'm getting Black Eyed Peas videos when I type in search terms with things like screen reader and gmail. Useless.