- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 18 Jun 2015 16:26:19 -0500
- To: PF <public-pfwg@w3.org>
- Message-ID: <OF4618597C.62C34D82-ON86257E68.007451F8-86257E68.0075C464@us.ibm.com>
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