Using screenreader NVDA the cooidinates announced in LibreOffice are unsuable because only towonly two numbers are announced without description what thes numbers are saying.
Steps to Reproduce:
1 Open Writer.
2. Working with screenreader NVDA hit NVDA + Delete.
The Screeader announces a two part number, withou anyone knoing what this is about to be.
A clear position shound be announced (lef, right, high and low) position should be announced.
User Profile Reset: Yes
OpenGL enabled: Yes
Using NVDA 2020.2
Using Windows 10, LibreOffice 7.0 and NVDA 2020.2 the problem still occurs.
My exact operating system information:
Edition Windows 10 Home
Operating system build 18363.1016
Version: 18.104.22.168 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Corresponding issue in NVDA issue tracker: https://github.com/nvaccess/nvda/issues/11696
Pasting my comment from https://github.com/nvaccess/nvda/issues/11696#issuecomment-1463575359 :
From a first analysis, I haven't seen any way to expose/retrieve the information at what position in the page the cursor currently is via the accessibility interfaces (`IAccessible2` in the case of LibreOffice).
The `IAccessibleComponent` interface has a way to [get the position in pixels relative to the parent](https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_component.html#a8709fdbf3f51ae079af274854a8bffd4) , but that's not really helpful here. From a first look, the Writer page itself also has no a11y object in the a11y tree.
What NVDA seems to do for MS Word is to use the Microsoft Office COM API to interact with MS Office, not the accessibility APIs:
It queries for the `wdHorizontalPositionRelativeToPage` and `wdVerticalPositionRelativeToPage` attributes described here:
This page has some more infos on using the COM with NVDA and Word:
So if there's no way to retrieve the information via the accessibility APIs, I see no "easy" way of implementing this to work with LibreOffice Writer as well.
What *might* work is to not use the accessibility APIs, but LibreOffice's UNO API (which also has a Python binding), but adding support for doing this would presumably be quite a lot of work.
Possibly, there are ways to retrieve the required information (or retrieve information from which the position in the page could then be calculated). Potentially helpful UNO interfaces might be (but that would need a closer look):
* `XTextViewCursor::getPosition()` to retrieve cursor pos relative to top left position of the first page of the document
* `XPageCursor::getPage()` can be used to retrieve the page that the cursor is currently on
* `offapi/com/sun/star/style/PageProperties.idl` to access properties of the page,...
Looking into the implementation of `SwXTextViewCursor::getPosition` (which is the LO-internal implementation of one of the interfaces) might give some more ideas.
If that's an approach to investigate further, it would probably be a good idea to start with a macro to run from within LO to see whether it's possible to calculate the position from the information accessible via the UNO API.
Based on the analysis in comment 3, I currently see nothing that can be done on the LO side, so I'm closing this as NOTOURBUG and suggest to keep tracking this in the corresponding NVDA issue for now:
From what I can see, LO generally seems to do "the right thing" according to the IAccessible2 specification, and reports the coordinates in screen pixels.
If there are any further insights or information I have missed in my analysis or it turns out that something else is needed on LO side, this can of course be reopened.
*** Bug 154149 has been marked as a duplicate of this bug. ***
(In reply to Michael Weghorn from comment #4)
> Based on the analysis in comment 3, I currently see nothing that can be done
> on the LO side, so I'm closing this as NOTOURBUG and suggest to keep
> tracking this in the corresponding NVDA issue for now:
> From what I can see, LO generally seems to do "the right thing" according to
> the IAccessible2 specification, and reports the coordinates in screen pixels.
> If there are any further insights or information I have missed in my
> analysis or it turns out that something else is needed on LO side, this can
> of course be reopened.
See the further discussion in the NVDA issue, including a quick demo in https://github.com/nvaccess/nvda/issues/11696#issuecomment-1465006145 : Custom attributes for the document object might be a way to move forward.
-> Reopening this ticket to keep track of this.
*** Bug 140732 has been marked as a duplicate of this bug. ***
Based on the discussion in the NVDA issue, I have now submitted a change to LibreOffice's Gerrit and a PR For NVDA with a potential implementation:
Now waiting for feedback/suggestions on these.
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":
tdf#136760 sw a11y: Provide page-relative cursor pos via doc attr
It will be available in 7.6.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Both, the NVDA pull request as well as the LibreOffice change have been merged now, so a page-relative position is reported in Writer when using the current development versions of LibreOffice and NVDA.
Example for a locale that uses imperial units:
"cursor positioned 0.79 inches from left edge of page, 0.79 inches from top edge of page"
Otherwise, centimetres are used instead of inches.
-> Closing as FIXED