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
