Bug 282117 – AX: USE(ATSPI) ports should consider walking the DOM to the build accessibility tree like non-ATSPI ports after https://bugs.webkit.org/show_bug.cgi?id=281749

• Status: NEW
• Component: Accessibility

[Tyler Wilcock]

After https://bugs.webkit.org/show_bug.cgi?id=281749, non-ATSPI ports walk the composed DOM tree to build the accessibility tree rather than the render tree, matching other browsers. This caused ~30 failures in the GTK test runners. Most of which are pretty innocuous, and in my opinion actually good things, since we eliminate useless AXSections that were created for uninteresting anonymous renderers.

However, I came across some tests that actually do expect anonymous renderers to be in the accessibility tree, e.g. accessibility/gtk/replaced-objects-in-anonymous-blocks.html. I'm not sure how to handle these ones, so I special-cased this new DOM walking behavior to be non-ATSPI with the hope that someone who is more familiar with GTK + ATSPI can help make the right decision here.

Searching for this bug's ID in the source should show all the places where we special-cased USE(ATSPI) to maintain existing behavior with https://bugs.webkit.org/show_bug.cgi?id=281749. Please feel free to start a chat with me over email or the WebKit Slack if you'd like to discuss this one.

[Radar WebKit Bug Importer]

<rdar://problem/138664720>

[Tyler Wilcock]

Note that while searching for https://bugs.webkit.org/show_bug.cgi?id=282117 in the source will lead to all interesting areas for resolving this bug, your evaluation may be that the #if USE(ATSPI) branch should stay — feel free to remove the associated FIXME in that case.

[Tyler Wilcock]

I wonder how Firefox and Chrome handle these anonymous renderers that we expect in the hierarchy — I believe they build their accessibility trees by primarily walking the DOM instead of the render tree, too.

[Mike Gorse]

I looked at the history of replaced-objects-in-anonymous-blocks.html, and it was added as part of https://bugs.webkit.org/show_bug.cgi?id=95180. The bug was fixing the reported text being incorrect, so I'm not sure if that test would be relevant anymore if this change is made.

But I tried removing the clauses that mention this bug and running the tests, and I also see other failures; aria-activedescendant-changed-notification.html appears not to be generating events, for instance. This seems strange, so I'm wondering if I missed something when making my build.

[Tyler Wilcock]

Hey Mike! Yeah, I got a lot of failures when removing these clauses too — for some of them I think it's just a matter of rebasing the test expectations, but I think there are also legitimate behavioral bugs (as you found with aria-activedescendant-changed-notification.html) this would introduce without additional implementation changes. Georges Stavracas (already cc'd on this bug) was looking into this a while ago, and we had a discussion on the WebKit Slack that is helpful context for anyone investigating this:

https://webkit.slack.com/archives/CU64U6FDW/p1733318329391229