Understood. Would it be helpful if we had 'errormessage' object attribute for that? I assume that having both a relation and a concatenated string for error message would address needs of all consumers.
On Wed, Sep 7, 2016 at 8:16 PM, James Teh <[email protected]> wrote: > To clarify, I'm concerned about aria-errormessage here. For aria-details, > we wouldn't be trying to report the information as one chunk. Instead, the > user would perform a command to navigate to the details, at which point > they would browse it like they browse any other content. > > > For aria-errormessage, the use case I'm concerned about is when the user > focuses an aria-invalid element with aria-errormessage. In that case, we > need to report the aria-errormessage content as one chunk. Because this is > focus handling, we don't use the buffer for this. There may not even be a > buffer in this case, since we don't need a buffer in, say, an ARIA > role="application". > > Jamie > > > On 8/09/2016 2:15 AM, Alexander Surkov wrote: > > Shouldn't it be same speed as walking the virtual buffer? I assume > aria-details may contain complex content, for example Pythagorean Theorem > from [1], that may be not suitable for stringification in general. > > > [1] https://www.w3.org/TR/wai-aria-1.1/#aria-details > > On Tue, Sep 6, 2016 at 11:31 PM, James Teh <[email protected]> wrote: > >> That doesn't solve the need to walk the tree to gather the error message, >> which is the real problem. >> >> On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote: >> >> I think Dominic's suggestion on an interface tester with bit flags works >> well. >> >> Rich >> >> >> >> Rich Schwerdtfeger >> >> >> >> ----- Original message ----- >> From: James Teh <[email protected]> <[email protected]> >> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, [email protected], >> [email protected], [email protected] >> Cc: [email protected] >> Subject: Re: Agreement on concatenation of aria-describedby and >> aria-errormessage relationships >> Date: Tue, Sep 6, 2016 7:19 PM >> >> >> Fair enough. Thanks for the clear reasoning. >> >> >> >> My one remaining concern is performance, but we will clearly need to find >> an alternative technical solution to this problem. In short, not >> concatenating means that for every focus event, we need to check for the >> invalid state plus an errormessage relation and then, if one is found, walk >> the tree for the target to gather the message. The latter in particular >> could be unacceptably slow. >> >> On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote: >> >> >> The ARIA working group is against concatenating the description and >> relationship strings. I will try to summarize: >> >> Specifically, concatenation by browsers could: >> >> >> 1. Defeat the purposes of aria-errormessage. The aria-errormessage >> relationship is designed to ensure assistive technology users are as aware >> of error messages as other users and to enable them to distinguish between >> error messages and field descriptions. The constraints of ARIA 1.0, and >> every other accessibility standard and API that preceded it, have forced >> developers to blend error messages and field descriptions. This blending >> has long inhibited both the perception and understanding of error >> messages, >> which are critical to effective operation of many user interfaces. >> 2. increase cognitive load for users when errors are present. >> Especially for screen reader users, we already have severe challenges with >> excess verbosity that forces the user to expend energy sorting out the >> most >> important aspects of screen reader feedback. Concatenating potentially >> very >> disparate content in this manner would aggravate the verbosity problem. >> 3. Reduce assistive technology flexibility. Part of the power of ARIA >> is that it gives assistive technologies the ability to present content in >> the manner best suited for their target audiences. When browsers eliminate >> semantically relevant distinctions, this type of flexibility is >> diminished. >> If this concatenation were performed, it would essentially eliminate the >> semantic distinctions. If an assistive technology developer wanted to >> present the field description separate from the error messages, the >> developer would be forced to ignore the browser-computed description when >> error messages are present and reconstruct the description computation >> within the assistive technology. >> 4. Lead either browsers or authors to devise their own string-based >> tokenization capability. Because aria-errormessage is a separate >> relationship, there will be designers and developers who want to ensure >> there is a method for parsing the string into its separate components. >> This >> would reduce the robustness of the solution and create both >> inconsistencies >> and complexity, especially when localizing implementations. >> 5. Introduce serious problems with globalization: namely there is no >> clean way to concatenate the 2 strings in a way that will make sense. We >> cannot put in a space as some languages don't have them (Mandarin). >> Concatenating them together does not read properly. >> >> >> The aria-errormessage relationship is intended to address long-standing >> accessibility issues faced by both developers and end users. The energy >> required to find effective remedies to those issues will definitely pay >> dividends for assistive technology users. >> >> Would each of you weigh in. Again this is now holding up 3 working groups >> going on 3 weeks now. Do we agree on not concatenating the two strings? >> >> Rich >> >> >> >> Rich Schwerdtfeger >> >> >> -- >> James Teh >> Executive Director, NV Access Limited >> Ph +61 7 3149 3306 >> www.nvaccess.org >> Facebook: http://www.facebook.com/NVAccess >> Twitter: @NVAccess >> SIP: [email protected] >> >> >> >> >> -- >> James Teh >> Executive Director, NV Access Limited >> Ph +61 7 3149 3306www.nvaccess.org >> Facebook: http://www.facebook.com/NVAccess >> Twitter: @NVAccess >> SIP: [email protected] >> >> -- > James Teh > Executive Director, NV Access Limited > Ph +61 7 3149 3306www.nvaccess.org > Facebook: http://www.facebook.com/NVAccess > Twitter: @NVAccess > SIP: [email protected] > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
