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.
That said, while having this as an object attribute would work, having a
potentially long message in an object attribute seems nasty to me.
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]>
To: James Teh <[email protected]>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing
list <[email protected]>, Brett Lewis
<[email protected]>, Joanmarie Diggs
<[email protected]>, Dominic Mazzoni <[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]
<mailto:[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
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
<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 <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
