W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2015

Re: Error Handling Best Practice?

From: Alistair Garrison <alistair.j.garrison@gmail.com>
Date: Tue, 22 Dec 2015 16:34:15 +0000
Cc: David MacDonald <david100@sympatico.ca>, "Balusani, Shirisha" <sirib@uillinois.edu>, "ajaysharma89003@gmail.com" <ajaysharma89003@gmail.com>, Jonathan Avila <jon.avila@ssbbartgroup.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Message-Id: <A50B63CF-DD0D-44CA-8E5B-0A44F5BF6379@gmail.com>
To: Michiel Bijl <michiel@agosto.nl>
Thanks for the suggestion. It's really the where and how to present the error message that I suppose I'm searching for - be it:

1) the block of error messages shown before a form, after the user has submitted the data; or 
2) error messages presented above each form field immediately an error is detected; or 
3) error messages presented below each form field immediately an error is detected; or 
4) combinations of some of the above.

The question - "from a user perspective which is best on a small screen"?

All the best 

Alistair

On 22 Dec 2015, at 16:21, Michiel Bijl wrote:

> 
> 
> @Alistair, Android 4.* supports HTML form validation according to caniuse.com. So you could set a custom error message with .setCustomValidity. 
> 
> @David & Kirsten, to explore all the possible ways to make error messages accessible (to all) and to develop a proposal for an error element, I have created a repository: https://github.com/MichielBijl/error
> 
> So Iíll be watching this thread for any methods that might come up.
> 
> óMichiel
> 
>> On 22 Dec 2015, at 17:10, Alistair Garrison <alistair.j.garrison@gmail.com> wrote:
>> 
>> Hi David, 
>> 
>> It won't work on an Android pre-4.4 phones - as they don't support aria.  Due to the number of users of Android 4.1, 4.2, 4.3 phones a non-aria solution is still needed.  Aria can only be considered as a progressive enhancement to some other more supported HTML + JavaScript method.
>> 
>> All the best 
>> 
>> Alistair
>> 
>> On 22 Dec 2015, at 15:49, David MacDonald wrote:
>> 
>>> aria-describedby works today... it works well.... 
>>> I support an <error> element. But it will still need an id that will be referred to by the corresponding input... so it will be no easier than described by.
>>> 
>>> David & Kirsten MacDonald
>>> 
>>> 
>>> 
>>> On Tue, Dec 22, 2015 at 4:18 AM, Alistair Garrison <alistair.j.garrison@gmail.com> wrote:
>>> Dear All, 
>>> 
>>> The discussion around future methods of error handling has been really interesting.  
>>> 
>>> I'm still left wondering, however, about way more supported, solid HTML + JavaScript methods - and success stories of solutions within a small screen environment.  
>>> 
>>> For real-world developers still having to support browsers that don't support aria this is a major problem which needs a clear solution, and for users a level of consistency to error handling on a small screen would be welcomed - to my mind, in the form of a mobile technique.
>>> 
>>> All the best 
>>> 
>>> Alistair
>>> 
>>> On 22 Dec 2015, at 08:12, Michiel Bijl wrote:
>>> 
>>>> There is a discussion going on over at GitHub. Sailesh Panchang expressed doubts as to whether we really need aria-errormessage, saying we can do the same thing with aria-describedby. Following that we discussed the subject a bit more on a11ySlackers. And came up with a couple of different ways/elements:
>>>> 
>>>> An <error> element
>>>> An error role (would be the same as the <error> element)
>>>> Use <output> to define the error. Status of the input should indicate whether output contains an error.
>>>> 
>>>> Any thoughts on these?
>>>> 
>>>> óMichiel
>>>> 
>>>>> On 22 Dec 2015, at 03:55, David MacDonald <david100@sympatico.ca> wrote:
>>>>> 
>>>>> error messages should be associated with the error field via aria-describedby
>>>>> 
>>>>> David & Kirsten MacDonald
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Dec 18, 2015 at 8:54 AM, Balusani, Shirisha <sirib@uillinois.edu> wrote:
>>>>> The best way would be inline error or displaying error links on the top of the page . If errors are displayed on the top of the page (after selecting the submit/ save button), the focus should be taken to the first error in the list.
>>>>> When user selects a error link, the focus should be shifted to the respective field( where error occurred).
>>>>> Thanks
>>>>> Siri
>>>>> 
>>>>> -----Original Message-----
>>>>> From: ajaysharma89003@gmail.com [mailto:ajaysharma89003@gmail.com]
>>>>> Sent: Friday, December 18, 2015 7:42 AM
>>>>> To: Michiel Bijl <michiel@agosto.nl>
>>>>> Cc: Jonathan Avila <jon.avila@ssbbartgroup.com>; Patrick H. Lauke <redux@splintered.co.uk>; w3c-wai-ig@w3.org
>>>>> Subject: Re: Error Handling Best Practice?
>>>>> 
>>>>> 
>>>>> Hi Michiel, by message I meant message in javascript alert dialog box, alert(), please forgive me for being unclear.
>>>>> 
>>>>> Ajay
>>>>> 
>>>>> 
>>>>> > On 18 Dec 2015, at 07:32, ajaysharma89003@gmail.com wrote:
>>>>> >
>>>>> > Hi there, I am just curious to have your comments on isn't using javascript to display error message and taking focus to error causing field after closing the message is a good way to assist the user to correct the error?
>>>>> >
>>>>> >
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
Received on Tuesday, 22 December 2015 16:34:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 December 2015 16:34:51 UTC