On Thu, Sep 8, 2016 at 8:58 AM, James Teh <[email protected]> wrote:
> He's talking about having a concatenated version of errormessage (i.e. all > the error message text in one call), not concatenating it to description. > That's why he asked, "Would it be helpful if we had 'errormessage' object > attribute for that?" Description and describedBy were never mentioned. > thank you, Jamie. > That said, while having this as an object attribute would work, having a > potentially long message in an object attribute seems nasty to me. > ok, I'm good with either case. On the other hand it's probably a good reason to implement 'attribute' method [1] [1] http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible2__2.html > > On 8/09/2016 10:54 PM, Richard Schwerdtfeger wrote: > > Alex, you must not NOT concatenate error message to details or describedby > relationships. You were given a 5 reasons why this would be a huge problem. > > Also aria-errormessage does not take multiple IDs. > > > > Rich Schwerdtfeger > > > > ----- Original message ----- > From: Alexander Surkov <[email protected]> > <[email protected]> > To: James Teh <[email protected]> <[email protected]> > Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list > <[email protected]> > <[email protected]>, Brett Lewis > <[email protected]> <[email protected]>, Joanmarie > Diggs <[email protected]> <[email protected]>, Dominic Mazzoni > <[email protected]> <[email protected]> > Subject: Re: Agreement on concatenation of aria-describedby and > aria-errormessage relationships > Date: Thu, Sep 8, 2016 6:41 AM > > 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 <%2B61%207%203149%203306> > 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 3306 <%2B61%207%203149%203306> > 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 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] > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
