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

The idea of making errormessage a role that is related to a field via describedby has been floated a few times. It would avoid a new kind of relation and ensures the AT can distinguish the error message from the other describing elements if needed. It seems semantically more robust to me.

 

Are there good reasons for not considering that approach?

 

Matt

 

From: James Teh [mailto:jamie@nvaccess.org] 
Sent: Sunday, April 17, 2016 3:14 PM
To: Rich Schwerdtfeger <richschwer@gmail.com>; Matt King <a11ythinker@gmail.com>
Cc: Joanmarie Diggs <jdiggs@igalia.com>; 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

 

On 18/04/2016 7:02 AM, Rich Schwerdtfeger wrote:



Field descriptions are used by more than error messages.

I don't think anyone is debating that. The question is whether description could be used for *both*.




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.

Both pieces of information must be presented, yes, but this isn't incompatible with exposure in description. You simply expose the error message first in the description.

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).

Jamie





-- 
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: jamie@nvaccess.org <mailto:jamie@nvaccess.org>