Steps to reproduce: 1. Open a saved .ods file in Calc 2. Use the Accerciser accessibility inspector to examine the name of the parent of the table (has the document-spreadsheet role) Expected result: The name should not be the URL. Actual result: The name is the URL. Example: 'file:///home/jd/checkout/orca/test/documents/fruit.ods - LibreOffice Spreadsheets' Accessible names should be short and meaningful. Exposing the URL should be done via the Document interface and not the name. Impact: I'm on a mission to eliminate all of Orca's sad hacks. :) Currently Orca is special-casing this scenario. I plan to remove that in the near future, so it would be great if this could be fixed on the LO side of things.
Thanks for your bug report and sorry for coming up with a lot of questions for now. (In reply to Joanmarie Diggs from comment #0) > Expected result: The name should not be the URL. Do you have any suggestion what the name *should* be instead? > Accessible names should be short and meaningful. Exposing the URL should be > done via the Document interface and not the name. Can you point to a specification/documentation describing how to do that correctly? Looking at the XML spec of the AT-SPI Document interface [1], that interface has `GetAttributes` and `GetAttributeValue` methods which seem to be the most likely candidates, but what attribute name should be used? From what I can see, LO currently doesn't have an equivalent for the AT-SPI Document interface, and neither Gtk 4 nor Qt provide a way to do so, only Gtk 3 does (AtkDocument). From a first glance, I also didn't see anything equivalent for UIA or NSAccessibility/macOS, which might make it harder to argue that Qt should be adding an equivalent. Since I didn't have to do with it at all yet: Could object attributes for the document object be a potential alternative? (As described in bug 155447 comment 2 in more detail, Gtk 4 and Qt currently also don't currently seem to support object attributes, but my first impression is that it *might* be easier to argue for adding those, but I might be wrong.) > Impact: I'm on a mission to eliminate all of Orca's sad hacks. :) (...) That generally sounds like a great idea! :) And it also fits well with my plan to make LO more compliant with the platform specifications/expectations. :-) One of the main challenge I ran into so far is that I didn't find good documentation for the supported/expected attributes etc. for AT-SPI. For IAccessible2 there are [2] and [3]. Is there anything similar for AT-SPI? Or would it make sense to start something like this and properly document things, e.g. in the at-spi2-core repo where other documentation is being added? (What I did so far was mainly looking into what the gtk3 VCL plugin of LO and the Gtk library currently do, and what Orca does/expects, but it's IMHO not great to have to do that every time and the different implementations also don't always agree/match...) [1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/7cc4cee53ddbd22631fd110f0e5ce045dec2e411/xml/Document.xml [2] https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes [3] https://wiki.linuxfoundation.org/accessibility/iaccessible2/objectattributes
I asked for the AtspiDocument support here: https://gitlab.gnome.org/GNOME/gtk/-/issues/6197 The generic object attribute is here: https://gitlab.gnome.org/GNOME/gtk/-/issues/6196 Let's see what they say. Thanks!
(In reply to Joanmarie Diggs from comment #2) > I asked for the AtspiDocument support here: > https://gitlab.gnome.org/GNOME/gtk/-/issues/6197 > > The generic object attribute is here: > https://gitlab.gnome.org/GNOME/gtk/-/issues/6196 > > Let's see what they say. Thanks! Thanks!
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