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]
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
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
Reopening. @Joanmarie: Would settingh an AccessibleId for AT-SPI2 instead of setting an object attribute work, as suggested in comment 2?
(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.
(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.