https://bugs.documentfoundation.org/show_bug.cgi?id=163989

Michael Weghorn <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Michael Weghorn <[email protected]> ---
> 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

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to