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 examplePythagorean
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]
<mailto:[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]> <mailto:[email protected]>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
[email protected]
<mailto:[email protected]>,
[email protected]
<mailto:[email protected]>, [email protected]
<mailto:[email protected]>
Cc: [email protected]
<mailto:[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 <tel:%2B61%207%203149%203306>
www.nvaccess.org <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
<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 <tel:%2B61%207%203149%203306>
www.nvaccess.org <http://www.nvaccess.org>
Facebook:http://www.facebook.com/NVAccess <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
