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.