https://bugs.documentfoundation.org/show_bug.cgi?id=163989
--- Comment #9 from Michael Weghorn <[email protected]> --- (In reply to Joanmarie Diggs from comment #0) > 1. The only reason I resorted to this is that I cannot find this text input > simply by examining the accessibility tree. So I figured it might have been > added somewhere unexpected. It turns out that this a problem with native GTK widgets inside VCL (i.e. non-native) toolbars. In the same way, e.g. the Paragraph Styles or Font Style comboboxes cannot be found in Accerciser's treeview of the LO a11y hierarchy. (There are panels, but the comboboxes inside the panels are missing.) Some logic to make native widgets within non-native ones work was added in commit 305c6fee0be4db38023d9ca5f7915e443e0bc1fc Author: Caolán McNamara Date: Wed Mar 24 11:33:42 2021 +0000 tdf#141197 if we have a sysobj child then include that in the atk hierarchy this also should make the case of an embedded video visible in the atk hierarchy as well as the target of the native gtk widgets in a vcl window container in the startcenter Change-Id: Ia91439cbccbffbb0badbfb466f7ab6d1ccbfe3ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113033 Tested-by: Jenkins Reviewed-by: Caolán McNamara , but the toolbar case is special and doesn't work (yet) because it's using comphelper::OAccessibleWrapper. With some experiments on a local branch (that still need to be turned into a proper solution), the objects show up in the a11y tree. The use case of > Expected results: clicking on "[text | ]" would cause Accerciser to show the > accessible object in the accessibility tree. to jump to the corresponding object still doesn't work with the search field in the "Find" toolbar with gtk3. It looks like that's due to some other brokenness/inconsistency somewhere in the a11y tree. -- You are receiving this mail because: You are the assignee for the bug.
