It seems to come down to how we interpret "child node" in https://www.w3.org/TR/accname-aam-1.1/#step2F - from the point of view of the accessibility tree, `aria-owns`-ed nodes are child nodes of the owning node - however, I don't expect most people would expect that to be the intended meaning.

However, I think trees are a naming edge case. It seems like you might be trying to use `aria-owns` here to work around the general problem where you never want descendant tree items to form part of the accessible name of their parent tree item, which I honestly think is better handled by using an explicit label for tree items (since then you don't need to worry about trying to contort the tree structure for naming purposes).

Is there another, non-tree-related case where this is a problem? Or, could we come up with a case where the Chrome behaviour here is preferable?

Logged https://github.com/w3c/aria/issues/538 against ARIA Accname-AAM to clarify

Thanks for filing the issue.
Able to reproduce the issue on windows7,Mac-10.12.3 & Ubuntu 14.04  using Chrome reported version-59.0.3044.0 ,stable version-57.0.2987.110 and canary-59.0.3049.0 with the steps mentioned in comment#0.

This is Non-regression issue, Observed from M54 and "computed properties' section is not available & no name displayed upon clicking id=cats" in M53 & M52 builds. "No settings are available in devtools even after enabling the flag". Hence marking this issue as untriaged & Confirming this issue to get more inputs from Dev team.

Please find the attached screencast of Canary for reference.
Thanks..

Deleted: 702811.mp4 1.2 MB

	702811.mp4 1.2 MB View Download

Mozilla has agreed to follow the Chrome model, and include aria-owns children in the accessible name. 

So now we have a consensus, and Chrome is getting it according to that.