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

Matt, 

Error messages are used in forms today a lot. Waiting to ARIA 2.0 is a mistake and the lack of error message support was a source of pain for users since we first met at Mozilla. We have avoided normative statements about ATs (with the exception of a security issue because the ATs are not providing accurate information to the user).  

aria-describedby participates in the accessible description computation. It also applies to hidden descriptions. Error messages must be visible.

Sorry, Matt but I am reading your comments and it is as if you never attended a single meeting. 

Field descriptions are used by more than error messages. In fact, the reason that described by was first used was to remove a hack that the SSA had where they were encoding help information about form elements to users. So, what you are suggesting is stomping on the help information to expose the error information. We are also finding that in one of the Federal agencies that people with short term memory loss are using the descriptions with a screen reader as the forget what the purpose of the form fields and other forms of input are for. So, then you stomp on it with an error message and they you want to know what you were supposed to input into the field and it is gone. This information MUST be separate. 

I don’t want to rehash these issue again Matt. We have already discussed these numerous times in both the ARIA working group and the AAPI mapping specs. 


Rich


Rich Schwerdtfeger




> On Apr 13, 2016, at 10:46 AM, Matt King <a11ythinker@gmail.com> wrote:
> 
> It seems like we should revisit the purpose of adding aria-errormessage and then ask ourselves whether or not any of these mapping proposals could achieve it. If not, perhaps we should give ourselves more time (ARIA 2.0) to identify the ideal path to the desired end.
> 
> When aria-errormessage was first discussed, my understanding was that the purpose is to distinguish an error message from a description so that assistive technologies would have the option to give it special treatment. 
> 
> Is there more to it than that?
> 
> The description of aria-errormessage does not contain any normative statements or suggestions that apply to assistive technologies. Are there any assumptions about what assistive technologies might do? Judging from this thread, one assumption I could derive is that assistive technologies would prioritize speaking error messages over descriptions.
> 
> All the user experience behaviors described in the aria-errormessage text are easily achieved with aria-describedby. If the primary desire was to get assistive technologies to prioritize error messages over descriptions, then we could as effectively achieve that objective with authoring practices.
> 
> It is worth noting that error messages often make field descriptions unnecessary. For example, a field description might be "Please enter  a date in yyyy/mm/dd format." And a corresponding error message may be "Please provide the date in yy/mm/dd format." If the error message and description are not redundant, then it seems reasonable to ask authors to provide the ID of the error message first followed by the ID of the description in the aria-describedby property.
> 
> Matt
> 
> -----Original Message-----
> From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
> Sent: Tuesday, April 12, 2016 6:48 AM
> To: James Teh <jamie@nvaccess.org>
> Cc: IA2 List <Accessibility-ia2@lists.linux-foundation.org>; ARIA Working Group <public-aria@w3.org>
> Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2
> 
> 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
>> 
> 
> 
> 
>