Bug 155447

Summary:	Add accessible object attributes to LO spellcheck dialog components for reliable identification by ATs
Product:	LibreOffice	Reporter:	Joanmarie Diggs <jdiggs>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	UNCONFIRMED ---
Severity:	enhancement	CC:	m.weghorn
Priority:	medium	Keywords:	accessibility
Version:	unspecified
Hardware:	All
OS:	All
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=135236
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	101912

Description Joanmarie Diggs 2023-05-23 11:05:44 UTC

Description:
Orca has customized presentation for application spell-check dialogs:
* Announces the misspelled word, along with its spelling
* Announces the surrounding text for context
* Announces the current suggestion from the suggestion list, along with its spelling

Because there is no spellcheck-specific accessibility API, Orca has fragile heuristics to identify:
* Whether or not the current window/dialog is the spellcheck dialog
* The widget containing the misspelled word
* The suggestion list

Changes in the LO spellcheck dialog can -- and do -- break those heuristics. :( And there is also the danger of false positives....

Under the circumstances, here is my proposal to make things a bit better, both for Linux and for Windows: Add accessible object attributes to the LO spellcheck dialog components so that ATs could identify them. For instance:

* On the dialog: is-spellcheck-dialog:true
* On the suggestions list: is-suggestions-list:true
* On the widget displaying the error: contains-error:true

Mind you, I don't care what the object attributes are as long as they are predictable. :) And maybe after LO does this, we can convince Thunderbird and Evolution and Gedit/Pluma and ... to use whatever those attributes happen to be.

Because IA2 also has object attributes, NVDA, JAWS, etc. should be able to also benefit from this solution.

Steps to Reproduce:
1. Create a document with misspelled words
2. Launch Orca (version 44.0 or earlier)
3. Press F7 for the spellcheck dialog

Actual Results:
Orca fails to announce the misspelled word, its spelling, the text surrounding the error, the suggested correction, etc.

Expected Results:
Orca would announce the misspelled word, its spelling, the text surrounding the error, the suggested correction, etc.

Reproducible: Always

User Profile Reset: No

Additional Info:
Apparently the spelling dialog has changed:

* The role of the window firing the window activate event
* The role of the error-message widget
* The role of the suggestions list widget
* The events fired when a suggestion has been accepted or ignored and a new error presented
* Maybe other things?

Comment 1 Michael Weghorn 2023-05-26 03:12:52 UTC

Sounds like a reasonable request to look further into.

Comment 2 Michael Weghorn 2023-10-19 09:11:24 UTC

(In reply to Joanmarie Diggs from comment #0)
> Under the circumstances, here is my proposal to make things a bit better,
> both for Linux and for Windows: Add accessible object attributes to the LO
> spellcheck dialog components so that ATs could identify them. For instance:

From what I can see, neither Gtk 4 nor Qt currently support setting object attributes, but always return an empty set (Qt, [1]) or only report a very limited set of predefined ones (Gtk 4, [2]).

I'm hesitant to implement something that only works for gtk3, so I tend to think that implementing support in Gtk 4 and Qt would be a prerequisite in case of depending on those attributes being present.

Maybe, an alternative might be to use the "AccessibleId" property of the Accessible interface to identify it, and set that to the "id" attribute as specified in the .ui file (cui/uiconfig/ui/spellingdialog.ui), currently (but that could be adapted as needed):

* "SpellingDialog" for the dialog
* "suggestionslb" for the suggestions list
* "sentence" for the widget displaying the text/error

I haven't looked into that in detail yet, but from a first glance, it looks like that should be doable with Gtk 3 and Qt (which uses the "full hierarchy path" for the AccessibleId, so would probably have something like "SpellingDialog.<parent1>.<parent2>.<parent3>.suggestionslb", but that could be handled on Orca side.

Gtk 4 currently always reports an empty AccessibleId, but I could come up with a MR suggesting to use the "buildable_id", which to me seems to fit with the idea of what AccessibleId is there for.

>     <!--
>         AccessibleId: application-specific identifier for the current object.
> 
>         You can use this to give a special id to an object to use in tests, for example,
>         "my_widget".  Note that there is no way to directly find an object by its id; your
>         test program may have to recursively get the children to find a specific id.  This
>         is because accessible objects can be created dynamically, and they do not always
>         correspond to a static view of an application's data.
>     -->
>     <property name="AccessibleId" type="s" access="read"/>

For IAccessible2, that could still be mapped to an "accessible-id:<id>;" atttribute or somesuch if considered useful.

@Joanmarie: What do you think? Would that be helpful?


[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/accessible/linux/atspiadaptor.cpp?id=546208f0ff23819d216cbb5bf0b5daded79b454e#n1608
[2] https://gitlab.gnome.org/GNOME/gtk/-/blob/7325121c63e5ab54d6cea483f932b60224146061/gtk/a11y/gtkatspicontext.c#L524-544
[3]

Comment 3 QA Administrators 2024-05-06 03:15:09 UTC Comment hidden (obsolete)

Dear Joanmarie Diggs,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping

Comment 4 QA Administrators 2024-06-06 03:17:29 UTC Comment hidden (obsolete)

Dear Joanmarie Diggs,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp

Comment 5 Michael Weghorn 2024-06-06 12:12:46 UTC

Reopening.

@Joanmarie: Would settingh an AccessibleId for AT-SPI2 instead of setting an object attribute work, as suggested in comment 2?

Comment 6 Joanmarie Diggs 2024-06-06 15:24:58 UTC

(In reply to Michael Weghorn from comment #5)
> Reopening.
> 
> @Joanmarie: Would settingh an AccessibleId for AT-SPI2 instead of setting an
> object attribute work, as suggested in comment 2?

Maybe.... 

I don't know how other apps or toolkits are using an AccessibleId. Whatever solution is agreed upon, I'd like it to be something that everyone uses. But given this statement:

> You can use this to give a special id to an object to use in tests

It sounds like API specifically for tools/uses that are NOT screen readers.

Comment 7 Michael Weghorn 2024-06-11 15:05:37 UTC

(In reply to Joanmarie Diggs from comment #6)
> I don't know how other apps or toolkits are using an AccessibleId. Whatever
> solution is agreed upon, I'd like it to be something that everyone uses.

That sounds reasonable. I'd also prefer having a more widely used solution rather than something LO-specific.
Do you know what's the best way to find a consensus on something that would be used more widely?

> But
> given this statement:
> 
> > You can use this to give a special id to an object to use in tests
> 
> It sounds like API specifically for tools/uses that are NOT screen readers.

I don't  think this is set in stone, and the doc for the ATK equivalent is not restricted to testing either, so I think it makes sense to adjust the AT-SPI XML documentation as well. Pending MR:
https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/161

From an implementation perspective, using the AccessibleId would IMHO have the advantage that it wouldn't require introducing new object attributes and there's already existing API to easily set that for ATK, GTK 3 and Qt at least.