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

Hi Matt,

I have a couple of comments, inline below.

On 2015-09-25 9:41 AM, Matt King wrote:
>
> 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.
>

The wording (my emphasis), "*after the user agent page load is 
complete*" implies that aria-busy is not usable while the page is being 
loaded.  Is that your intent?

If so, what about cases where numerous DOM manipulations are done during 
a page load?  Take for example, the github rawgit URLs that we use for 
the ARIA specs.  When documents are loaded from rawgit, this sequence 
occurs:

1. The base document is loaded from github,
2. ReSpec goes to work building and adding numerous chunks of DOM 
including a table of contents, importing the glossary, building and 
adding the bibliography, and so on.
3. The final fully formed document is ready.

During step two, the document is aria-busy.  Would it be useful to 
inform an AT as to when those modifications are all finished and the 
document is at step 3?  That could be done by setting aria-busy to 
"true" at step 1, and switching it to "false" at step 3.

As a test, I've created a branch where aria-busy is set to "true" on the 
<body> until ReSpec is finished, whereupon aria-busy is switched to "false":
http://rawgit.com/w3c/aria/ariaBusyOnBodyTest/aria/aria.html

> 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.
>

One editorial suggestion.  Change this sentence:

"If authors know multiple additions, modifications, or removals are 
needed within a container element, they can set aria-busy to true on the 
container element before the first change, and then set aria-busy to 
false when the last change is complete."

To:
"If multiple additions, modifications, or removals are needed within a 
container element, authors set aria-busy to true on the container 
element before the first change, and then set aria-busy to false when 
the last change is complete."

Hope that's useful.

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Monday, 28 September 2015 13:42:16 UTC