Re: Rationale for aria-errormessage

Hi Sailesh,

The reason for aria-errormessage, and this was discussed on numerous calls, is that for a given form you may have multiple error messages that are rendered on the screen. Each is associated with a given form element. The aria-describedby may also be used on those form elements to define how to use that particular form element. 

We can’t have the two conflicting with each other. If the user receives an error message and it overwrites the description on how to operate the form field then we have another problem in that you have received an error message associated with the invalid field and then you want to know why you got it and how to fix it, yet your error message has replaced the description text for how to operate the field. 

So, this fairly obvious conflict should easily be explained in our authoring practices guide. 

You were not to first to raise this point and the group resolved to have the separate error message for these reasons. 

I hope this explains the use case and need. 

Best,
Rich


Rich Schwerdtfeger




> On Jul 25, 2016, at 3:42 PM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> Aria-errormessage:
> The rationale for including this is not documented.
> It is merely a special case of aria-describedby and is burdened  with
> the requirement of aria-invalid.
> If the programmatically associated message conveys it is an error or
> that input is invalid, why burden SR users with output of aria-invalid
> too?
> See ARIA21 ... aria-invalid can be used without a separate message
> like in example#1 and as noted is not always needed.
> Developers / testers need to be better trained in use of
> aria-describedby for error messaging. And in any case using
> aria-describedby for this purpose can never be wrong or fail WCAG2.
> Aria-errormessage will confuse developers / testers and some will use
> describedby  and some the new one  and users will suffer till user
> agents and AT makers decide to provide uniform support for
> aria-errormessage.
> 
> Sailesh Panchang
> 

Received on Monday, 25 July 2016 21:16:00 UTC