RE: Fwd: Error Handling Best Practice?

Ø  IMHO, maintaining interaction with the current page is preferable. It will certainly help users retain focus, be less disruptive (since convention is now for error messages

Not to mention that going to a new page may cause the loss of some data such as credit card info, etc. which the user might have to re-enter.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com
703.637.8957 (o)
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Mike Elledge [mailto:melledge@yahoo.com]
Sent: Thursday, December 17, 2015 9:46 AM
To: Adam Powell; WAI Interest Group
Subject: Re: Fwd: Error Handling Best Practice?

Hi Adam--

We haven't had to track form failures, so that's an added wrinkle I haven't had to take into account. But from a usability standpoint, IMHO, maintaining interaction with the current page is preferable. It will certainly help users retain focus, be less disruptive (since convention is now for error messages to appear on the current page), and potentially less confusing, given the multiple windows open on most person's desktops.

Another consideration is that tracking usually takes place in the background and is invisible to users. Breaking expectations of
how a feature behaves in order to capture mistakes doesn't seem like the best approach.



Mike

On Thursday, December 17, 2015 7:25 AM, Adam Powell <adam@adaminfinitum.com<mailto:adam@adaminfinitum.com>> wrote:

Hi All,
This is a timely thread for me but in a different context, I'm currently working on an analytics implementation for an ecommerce site and we are trying to track attempts, successes and failures upon form submissions (create an account, sign in, etc.).

Rather than relying on hidden HTML (initially commented, then uncommented via AJAX/JS), which is very hard to track, I recommended that there be a redirect to a confirmation or failure page (with a different, obvious URL).

It sounds like if that is implemented, they'd want to ensure the 'failure' page would have content at the top of the page that explained (in a list) what went wrong and below that it would have another form with the same fields and function (so users could repeat the form submission without relying on a 'back' button or getting to the page in some other way).

Would it be advisable to make that very first content—essentially the error message(s)—be a list links to anchors/ids of each input with an error?

Are there any accessibility reasons a redirect to a confirmation or failure page should be avoided?

Adam Powell
Learn more at my website: Adam Infinitum<http://www.adaminfinitum.com/>


On Thu, Dec 17, 2015 at 5:55 AM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 17/12/2015 09:31, Alistair Garrison wrote:
[...]
I would be very interested to hear any comments back from the wider
community about user experience success stories relating to accessible
error handling methods, discussing such things as:

1) Is placing an in-line error message before the box better than after
the box?
2) What's the best way to manage focus when dealing with in-line validation?
3) Is placing an error message box before the form a better user
experience than in-line validation?
4) Is in-line validation better than post-form-submit validation? on the
mobile?

I think (and this confused me on the Mobile Task Force list too) you're using "in-line validation" to mean two things here. In your preceding points, you use "in-line" to mean error messages right next to their respective form fields, while in this point, you're using it to mean "the error is displayed right away after the user interacted with the form control, rather than only after the form was submitted"...

Speaking of "in-line validation" in the latter case, this may be interesting: for web content, HTML5 form validation "native" validation bubbles are - both on desktop and mobile - not well supported by AT / not exposed by UAs. See http://developer.telerik.com/featured/building-html5-form-validation-bubble-replacements/#comment-2381878676

5) Should a submit button always be enabled, or can it be disabled when
a form is incomplete?

By having the submit button disabled until the form is complete/valid, you're forcing the user to go through the form until they finally spot the bit they've missed out, which may not be obvious to them. If you allow the user to submit, and then clearly signpost what was incomplete/wrong in the form, they have a better chance of finding/rectifying that, in my opinion.

P
--
Patrick H. Lauke

www.splintered.co.uk<http://www.splintered.co.uk/> | https://github.com/patrickhlauke

http://flickr.com/photos/redux/ | http://redux.deviantart.com<http://redux.deviantart.com/>
twitter: @patrick_h_lauke | skype: patrick_h_lauke