Re: Error Handling Best Practice?

On 17/11/2015 10:30, Alistair Garrison wrote:
> Dear All,
>
> Seemingly one of the best methods for telling people about errors in
> form data is to allow the user to submit the form, then by either by
> client-side or server-side means validate the data.  If the data
> contains errors a message box is placed before the form with all the
> error messages in it, and focus (visual and keyboard) is taken to this
> box (http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/SCR32).  At
> least, this is one of the best methods on desktop…
>
> Trying to translate this concept to a mobile is a little difficult, due
> mostly to the smaller screen size - as content pushed in at the top
> moves all the other content down "below the fold".

If the purpose of the page is for the user to (correctly) fill in a 
form, and there were errors when the user attempted to do so, I'd think 
that the validation results with a list of problems that prevented that 
submission from being successfully completed is the most important piece 
of content that should be "above the fold", no?

> I've done a little research around HTML5 validation, but the
> inconsistent native support / AT support means the method cannot be
> broadly relied upon.  The million and one JavaScript validation methods
> are also an option for telling people if the value they have entered is
> correct, but it is also a lot more confusing that the single error
> message box (mentioned above).

This would likely depend on the length/complexity of the form. If it's a 
short form, like a username/password login, using client-side validation 
(either with HTML5 validation, or some custom JS form validation script) 
that tells the user right away if something is missing/doesn't look 
right before they go through the trouble of submitting, waiting for the 
server response (on potentially slow mobile data network), only to then 
be told that I missed out a character or didn't tick a mandatory checkbox.

It's true that native browser support for HTML5 validation errors 
is...patchy. However, this can be complemented with more traditional 
client-side techniques (generating error messages in markup with a 
role="alert", a live region, associating the error text with 
aria-describedby, etc).

For long forms however, it may well be that doing inline validation may 
not be the best approach, particularly if a user is likely to work 
through the form in a non-sequential order (filling in one section 
first, before going back for some other part). Here, the 
submit/wait/revisit the form with a list of errors at the start pattern 
probably works better.

> So, in your opinions what would be the best "best practice method" for
> error handling and error presentation on a mobile.
>
> All the best
>
> Alistair

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

Received on Tuesday, 17 November 2015 10:51:07 UTC