We *cannot* map aria-errormessage or aria-details to a string description. That is absolutely prohibited in the aria specification. It is not to be stringified. Neither is aria-details. Also, in the aria spec. if aria-details and aria-describedby cannot be mapped separately aria-details takes precedence.
These are intended to be references so that we can also get access to the structural markup.
Now, if you are going to overload the description relationships we need something on the target that indicates they are an error or an extended description. We need to have the distinctions. Object attributes are an option.
Rich
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov <surkov.alexan...@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org" <accessibility-ia2@lists.linuxfoundation.org>, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>
Subject: Re: aria-details and aria-errormessage mapping
Date: Fri, Aug 12, 2016 7:42 PM
I'd love to hear Jamie on this honestly, but his wording was:
"To me, it sounds like errormessage just makes the rules slightly simplyDo we a real example/scenario where AT has to know that a message on the screen is an error message, and this knowledge would improve the user experience?
to make life simpler for authors; errormessage isn't presented unless
invalid is true, errormessage must be visible to be presented, etc. That
might be fair enough. However, that doesn't mean it's an entirely
fundamentally separate concept, and thus, there's a good argument for
mapping it to description in a11y APIs (with appropriate rules)."On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger <sch...@us.ibm.com> wrote:Yes, we heard. So, we need to be able to differentiate an associated error message from a help descriptions. So, you could have a second aria-details relationship in the list of relationships as it would not be stringified (a necessity), BUT you would need to put something on the target ID container to indicate to the AT that it is an error message. Otherwise you need a different relationship. If you are not having reverse relationships and AT vendors would provide a mechanism to go back to the element that was invalid then you would be fine. The use cases we have seen in practices is that multiple form elements become invalid and each has an associated popup error message.We cannot mix descriptions and error messages and the error messages must be visible to all users to be mapped.Rich
Rich Schwerdtfeger----- Original message -----
From: Alexander Surkov <surkov.alexan...@gmail.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org " <accessibility-ia2@lists.linuxfoundation.org >, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>
Subject: Re: aria-details and aria-errormessage mapping
Date: Wed, Aug 10, 2016 12:48 PM
Note, Jamie has been objecting against new relation for aria-errormessage [1].
[1] https://lists.linuxfoundation.org/pipermail/accessibility- ia2/2016-April/002046.html On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov <surkov.alexan...@gmail.com> wrote:All reverse relations go at performance/memory cost, I would introduce them iff AT needs them. I'm not sure I see a valid scenario, when they were useful, thus deferring a decision to Joanie and Jamie, who knows more about AT internal gear than me.On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger <sch...@us.ibm.com> wrote:Those would be great. What would you have for reverse relationships?
Rich Schwerdtfeger----- Original message -----
From: Alexander Surkov <surkov.alexan...@gmail.com>
To: "accessibility-ia2@lists.linuxfoundation.org " <accessibility-ia2@lists.linuxfoundation.org >, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:
Subject: aria-details and aria-errormessage mapping
Date: Tue, Aug 9, 2016 2:12 PM
Hi.Alex.
ARIA 1.1 got two relation-like attributes: aria-details [1] and aria-errormessage [2], used to connect an element with content providing extra info. Rich mentioned that these attributes are likely need new IAccessible2 relations to expose them, which sounds reasonable. If that's the case, then we should end up with something like:
An object containing details for the target object.IA2_RELATION_DETAILSAn object containing an error message for the target object.IA2_RELATION_ERROR_MESSAGEThanks.
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
