Hey Joanie, all.
Let me try to summarise this mess from my perspective.
1. When you made your initial proposal (description relationships plus
object attribute), I agreed. You clearly don't see them as fundamentally
different.
2. However, I noted that if it's being exposed via description
relationships, it follows that it should also be exposed as part of the
calculated description text.
3. At this point, it became clear that several people (most notably
Rich) believe that error messages are fundamentally different to
descriptions and were thus against (2).
4. If we aren't going to do (2), IMO, (1) doesn't make sense.
5. It's also clear that there is significant disagreement amongst spec
people as to whether error messages are fundamentally different or not;
(1) versus (3). That's a major alarm bell for me. IMO, if ARIA and
accessibility API disagree on this, the whole idea is broken and needs
to be reconsidered from the ground up.
6. My suggested path forward from here is probably to do (1) and (2),
despite the objections in (3). We can always change that decision later,
since this approach is backwards compatible.
Thanks,
Jamie
On 12/04/2016 11:47 PM, Joanmarie Diggs wrote:
Hey Jamie, all.
FWIW, I had proposed exposing it via the existing description-related
relationships plus an object attribute:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002001.html
And I indicated that I didn't have strong feelings either way about
whether or not the description was included as part of the alternative
text calculation:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002011.html
In other words, I personally do not see it as fundamentally different.
Mind you, knowing that something is an error message might prove handy,
hence my suggestion of an object attribute on the element that contains
the error message.
I don't like to take performance hits any more than you do. If you feel
like this approach will result in a performance hit, then we should
rethink things.
All of that said.... Where I myself am is that we need to map this new
ARIA feature. And we're trying to get ARIA 1.1 locked down. Given that,
along with the fact that it is seen as desirable that we keep our
platforms aligned whenever possible, what I want is *some* mapping. :) I
tossed out the new relation type because I got the impression that my
original proposal was not seen as acceptable, and because you suggested
a new relation type:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002019.html
--joanie
On 04/11/2016 08:18 PM, James Teh wrote:
On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:
If there's sufficient belief that errormessage is inherently different
FWIW, I don't believe this personally--I've not seen a single argument
that I wasn't able to defeat--but it seems like this decision has
already been made in ARIA. Certainly, NVDA will just be merging it into
description internally. What I will say is if ARIA views it as being
fundamentally different (as misguided as I think this is), it seems
problematic if the accessibility APIs merge it.
That said, one nasty problem with an additional API or relation is that
we have to call/crawl that additional thing for *every* accessible just
to find out whether it has an error message. That's kinda ugly from a
performance perspective; we hurt performance everywhere just to support
aria-errormessage. Still, I guess this is the best we can have given the
majority opinion that it is so fundamentally different.
I'm happy with the names you proposed.
Jamie
--
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
