Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

I agree with James.
In my experience there is very little difference between an error
message and a description.
Both need a programmatic relation to the object that caused them
(because both need to be automatically announced as user focus moves
to the associated object).
aria-describedby already provides a way to do this.
It can also be used to enable user to move focus from object to its
description (Jaws offers this using a keyboard shortcut).
I see 3 major sources of problems for error messages:
1. They need priority in the description string (I have had to tell
authors to put the error message ID first in the aria-describedby
target string, if the field already has an associated description).
This still does not address user agent behavior such as that of
Voiceover, which reads accessible description after a couple of
seconds delay.
2. A clear identification that this is an error message. Admittedly
this is not necessarily an accessibility bug as it is a usability
issue. Most error messages are implemented as a text string and an
associated "error" icon. Simply putting the alt text "error!" on the
icon and including it along with the error message text in the
referenced container element solves the problem. If the icon is
implemented as a CSS background image, the word "Error! " is added to
the message.
3. Author confusion around aria-describedby announcing elements even
if they are not in the DOM.
I often see pages where the hidden error message has already been
linked to the form field when the page loads, with the author intent
that screen readers will only announce it once it becomes visible.
Bbut screen readers always read it because aria-describedby does not
care about the display status of its target (as per spec).
to demonstrate:
<input type="text" aria-describedby="foo">
<span id="foo" style="display: none;">You have exceeded the maximum
character length of 10</span>
Author thinks the associated error message is only going to be
announced once we switch foo's display: none; to display: block;
But foo is always going to be read when focus lands on the input field
regardless of its display status.

I am not a tool implementer, but in my mind an "aria-errormessage"
role on the error message container together with aria-describedby
reference might solve all 3 issues.
1. A.t. or browsers could give it a priority status (put it first in
the description string/announce it with less of a delay than ehlp
text).
2. They could announce the word "error" if they encounter the role.
3. They could provide an additional check for the message's display
status before they decide to announce it or not, only announce it if
it is visible.

We already overload authors with ARIA relationships, role and
attributes, and we see a lot of ARIA misuse out there. I am worried
that adding another ARIA relationship attribute is only going to make
things worse.
Granted, what I am proposing can increase author confusion, but at
least it only adds one role, not a role and a dual relationship
reference.





On 4/11/16, James Teh <jamie@nvaccess.org> 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: jamie@nvaccess.org
>
>
>


-- 
Birkir R. Gunnarsson
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Tuesday, 12 April 2016 10:04:19 UTC