https://bugs.documentfoundation.org/show_bug.cgi?id=77679
--- Comment #19 from [email protected] --- > 1) adjusting the XAccessibleHyperText/XAccessibleHyperlink UNO API > interfaces to provide all relevant information Thanks. Indeed there's gonna be a need to be able to report both the URI(s) and the accessible object(s). Currently there's only any XAccessibleHyperlink::getAccessibleActionObject([in] long nIndex) that, despite it's name, is used to return the URI as a string. It should either start returning XAccessibles (or the objects from which it is possible to get the XAccessible) that also provide a mean of getting the URI, or the XAccessibleHyperlink interface extended to be able to report both. IAccessible2 for example does the latter (separate methods). 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()`. > 2) adjusting existing implementations of those interfaces accordingly > 3) bridging interfaces properly to the corresponding platform/toolkit APIs At least for the GTK3 VCL at a glance it looks like it would be reasonably easy. --- (In reply to cwendling from comment #16) > Also, there's a different but related challenge for objects embedded as > anything but "as character": although they are present in the a11y tree at > the same level as paragraphs (not embedded), navigation do not reach them > moving through the document, meaning the user never reach them unless > explicitly navigating them. > > I'm not actually sure why those type of anchors do not link the objects to > the paragraphs, given anchoring "to character" or "to paragraph" seem to > still closely relate to paragraphs, doesn't it? In any case, this should > also be changed, either by navigating to the objects (e.g. sending focus > event to them) or by embedding them to the relevant paragraph so it's part > of something that gets focused during regular document navigation. Can anybody give some insight or opinion here? As it is I don't see a real reason why it's not actually linked to the paragraph, and the simple solution would be to treat it as any other embedded content: * have a placeholder in the paragraph for it * link the relevant XAccessible through XAccessibleHypertext and XAccessibleHyperlink (that part is currently missing in LO). I don't think there is a need API-wise to actually have the target XAccessibles as children of the paragraph, so that part could potentially even stay as it is (those images/frames/etc currently are siblings of the paragraph). Again, the other solution would be to have the images get focused through caret movement while browsing the document (and that would probably be easier to also simplify interacting with those using the keyboard), but that might be harder to pull off. What do you think? -- You are receiving this mail because: You are the assignee for the bug.
