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

Hi Group,

I'm sorry I missed Monday's call. I don't agree with the recent changes to
how programmatic AT focus works with aria-activedescendant. What follows of
course, just my opinion.

But first let me make sure I understand what we are talking about. This is
the case where an assistive technology is using programmatic API to set
(pretend) focus to a child of an aria-activedescendant container (e.g.
accSelect(SELFLAG_TAKEFOCUS)). By pretend I mean, the focus event that gets
fired on the desktop will be for the actual child node, but DOM focus (for
the purposes of keyboard handling etc) will be on the container.

Based on my understanding of the problems in the user agent implementation
of this case, I'm guessing that the term "activate" in this context boils
down to a temptation to simulate a click on the child node in question.

If my understanding is correct so far, I think we have a problem. Firstly,
we can't assume the 'activation' mechanism we choose (e.g. click) is going
to be correct for all instances of aria-activedescendant usage. We're not
going to do AI on the aria-activedescendant container's event handlers.
Guessing for which cases we should be able to get away with an activate and
which we shouldn't further complicates ARIA, which we should be desperately
trying to avoid.

I think I disagree with "The user agent MUST NOT simply change the value of
aria-activedescendant" if I understand it correctly. Firefox has for year(s)
implemented the programmatic focusing of children of aria-activedescendant
containers, by simply (?) changing the value of aria-activedescendant and
ensuring DOM focus is set to the this container node. Note, I've long
realized the sad state of affairs with DOMAttrModified (
http://www.quirksmode.org/dom/events/index.html) and its kin, and I know
polling is evil. Joseph, remember talking about this 100 years ago ;)

The fact "there is no reliable mechanism to notify" a web "application" that
the aria-activedescendant has changed is not enough of a reason to further
complicate ARIA for authors and browser implementations. I would rather get
rid of aria-activedescendant altogether (which I've proposed in the past).
Anyways, perhaps a more acceptable proposal is this:

Let's advocate for fixing the real problem, in the host language, and in the
meantime advocate for using alternate design patterns (roving-focus) instead
of aria-activedescendant.

Cheers,
David

On Wed, Apr 27, 2011 at 11:04 AM, Andi Snow-Weaver <andisnow@us.ibm.com>wrote:

> Per Monday's ARIA TF call [1], I have removed bullet 5 from section 4.2 and
> modified section 4.3 as discussed. Please review section 4.3 [2] and let me
> know if I missed anything.
>
> [1] http://www.w3.org/2011/04/25-pf-minutes.html#item01
> [2] http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_at
>
> Andi
>