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 Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess SIP: jamie@nvaccess.org
Received on Sunday, 17 April 2016 22:14:07 UTC