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

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.



On Apr 12, 2011, at 10:56 AM, Larry Weiss wrote:

> My suggested edits inline and prefaced with LW:
>  
> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
> Sent: Thursday, April 07, 2011 8:50 AM
> To: Larry Weiss; Cynthia Shelly; Andi Snow-Weaver; david.bolter@gmail.com; jcraig@apple.com
> Cc: wai-xtech@w3.org
> Subject: aria-activedescendant changes to the aria-implementation guide
>  
> After discussion with the Mozilla accessibility developer for Linux and discussions with Larry Weiss (Microsoft) I have made extensive modifications to sections 4.2 and 4.3 (http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_aria-activedescendant). The general issues addressed by this change are:
> 
> - Removing the editorial note and state how aria-activedescendant is supposed to work
> - Make a clear distinction about what "focus" we are dealing with. I have delineated DOM and desktop focus. 
> - Added a statement regarding the authors responsibility to not show focus on the container element for elements that support aria-activedescendant. (We should probably state this in the authoring practices too)
> - Correct the statement that the container with aria-activedescendant does not disappear from the accessibility tree
> - Modified the text so that we don't state "tab navigation order" to be more in line with HTML 5 to ensure device independence for mobile.
> 
> Andi, we should include glossary entries for DOM and desktop focus. Note: we may consider calling desktop focus platform focus. 
> 
> Please review the changes and comment. I put this on xtech so Larry does not get bounced.
> 
> <change>
> 4.2. Controlling focus with aria-activedescendant
> 
> Editorial note: In current implementations as described below, user agents keep the desktop focus on the container but communicate focus events and states to the assistive technology as if the active descendant has focus.
> 
> Alternatively, the actual desktop focus could move to the active descendant. This would be a less complex scenario for user agents to implement and would be a better scenario for users who have customized the appearance of their desktop keyboard focus. There is some concern that if the desktop focus is placed on the active descendant, some keyboard events might get dropped.
> 
> The WAI-ARIA User Agent Implementation task force seeks feedback from reviewers on this issue.
> 
> The aria-activedescendant property may also be used to enable keyboard accessibility on WAI-ARIA elements that support this attribute. It is often a more convenient way of creating containerwidget keyboard navigation (where the entire widget is in the tab order just once, but the user can use other keys, typically arrow keys, to navigate to descendant items of the container).
> 
> Typically, the author will use host language semantics to put the container element in the sequential tab order (tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since actual focus is on the container.
> 
> The user agent MUST do the following to implement aria-activedescendant:
> 
> 1. Implement the host language method for keyboard navigation so that the container widget may be included in the tab order. For HTML implementations, see Controlling focus with tabindex. 
> 2. Do not expose any element in the accessibility API the when it has DOM focus and also has aria-activedescendant which points to a valid ID.
> 3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, fire an accessibility API FOCUS event on the new active descendant. If aria-activedescendant is cleared or does not point to an element in the current document, fire a FOCUS event for the container object that had the attribute change.
> 4. For any element with an ID attribute, where the element is a descendant of an element with the aria-activedescendant attribute, apply the following states to the target to ensure the object is accessible:
> 1. FOCUSABLE, if the element also has a WAI-ARIA role — because the aria-activedescendant of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because real HTML elements that would be focusable would already have the FOCUSABLE state.
> 2. ACTIVE, whenever the container element sets aria-activedescendant to match the ID of this descendant
> 3. FOCUSED, if ACTIVE and the container widget with aria-activedescendant has true DOM focus
> 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.
> 4.3. Handling focus changes from the Assistive Technology
> Alternative input software needs to be able to set focus to items that are focusable. Screen readers, voice input software and on-screen keyboards may set focus based on user commands implemented in that software. User agents MUST allow AT to set focus using accessibility APIs as defined in the following table:
> 
> MSAA
> Microsoft UIA
> ATK/AT-SPI
> Mac OS X Accessibility
> accSelect(SELFLAG_TAKEFOCUS)
> RaiseAutomationEvent
> AtkComponent::grab_focus
> Notification:AXFocusedUIElementChanged
> If the would-be-focused element can take real DOM focus, the user agent MUST set the DOM focus to it.
> Otherwise, if the current element has an ID and an ancestor with the aria-activedescendant attribute present, the user agent MUST set DOM focus to that ancestor. If successful, then setaria-activedescendant on the ancestor to the ID of the current element. When it is not possible for the user agent to set DOM focus to the containing element with aria-activedescendant, the user agent MAY attempt to set focus to the child element itself. Note: the inability to set focus to the containing element indicates an author error.
> 
> </change>
> <to>
> 
> 4.2. Controlling focus with aria-activedescendant
> When implementing, as as described below, user agents keep the DOM focus on the container but communicates desktop focus events and states to the assistive technology as if the active descendant has focus. It is the responsibility of the user agent to ensure that keyboard events are processed at the element that has DOM focus. Since keyboard events are to be processed at the container any keyboard events directed at the active descendant would bubble up to the DOM element with focus for processing.
> 
> The aria-activedescendant property may be used to enable keyboard accessibility on WAI-ARIA elements that support this attribute. It is often a more convenient way of creating containerwidget keyboard navigation (where the entire widget is in the tab order just once, but the user can use other keys, typically arrow keys, to navigate to descendant items of the container).
> 
> Typically, the author will use host language semantics to put the container element in the focus navigation order (tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus and for styling the DOM focused container such that it does not appear to be focused. The author cannot use :focus to style the currently active descendant since actual focus is on the container. 
> 
> LW: Change “actual focus” to “DOM focus”.  (The qualifiers “actual”, “real”, or “true” to describe focus are misleading.  Instead, use “DOM”, “keyboard”, or “desktop” to unambiguously specify which focus is being described.)
> 
> The user agent MUST do the following to implement aria-activedescendant:
> 
> 1. Implement the host language method for keyboard navigation so that the container widget may be included in the focus navigation order. For HTML implementations, see Controlling focus withtabindex. 
> 2. Do not expose the focused state for any element in the accessibility API when it has DOM focus and also has aria-activedescendant which points to a valid ID.
> 
> LW: “focused state” is ambiguous here.  I suggest:  “Do not expose desktop focus via the accessibility API on an element that has DOM focus and also has aria-activedescendant which points to a valid ID.”
> 
> 3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, fire an accessibility API desktop FOCUS event on the new active descendant. Ifaria-activedescendant is cleared or does not point to an element in the current document, fire a desktop FOCUS event for the container object that had the attribute change.
> 
> LW: Wouldn’t it be better to fire a desktop focus event for the element with DOM focus (or it’s active descendant)? 
> 
> 4. For any element with an ID attribute, where the element is a descendant of an element with the aria-activedescendant attribute, apply the following states to the target to ensure the object is accessible:
> 1. FOCUSABLE, if the element also has a WAI-ARIA role — because the aria-activedescendant of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because real HTML elements that would be focusable would already have the FOCUSABLE state.
> 2. ACTIVE, whenever the container element sets aria-activedescendant to match the ID of this descendant
> 3. FOCUSED, if ACTIVE and the container widget with aria-activedescendant has true DOM focus
> 
> LW: Remove the word “true” as a qualifier of “DOM focus”.
> 
> 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.
> 
> LW: Qualify that the assistive technology would set “desktop focus”.
> 
> LW: Isn’t #5 the same as 4.3 below?  If so, why have it in both places?  And why are they different?
> 
> 
> 4.3. Handling focus changes from the Assistive Technology
> Alternative input software needs to be able to set destkop focus to items that are focusable. Screen readers, voice input software and on-screen keyboards may set desktop focus based on user commands implemented in that software. User agents MUST allow AT to set desktop focus using accessibility APIs as defined in the following table:
> 
> MSAA
> Microsoft UIA
> ATK/AT-SPI
> Mac OS X Accessibility
> accSelect(SELFLAG_TAKEFOCUS)
> RaiseAutomationEvent
> AtkComponent::grab_focus
> Notification:AXFocusedUIElementChanged
> If the would-be-focused element can take real DOM focus, the user agent MUST set the DOM focus to it. 
> 
> LW: Remove the word “real” as a qualifier of “DOM focus”.
> 
> Otherwise, if the current element has an ID and an ancestor with the aria-activedescendant attribute present, the user agent MUST set DOM focus to that ancestor. If successful, then setaria-activedescendant on the ancestor to the ID of the current element. When it is not possible for the user agent to set DOM focus to the containing element with aria-activedescendant, the user agent MAY attempt to set focus to the child element itself. Note: the inability to set focus to the containing element indicates an author error. 
> 
> LW: Qualify which focus is set: “… the user agent MAY attempt to set DOM focus to the child element itself.  Note: the inability to set DOM focus to the containing element indicates an author error.”
> </to>
> 
> 
> Rich Schwerdtfeger
> CTO Accessibility Software Group