>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.
James,
I appreciate your willingness to work with us on this. However, let me
provide you with the full picture.
1. Extended descriptions, referenced by aria-details was requested by
the digital publishing industry. The extended description can have all
kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings,
etc. It is intended as an extended, and sometimes alternative content
to better illustrate what is being referenced. For these reasons it is
essential that we *always* preserve content. In fact the
stringification in many cases could be completely useless to a screen
reader user. Also, for these reasons the intent is for it to be
visible and not hidden as aria-describedby often is as it must be
accessible to all users and not just the blind. Furthermore, there
will be instances where the content will be contained within an IFrame
within a details/summary element. The big thing here is
stringification is simply the wrong thing to do and it must not happen
in the browsers for extended descriptions.
The second thing you need to understand is the aria-details attribute
was created after months of fighting between browser vendors and
people in the accessibility community over longdesc. We don't want to
open up that pandora's box again. This is the solution that has come
to place. aria-describedby simply does not meet the needs of digital
publishing community. What is more they plan to support it in their
digital books once a mechanism is put in place, within browsers, to
show and hide content reference by aria-details in order to preserve
the needs of publishers who don't want extended descriptions rendered
by default. We definitely, don't want this functionality applied to
aria-describedby.
>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.
Error messages are not the same as extended descriptions and we don't
want the same functionality to duplicated with error messages as I
described above. The need for error messages arose many major
companies rendering visible, popup, error messages for each invalid
form entry. They want to have people with disabilities get access to
each error messages associated with the invalid control and they want
to also have access to the hidden aria-describedby help information
they provide for that control. So, stomping on one in favor of the
other is a very bad experience. They are indeed distinct and separate
concepts.
>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.
See above. I hope I have addressed most of your concerns.
>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.
ok
>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.
Joanie Diggs asked for reverse relationships as she wants to be able
to traverse back to the source. She is on CC and will be back from
vacation next week.
Best,
Rich
Rich Schwerdtfeger
----- Original message -----
From: James Teh <[email protected]>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, [email protected]
Cc: [email protected], [email protected]
Subject: Re: aria-details and aria-errormessage mapping
Date: Thu, Aug 18, 2016 9:45 PM
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 <[email protected]>
<mailto:[email protected]>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "[email protected]"
<mailto:[email protected]>
<[email protected]>
<mailto:[email protected]>, James
Teh <[email protected]> <mailto:[email protected]>,
Joanmarie Diggs <[email protected]> <mailto:[email protected]>
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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
James Teh <[email protected]
<mailto:[email protected]>>, Joanmarie Diggs
<[email protected] <mailto:[email protected]>>
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
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> wrote:
Those would be great. What would you have for
reverse relationships?
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov
<[email protected]
<mailto:[email protected]>>
To:
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
James Teh <[email protected]
<mailto:[email protected]>>, Joanmarie
Diggs <[email protected]
<mailto:[email protected]>>, 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 <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [email protected] <mailto:[email protected]>
