Hi.
I've already stated my view on this and asked several questions, but it
seems key decisions have already been made, despite a lack of
clarification around the concerns I've raised. Given that this has
basically become a circular time sink of an argument, I'll provide a
final summary of my thoughts.
1. With regard to stringification, I still haven't seen a single solid
justification for why errormessage and details are different to
description from a user perspective. It's been argued that users should
be able to get to the content and read it in its full semantic glory,
but no one has pointed out a use case for why that is actually necessary
for, say, an error message. Surely, the desired UX for a screen reader
is that it should read the error message when it appears, not force the
user to press some key to jump there and review it. If we want to read
the message, we need to stringify it... and crawling the tree to
stringify it ourselves is going to be a hideous perf problem.
2. Having errormessage/details as completely separate concepts from
description means an AT now has two more things it has to fetch for
*every single object that gets focus*. This is yet another perf problem.
3. That said, since the no description/no stringification decision has
already been made (despite the concerns above which I raised months
ago), relations is the only mapping that doesn't violate the spec.
4. Since we're not stringifying as part of description, it does not make
sense to map these to the describedBy relation. Thus, we need two new
relations.
5. Reverse relations may well be useful in the future. However, if
they're a potential perf problem, I agree it makes sense to wait until
we have a use case, so long as implementers accept that this use case
may one day arise.
Thanks,
Jamie
On 19/08/2016 7:21 AM, Richard Schwerdtfeger wrote:
We *cannot* map aria-errormessage or aria-details to a string
description. That is absolutely prohibited in the aria specification.
It is not to be stringified. Neither is aria-details. Also, in the
aria spec. if aria-details and aria-describedby cannot be mapped
separately aria-details takes precedence.
These are intended to be references so that we can also get access to
the structural markup.
Now, if you are going to overload the description relationships we
need something on the target that indicates they are an error or an
extended description. We need to have the distinctions. Object
attributes are an option.
Rich
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov <surkov.alexan...@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org"
<accessibility-ia2@lists.linuxfoundation.org>, James Teh
<ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>
Subject: Re: aria-details and aria-errormessage mapping
Date: Fri, Aug 12, 2016 7:42 PM
I'd love to hear Jamie on this honestly, but his wording was:
"
To me, it sounds like errormessage just makes the rules slightly
simply
to make life simpler for authors; errormessage isn't presented unless
invalid is true, errormessage must be visible to be presented,
etc. That
might be fair enough. However, that doesn't mean it's an entirely
fundamentally separate concept, and thus, there's a good argument for
mapping it to description in a11y APIs (with appropriate rules)."
Do we a real example/scenario where AT has to know that a message
on the screen is an error message, and this knowledge would
improve the user experience?
On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger
<sch...@us.ibm.com <mailto:sch...@us.ibm.com>> wrote:
Yes, we heard. So, we need to be able to differentiate an
associated error message from a help descriptions. So, you
could have a second aria-details relationship in the list of
relationships as it would not be stringified (a necessity),
BUT you would need to put something on the target ID container
to indicate to the AT that it is an error message. Otherwise
you need a different relationship. If you are not having
reverse relationships and AT vendors would provide a mechanism
to go back to the element that was invalid then you would be
fine. The use cases we have seen in practices is that multiple
form elements become invalid and each has an associated popup
error message.
We cannot mix descriptions and error messages and the error
messages must be visible to all users to be mapped.
Rich
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov <surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>"
<accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>>,
James Teh <ja...@nvaccess.org
<mailto:ja...@nvaccess.org>>, Joanmarie Diggs
<jdi...@igalia.com <mailto:jdi...@igalia.com>>
Subject: Re: aria-details and aria-errormessage mapping
Date: Wed, Aug 10, 2016 12:48 PM
Note, Jamie has been objecting against new relation for
aria-errormessage [1].
[1]
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-April/002046.html
<https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-April/002046.html>
On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov
<surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>> wrote:
All reverse relations go at performance/memory cost, I
would introduce them iff AT needs them. I'm not sure I
see a valid scenario, when they were useful, thus
deferring a decision to Joanie and Jamie, who knows
more about AT internal gear than me.
On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger
<sch...@us.ibm.com <mailto:sch...@us.ibm.com>> wrote:
Those would be great. What would you have for
reverse relationships?
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov
<surkov.alexan...@gmail.com
<mailto:surkov.alexan...@gmail.com>>
To:
"accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>"
<accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>>,
James Teh <ja...@nvaccess.org
<mailto:ja...@nvaccess.org>>, Joanmarie Diggs
<jdi...@igalia.com
<mailto:jdi...@igalia.com>>, Richard
Schwerdtfeger/Austin/IBM@IBMUS
Cc:
Subject: aria-details and aria-errormessage
mapping
Date: Tue, Aug 9, 2016 2:12 PM
Hi.
ARIA 1.1 got two relation-like attributes:
aria-details [1] and aria-errormessage [2],
used to connect an element with content
providing extra info. Rich mentioned that
these attributes are likely need new
IAccessible2 relations to expose them, which
sounds reasonable. If that's the case, then we
should end up with something like:
An object containing details for the target
object.
IA2_RELATION_DETAILS
An object containing an error message for the
target object.
IA2_RELATION_ERROR_MESSAGE
Thanks.
Alex.
[1]
https://www.w3.org/TR/wai-aria-1.1/#aria-details
<https://www.w3.org/TR/wai-aria-1.1/#aria-details>
[2]
https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
<https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage>
--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org
_______________________________________________
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
