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?
Sounds like a reasonable request to look further into.
(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]