Re: Rationale for aria-errormessage

Sailesh,
Some AT process aria-describedby in a way which is not appropriate for error messages. They either delay reading the description or allow the user to turn off the announcement of the description completely. This is quite reasonable for descriptions but  is not appropriate for error messages. 
Regards,
James



> On Jul 26, 2016, at 16:16, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> Hello Rich,
> I do not see any conflict and nothing that is "fairly obvious".
> In my comment above, I did note this is a special case of
> aria-describedby and  that "Developers / testers need to be better
> trained in use of aria-describedby for error messaging". That means
> knowing how to append another id-reference  to aria-describedby. Only
> in circumstances the(generally rare) it may be reasonable to retain
> only the reference to the error message text.
> The key point is that aria-describedby is now supported by UA/AT so it
> is up to content developers to use it properly. Introducing another
> attribute will not shift any responsibility off content developers. In
> fact they need to understand when to use which attribute. In addition,
> now of course AT makers will be required to build a hook for this new
> attribute. I wonder if they will assign it a high priority to this.
> And will it be wrong if one continues to use aria-describedby for
> error messaging? Will it fail WCAG2?
> PS: Good to know I am not the first one to  wonder about the purpose
> of this attribute. In fact I raised a Github issue in Dec 2015
> (Aria-errormessages property: what void does it fill? ) but did not
> see any substantial explanations to  my question at that time too.
> Best wishes,
> Sailesh
> 
> 
>> On 7/25/16, Rich Schwerdtfeger <richschwer@gmail.com> wrote:
>> 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ft 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 Tuesday, 26 July 2016 16:05:15 UTC