Re: issue-633 New draft of aria-busy based on Sep 24 ARIA meeting

Hi Matt,

Some feedback. It may not be critical now but in ARIA 2.0 we are going to
have to deal with Web components and we may not have a DOM to contend with.

So for example:
"If an element with articlefeed or itemfeed is marked busy, assistive
technologies MAY similarly defer rendering DOM changes that occur inside
the feed with the exception of user-initiated changes that occur inside the
article or listitem that the user is reading during the busy period."

You may want to say :

"If an element with articlefeed or itemfeed is marked busy, assistive
technologies MAY similarly defer rendering changes that occur inside the
feed with the exception of user-initiated changes that occur inside the
article or listitem that the user is reading during the busy period."

You may also want to change:
"For example, if multiple updates to the document involve adding a tree
element and then populating that element with treeitems, the element having
a role of tree tree needs aria-busy set true before the tree is added and
then set false after the tree is complete. "

Other than that, to me, it is fine.

Cheers,
Rich


Rich Schwerdtfeger



From: Matt King <a11ythinker@gmail.com>
To: "'PF'" <public-pfwg@w3.org>
Date: 09/25/2015 08:42 AM
Subject: issue-633 New draft of aria-busy based on Sep 24 ARIA meeting



As discussed in the Sep 24 ARIA meeting, one of several aspects of issue
633 is clarifying the intent of aria-busy so its applicability to and use
in design patterns for the articlefeed and itemfeed roles is clear.

A new draft of aria-busy that incorporates feedback from yesterday’s
meeting is available at:
http://rawgit.com/w3c/aria/mck_issue633/aria/aria.html#aria-busy


I have made the following changes from the current master branch, which is
at:
http://rawgit.com/w3c/aria/master/aria/aria.html#aria-busy


      1.       Change the definition to clearly state that aria-busy
      applies to all elements and is not limited to live regions and
      widgets.
      2.       Extended the definition to state that it applies only to
      modification that occurs after page load is complete.
      3.       Replaced the example with one that directly corresponds to
      the normative author MUST statement.
      4.       Added 2 normative MAY statements for assistive technologies
      that support both the general use case as well as use in articlefeed
      and itemfeed.
      5.       Removed the statement, "If there is an error updating the
      element, authors MAY set the aria-invalid attribute to true." Removed
      because:it does not match the definition of aria-invalid, which
      applies to user-enetered values, not script errors.

Matt King