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:ja...@nvaccess.org] 
Sent: Sunday, April 17, 2016 3:14 PM
To: Rich Schwerdtfeger <richsch...@gmail.com>; Matt King <a11ythin...@gmail.com>
Cc: Joanmarie Diggs <jdi...@igalia.com>; IA2 List 
<accessibility-...@lists.linux-foundation.org>; ARIA Working Group 
<public-a...@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: ja...@nvaccess.org <mailto:ja...@nvaccess.org> 
_______________________________________________
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Reply via email to