- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Tue, 12 Apr 2016 06:03:50 -0400
- To: James Teh <jamie@nvaccess.org>
- Cc: Joanmarie Diggs <jdiggs@igalia.com>, IA2 List <Accessibility-ia2@lists.linux-foundation.org>, ARIA Working Group <public-aria@w3.org>
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