- From: James Nurthen <james.nurthen@oracle.com>
- Date: Wed, 24 Feb 2016 15:45:20 -0800
- To: public-aria@w3.org
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