Association of Error Messages

A key issue that keeps coming up is the need to associate error messages
with widgets or HTML controls having aria-invalid set to "true."

Today, aria-invalid takes a token and not an ID that defines the type of
error message or simply whether or not the element is invalid. This
requires us to define a separate reference to an error message that takes
an IDREF or IDREFS. Often forms render an error message per invalid input
control.

Today we have an aria-describedby property that resolves to a string
description on all platform accessibility API mappings. On some platforms
it resolves to a relationship. We could define a role or attribute on the
object referenced in the aria-describedat property and use this to overload
aria-describedat so that we could tell an assistive technology that this
description applies to an error. There are problems with this approach and
they are as follows:

1. Some platforms don't provide a relationship for descriptions so that you
could look to the reference and see that it is an error message- MacOSX
2. On all platforms this would mean that the description used for help is
lost if an error message is provided.
3. None of the platforms provide for separate Accessibility API
relationships for error messages.
4. Even if we did have a relationship we also need to ensure that when a
role of "alert" is provided that it does not conflict with an error message
when referencing the relationships (the browser can only handle one role on
the ID;'d element)

Is it acceptable to overload aria-describedby by applying error message
role to the targed element ? If so, we would potentially need to stick the
error messages in an object attribute.
Will platform vendors be willing to introduce a new relationship for error
messages to platform accessibility APIs?

I would like to hear thoughts from members.

Thanks,
Rich

Rich Schwerdtfeger

Received on Thursday, 18 June 2015 21:27:32 UTC