Steps to reproduce: 1. Launch Writer 2. Press Ctrl+F and type "foo" 3. Launch Accerciser and turn on event monitoring for object:text-caret-moved events for soffice 4. Return to the find entry and left/right arrow among the letters in "foo" 5. When Accercisershows events for the text input, click on "[text | ]" Expected results: clicking on "[text | ]" would cause Accerciser to show the accessible object in the accessibility tree. Actual results: clicking on "[text | ]" does nothing. Notes: 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. 2. If you're curious, repeat the steps above, but just write "foo" in the document. When you click on "[paragraph | ]" in the resulting event, you're brought to that object in Accerciser. 3. There doesn't yet appear to be any impact (at least not in Orca's main branch). That might change depending on later sanity checks being added to Orca. 4. As the selection in the document changes due to interactions within the find input, a notification is firing the "showing" event causing Orca to say "notification". But there's no presentable information in the accessible object for Orca to present. Michael: Could you please look into both issues? The announcement of "notification" is annoying/pointless to users. Related aside: I'm trying to add generic/global support for presenting find-in-page/document results. If presenting the new document location is what the notification is attempting to address, let's talk because there's a different way this should be done, at least in the case of Orca. (New app developer docs are on my todo list. :))
> Expected results: clicking on "[text | ]" would cause Accerciser to show the > accessible object in the accessibility tree. > > Actual results: clicking on "[text | ]" does nothing. For me, clicking on the object does highlight the correct area of the text box on screen, but doesn't select the item in the tree view, which usually means that something is inconsistent in the a11y tree. For gtk3, printing the hierarchy bottom-up (i.e. starting from the text box) in Accerciser's IPython console gives this: In [2]: obj = acc In [3]: while obj: In [3]: print(f'object: {obj}, index in parent: {obj.get_index_in_parent()}') In [3]: obj = obj.parent In [3]: object: [text | ], index in parent: 0 object: [combo box | ], index in parent: 0 object: [filler | ], index in parent: 0 object: [panel | ], index in parent: 0 object: [viewport | ], index in parent: 0 object: [scroll pane | ], index in parent: 3 object: [root pane | Untitled 1 — LibreOfficeDev Writer 25.2 [80d4ce197f2b9b38ce6af6ed18eb159edd24be5f]], index in parent: 0 object: [panel | ], index in parent: 1 object: [panel | ], index in parent: 0 object: [frame | Untitled 1 — LibreOfficeDev Writer 25.2 [80d4ce197f2b9b38ce6af6ed18eb159edd24be5f]], index in parent: 0 object: [application | soffice], index in parent: -1 object: [desktop frame | main], index in parent: -1 Trying to go this path in reverse order (i.e. starting at the application) looks OK until reaching the object: [root pane | Untitled 1 — LibreOfficeDev Writer 25.2 [80d4ce197f2b9b38ce6af6ed18eb159edd24be5f]], index in parent: 0 object, but that one doesn't have any "[scroll pane | ]" child in the tree view. That will need further investigation. > 4. As the selection in the document changes due to interactions within the > find input, a notification is firing the "showing" event causing Orca to say > "notification". But there's no presentable information in the accessible > object for Orca to present. > > Michael: Could you please look into both issues? The announcement of > "notification" is annoying/pointless to users. > > Related aside: I'm trying to add generic/global support for presenting > find-in-page/document results. If presenting the new document location is > what the notification is attempting to address, let's talk because there's a > different way this should be done, at least in the case of Orca. (New app > developer docs are on my todo list. :)) Possibly related commit: commit 97d3d4f371f82704dba907975e6cfdaac456fe4d Author: Heiko Tietze Date: Fri Sep 15 14:23:50 2023 +0200 Resolves tdf#156227 - More appealing feedback for find/quickfind ErrorMessageType removed in favor of an infobar-like label Accessibility notification added for the quickfind bar The notification seems to be for the object (label?) that displays "Search key not found" etc., as I see this after pressing enter: 82.0 object:state-changed:showing(1, 0, 0) source: [notification | Search key not found] application: [application | soffice] The idea there seems to follow a similar pattern to the equivalent label in the "Find and Replace" dialog, as added there in commit commit 947fe0d89dee75ee43515ef7dfb43837d65a45bc Author: Jim Raykowski Date: Thu Sep 8 19:27:31 2022 -0800 tdf#119788 tdf#117173 add accessibility NOTIFICATION role and use it to make screen readers announce notifications from the 'Find and Replace' dialog That was discussed in tdf#117173 which also refers to an Orca issue and merge request, but GNOME Gitlab seems to be non-functional right now... In any case, I agree that having a state-changed:showing(1, 0, 0) event for a notification with no useful text doesn't sound like a good idea. Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 80d4ce197f2b9b38ce6af6ed18eb159edd24be5f CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
(In reply to Michael Weghorn from comment #1) > In any case, I agree that having a state-changed:showing(1, 0, 0) event for > a notification with no useful text doesn't sound like a good idea. Sending that event also when the label is empty happens since commit 48ba98a51f029cd14b5d982dab36eb581d40fef3 Author: Heiko Tietze Date: Wed Nov 29 14:29:57 2023 +0100 Resolves tdf#158412 - Don't show chevron in quick find bar https://gerrit.libreoffice.org/c/core/+/177523 is a potential fix to restore the previous behavior, but I don't know the involved code/logic for the search bar that well, so maybe Heiko has more thoughts there. A potential alternative might be to stop using the notification a11y role for that label and relying on the object:state-changed:showing event for that label for it to be announced and use an Announcement event directly, which was added to AT-SPI2 in https://gitlab.gnome.org/GNOME/at-spi2-core/-/commit/26835da29918be2c0da6c08fb70d893de22891d2 That would basically move the logic on when to (not) announce from Orca to LibreOffice itself. @joanie: Would using object:announcement be preferred over the current object:state:changed:showing logic or better to leave as is (and leave it to the screen reader to decide whether or not to announce the label text)?
We had the discussion on https://gerrit.libreoffice.org/c/core/+/156943; your patch does not changes much so +1 if it works.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f5dfd3986e9c51b5e33b58d6acb0629e19e5d00 tdf#163989 a11y: Avoid "showing" event on empty notification label It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Heiko Tietze from comment #3) > We had the discussion on https://gerrit.libreoffice.org/c/core/+/156943; > your patch does not changes much so +1 if it works. Thanks. Merged now to git master. Backport for 24-8 pending in Gerrit: https://gerrit.libreoffice.org/c/core/+/177535 The other issue (broken a11y tree) is still open.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/e0cedca04770e19b9de177bfc660387fc2bd0bae tdf#163989 a11y: Avoid "showing" event on empty notification label It will be available in 24.8.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #1) > For me, clicking on the object does highlight the correct area of the text > box on screen, but doesn't select the item in the tree view, which usually > means that something is inconsistent in the a11y tree. > > For gtk3, printing the hierarchy bottom-up (i.e. starting from the text box) > in Accerciser's IPython console gives this: > > [...] For qt6, the a11y hierarchy is broken in a different way (objects are consistent bottom-up and top-down, but one child index is wrong), which also breaks the Accerciser highlighting feature. More details in the commit message of the pending fix: https://gerrit.libreoffice.org/c/core/+/182371 However, the gtk3 issue is a different one and remains.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/57cb96439adc022768fb279f2d2ab33a392a9f80 tdf#163989 toolbar item window a11y: Leave wrapped accessible in place It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ef30632ede4258f0c45194259567849cc172dab tdf#163989 a11y: Introduce Window::GetAccessibleParent It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/827da8833cccda2b51f99eb0257be8ee68232899 tdf#163989 vcl a11y: Don't rely on Window a11y parent being Window It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/39e0bdb686baf76a4c54d12cfa66aa9f08db8c3f tdf#163989 vcl a11y: Rework toolbar item window a11y It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #9) > 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. That's implemented by the commits from comment 10 to comment 12 now. > 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. That's still open.
(In reply to Michael Weghorn from comment #13) > > 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. > > That's still open. Pending https://gerrit.libreoffice.org/c/core/+/182992 finally makes that work for me.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4465cd882891caae22cf059e5b44f9642dc6d76f tdf#163989 gtk3 a11y: Set a11y parent for native GTK vcl::Window child It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.