Re: Concern with prose in @aria-errormessage

I see. We agree totally. The error message relationship is there to ensure
that the correct message is associated with the correct form field.

This was a very big problem for many members of the ARIA task force -
Specifically, IBM, Oracle, and SAP. IBM was using live regions as well. :-)

Thank you for your feedback.


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	James Craig <jcraig@apple.com>, "WAI Protocols & Formats"
            <public-pfwg@w3.org>
Date:	09/13/2015 11:52 PM
Subject:	Re: Concern with prose in @aria-errormessage



Rich,

I'm okay with the current text, which says that the error message element
MAY be a live region.

I was responding to James's suggestion that we disallow this. James says
that we shouldn't allow aria-errormessage to point to a live region,
because that could lead to a duplicate announcement.

My concern is that if an author is *already* using a live region for their
error message (this is a common practice now), that they won't want to
remove the live region when adding support for aria-errormessage, because
then users with a browser or AT that doesn't yet support aria-errormessage
would have an inferior experience.

My preference would be to leave the text as it is now, and encourage AT to
do the extra work to prevent duplicate announcements when an error message
is also a live region.

- Dominic

On Sun, Sep 13, 2015 at 1:09 PM Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  Dominic,

  I am confused by your concern.

  aria-errormessage does point to the error message and it can be a live
  region. Are you saying that if it does point to the error message that
  the error message MUST be a live region?

  What we are saying in the text is that if you have an error message
  (which you would in the case of an alert, status, or aria-live="...").
  How does pointing to an error message break backward compatibility> We
  are not asking that the author remove aria live properties.

  We don't say anything about what is announced when aria-errormessage is
  applied. All that the relationship does is indicate which error message
  in the page is associated with the element.

  Rich


  Rich Schwerdtfeger

  Inactive hide details for Dominic Mazzoni ---09/11/2015 11:04:35 AM---On
  Fri, Sep 11, 2015 at 12:58 AM, James Craig <jcraig@appDominic Mazzoni
  ---09/11/2015 11:04:35 AM---On Fri, Sep 11, 2015 at 12:58 AM, James Craig
  <jcraig@apple.com> wrote: > http://rawgit.com/w3c/aria

  From: Dominic Mazzoni <dmazzoni@google.com>
  To: James Craig <jcraig@apple.com>
  Cc: "WAI Protocols & Formats" <public-pfwg@w3.org>
  Date: 09/11/2015 11:04 AM
  Subject: Re: Concern with prose in @aria-errormessage






  On Fri, Sep 11, 2015 at 12:58 AM, James Craig <jcraig@apple.com> wrote:


        http://rawgit.com/w3c/aria/master/aria/aria.html#aria-errormessage

        I'm concerned this line in @aria-errormessage is going to result in
        duplicated announcements. Reconciling these two different types of
        user-facing announcements would be very challenging from an
        implementation perspective.
              Authors may use live regions for the error message element
              applying either an aria-live property or using one of the
              live region roles, for example, alert.

        Please change it to recommend one or the other (either
        @aria-errormessage or live regions) but not both simultaneously.

  I understand your concern, but I'm afraid that this would hinder adoption
  of aria-errormessage because of backwards compatibility. If I have a
  highly accessible web form right now and I switch from using role=alert
  for error messages (in addition to aria-invalid, of course) to
  aria-errormessage, that would be a regression for any users who aren't
  using a supported browser/AT combination.

  While I realize it's an implementation challenge, I'd lean towards
  allowing the target of aria-errormessage to point to a live region (or
  alert), and put the burden on AT to keep track of this and detect it as
  part of support for aria-errormessage.