- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 22 Dec 2015 10:49:03 -0500
- To: Alistair Garrison <alistair.j.garrison@gmail.com>
- Cc: Michiel Bijl <michiel@agosto.nl>, "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: <CAAdDpDYeDuvK05YTMtHzD7d08eYagC8du+WoJyQOm5Tf32iKgQ@mail.gmail.com>
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 > <https://github.com/w3c/aria/issues/128#issuecomment-166383811>. 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 > <https://gitter.im/w3c/a11ySlackers?at=56783de1091b6f9e043a1294>. 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 15:49:36 UTC