Comment 1 by jteh on 2014-08-30 08:58
This is due to a bug in OpenOffice, but I'll need to figure out exactly what this is and report it.

@jcsteh indicates in #4431 (comment) that the reported issue is an Open Office bug. Does this still occur in the latest version of OO, and if so, has this already been reported to OO developers? It is also worth noting that Open Office development status, as displayed by Wikipedia, is currently moribund.

I can't reproduce the blank or page number behaviour described in LibreOffice. I can reproduce the problem with the entire number being reported for numbers with decimal points, though. That needs to be fixed in LibreOffice. Technical: Word offsets span the entire number, even though control+right/leftArrow stop at each number and each decimal point.

I don't have OpenOffice to test with at present, but given the almost dead nature of OpenOffice development, I don't think it's worth pursuing it anyway.

@Laughingthunder is this still reproducible?
@Qchristensen, @jcsteh can anyone reproduce it? Do you have any updates on open Office development? If it is not worthy to Keep working on this due to discontinued development on Open Office, then I suggest to Close this issue.

If the issue still occurs inh Libre Office, then let's Keep the issue open and maybe someone starts working on it.

It does still occur. It looks like their IA2 API is exposing offsets according to Uniscribe while in practice, they are using own logic that is more likely to NVDA's non-uniscribe calculation of word offsets that breaks on non-alphanumerics.

CC @codeofdusk

@LeonarddeR can you still reproduce the original issue? When I try in LibreOffice 6.1.3.2 or Open Office 4.1.6 with NVDA 2018.4.1, my experience is the same as Jamie's a year ago, that is, I can't repro the blank report, but numbers with decimal points get read all at once, even though moving by word stops at each full stop.

The decimal number issue is still reproducible in both open office 4.1.6 and libre office 6.2.2 with NVDA 2019.1.
All other isues "reporting blank" and "reporting page number" are not reproducible anymore.

Did anyone report the issue regarding decimal numbers to Libre office or open office?

cc: @michaelweghorn is there already an issue for this in the document foundation bug tracker for Libreoffice? I can still reproduce the issue with LO 24.2 where NVDA pronounces the entire number when using ctrl+left an right arrow although the caret stops at the decipal point or comma. Se comments above for technical reasoning.
In MS Word and other editors NVDA treats every sign as single word i.e. dash or underline or dot etc. when navigating word by word.

@Adriani90 I'm not aware of a corresponding bug report in LibreOffice Bugzilla.

#4431 (comment) says:

I can reproduce the problem with the entire number being reported for numbers with decimal points, though. That needs to be fixed in LibreOffice. Technical: Word offsets span the entire number, even though control+right/leftArrow stop at each number and each decimal point.

This sounds similar to #15436 which was fixed on NVDA side in #15558 - see the PR description for more details.

If I remember correctly, LibreOffice internally uses the ICU library to determine word boundaries when queried via the IAccessible interface, but the Ctrl+Right jump is determined differently.
At least my first thought is that it's probably not desirable here to align with what Word does, because:
ICU presumably implements what the Unicode standard defines for word boundary handling, see https://unicode-org.github.io/icu/userguide/boundaryanalysis/#word-boundary and https://www.unicode.org/reports/tr29/#Word_Boundaries (the former references the latter). In the example in that specification, "32.3" is considered a single word, which matches with LibreOffice returning that as a single word, and seems "correct" to me, rather than reporting "32" and "." and "3" as single "words".

In my understanding, that leaves the option of considering to adjust what Ctrl+Right etc. do, and let them adhere to the same definition of a word, i.e. jump over the whole word, not just up to the next ".", for example.
That would probably have both, advantages and disadvantages, depending on the scenario/use case (not only a11y ones). Feel free to open a bug report at https://bugs.documentfoundation.org/ for further consideration.

An alternative might be to make NVDA aware of the difference, and not report the whole word, but only the same part of it as Ctrl+Right jumps. (At least for the sample sentence used in here or the Unicode spec sample, I think reading out "32.3" when jumping just before the word is more meaningful, though.)

Thanks for the good information @michaelweghorn. I understand the reason why number separators and number between them as well as decimal numbers are not treated as single words for numbers lower than 1,000 and this should not be changed in LO. However, MS Office in general does actually improve the user experience from an accessibility point of view for long numbers, I give an example below. Just for further note, Firefox does the same.
In contrast, Libreoffice like word handling is broader met in practice, i.e. all edit fields in Windows such as powershell, run dialog, browsers such as Chromium browsers, Opera etc.

Let's take this number as an example:
2,100,002,312,234,546.553432
Which is basically 2.1 quadrillion. I have to do alot with such figures during my job as an analyst for example when reading relevant financial document or climate carbon accounting calculations.
The screen reader does not pronounce it as being in the quadrillion range, so I just hear a lot of numbers in a row and I have to build my own assumption on which range this figure could be to write something more readable out of it.
Ofcourse I could navigate character by character and count the numbers, but navigating numbers separator by separator makes this job a lot easier, also when I want to adjust single digits within the number.

Note that separators are also useful for sighted people when reading long numbers, so we should try to give blind users the same experience where possible when navigating word by word.
If there are no separators, we have to take the whole number as a single word, but this is the same challenge for sighted people. So let's talk just about numbers with separators and decimal places.

I think there are two alternatives:

1. For numbers >= 1,000: ctrl+right should move from 1 to every pair of number after the separators e.g. 000 to xxx to decimal places, the separators and the decimal point should not be treated as a single word
2. At least pronouncing number ranges until quadrillion should be implemented in the screen reader when navigating word by word, might be more feasible to do but still the user should be aware that the cursor stops at the decimal point when navigating word by word.

I think alternative 1 would improve user experience also when adjusting digits in such long numbers.

Thanks @Adriani90 for your input and mentioning specific examples of use cases.

FYI, the Orca screen reader on Linux announced the sample number just fine in a quick test of mine ("two quadrillion two hundred trillion ..."). I don't know whether this is in the screen reader's responsibility or up to the text-to-speech engine used underneath.

Note that separators are also useful for sighted people when reading long numbers, so we should try to give blind users the same experience where possible when navigating word by word. If there are no separators, we have to take the whole number as a single word, but this is the same challenge for sighted people. So let's talk just about numbers with separators and decimal places.

I think there are two alternatives:

1. For numbers >= 1,000: ctrl+right should move from 1 to every pair of number after the separators e.g. 000 to xxx to decimal places, the separators and the decimal point should not be treated as a single word

2. At least pronouncing number ranges until quadrillion should be implemented in the screen reader when navigating word by word, might be more feasible to do but still the user should be aware that the cursor stops at the decimal point when navigating word by word.

I think alternative 1 would improve user experience also when adjusting digits in such long numbers.

For 1), I can also think of reasons why users might prefer the current behavior of moving to the decimal separator instead of just the next pair.
I don't know whether this is the ultimate answer, but would it possibly make sense to let the screen reader handle that, i.e. implement the handling in NVDA accordingly and maybe even make it configurable (e.g. allow to configure keyboard shortcuts for navigation commands for such numbers)? The API for retrieving and changing cursor position is available, so from a technical point of view, that should be doable in my understanding.

An app really should be consistent in how it defines a word. That is the only way that moving by word in the app and what gets reported by accessibility clients can be properly consistent. I think exactly how it is defined is less important than having consistency between control+left/rightArrow and accessibility APIs.

An app really should be consistent in how it defines a word. That is the only way that moving by word in the app and what gets reported by accessibility clients can be properly consistent. I think exactly how it is defined is less important than having consistency between control+left/rightArrow and accessibility APIs.

As mentioned in #4431 (comment) , I don't think LibreOffice should change it's definition of a word that's based on what ICU/the Unicode standard considers one, which would then leave the option described in that comment to adjust what Ctrl+Left/Right do.

@Adriani90 What do you think?

Yes I agree the definition is not really the point, it is the behavior of the caret movement that would matter in this case. @jcsteh should we not then rethink the ctrl+left and right arrow navigation for large numbers to provide similar experience of number navigation like sighted people?
@michaelweghorn wrote:

For 1), I can also think of reasons why users might prefer the current behavior of moving to the decimal separator instead of just the next pair.

I agree, but then the screen reader should report only the part of the number before the caret and continue report the decimals when pressing ctrl+right arrow one more time.
Ideally the user could switch between both ctrl+left/right behaviors via a new setting:
consider every dot and comma separator when navigating numbers with ctrl+left and right arrow --> the setting could be enabled or disabled either in the screen reader settings or in the app settings (LO in this case).

I vote to have this setting in the screen reader settings due to the unified definition of the word and the ctrl+left and right arrow which would avoid the need of adjusting this setting in a lot of applications manually.

I am also not really sure about the responsibility for announcing the number terminology. But Orca uses eSpeak as well and I am using the same synth with NVDA so I assume it is indeed screen reader responsibility to handle these and not the synth engine.

Ideally, a screen reader shouldn't be overriding control+right/leftArrow or any other kind of cursor navigation. This kind of overriding results in inconsistent behaviour for screen reader users vs other users. It's true that we do override the paragraph navigation commands, but that's only because most apps don't implement them at all.

Whether LibreOffice uses the ICU definition of a word or some other definition is really a decision to be made by the LibreOffice project. The only thing that a screen reader requires is that the definitions be consistent between keyboard navigation and API.