>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 <ja...@nvaccess.org> <mailto:ja...@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
surkov.alexan...@gmail.com <mailto:surkov.alexan...@gmail.com>
Cc: accessibility-ia2@lists.linuxfoundation.org
<mailto:accessibility-ia2@lists.linuxfoundation.org>,
jdi...@igalia.com <mailto:jdi...@igalia.com>
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 <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: 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 <http://www.nvaccess.org>
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org>
