- From: Michiel Bijl <michiel@agosto.nl>
- Date: Thu, 17 Dec 2015 16:19:48 +0100
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Cc: Alistair Garrison <alistair.j.garrison@gmail.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-Id: <2263027D-702B-4D42-B009-743B6E91C4F6@agosto.nl>
That’s why we have aria-errormessage right? Not sure that is implemented anywhere though. —Michiel > On 17 Dec 2015, at 16:07, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote: > > as a general comment — > > introducing text behind the element a blind person is looking at on a page generally makes it less likely that they will ever “see” (encounter) (experience) it. > > In this particular case - there are other options and issues — I won’t duplicate other posts. > > gregg > > >> On Dec 17, 2015, at 3:31 AM, Alistair Garrison <alistair.j.garrison@gmail.com <mailto:alistair.j.garrison@gmail.com>> wrote: >> >> Hi, >> >> I sent a note to the Mobile Task Force list regarding error handling best practices, ideally when working with smaller screen sizes (first email in this Thread). I received a few comments, below, but I'm still left wondering. >> >> 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? >> 5) Should a submit button always be enabled, or can it be disabled when a form is incomplete? >> >> etc… >> >> I apologies in advance if this question has been raised and answered in the past… If so a pointer to that information would be gratefully received. >> >> In addition, I'd be more than happy to collate comments into a WCAG 2.0 technique if that would be of interest. >> >> Very best regards >> >> Alistair Garrison >> >> Begin forwarded message: >> >>> From: <alands289@gmail.com <mailto:alands289@gmail.com>> >>> Subject: Re: Error Handling Best Practice? >>> Date: 17 November 2015 14:23:00 GMT >>> To: Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>, Alistair Garrison <alistair.j.garrison@gmail.com <mailto:alistair.j.garrison@gmail.com>>, "public-mobile-a11y-tf@w3.org <mailto:public-mobile-a11y-tf@w3.org>" <public-mobile-a11y-tf@w3.org <mailto:public-mobile-a11y-tf@w3.org>> >>> >>> There are many challenges with error messaging alerts. >>> The summarized method all in one div for web works great as an alert since the screen reader will announce all the error fields. >>> In-line is good in that it does show the user each field that has an error. Developers are often challenged to make the page/app announce all inline errors in one announcement if you will. >>> Moving to mobile, I still like the one place alert, a popup works great as it can get announced, then the user can go to the inline marked/labeled fields in error to fix. >>> >>> Regards, >>> Alan >>> >>> Sent from Windows Mail >>> >>> From: Jonathan Avila <mailto:jon.avila@ssbbartgroup.com> >>> Sent: Tuesday, 17 November, 2015 9:04 AM >>> To: Alistair Garrison <mailto:alistair.j.garrison@gmail.com>, public-mobile-a11y-tf@w3.org <mailto:public-mobile-a11y-tf@w3.org> >>> >>> Ø So, in your opinions what would be the best "best practice method" for error handling and error presentation on a mobile. >>> >>> One thought might be to summarize the errors at the top but to indicate and associate them inline and focus the first field in error after submit. I would agree with others that inline is probably best when you have more than 2 or 3 fields. Any inline messages would also need to be very visually apparent as well to help the user understand that the form was submitted but an error was found and they need to address the error to continue. >>> >>> Jonathan >>> >>> -- >>> Jonathan Avila >>> Chief Accessibility Officer >>> SSB BART Group >>> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> >>> Phone 703.637.8957 >>> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP> >>> >>> From: Alistair Garrison [mailto:alistair.j.garrison@gmail.com <mailto:alistair.j.garrison@gmail.com>] >>> Sent: Tuesday, November 17, 2015 5:31 AM >>> To: public-mobile-a11y-tf@w3.org <mailto:public-mobile-a11y-tf@w3.org> >>> Subject: Error Handling Best Practice? >>> >>> 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 <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". >>> >>> 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). >>> >>> 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 >> >
Received on Thursday, 17 December 2015 15:20:44 UTC