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]>
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 <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [email protected] <mailto:[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]
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
