Re: Fwd: Error Handling Best Practice?

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>
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 | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>