Regarding Issues #841 and #1234, as well as PR #1100.

Currently the accessibility tree inclusion section includes this line:

[include in the accessibility tree…] "Elements that are focusable even if the element or one of its ancestor elements has its aria-hidden attribute set to true."

I had some prior concerns about including all "focusable" elements (even if hidden) versus including hidden elements at the time they became "focused." In #841, I originally suggested:

…include something like both "visible elements that are focusable" and ~"hidden elements if/when they become focused."

@carmacleod waited on @aleventhal and me to resolve this comment in PR #1100:

@aleventhal Are you good with this? Does it need to be more specific about whether or not it is exposed to the tree at the time that the element is focused?

And then I deferred and approved the PR:

We can address that in a follow-up issue. I don't think it needs to delay this one... Marking PR as Reviewed.

But I can't see that I filed the "follow-up issue" and don't see it linked... So filing this new one for more discussion.

This is coming up now because the implementation of this change in WebKit will cause a number of layout tests to fail... I think these are probably expected and can be updated, but I wanted to verify with @aleventhal, @joanmarie, and @carmacleod before it ships. IIRC the discussion from April 2020 correctly, the WG came to the consensus that the language "focusable" was intended, not the "only when focused" language originally proposed. I think that's probably correct, but wanted to point out that this makes it more difficult for authors to use aria-hidden to hide larger containers.

<div aria-hidden="true">
   <p>This paragraph text is hidden, but the <a href="#">link</a> is exposed to AT out of context.</p>
</div>

In order to hide that link (or any other focusable) from AT, the web author would need to do one of the following:

• explicitly add `tabindex="-1" on every focusable element in the "hidden" section (maybe this will work?)
• make the container unrendered (e.g. hidden="" a.k.a. display:none) instead of aria-hidden
• use inert="" on the container instead of aria-hidden

Another way to look at this, is that the ARIA change encourages incentivizes authors to use inert="" instead of aria-hidden="true"... This is probably the right call in the long term, but inert is not yet in WebKit.

Long story short... This may not be an issue. If everyone responds, "We're good", this can probably be closed.