Scrolling into view of the of focused activedescendant needs to be included in the scenario

Best Practices Guide may be helpful. 

The browser needs to handle it when the authors have done it incorrectly. 

Concern about aria-activedescendant focus and how it might not be the same as desktop focus (comment for WAI-ARIA).

From DB: The web developer wants to have all keyboard handling on the container so that all keypresses go to the container

July 22, F2F in Boston:

Browser has to be able to put visible focus on the active descendant. Actual focus would be on the container. 

For example, container has focus, but set active descendant. Visible focus should be moved to the descendant. 

Rule: any element that has focus and has ariaactivedescendant, visible focus should be directed to the childid.

Current implementations don't put desktop focus on the childid. DB says because the container handles the keyboard events. If made it the desktop focus, events could bubble up to the container if child doesn't handle and the focus would inherit the user's display settings.

In July 31st editor's draft, make it the desktop focus with a note asking for feedback from implementers.

Changed the overview paragraph but not the rules yet. Want to discuss with UAI TF before proceeding.

(In reply to comment #3)
> July 22, F2F in Boston:
> 
> Browser has to be able to put visible focus on the active descendant.

I disagree. Visual styling is up to the web developer.

> Actual
> focus would be on the container. 

Agreed.

> 
> For example, container has focus, but set active descendant. Visible focus
> should be moved to the descendant. 

I can see the attraction of this. But it breaks the mental model of ARIA being
purely a passive semantic description of what the scripter is already doing
visually (styling).

I'll try to be open minded though :)

> 
> Rule: any element that has focus and has ariaactivedescendant, visible focus
> should be directed to the childid.
> 

Via script :)

From September 15 UAI TF meeting:

DB: what does it mean to keyboard handlers on container element?
DB: if put real focus on child and don't know where it came from or if dealing with mashup scenario, it's possible that the child could swallow the event
DB: breaks simple model of ARIA that want developers to have
CS: would be good for sighted keyboard users who customize the desktop focus and for ATs that customize the focus
DB: AT doesn't see the difference because UA fires the events for the AT to fake it
CS: MS research shows that a growing number of users are customizing their desktop focus
CS: at F2F, we were talking about describing this as desktop focus, describe some of these concerns, and ask for feedback
DB: not clear why aria-activedescendant is needed
DB: from ARIA TF, hear that people implementing grids need it because it simplifies the JavaScript


keep draft of aria-activedescendant scenario the same but add editorial note of what we are thinking and what some of the issues are, ask for feedback

think DOM focus is the same as desktop focus - need to say that somewhere or have a glossary term

Restored edited paragraph and added editorial note.

Waiting for public review comments.

Rich to draft the changes and circulate for review.

Completed at May 2011 Face to Face