https://bugs.documentfoundation.org/show_bug.cgi?id=77679
--- Comment #22 from Michael Weghorn <[email protected]> --- (In reply to cwendling from comment #19) > Given the API name, I'd ideally break compatibility and have > XAccessible XAccessibleHyperlink::getAccessibleActionObject([in] long > nIndex) return the XAccessible object and a new > string XAccessibleHyperlink::getAccessibleActionURI([in] long nIndex) > or similar return the URI, if any. It's not necessarily an actual API break > given that the former "returns an implementation dependent value" (in the > form of an `any`), but it's definitely a change of behavior. > > However, if it's an issue to change any of these interfaces, we could add an > XAccessibleHyperlink2 (like there are XAcessibleContext2) and add a single > `XAccessible XAccessibleHyperlink2::getAccessibleActionTarget([in] long > nIndex)` or similar. Or a hybrid (more reasonable) solution that adds a > similar method to the existing interface without changing the meaning of the > current `XAccessibleHyperlink::getAccessibleActionObject()`. Changing the XAccessibleHyperlink interface in whatever ways makes sense is fine. It's unpublished API, only meant for internal use. (In reply to cwendling from comment #21) > > Should I report a separate issue for keyboard-navigating to images, frames > > and forms (and maybe others)? Actually it's not possible to interact with > > the ones anchored as character either in any natural way, the only upside > > would be that they could be announced together with the paragraph allowing > > the user to know they exist, but interaction would still be tricky > > (Navigator of Shift+F4 or similar, but no right click or such form the > > paragraph). > > I just opened bug#172423 to track this part of the issue. Whether it should > land back here or not can be decided over there. Sounds good, thanks! -- You are receiving this mail because: You are the assignee for the bug.
