Our descriptions of setting the FOCUSED and FOCUSABLE states seems a bit random to me.

In Controlling focus with tabindex:

1 Where tabindex equals a negative integer, allow the element to be focused, but do not include the element in the sequential tab order.
<als> what does "allow the element to be focused" mean? Should this state explicitly to set the FOCUSABLE state? </als>

2. Where tabindex="0", allow the element to be focused and include it in the sequential tab order.
<als> ditto </als>

3. Where tabindex is greater than zero, allow the element to be focused, and include the element in the sequential tab order according to the value of the tabindex attribute and before any elements with tabindex either omitted or with a value of zero.
<als> ditto </als>

8. Expose the FOCUSED and FOCUSABLE accessibility API states, and FOCUS events for any element in the accessibility tree.
<als> Is this right? To me, it seems to be saying always expose the FOCUSED state but shouldn't you only do that when the element actually has focus? </als>

<als> We have no rule in this section about what to do when an element actually has focus. Is this okay? </als>

In Controlling focus with aria-activedescendant:

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

    A. 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 HTML elements that would be focusable would already have the FOCUSABLE state.
    B. ACTIVE, whenever the container element sets aria-activedescendant to match the ID of this descendant
    C. FOCUSED, if ACTIVE and the container widget with aria-activedescendant has DOM focus

In Handling focus changes from the AT

* If the current element has an ID and an ancestor with the aria-activedescendant attribute present, the user agent MUST set the accessibility API FOCUSED state and fire an accessibility API desktop FOCUS event on the new active descendant.

In State and Property Mapping:

1. User agents MUST compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant. See the rules in Controlling focus with aria-activedescendant.
<als> This seems to be the rule that directs the UA to set the FOCUSED/FOCUSABLE states but it's hidden in an implicit understanding of "managed states". </als>

In aria-hidden row of the S&P Mapping Table:

For OS X, we have "Not exposed in AX API unless focused"

In 5.8.3 Selection: 

In the single selection case, it is not always necessary to manage selection events and states separate from focus, since selection mirrors focus. One exception is for tablist. In the case of a tab, if either the tab or its associated tabpanel has focus, then the tab is considered to be SELECTED. To implement this, the user agent can walk up the parent chain from the focus until it finds a tabpanel, then traverse the aria-labelledby relation from the tabpanel to the related tab, and mark the found tab as focused.
<als> are there any other exceptions to the "selection mirrors focus" rule for single selection? Should the last phrase say "mark the found tab as FOCUSED"?</als>

We have nothing in this section that defines the events to be fired if aria-selected changes. They are in the Events section above. At a minimum, the Events section should refer to this section for more information. Would it be better to just have all of the Selection stuff covered in 5.8.3 or is it okay to have it split like this?

Under the multiselection case:

The first bullet says "Expose the correct states on the container: MULTISELECTABLE and, in MSAA, also explose EXTSELECTABLE."

I think we can cover this adequately in the S&P mapping table and remove this bullet. It's all there already (aria-multiselectable) for each API except in the case of OS X where this is "not mapped". Should the MSAA state be STATE_SYSTEM_MULTISELECTABLE?

The second bullet says "In Microsoft UIA, the Selection and SelectionItem Control Patterns expose the selection availability, state, and methods."

In the S&P mapping table for UIA, we have "Set CanSelectMultiple property on the Selection Control Pattern." Is there more we need to say for UIA?

The third bullet says "In IAccessible2, for text elements, support the selection methods defined on the IAccessibleText interface." 

I've added this to the S&P mapping table. "The fourth bullet says "The selection interface can be used by an assistive technology to actually set the selection on a descendant. This should fail for the specified descendant if aria-selected is undefined, which indicates the element is not SELECTABLE. It should also fail if the specified descendant is DISABLED or READONLY for any reason. When clearing selection on an item, set aria-selected="false" but do not remove the attribute, so that it is still SELECTABLE."

So this is not about events and not about mapping. It seems out of place here but again, it's a really small thing to separate out. Also, wouldn't changing the value of "aria-selected" be a change to the DOM which we agreed UAs should not do in ARIA 1.0 because there is no way for the app to get notified of the change?

According to the text, the table is only applicable for the multiselection case. But it has a row for the "Selection follows focus" case. Is this relevant for multiselection? Should this be pulled out into a separate table for single selection?

Another question about this row. It says "but arrange events so state change does not occur on focused item, to avoid extra selection change announcements" for MSAA and ATK columns. What does this mean?

Comments about the FOCUSED and FOCUSABLE states are related to bug 13208.

Cynthia,

Please review the Selection events section for correctness. Then pass this on to David.

Looks good to me.  David?

David,

Please review the Selection Events section and let me know if you think it is good to go or if changes are needed.

http://www.w3.org/WAI/PF/aria-implementation/#mapping_events_selection

(In reply to comment #6)
> David,
> 
> Please review the Selection Events section and let me know if you think it is
> good to go or if changes are needed.
> 
> http://www.w3.org/WAI/PF/aria-implementation/#mapping_events_selection

I need someone else to look at:
"object::selection_changed + object_notify_state_change, but arrange events so state change does not occur on focused item, to avoid extra selection change announcement"

Andi, wherever we have a pattern of verbiage like "object::selection_changed + object_notify_state_change" I think we should just have "object::selection_changed".

AFAIK object_notify_state_change is a function that causes/fires the "object:..." event message. So you don't really do 'both', which is confusing if we keep the "+".