https://bugs.documentfoundation.org/show_bug.cgi?id=168409
--- Comment #6 from Michael Weghorn <[email protected]> --- (In reply to Jean-Pierre Ledure from comment #5) > > Please note that the accessibility UNO API is unpublished and for > > LibreOffice-internal use only and subject to change by design. It is not > > meant to be used by third party code like macros or extensions, so anything > > that relies on it never had any guarantee to keep working. > > Hmm ... Can you give pointers to that statement ? Commit that explicitly unpublished UNO accessibility API: https://git.libreoffice.org/core/+/70626249cd247d9acdad417b8eaf252bae22c059 There is a corresponding release note entry for 4.0 ( https://wiki.documentfoundation.org/ReleaseNotes/4.0 ). Quoting from that one: > * Deprecation and un-publishing of internal accessibility API > * This API was primarily used internally for our bridge implementations to > native accessibility technology APIs, and will need adapting in future. > > The following UNO services and interfaces are no longer published: > [long list of all UNO a11y interfaces and services] (In reply to Jean-Pierre Ledure from comment #5) > (https://api.libreoffice.org/docs/idl/ref/ > servicecom_1_1sun_1_1star_1_1accessibility_1_1AccessibleContext.html is > silent about such a limitation.) In general, any API that is not marked as "published" is unpublished and considered for internal use. See also tdf#163747 for more details. Unfortunately, the distinction apparently hasn't been clear to many users of the API in practice. (We generally try to avoid changing even unpublished API "for no reason" if there is a fair chance of it being used in practice, but I don't see keeping UNO a11y API as something feasible going forward. Those uses of the API I have become aware of so far were actually unrelated to the intention of the API, i.e. not directly related to accessibility in the first place.) > I understand perfectly your intent. > Note however that the release notes also are silent about this API change. See above for the corresponding release note entry for 4.0 when the API was unpublished. (For what it's worth: Technically, the commit mentioned in comment 2 also didn't change the API itself, only the implementation detail on what object implements the relevant logic, with further changes done in later commits.) > > Please try to find an alternative to using the UNO accessibility API - and > > feel free to create a new feature request (with clear requirements + use > > case) in case you're missing specific API. > > As a use case, consider next example that ran smoothly in LO 25.2 and > before, and aborts in LO 25.8: > https://gitlab.com/LibreOfficiant/scriptforge/-/snippets/4874248 > The demand is simply: which are the (push)buttons in a toolbar, their > coordinates and the commands associated with a click ? > Is this stored elsewhere in a UNO instance ? I'm not particularly familiar with extension or macro development and don't have any particular API in mind. > Thanks for helping me to find a workaround. For the current development version (git master), what could possibly work as a temporary workaround is using the same approach that the Java accessibility tests currently use to get access to the XAccessible/XAccessibleContext by using the deprecated XVclWindowPeer interface and its XVclWindowPeer::getProperty method to request the "XAccessible" property, see commit d1a25112bbbe3eb8e1c86840cb853e1694ec96ba Author: Michael Weghorn Date: Wed Jun 18 17:49:48 2025 +0200 java a11y tests: Don't rely on XWindow being XAccessible and its commit message for more details. But please be aware that this can only be seen as a temporary workaround, as that would still rely on accessibility implementation details that are subject to further changes in the future. As far as I can see, this commit is also not included in the 25-8 branch, but if such a temporary workaround is desirable for now to give more time for finding a better solution, making that approach available for 25.8 as well could be investigated. What do you think? -- You are receiving this mail because: You are the assignee for the bug.
