Re: [Accessibility-ia2] aria-details and aria-errormessage mapping [Issue-1044]

[Richard Schwerdtfeger]

Alex, Jamie,
 
We discussed this concatenation and Microsoft (Cynthia Shelly) and also Matt King and the more we look at concatenation the worse it looks. This impact more than IA2. It would effect the UIA Mapping for Edge and it creates problems for internationalization whereby we can't put a space in between for all languages.
 
Matt King (Facebook), will respond with another list of problems as will Cynthia. The whole point in the first place was to separate them out in all languages. Another reason is the size of the string that could result.
 
Rich
Rich Schwerdtfeger
 
 
- Original message -From: Richard Schwerdtfeger/Austin/IBMTo: surkov.alexan...@gmail.comCc: accessibility-ia2@lists.linuxfoundation.org, ja...@nvaccess.org, jdi...@igalia.comSubject: Re: aria-details and aria-errormessage mappingDate: Tue, Aug 23, 2016 3:21 PM 
Alex,
 
You can't expose aria-details as an action it is a relationship to the extended detail. Who said you were to implement an action? It is not a longdesc.
 
It could point to a details/summary which shows and hides the content itself. The target might be hidden by book readers until the user turns on a facility to show the extended description.
 
 
Here is an example:
 

 

 Jamie, are we going with a new relation for aria-details or can you think of another mechanism to expose it? Thanks.Alexander.
 
On Sun, Aug 21, 2016 at 8:46 PM, James Teh  wrote:

Hi Rich,
 
Thanks for the clear explanations; I really do appreciate it. Part of the confusion here is that I've unintentionally conflated aria-details with aria-errormessage.
 
Regarding aria-details, what you say absolutely makes sense. Given that, reading the details automatically as a simple message doesn't make sense anyway. Instead, we'd report their presence and let the user act, just as we do for longdesc now.
 
However, this same logic does not apply to errormessage. From an author perspective, I follow that we don't want error messages "stomping" on describedby. However, from an accessibility client perspective, I still don't see the difference. They could still be exposed as part of the description string if they're visible. Aside from being simpler, that would also be better for performance, since an AT doesn't then have to crawl the tree "stringifying" the error messages itself. Can you please explain why this approach doesn't work? Again, please note that I'm talking about the accessibility API mapping, *not* the ARIA attributes; I understand why errormessage and describedby are separate ARIA attributes for authors.Thanks.Jamie
 
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
 
James,
 
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
 
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions. 
 
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Joanmarie Diggs]

Hey Rich.

Understood regarding non-normative requirements on ATs. But note that my
statement didn't say who would hold those expectations. If authors
expect it and/or users expect it, and other screen readers meet that
expectation, then Orca should also meet it. Moreover, if NVDA provides
that functionality, one or more Orca users will point this out to me and
ask me to provide it too on that basis alone. Props again to Jamie and
Mick. :)

--joanie (whose position continues to remain unchanged)

On 08/24/2016 03:09 PM, Richard Schwerdtfeger wrote:
> Well, If you had an error message I can certainly see the need for the
> user to, after they have gone to the error message, go back to the
> associated control to fix the error. ... aria-details reverse
> relationship, I don't believe, is as critical.  We do not, however, put
> normative requirements on ATVs in terms of the user experience.
>  
> Rich
>  
> 
> 
> Rich Schwerdtfeger
>  
>  
> 
> - Original message -
> From: Joanmarie Diggs <jdi...@igalia.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: accessibility-ia2@lists.linuxfoundation.org, cl...@alum.mit.edu
> Subject: Re: [Accessibility-ia2] aria-details and aria-errormessage
> mapping
> Date: Wed, Aug 24, 2016 1:50 PM
>  
> Hi Rich.
> 
> My previously-stated [1] position has not changed, namely:
> 
> 
> IF ATs will be expected to provide navigation between error messages and
> elements with errors regardless of circumstances, THEN I think we need
> the reverse relationship because doing a complete tree dive looking for
> the element which points to the error is not reasonable.
> 
> On the other hand, if my scenario is so artificial that it would never
> happen, then I'm fine with having to keep track of the field before
> moving the user to the error.
> 
> 
> Whether or not ATs will be expected to provide such navigation, I could
> not tell you. Once we know that answer, you can plug it into the quoted
> statement to get my response. ;)
> 
> [1]
> 
> https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-August/002064.html
> 
> --joanie
> 
> On 08/24/2016 02:26 PM, Richard Schwerdtfeger wrote:
> > 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
> >  
>     >  
> >
>     > - 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
> >  
> >  
> >
> > - Origin

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

Well, If you had an error message I can certainly see the need for the user to, after they have gone to the error message, go back to the associated control to fix the error. ... aria-details reverse relationship, I don't believe, is as critical.  We do not, however, put normative requirements on ATVs in terms of the user experience.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs <jdi...@igalia.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-ia2@lists.linuxfoundation.org, cl...@alum.mit.eduSubject: Re: [Accessibility-ia2] aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 1:50 PM 
Hi Rich.My previously-stated [1] position has not changed, namely:IF ATs will be expected to provide navigation between error messages andelements with errors regardless of circumstances, THEN I think we needthe reverse relationship because doing a complete tree dive looking forthe element which points to the error is not reasonable.On the other hand, if my scenario is so artificial that it would neverhappen, then I'm fine with having to keep track of the field beforemoving the user to the error.Whether or not ATs will be expected to provide such navigation, I couldnot tell you. Once we know that answer, you can plug it into the quotedstatement to get my response. ;)[1]https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-August/002064.html--joanieOn 08/24/2016 02:26 PM, Richard Schwerdtfeger wrote:> 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>  >  >>     - 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 ->        

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

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
 
 
- Original message -From: Richard Schwerdtfeger/Austin/IBM@IBMUSSent by: accessibility-ia2-boun...@lists.linuxfoundation.orgTo: jdi...@igalia.comCc: accessibility-ia2@lists.linuxfoundation.orgSubject: Re: [Accessibility-ia2] aria-details and aria-errormessage mappingDate: 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,
RichRich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: ja...@nvaccess.org, accessibility-ia2@lists.linuxfoundation.org, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 9:52 AM 
Hey Rich.On matters where I have no strong opinion, but Jamie does, I defer toJamie. Mapping of aria-details and aria-errormessage for my platformfalls into this category, at least currently. Let's suck it and see.--joanieOn 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 >     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>      >     -->  

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

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,
RichRich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: ja...@nvaccess.org, accessibility-ia2@lists.linuxfoundation.org, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 9:52 AM 
Hey Rich.On matters where I have no strong opinion, but Jamie does, I defer toJamie. Mapping of aria-details and aria-errormessage for my platformfalls into this category, at least currently. Let's suck it and see.--joanieOn 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 >     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 >     Facebook: http://www.facebook.com/NVAccess>     Twitter: @NVAccess>     SIP: ja...@nvaccess.org >>  >  
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Joanmarie Diggs]

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 
> 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 
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org 
> 
>  
> 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

I'm not yet certain if we agreed upon how to expose aria-details, because
longdesc is exposed as an action, which pops up a window with the longdesc,
when invoked. My understanding is it is a web author responsibility to
implement aria-details UI, and thus action mechanism perhaps is not
suitable for it.

Jamie, are we going with a new relation for aria-details or can you think
of another mechanism to expose it?

Thanks.
Alexander.

On Sun, Aug 21, 2016 at 8:46 PM, James Teh  wrote:

> Hi Rich,
>
>
> Thanks for the clear explanations; I really do appreciate it. Part of the
> confusion here is that I've unintentionally conflated aria-details with
> aria-errormessage.
>
>
> Regarding aria-details, what you say absolutely makes sense. Given that,
> reading the details automatically as a simple message doesn't make sense
> anyway. Instead, we'd report their presence and let the user act, just as
> we do for longdesc now.
>
>
> However, this same logic does not apply to errormessage. From an author
> perspective, I follow that we don't want error messages "stomping" on
> describedby. However, from an accessibility client perspective, I still
> don't see the difference. They could still be exposed as part of the
> description string if they're visible. Aside from being simpler, that would
> also be better for performance, since an AT doesn't then have to crawl the
> tree "stringifying" the error messages itself. Can you please explain why
> this approach doesn't work? Again, please note that I'm talking about the
> accessibility API mapping, *not* the ARIA attributes; I understand why
> errormessage and describedby are separate ARIA attributes for authors.
>
> Thanks.
>
> Jamie
>
>
> On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>
> >I've already stated my view on this and asked several questions, but it
> seems key decisions have already been made, despite a lack of clarification
> around the concerns I've raised. >Given that this has basically become a
> circular time sink of an argument, I'll provide a final summary of my
> thoughts.
>
> >1. With regard to stringification, I still haven't seen a single solid
> justification for why errormessage and details are different to description
> from a user perspective. It's been argued that >users should be able to get
> to the content and read it in its full semantic glory, but no one has
> pointed out a use case for why that is actually necessary for, say, an
> error message. Surely, >the desired UX for a screen reader is that it
> should read the error message when it appears, not force the user to press
> some key to jump there and review it. If we want to read the >message, we
> need to stringify it... and crawling the tree to stringify it ourselves is
> going to be a hideous perf problem.
>
> James,
>
> I appreciate your willingness to work with us on this. However, let me
> provide you with the full picture.
>
> 1. Extended descriptions, referenced by aria-details was requested by the
> digital publishing industry. The extended description can have all kinds of
> markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is
> intended as an extended, and sometimes alternative content to better
> illustrate what is being referenced. For these reasons it is essential that
> we *always* preserve content. In fact the stringification in many cases
> could be completely useless to a screen reader user. Also, for these
> reasons the intent is for it to be visible and not hidden as
> aria-describedby often is as it must be accessible to all users and not
> just the blind. Furthermore, there will be instances where the content will
> be contained within an IFrame within a details/summary element. The big
> thing here is stringification is simply the wrong thing to do and it must
> not happen in the browsers for extended descriptions.
>
> The second thing you need to understand is the aria-details attribute was
> created after months of fighting between browser vendors and people in the
> accessibility community over longdesc. We don't want to open up that
> pandora's box again. This is the solution that has come to place.
> aria-describedby simply does not meet the needs of digital publishing
> community. What is more they plan to support it in their digital books once
> a mechanism is put in place, within browsers, to show and hide content
> reference by aria-details in order to preserve the needs of publishers who
> don't want extended descriptions rendered by default. We definitely, don't
> want this functionality applied to aria-describedby.
>
> >2. Having errormessage/details as completely separate concepts from
> description means an AT now has two more things it has to fetch for *every
> single object that gets focus*. This is >yet another perf problem.
>
> Error messages are not the same as extended descriptions and we don't want
> the same functionality to duplicated with error messages as I described
> above. The need 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[James Teh]

Hi Rich,


If it's not being stringified, IMO, it doesn't make sense to use 
describedBy because describedBy should all be stringified in 
description. My question is why it can't be stringified. You say it 
can't be stringified because:


1. "the content must be visible": That's not a reason not to stringify. 
Describedby can also be visible, yet that never prevented it from being 
stringified.


2. "it will often have content in it, including links, that the user may 
need to navigate to to get help about the error": That could also be 
true for describedby, yet again, that wasn't cited as a reason not to 
stringify it. This argument is problematic anyway because a user won't 
be able to get to those links unless they choose to *review* the error 
message, but the error message has to be spoken in the first place in 
order for a user to know about the error. Reporting the error message 
initially is problematic because now the AT has to stringify the message 
itself, which could be a massive perf hit.



Jamie


On 22/08/2016 11:03 AM, Richard Schwerdtfeger wrote:

Hi James,
If you wanted to reuse the existing description relationships (with a 
separate description relationship instance) and place an object 
attribute on the error message target to indicate that it is an error 
message I think that makes perfect sense. It just can't be 
stringified. However, the errormessage is not to be stringified as the 
content must be visible and it will often have content in it, 
including links, that the user may need to navigate to to get help 
about the error. The aria referenced error messages are all required 
to be visible to apply the relatinship.



Rich Schwerdtfeger

- Original message -
From: James Teh 
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: Sun, Aug 21, 2016 7:46 PM

Hi Rich,

Thanks for the clear explanations; I really do appreciate it. Part
of the confusion here is that I've unintentionally conflated
aria-details with aria-errormessage.

Regarding aria-details, what you say absolutely makes sense. Given
that, reading the details automatically as a simple message
doesn't make sense anyway. Instead, we'd report their presence and
let the user act, just as we do for longdesc now.

However, this same logic does not apply to errormessage. From an
author perspective, I follow that we don't want error messages
"stomping" on describedby. However, from an accessibility client
perspective, I still don't see the difference. They could still be
exposed as part of the description string if they're visible.
Aside from being simpler, that would also be better for
performance, since an AT doesn't then have to crawl the tree
"stringifying" the error messages itself. Can you please explain
why this approach doesn't work? Again, please note that I'm
talking about the accessibility API mapping, *not* the ARIA
attributes; I understand why errormessage and describedby are
separate ARIA attributes for authors.


Thanks.

Jamie
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:

>I've already stated my view on this and asked several questions,
but it seems key decisions have already been made, despite a lack
of clarification around the concerns I've raised. >Given that
this has basically become a circular time sink of an argument,
I'll provide a final summary of my thoughts.

>1. With regard to stringification, I still haven't seen a single
solid justification for why errormessage and details are
different to description from a user perspective. It's been
argued that >users should be able to get to the content and read
it in its full semantic glory, but no one has pointed out a use
case for why that is actually necessary for, say, an error
message. Surely, >the desired UX for a screen reader is that it
should read the error message when it appears, not force the user
to press some key to jump there and review it. If we want to read
the >message, we need to stringify it... and crawling the tree to
stringify it ourselves is going to be a hideous perf problem.
James,
I appreciate your willingness to work with us on this. However,
let me provide you with the full picture.
1. Extended descriptions, referenced by aria-details was
requested by the digital publishing industry. The extended
description can have all kinds of markup in it and not just HTML:
ChemML, MathML, SVG drawings, etc. It is intended as an extended,
and sometimes alternative content to better illustrate what is
being referenced. For these reasons it is essential that we
*always* preserve content. In fact the stringification in many
cases could be 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

Hi James,
 
If you wanted to reuse the existing description relationships (with a separate description relationship instance) and place an object attribute on the error message target to indicate that it is an error message I think that makes perfect sense. It just can't be stringified. However, the errormessage is not to be stringified as the content must be visible and it will often have content in it, including links, that the user may need to navigate to to get help about the error. The aria referenced error messages are all required to be visible to apply the relatinship. 
 
Rich Schwerdtfeger
 
 
- Original message -From: James Teh To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Sun, Aug 21, 2016 7:46 PM 
Hi Rich,
 
Thanks for the clear explanations; I really do appreciate it. Part of the confusion here is that I've unintentionally conflated aria-details with aria-errormessage.
 
Regarding aria-details, what you say absolutely makes sense. Given that, reading the details automatically as a simple message doesn't make sense anyway. Instead, we'd report their presence and let the user act, just as we do for longdesc now.
 
However, this same logic does not apply to errormessage. From an author perspective, I follow that we don't want error messages "stomping" on describedby. However, from an accessibility client perspective, I still don't see the difference. They could still be exposed as part of the description string if they're visible. Aside from being simpler, that would also be better for performance, since an AT doesn't then have to crawl the tree "stringifying" the error messages itself. Can you please explain why this approach doesn't work? Again, please note that I'm talking about the accessibility API mapping, *not* the ARIA attributes; I understand why errormessage and describedby are separate ARIA attributes for authors.Thanks.Jamie 
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
 
James,
 
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
 
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions. 
 
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply does not meet the needs of digital publishing community. What is more they plan to support it in their digital books once a mechanism is put in place, within browsers, to show and hide content reference by aria-details in order to preserve the needs of publishers who don't want extended descriptions rendered by default. We definitely, don't want this functionality applied to aria-describedby.
 
>2. Having errormessage/details as completely separate concepts from description means an AT now has two more things it has to fetch for *every 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[James Teh]

Hi Rich,


Thanks for the clear explanations; I really do appreciate it. Part of 
the confusion here is that I've unintentionally conflated aria-details 
with aria-errormessage.



Regarding aria-details, what you say absolutely makes sense. Given that, 
reading the details automatically as a simple message doesn't make sense 
anyway. Instead, we'd report their presence and let the user act, just 
as we do for longdesc now.



However, this same logic does not apply to errormessage. From an author 
perspective, I follow that we don't want error messages "stomping" on 
describedby. However, from an accessibility client perspective, I still 
don't see the difference. They could still be exposed as part of the 
description string if they're visible. Aside from being simpler, that 
would also be better for performance, since an AT doesn't then have to 
crawl the tree "stringifying" the error messages itself. Can you please 
explain why this approach doesn't work? Again, please note that I'm 
talking about the accessibility API mapping, *not* the ARIA attributes; 
I understand why errormessage and describedby are separate ARIA 
attributes for authors.



Thanks.

Jamie

On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>I've already stated my view on this and asked several questions, but 
it seems key decisions have already been made, despite a lack of 
clarification around the concerns I've raised. >Given that this has 
basically become a circular time sink of an argument, I'll provide a 
final summary of my thoughts.


>1. With regard to stringification, I still haven't seen a single 
solid justification for why errormessage and details are different to 
description from a user perspective. It's been argued that >users 
should be able to get to the content and read it in its full semantic 
glory, but no one has pointed out a use case for why that is actually 
necessary for, say, an error message. Surely, >the desired UX for a 
screen reader is that it should read the error message when it 
appears, not force the user to press some key to jump there and review 
it. If we want to read the >message, we need to stringify it... and 
crawling the tree to stringify it ourselves is going to be a hideous 
perf problem.

James,
I appreciate your willingness to work with us on this. However, let me 
provide you with the full picture.
1. Extended descriptions, referenced by aria-details was requested by 
the digital publishing industry. The extended description can have all 
kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, 
etc. It is intended as an extended, and sometimes alternative content 
to better illustrate what is being referenced. For these reasons it is 
essential that we *always* preserve content. In fact the 
stringification in many cases could be completely useless to a screen 
reader user. Also, for these reasons the intent is for it to be 
visible and not hidden as aria-describedby often is as it must be 
accessible to all users and not just the blind. Furthermore, there 
will be instances where the content will be contained within an IFrame 
within a details/summary element. The big thing here is 
stringification is simply the wrong thing to do and it must not happen 
in the browsers for extended descriptions.
The second thing you need to understand is the aria-details attribute 
was created after months of fighting between browser vendors and 
people in the accessibility community over longdesc. We don't want to 
open up that pandora's box again. This is the solution that has come 
to place. aria-describedby simply does not meet the needs of digital 
publishing community. What is more they plan to support it in their 
digital books once a mechanism is put in place, within browsers, to 
show and hide content reference by aria-details in order to preserve 
the needs of publishers who don't want extended descriptions rendered 
by default. We definitely, don't want this functionality applied to 
aria-describedby.
>2. Having errormessage/details as completely separate concepts from 
description means an AT now has two more things it has to fetch for 
*every single object that gets focus*. This is >yet another perf problem.
Error messages are not the same as extended descriptions and we don't 
want the same functionality to duplicated with error messages as I 
described above. The need for error messages arose many major 
companies rendering visible, popup, error messages for each invalid 
form entry. They want to have people with disabilities get access to 
each error messages associated with the invalid control and they want 
to also have access to the hidden aria-describedby help information 
they provide for that control. So, stomping on one in favor of the 
other is a very bad experience. They are indeed distinct and separate 
concepts.


>3. That said, since the no description/no stringification decision 
has already been made (despite the concerns above which I raised 
months 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
 
James,
 
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
 
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions. 
 
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply does not meet the needs of digital publishing community. What is more they plan to support it in their digital books once a mechanism is put in place, within browsers, to show and hide content reference by aria-details in order to preserve the needs of publishers who don't want extended descriptions rendered by default. We definitely, don't want this functionality applied to aria-describedby.
 
>2. Having errormessage/details as completely separate concepts from description means an AT now has two more things it has to fetch for *every single object that gets focus*. This is >yet another perf problem.
 
Error messages are not the same as extended descriptions and we don't want the same functionality to duplicated with error messages as I described above. The need for error messages arose many major companies rendering visible, popup, error messages for each invalid form entry. They want to have people with disabilities get access to each error messages associated with the invalid control and they want to also have access to the hidden aria-describedby help information they provide for that control. So, stomping on one in favor of the other is a very bad experience. They are indeed distinct and separate concepts.
>3. That said, since the no description/no stringification decision has already been made (despite the concerns above which I raised months ago), relations is the only mapping that >doesn't violate the spec.
 
See above. I hope I have addressed most of your concerns.
>4. Since we're not stringifying as part of description, it does not make sense to map these to the describedBy relation. Thus, we need two new relations.
 
ok
>5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept >that this use case may one day arise.
Joanie Diggs asked for reverse relationships as she wants to be able to traverse back to the source. She is on CC and will be back from vacation next week.
 
Best,
Rich
Rich Schwerdtfeger
 
 
- Original message -From: James Teh To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.comCc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.comSubject: Re: aria-details and aria-errormessage mappingDate: Thu, Aug 18, 2016 9:45 PM 
Hi.
 I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. Given that this has basically become a circular time sink of an argument, I'll provide a final 

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

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 To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: "accessibility-ia2@lists.linuxfoundation.org" , James Teh , Joanmarie Diggs Subject: Re: aria-details and aria-errormessage mappingDate: 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 simplyto make life simpler for authors; errormessage isn't presented unlessinvalid is true, errormessage must be visible to be presented, etc. Thatmight be fair enough. However, that doesn't mean it's an entirelyfundamentally separate concept, and thus, there's a good argument formapping it to description in a11y APIs (with appropriate rules)."Do 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?
 
On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger  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 
To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: "accessibility-ia2@lists.linuxfoundation.org" , James Teh , Joanmarie Diggs Subject: Re: aria-details and aria-errormessage mappingDate: 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  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  wrote:

Those would be great. What would you have for reverse relationships?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov To: "accessibility-ia2@lists.linuxfoundation.org" , James Teh , Joanmarie Diggs , Richard Schwerdtfeger/Austin/IBM@IBMUSCc:Subject: aria-details and aria-errormessage mappingDate: Tue, Aug 9, 2016 2:12 PM 
Hi.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_DETAILS
An object containing an error message for the target object.
IA2_RELATION_ERROR_MESSAGEThanks.Alex.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
 
 
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

I'd love to hear Jamie on this honestly, but his wording was:

"

To me, it sounds like errormessage just makes the rules slightly simply
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)."

Do 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?

On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger 
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 
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs 
> 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 
> wrote:
>
> Those would be great. What would you have for reverse relationships?
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: Alexander Surkov 
> To: "accessibility-ia2@lists.linuxfoundation.org" <
> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
> ja...@nvaccess.org>, Joanmarie Diggs , Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc:
> Subject: aria-details and aria-errormessage mapping
> Date: Tue, Aug 9, 2016 2:12 PM
>
> Hi.
>
> 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_DETAILS
> An object containing an error message for the target object.
> IA2_RELATION_ERROR_MESSAGE
> Thanks.
> Alex.
>
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
>
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Joanmarie Diggs]

The reason one might wish to have the reverse relationship is if the
error messages could be encountered independently. Consider the
following scenario:

1. User fills out form
2. User presses submit
3. New page loads displaying the errors at the top with the form fields
   reproduced below the list of errors

(Yeah, it's artificial. But, you know, authors...)

In the above scenario, the AT didn't provide the navigation to the error
as the result of some command. Thus the AT doesn't have anything to keep
track of.

IF ATs will be expected to provide navigation between error messages and
elements with errors regardless of circumstances, THEN I think we need
the reverse relationship because doing a complete tree dive looking for
the element which points to the error is not reasonable.

On the other hand, if my scenario is so artificial that it would never
happen, then I'm fine with having to keep track of the field before
moving the user to the error.

--joanie


On 08/10/2016 08:33 AM, Alexander Surkov 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  > wrote:
> 
> Those would be great. What would you have for reverse relationships?
>  
> 
> 
> Rich Schwerdtfeger
>  
>  
> 
> - Original message -
> From: Alexander Surkov  >
> To: "accessibility-ia2@lists.linuxfoundation.org
> "
>  >, James Teh
> >, Joanmarie
> Diggs >, Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc:
> Subject: aria-details and aria-errormessage mapping
> Date: Tue, Aug 9, 2016 2:12 PM
>  
> Hi.
> 
> 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_DETAILS
> An object containing an error message for the target object.
> IA2_RELATION_ERROR_MESSAGE
> Thanks.
> Alex.
> 
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
> 
> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
> 
> 
>  
> 
> 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Alexander Surkov]

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 
> wrote:
>
>> Those would be great. What would you have for reverse relationships?
>>
>>
>>
>> Rich Schwerdtfeger
>>
>>
>>
>> - Original message -
>> From: Alexander Surkov 
>> To: "accessibility-ia2@lists.linuxfoundation.org" <
>> accessibility-ia2@lists.linuxfoundation.org>, James Teh <
>> ja...@nvaccess.org>, Joanmarie Diggs , Richard
>> Schwerdtfeger/Austin/IBM@IBMUS
>> Cc:
>> Subject: aria-details and aria-errormessage mapping
>> Date: Tue, Aug 9, 2016 2:12 PM
>>
>> Hi.
>>
>> 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_DETAILS
>> An object containing an error message for the target object.
>> IA2_RELATION_ERROR_MESSAGE
>> Thanks.
>> Alex.
>>
>> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
>> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
>>
>>
>>
>>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Richard Schwerdtfeger]

Those would be great. What would you have for reverse relationships?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov To: "accessibility-ia2@lists.linuxfoundation.org" , James Teh , Joanmarie Diggs , Richard Schwerdtfeger/Austin/IBM@IBMUSCc:Subject: aria-details and aria-errormessage mappingDate: Tue, Aug 9, 2016 2:12 PM 
Hi.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_DETAILS
An object containing an error message for the target object.
IA2_RELATION_ERROR_MESSAGEThanks.Alex.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

[Joanmarie Diggs]

Hey Alex, all.

On both of these, we were waiting on the IA2 mapping because I was/am
pretty sure that I'd be okay with your mappings and would duplicate them
in ATK and AT-SPI2.

I'm fine with what you propose below, but do we also want a reciprocal
relation type?

--joanie

On 08/09/2016 03:12 PM, Alexander Surkov wrote:
> Hi.
> 
> 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_DETAILS
> 
> An object containing an error message for the target object.
> 
> IA2_RELATION_ERROR_MESSAGE
> 
> Thanks.
> Alex.
> 
> [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
> [2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2