I have a Q&A Form where Users can share there thoughts on small-business.
The Form consists of 10 (optional) Questions.
Here is a sample…
The only data validation I really do is making sure the Answer < 1024 characters. And if there is a problem, then I re-load the Form with the suspect Answers, and display a message like “Answer cannot exceed 1,204 characters. Current is 1,500 characters.”
Questions:
1.) What kinds of Messages should I be displaying?
One person suggested I place a message next to each field regardless of the outcome, e.g.
No changes were made
Answer updated!
Answer added!
Answer cannot exceed 1,024 characters
Is that too much?
2.) Where should I display the messages?
I like the idea that they are immediately below the text Box so they don’t mess up the spacing between the Label and Input.
3.) What kind of “workflow” should I have?
In the past, when an action was completed successfully (e.g. Form Updated, Password Re-set, etc), I would re-direct to a new page and display a message like…
“Thank you for your submission!
You Profile Answers have been updated.”
Do I even need to show people when everything went as planned?
Is it better to display a new “Success Page” or take them back to the Form?
Any other thoughts or ways to improve things would be helpful.
There’s no right answer to this, and there’s been a lot of discussion about it that I’ve seen.
One thing to consider is what a non-sighted user will experience. It might be quite confusing if the error message comes after the question and textarea. Another thing to consider is the what happens when the page reloads. A non-sighted user might have to step through headers, menus and all sorts of stuff before getting to any text that says “there was an error”. So ideally, the first message they should get on page reload is “there was an error!”
However, from a design point of view, a plain page with just an error heading is a bit ugly, so I guess there’s a bit of thinking needed there. Perhaps a hidden message at the top of the page to be read out to non-sighted users? Or the page title?
My current preference is to have a prominent message / heading that indicates there were errors, and then directs people to view the errors (in red) next to (or underneath) each label.
I’ve also been wondering how feasible it would be to hide the form fields that were filled in correctly. I’m not sure if this has been done before, and there could be some issues with it, I suppose (e.g. the user might want to change some answers that were OK). I guess, in that situation, the correct answers could be closed but available to view (via JS). But then there are more accessibility issues. Sigh!
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.
So yes
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.
I hate form errors where you can’t immediately see where the error was. I would go for a prominent message at the top of the page asking you to review the highlighted items below.
It should be clear immediately where the error is visually and then next to the input you can give more information. Remember there may be more than one error on submission so make sure they are all prominent.
I strongly strongly strongly urge developers to put non-form controls and similar text (like directions) outside the form, not inside. P’s are not form controls and for example would be missed by Forms Mode in JAWS etc.
That would seem to defeat the purpose wouldn’t it?
It would be logical to have the error message next to the element it refers to. It would certainly make it very difficult (impossible) to style as shown in my demo and therefore make it harder for virtually 90% of users to see the error easily. I’m all for accessibility but that must mean don’t make it worse for normal users.
The original w3c recommendations were actually to use p elements to wrap form controls and indeed html5 says the same thing. I do disagree with their use simply to wrap form controls but I disagree that they shouldn’t be used inside a form to provide more information at the context that it is required. It would be impossible to cater for descriptive text otherwise in any usable way.
Unless of course you meant substitute a div instead of the p element but I would also see that as non semantic.
and similar text (like directions) outside the form
That would really annoy me if I had to keep scrolling back to the top of along form to see what I was supposed to be inputting. Don’t make it harder for me than it already is.
I’m getting old lol - I don’t want to have to search for things
I do a fair bit of online purchasing these days and forms drive me mad. Nine times out of ten they don’t work properly or they are almost impossible to fill in.
Mallory (Stomme) is the accessibility expert though so I would take more heed of what she says than me
On my website I’ll have a special area with just one Field and a big red EASY button on it for you!
I do a fair bit of online purchasing these days and forms drive me mad. Nine times out of ten they don’t work properly or they are almost impossible to fill in.
Your sample was “aggressive”, but informative.
I’ll have to chew on it some.
Mallory (Stomme) is the accessibility expert though so I would take more heed of what she says than me
No no, specifically look at what part I quoted. You have plain text inside the form that says “There were errors; see below.” That does not belong in the form.
When I have my list of errors before the form, yes I do also have them inside (but in my insurance forms it was done more complicated-ly than Debbie would need to). But then it’s either stuffed inside the label and styled apart or we use ARIA attributes (which can help newer screen readers in Forms Mode hear non-form-controls since they are now aria-describedby the error message.
http://stommepoes.nl/Scooterverzekeren/scooterberekenfout.html I really need to make an updated version of this, this is no longer good but hopefully shows what I mean. There’s no aria in there, it’s that old. My newer version had the error templates IN the regular markup for the backender so I don’t have a better example. Hopefully soon.
This topic was on my mind recently when I wrote an article about it (but I won’t link to it for obvious reasons). A few thoughts:
I use aria-describedby in any case. I always add an ID to each error message, to be referenced by that attribute, which can be added programmatically to affected form controls in response to the relevant error(s). Do that wherever the errors are shown.
I have to back up Stomme poes’s point about general mark-up in forms: I hate to see that because it shows that the author has probably never tested thoroughly with screen-readers to see why it can fail. You can use multiple label elements, which is one way of getting around that. But, as I do not put error messages inside the forms, preferring instead to place them en bloc and highlight the inputs, I do not know off-hand how multiple labels plays with a range of ATs/UAs. Test before releasing to the wild is generally my advice with all such things. HTML5 allows labels outside of forms, which may one day be useful for marking-up external error messages: I’m not completely convinced of this idea, though.
If you want en bloc messages high in the mark-up, add a link to the form, especially if thereis content in between. I have seen some developers linking each message to each input, but I consider that to be overkill and it’s restrictive: what if you need to write a message that refers to more than one input?
You can put the messages en bloc right above the form, and send the UA to that point by adding a hash + element ID to the form action. It needs a bit of JS for wekbit browsers. I’m testing this at the moment and it so far works robustly enough… But YMMV, as the Americans like to say. Every possible method has finer pros and cons (the Devil really is in the details) that are too much for me to discuss here.
Whatever you do depends to some extent on the nature of the form and of the page on which it is used. For instance, a lot of content between the form and the messages; or a long form. Though one should never lose sight of the possibility that a long/complex form is too long/complex and therefore unnecessarily creating this secondary problem.
But whatever, I never knowingly let any considerations override the ultimate consideration: does what I’ve done maintain a sufficient level of accessibility for AT users, keyboarders, low-vision users… If not, I review the whole thing, form included.
Debbie, a second and slightly shorter comment for you, because I wouldn’t want you to think that I wasn’t going to address your questions directly! (I hate it when mine aren’t!)
Q1: Keep 'em easily understandable and fairly short. Nothing remotely technical. As Stomme poes (I think) pointed out, there’s no need to use those AJAX-like positive messages in this context.
Q2: See my ramblings above.
Q3: Redirecting upon a successful submission is classic practice and works very well. It’s also very accessible, because the new page is obvious to ATs and its content is minimal. There is a classic phrase to describe this method, “something, something, redirect” or something… Heck, I can’t remember it now.
Possible option, which is sometimes handy: display the results of the form submission below the confirmation as a reminder. Sometimes useful, but must be well filtered for safety.
Only go back to the form if necessary. When errors occur, in other words.
As an aside: your validation and sanitisation routine seems as if it is very loose indeed. Be careful, won’t you?
Yeah, it’s up in my (too long) post: POST, Redirect, GET. This also lets people hit the back button to view the form again (for whatever reason… you can do this on Amazon.com for example and I do sometimes go back to make sure I did it right or re-check my total).
I used to have multiple labels to hold additional information but some of my readers seemed to skip these if I was tabbing from input to input. However this more likely was due to my inexperience with the readers instead.
Until I rework my forms example, the commented out markup of this page (sorry that it’s in Dutch) shows what I was going for. It never got implemented at quite the level I wanted due to the pre-made system the back-ender ended up using to generate both the forms and the error-messages, so the testing never really got finished. What I hoped for was generated anchors as link destinations for each error, followed by a p with an id and aria-describedby matching the label of the bad input (or, for birthdate, set of inputs… that setup was because the backender preferred select dropdowns for dates. Something I’d reconsider if building forms all by myself).
I notice both my examples, I did change the h1 text, while in my earlier comment to Debbie I said I left it the same. Hm. Since the h1 is a common way of jumping to the important part of the page, I guess it along with the page title (and skip link of first example) make it really obvious that something went wrong.
Saying the text is “too long” and “the limit is 1024 characters but your message is 2000 characters” is clear and works.
