[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #22 from Michael Weghorn --- (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.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #21 from [email protected] --- (In reply to cwendling from comment #20) > (In reply to cwendling from comment #19) > > 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. > > Actually thinking a bit more about it as focusing the images (and frames, > etc.) when browsing the document with the regular caret would be required > for proper interaction with them, so it might be best to leave the a11y > representation for them as it is, and allow the caret to reach them. > > 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 [email protected] changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=17 ||2423 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #20 from [email protected] --- (In reply to cwendling from comment #19) > 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. Actually thinking a bit more about it as focusing the images (and frames, etc.) when browsing the document with the regular caret would be required for proper interaction with them, so it might be best to leave the a11y representation for them as it is, and allow the caret to reach them. 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). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
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.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #18 from Michael Weghorn --- (In reply to Michael Weghorn from comment #17) > It's been a while that I started looking into this, but if I remember > correctly, this might need > > 1) adjusting the XAccessibleHyperText/XAccessibleHyperlink UNO API > interfaces to provide all relevant information > 2) adjusting existing implementations of those interfaces accordingly > 3) bridging interfaces properly to the corresponding platform/toolkit APIs And if I remember correctly, Qt doesn't have any public API for this yet, so making it work for qt6/kf6 vcl plugins as well might require some Qt upstream work as well. (But that could be handled separately, shouldn't block fixing it for other toolkits/platforms.) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #17 from Michael Weghorn --- (In reply to cwendling from comment #16) > This has serious impact on the accessibility of most embedded content > (images, frames, etc.). > > And although links more or less work as they are now (see comment 20 on > bug35107), but they are not standard and break as soon as something more > standard is present on the same paragraph/line (actually, if there's a > U+FFFC Orca's heuristics will fail). > > In practice, all of links, comments, images, frames, etc. will need to be > fixed to get properly reported by the Hypertext interface. > > @michealw would you know whether all these are ad-hoc implementations that > would all need to be fixed, or if there's a more generic place for this? It's been a while that I started looking into this, but if I remember correctly, this might need 1) adjusting the XAccessibleHyperText/XAccessibleHyperlink UNO API interfaces to provide all relevant information 2) adjusting existing implementations of those interfaces accordingly 3) bridging interfaces properly to the corresponding platform/toolkit APIs -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #16 from [email protected] --- This has serious impact on the accessibility of most embedded content (images, frames, etc.). And although links more or less work as they are now (see comment 20 on bug35107), but they are not standard and break as soon as something more standard is present on the same paragraph/line (actually, if there's a U+FFFC Orca's heuristics will fail). In practice, all of links, comments, images, frames, etc. will need to be fixed to get properly reported by the Hypertext interface. @michealw would you know whether all these are ad-hoc implementations that would all need to be fixed, or if there's a more generic place for this? --- 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. Anyone with knowledge regarding anchors is welcome to comment on why those anchoring methods should not (or should) lead to objects being children of a given paragraph. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 [email protected] changed: What|Removed |Added Depends on||141317 CC||[email protected] Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=141317 [Bug 141317] Screenreaders not announcing focus switch between frames (see comment 3) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Michael Weghorn changed: What|Removed |Added Blocks||163801 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=163801 [Bug 163801] Paragraphs unexpectedly implement the "selection" interface, states, and events -- You are receiving this mail because: You are the assignee for the bug.
[Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Joanmarie Diggs changed: What|Removed |Added CC||[email protected] --- Comment #15 from Joanmarie Diggs --- Michael: I just confirmed that what is described in the opening report is still an issue. The impact is that Orca says nothing for the embedded objects because it has no way of retrieving them. Orca needs to be able to retrieve the embedded objects via the Hypertext interface as Hyperlink objects. (Yes, I know the embedded objects are not links. The API is unfortunately named.) The embedded objects should implement the hyperlink interface so that Orca can retrieve the following: * The actual accessible objects * The start and end character offsets of the embedded objects with respect to their parent paragraph. Given that IA2 has similar interfaces, my guess is this bug also impacts NVDA. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #14 from QA Administrators --- Dear Joanmarie Diggs, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #13 from QA Administrators --- Dear Joanmarie Diggs, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #12 from Frans-Willem Post --- I can confirm this issue under Ubuntu 18.10. These are my specs: Version: 6.1.2.1 Build ID: 1:6.1.2-0ubuntu1.1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: nl-NL (en_US.UTF-8); Calc: group threaded -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #11 from QA Administrators --- ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Stéphane Aulery changed: What|Removed |Added CC||[email protected] See Also||http://bugs.debian.org/8728 ||11 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Alex ARNAUD changed: What|Removed |Added CC||[email protected] --- Comment #10 from Alex ARNAUD --- Dear all, This bug also affects images: they are not visible for screen reader users. Best regards. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Alex ARNAUD changed: What|Removed |Added CC||jean-philippe.mengual@libre ||office.org --- Comment #9 from Alex ARNAUD --- Dear all, The issue is still present on LibreOfficeDev 5.5 from 2017-05-30. Best regards. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 --- Comment #8 from QA Administrators --- ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Robinson Tryon (qubit) changed: What|Removed |Added Keywords||accessibility Whiteboard|a11y| --- Comment #7 from Robinson Tryon (qubit) --- Migrating Whiteboard tags to Keywords: (a11y -> accessibility) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 77679] [ACCESSIBILITY] Accessibility support for replaced objects is incomplete
https://bugs.documentfoundation.org/show_bug.cgi?id=77679 Cor Nouws changed: What|Removed |Added CC||[email protected] Summary|Accessibility support for |[ACCESSIBILITY] |replaced objects is |Accessibility support for |incomplete |replaced objects is ||incomplete -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
