RE: [IE10 and IE 11] Using aria-activedescendant attribute to control focus within a widget does not work | Microsoft Connect

Hi,
Just to follow up on my original question, which I believe I've resolved.

Regarding the multiple aria-activedescendant instances at
http://cookiecrook.com/test/aria/tree/ariatree2.html
This looks to be controlled from the node that includes role=tree and
role=group to manage child nodes, so when focus is moved, it moves to
another branch where this is managed using aria-activedescendant, then
aria-activedescendant is used to control child node selection within that
level, and so on.

The problem I noticed in JAWS15 in IE11 is that, all of the child nodes are
announced on every branch, which does not occur in Firefox.

Looking closer, this matches the name assigned to the focusable tree node in
the accessibility tree, implying that this isn't a JAWS bug.

So this does look to be an IE bug after all, since the accessible name for
the focusable node in the accessibility tree is the concatenated names for
all child nodes in the branch, and not just the child node referenced using
aria-activedescendant as it should be.


-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Tuesday, June 10, 2014 10:37 AM
To: 'PF'
Subject: [IE10 and IE 11] Using aria-activedescendant attribute to control
focus within a widget does not work | Microsoft Connect

http://connect.microsoft.com/IE/feedback/details/817699/ie10-and-ie-11-using
-aria-activedescendant-attribute-to-control-focus-within-a-widget-does-not-w
ork

Hi,
This isn't an IE specific question, but it's mentioned in the above
referenced bug. A client was asking me about this today, saying that
aria-activedescendant isn't supported in IE, but to my knowledge, it is.

So, the bug sites the following two examples:
http://oaa-accessibility.org/example/11/
and
http://cookiecrook.com/test/aria/tree/ariatree2.html

The first uses role=application and tabindex=-1 on the container, which
appears to be screwing with screen reader tabability in JAWS15 and IE11,
even though it's possible to arrow to it and press Enter to activate and use
the arrow keys. The accessibility tree does look to be updated correctly
when the arrow keys change the value on Win7.

The second example shows an ARIA tree construct, which has a similar
container, however there are multiple instances of aria-activedescendant on
various nodes throughout the tree construct, which, to my knowledge, is a
mis-use of aria-activedescendant in this instance. Is this the case? The way
that focus is handled and the multiple aria-activedescendant attributes
looks weird to me.

Is this a valid construct?

Thanks,
Bryan