Re: ACTION-1674: New error message mechanism proposal

What about using roles?  Like role=error and role=instructions. These could have tabindex=0 and allow windows screen readers to be in application mode and have this type of info in the tab order.  Then aria-described by could point to elements with these roles

Jon  Gunderson
Sent from my iPhone

On Jul 4, 2015, at 8:05 AM, Michiel Bijl <michiel@agosto.nl<mailto:michiel@agosto.nl>> wrote:

Is there any reason to not use aria-describedby for this? aria-errormessage essentially does the same thing, but with a more meaningful attribute.

—Michiel

On 02 Jul 2015, at 21:44, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:


The group has raised an issue that we need a mechanism to define a way to provide error messages to assistive technologies that:

- Allow for an association between the error message and the element that the error message applies to
- Provides an importance level

Overloading aria-invalid was discussed in that a custom string could be provided. The group found did not work as aria-invalid takes tokens and not strings. Also, some host platforms use an enumeration of these values.

When error messages are created and made visible we have found many use cases are designed to announce the error when it happens (live regions). However, there may be exceptions where we don't want them announced. Another issue that was raised was that it is important that all users be able to see the error message which would imply a relationship to a message, like aria-describedby, that would allow an author to reference the visible relationship. Typically, this would require the AT user to follow the reference to the error message if needed.

As it turns out aria-live already defines implied importance levels with what we believe to be sufficient granularity - assertive, polite, and off. Also many of the use cases where errors messages are made available they are often live so that the user hears them. So, I propose the following;

We define attribute called aria-errormessage that takes a single ID that points to the error message. Authors should ensure that the ID points to a message that has an aria-live property. The default is aria-live="off", consistent with the aria-live attribute.  When the aria-errormessage is applied the author MUST also supply the aria-invalid attribute to the element. It is not an author MUST to have an aria-erromessage when aria-invalid is provided.

aria-errormessage is a global property.

We should consider allowing aria-errormessage to reference pre-defined live regions:

  1.  role="status" This would allow for a changing error message.
  2.  role="alert" This will not work because alerts come up and then disappear.
  3.  role="log" I suspect you could have error log that changes but I think that could make people sick as it scrolls if it kept updating.

Rich


Rich Schwerdtfeger