User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

1. Open the APG File Directory Tree View Example: https://w3c.github.io/aria-practices/examples/treeview/treeview-1/treeview-1a.html

2. Inspect the Accessibility Tree of one of the expandable treeitems, for example, the one labelled "Reports". Notice that the accessible name of this treeitem is "Reports" (correct).

3. Now expand the "Reports" treeitem. Notice that the accessible name changes to "Reports report-1 report-2 report-3" (incorrect).

Actual results:

The markup for an expandable treeitem in this example simplifies to the following:

<li role="treeitem" aria-expanded="true" tabindex="0">
Reports
<ul role="group">
<li role="treeitem" tabindex="-1">report-1</li>
<li role="treeitem" tabindex="-1">report-2</li>
<li role="treeitem" tabindex="-1">report-3</li>
</ul>
</li>

Firefox appended the entire text content of the group child ("report-1 report-2 report-3") to the accessible name of the treeitem.

If the user is running a screen reader, reading the entire content of each expanded treeitem can get very verbose.

Expected results:

The accessible name of an expanded tree node should not contain the content of its group child.

Note that this bug is similar to bug 726931 however that bug has different (potentially invalid?) markup, whereas this bug that I am opening today shows the problem in a valid ARIA tree.

First and foremost, I totally agree this is bad for users and not desirable. That said, I don't see anything in the Accessible Name and Description Computation spec that precludes this behaviour. When calculating name from content, it doesn't seem to exclude any descendants; see 2H. So, we might need to fix the spec here too. The question is what the rule should be to preclude this.

Note that before bug 1616851, this probably wouldn't have happened, since groups weren't allowed to participate in name calculation. However, that fix was necessary to fix other problems.

Agree that ACCNAME needs to help out here, and I believe the relevant issue is ACCNAME 7.

However, please note that Chromium and Safari work correctly with this example, so please don't wait for ACCNAME.

The ARIA spec for treeitem says:

Authors MUST ensure elements with role treeitem are contained in, or owned by, an element with the role group or tree.

so it's pretty clear that you can exclude group descendants when calculating a treeitem's name.

Also, the new Naming with Child Content section in the APG says the following:

When calculating a name from content for an element, user agents recursively walk through each of its descendant elements, calculate a name string for each descendant, and concatenate the resulting strings. In two special cases, certain descendants are ignored: group descendants of treeitem elements and menu descendants of menuitem elements are omitted from the calculation.

So I think there's enough spec language already available to comfortably make this change.

Regarding bug 1616851, I'm confused about listitem naming in general. I'll look into it more, and discuss in ARIA 1117 because I don't want to take over this bug with that discussion.

For now, please note that:

• the ARIA spec for listitem doesn't have name from content - only name from author
• the Chromium implementation doesn't add the listitem content as the accessible name until after the script adds tabindex to the listitem and focuses it (i.e. after the user presses n or p)

Confirmed that bug 1616851 regressed this.

https://hg.mozilla.org/mozilla-central/rev/54aff812a50b

Backed out as requested by jya.

Backout link: https://hg.mozilla.org/integration/autoland/rev/ad11f747fb54b140a8959e35a487305392f6e57e

Backout got merged: https://hg.mozilla.org/mozilla-central/rev/ad11f747fb54

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0eddaaf7677ab4f5d49d7d3aaccf198af24bd954

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
If yes, don't forget to request an uplift for the patches in the regression caused by this fix.

For more information, please visit auto_nag documentation.

https://hg.mozilla.org/mozilla-central/rev/0c1640b5d951

Not a new issue in Fx79. Given where we are in the cycle, let's let this fix ride Fx80. I'm still open to eventually taking this on ESR78 if we don't want to live with this bug there for its entire lifecycle.

AFAIK this hasn't had any issues reported against it. Is this something we wanted to fix on ESR78 still?

Comment on attachment 9162713 [details]
Bug 1650462: Don't include group descendants when calculating the acc name of treeitems.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Incorrect accessibility for some web content.
• User impact if declined: Incorrect label reported by screen readers for certain multi-level tree controls on the web.
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Only affects a11y name calculation. Covered by tests. Baked on nightly, beta and release with no reported issues.
• String or UUID changes made by this patch: None.

Comment on attachment 9162713 [details]
Bug 1650462: Don't include group descendants when calculating the acc name of treeitems.

a11y fix, approved for 78.3

https://hg.mozilla.org/releases/mozilla-esr78/rev/351ecbf2ae5a