Hi Rich. My previously-stated [1] position has not changed, namely:
<quote> 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. </quote> 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: [email protected] > To: [email protected] > Cc: [email protected] > 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 <[email protected]> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: [email protected], > [email protected], > [email protected] > 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 <[email protected]> > > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > > Cc: [email protected], > [email protected], > > [email protected] > > 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: [email protected] <mailto:[email protected]> > > > > > > > > > > > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 > > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
