- From: Alistair Garrison <alistair.j.garrison@gmail.com>
- Date: Tue, 22 Dec 2015 16:34:15 +0000
- To: Michiel Bijl <michiel@agosto.nl>
- 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>
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