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]
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
