Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

The reason that aria-describedby is not appropriate for error messages 
is that they are, perhaps, the most important information about a field.
Certain AT (for example in NVDA if I turn off "report object 
descriptions") give the user the ability to turn off descriptions or, in 
other cases (VO), wait a long time before reading descriptions. These 
behaviours are not appropriate for error messages which need to always 
be read out.

Regards,
James

On 2/24/16 3:14 PM, James Teh wrote:
> I thought aria-describedby could refer to multiple nodes. As such, I don't follow why authors were "stuck" when they wanted both an error message and a description. They could just put both in aria-describedby.
>
> If you really do want errormessage to be treated as an entirely separate thing, then I have to change my position on this: we need a new relation and new events. If it's really such a new and separate thing, we don't have to worry about existing AT not getting the benefit.
>
> Sent from a mobile device
>
>> On 25 Feb 2016, at 1:50 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
>>
>> Part of the rationale for introducing aria-errormessage was that authors were already using aria-describedby for the error message, but were stuck when they wanted to provide a description separate from the error message. Thus, a reason for introducing aria-errormessage was to distinguish it from the description.  Consider also that error messages are transient, whereas descriptions are not.
>>
>> Conflating the two at the AAPI level is counterproductive.
>>
>>> On 2016-02-23 6:20 PM, Joanmarie Diggs wrote:
>>> Hey Jamie.
>>>
>>> Yeah, we have a description property which is a string. Right now, I
>>> don't have a strong feeling either way about whether aria-errormessage's
>>> text belongs as part of that value. So if you think it should be there
>>> in addition to exposed via the relationship pair, I don't mind.
>>>
>>> --joanie
>>>
>>>> On 02/23/2016 06:03 PM, James Teh wrote:
>>>>> Sounds great. I'm happy with this mapping.
>>>>>
>>>>> Would this message be included in the concatenated description string
>>>>> for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2),
>>>>> you can call the accDescription property and it provides the description
>>>>> as a string. Right now, that would include the text of anything listed
>>>>> in aria-describedby. I think it*should*  include the error message myself.
>>>>>
>>>>> Jamie
>>>>>
>>>>> On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:
>>>>>>> Hey all.
>>>>>>>
>>>>>>> We need to map aria-errormessage on the various platforms, including
>>>>>>> ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
>>>>>>> homogeneity, I'll toss out what I was thinking for my platform for
>>>>>>> consideration by IA2 folks.
>>>>>>>
>>>>>>> Proposal: Connect the message to the element with the error via the
>>>>>>> RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
>>>>>>> "errormessage" as an object attribute.
>>>>>>>
>>>>>>> Rationale:
>>>>>>>
>>>>>>> 1. An error message provides descriptive information about an object.
>>>>>>>
>>>>>>> 2. Exposure via a relation eliminates the need to tree dive to find
>>>>>>>      the error.
>>>>>>>
>>>>>>> 3. Accessible relations can have multiple targets, so this exposure
>>>>>>>      does not stomp on a non-error description while at the same time
>>>>>>>      eliminating the need for each platform to create a new relation
>>>>>>>      type(s).
>>>>>>>
>>>>>>> 4. The object attribute is needed to identify which target (if any)
>>>>>>>      is an error message.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> --joanie
>>>>>>> _______________________________________________
>>>>>>> Accessibility-ia2 mailing list
>>>>>>> Accessibility-ia2@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>>
>> -- 
>> ;;;;joseph.
>>
>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>>                  - C. Carter -
>>

Received on Wednesday, 24 February 2016 23:44:53 UTC