Re: Rationale for aria-errormessage

I disagree. Speaking a description with a delay or allowing a user to turn them off once they are familiar with an application seems like useful behavior to me. 

As such a description is not appropriate for error messages which are perhaps the most important information being conveyed. 

Regards,
James. 

> On Jul 26, 2016, at 19:42, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> Hi James,
> VoiceOver speaks  aria-describedby with a delay which several users
> feel is problematic ... regardless of whether the referred text is an
> error message or not.
> So Apple should reduce the delay factor or make it user configurable
> or turn it off and render it in a different pitch.
> I learnt JAWS turns it off  with verbosity=advanced. This is
> dangerous ... aria-describedby text is not screen reader specific
> advisory text but PD content. This needs to be reversed.
> So if tomorrow Apple starts supporting this new property but  not the
> other vendors, content authors will need to use both. ... Like a
> complex table needs header-id  and also aria-labelledby if if one
> wants it to work with VO.
> So far I am not convinced of the need for aria-errormessages. It will
> create more problems than it is expected to solve.
> Best regards,
> Sailesh
> 
> 
>> On 7/26/16, James Nurthen <james.nurthen@oracle.com> wrote:
>> 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 22:49:27 UTC