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

I think the support of activedescendant is generally still buggy in IE.
It is a pity that MS is not documenting its implementation in detail with examples since this really limits debugging of custom controls using this concept.

What I learned from the past is that avoiding activedescendant and working with direct element focusing worked better in IE, while Firefox support for activedescendant was almost always as specified.

This unfortunately leads to implementations working better in one of these browsers, dependant of which method developer decided to use.

Stefan

Sent from my iPad

On 18.06.2014, at 20:48, "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:


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