These were the original relation names for error message and details
IA2_RELATION_DETAILS
IA2_RELATION_ERROR_MESSAGE
I also have these relationships for ATK/ATSPI:
RELATION_DETAILS
RELATION_ERROR_MESSAGE
They are listed in this branch I am working on: https://rawgit.com/w3c/aria/action2102/core-aam/core-aam.html
Unless stated otherwise these are what I am putting in the spec. Joanie, I need you an Jamie to settle on whether there is a reverse relationship.
I have opened an issue against the name and description spec. regarding concatenation: https://www.w3.org/WAI/ARIA/track/issues/1044
I have included Joseph on CC so that he is aware of the name and description issue.
Rich Schwerdtfeger
Rich Schwerdtfeger
----- Original message -----
From: Richard Schwerdtfeger/Austin/IBM@IBMUS
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
To: jdi...@igalia.com
Cc: accessibility-ia2@lists.linuxfoundation.org
Subject: Re: [Accessibility-ia2] aria-details and aria-errormessage mapping
Date: Wed, Aug 24, 2016 10:01 AM
ok.So, Alex, please provide me the name of the two IA2 relationships fore details and error message? I will work with joseph and amelia to look at concatenation of error messages in the description.Also, Joanie expressed a desire to have reverse relationships for details and error message. I would like you all to give a definitive answer on that. If you decide to go with a reverse relationship then I will need the the names for the spec.Keep in mind that after IA2 and ATK/ATSPI we also have to deal with UIA and MacOSX.Regards,Rich
Rich Schwerdtfeger----- Original message -----
From: Joanmarie Diggs <jdi...@igalia.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: ja...@nvaccess.org, accessibility-ia2@lists.linuxfoundation.org, surkov.alexan...@gmail.com
Subject: Re: aria-details and aria-errormessage mapping
Date: Wed, Aug 24, 2016 9:52 AM
Hey Rich.
On matters where I have no strong opinion, but Jamie does, I defer to
Jamie. Mapping of aria-details and aria-errormessage for my platform
falls into this category, at least currently. Let's suck it and see.
--joanie
On 08/24/2016 10:39 AM, Richard Schwerdtfeger wrote:
> Alright. I am looking at the ARIA spec. and it does not preclude
> concatenating the strings for error messages. Our name and description
> spec. will take a hit as will the SVG a11y mapping spec. I will need to
> discuss this with Joseph Scheuhammer. Joanie do you support James'
> rational for concatenation?
>
> We do need separate relationships on the platform for details,
> descriptions, and error messages.
>
> Rich
>
>
> Rich Schwerdtfeger
>
>
>
> ----- Original message -----
> From: James Teh <ja...@nvaccess.org>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com,
> surkov.alexan...@gmail.com
> Subject: Re: aria-details and aria-errormessage mapping
> Date: Tue, Aug 23, 2016 8:02 PM
>
>
> Hi Rich,
>
>
> On 24/08/2016 5:14 AM, Richard Schwerdtfeger wrote:
>> 1.There is only one method in each platform to place a
>> description. If you have describedby and errormessage
>> relationships which wins?
> Concatenate, which brings us to:
>
>> 2. We cannot guarantee that concatenating them both into one big
>> description will make sense to the user as they were not designed
>> to work that way. Also, the user might want not want to listen to
>> them both together.
> If the field is invalid, we're going to read the error message
> anyway and it's going to be read as well as the description and any
> other info. The practical upshot is that we end up with the same
> result as concatenation.
>
>> 3. Error messages are typically created as alerts as they pop up
>> and need to be spoken. So, the user will hear them. The issue is
>> which one belongs to which form element.
> When an invalid form element gets focus, I'm guessing it makes sense
> for the user to receive the error message. That requires it to be
> stringified.
>
>> 4. We don't want to have the user agent have to stringify the text
>> either for performance reasons.
> It's more performant for a user agent to stringify than it is for an
> AT. Also, user agents are already stringifying aria-labelledby,
> aria-describedby, name from content, etc., so that argument doesn't
> really hold.
>>
>> So, I would not want you to stringify the error text. The only
>> times you will need to provide access to the error message is when
>> you:
>> 1. Have an invalid element (aria-invalid)
> At which point we need to stringify it. I'm only suggesting that it
> be stringified by the UA if all conditions are met; invalid,
> visible, etc.
>> 2. An error message is provided.
> At which point we also need to stringify it, but in fairness, this
> will probably be an alert anyway, so I'm less worried about this one.
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org <http://www.nvaccess.org>
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org>
>
>
>
_______________________________________________
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
