Hi Rich, I think you nicely articulated our concerns w/r/t the concatenation of error/description information. In particular, it is really hard to separate out error information from a description if the user wants it for some reason while concatenating the information is not too difficult. Let’s not concatenate. Brett
Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 [email protected]<mailto:[email protected]> www.vfo-group.com<http://www.vfo-group.com> From: Richard Schwerdtfeger [mailto:[email protected]] Sent: Tuesday, September 06, 2016 1:36 PM To: [email protected]; [email protected]; Brett Lewis <[email protected]>; [email protected] Cc: [email protected] Subject: Agreement on concatenation of aria-describedby and aria-errormessage relationships 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
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
