Re: aria-activedescendant changes to the aria-implementation guide

We discussed this some more on the AAPI call today. I had an action to send a proposed rewrite of that text to the list:

<from>
> 5. If the assistive technology sets focus to a descendant of a container with aria-activedescendant, change the value of aria-activedescendant to point to that item.
</from>

<to>
> 5. If the assistive technology fires a desktop API focus event to a descendant of a container with aria-activedescedant, the user agent SHOULD fire an activation event on the descendant element, with the following stipulations:
> User agents SHOULD NOT fire an activation event on elements with the role button, link, menuitem, menuitemcheckbox, or menuitemradio.
> User agents SHOULD fire an activation event on elements with the role listitem, radio, or option.
> User agents MAY fire an activation event on elements with the role gridcell, columnheader, rowheader, or row (Ed note: I'm note sure about the grid roles on this third bullet regarding MAY versus SHOULD NOT. Looking for alternate opinions.)
</to>




On Apr 12, 2011, at 12:02 PM, James Craig wrote:

> As Rich noted on the Monday's group call, the following implies that the AT or UA would make a change to the DOM without the author's knowledge. 
> 
>> 5. If the assistive technology sets focus to a descendant of a container with aria-activedescendant, change the value of aria-activedescendant to point to that item.
> 
> Problems:
> 
> Assuming a container is using the activedescendant design pattern, nothing within that container should be user-focusable, so the AT should never be able to set focus on a descendant. If the sentence is talking about firing some type of API focus notification that does not actually change the DOM focus (e.g. if it would not affect document.activeElement, :focus pseudo-class, or the visible focus ring), then the wording needs updating. Even if that bit were resolved, the AT or UA should never change the DOM out from under the author script.
> 
> I think this sentence should be removed entirely.
> 

Received on Thursday, 14 April 2011 20:11:48 UTC