Date: prev next · Thread: first prev next last


Hi Michael,

Nice to start chatting with you, I heard of you at Libocon via COlomban you met there and worling with my organization. I am glad if I can help you working on LO accessibility given the high needed job. For your info, as a "power user"/tester, I mainly use Linux and I use Libreoffice latest stable (in Sid on Debian). Hypa uses an older one due to bugs that COlomban will show you, but the bug tracker mentions most of them, reported by me and my former colleague.


Le 06/10/2023 à 20:32, Michael Weghorn a écrit :
Hi Daniel and Jason,

thanks a lot for your email mentioning these points and the further input!

Some notes/questions on the individual points follow below.

On 2023-10-05 00:01, Jason White wrote:
On 4/10/23 17:22, Daniel McGrath wrote:
Firstly, when bringing up a word count, it's very difficult to see...
for the screen reader to read the word count. Most of the window seems
taken up with a needlessly (to me) long explanation of what word count
does. The only way I've found of hearing the actual word count is to
use insert+b to get NVDA to read the whole dialog box, and the word
count comes right at the end. Little thing I know, but rather
irritating if one is trying to keep tabs on the number of words, and
having to read every time that this shows the word count of the
current selection and the whole document, and that this is
automatically updated as you type. Useful to know once of course, but
annoying to have to hear every single time.
I've just tested this under Linux with Orca, and I can use the screen reader's review commands to read the dialogue. Starting from the bottom gives me the character counts (with and without spaces), and the word count.

Actually I think something needs to be explained: using screen readers like Orca or NVDA, we consider as accessible information what may be reached via the caret, ie. what you can move with tab key or the arrow keys. Using advanced features to access to the information, eg. object navigation or flat review, is not optimal. It might work, but not everybody know it and is it considered as a kind of hack to workaround accessibility limitations.


The explanation of what word count does is not shown in the dialog, but set as the accessible description of the dialog. And when an accessible description is set for a dialog, NVDA announces that description instead of the dialog content.

NVDA source code for this:
https://github.com/nvaccess/nvda/blob/a380b6a76a0a29df32e57c1bd974b11a895ac0c8/source/NVDAObjects/behaviors.py#L151-L156

On top of that, the same text was set for both of the buttons, so when pressing NVDA+B, the text would get announced three times: once as the accessible description of the dialog at the very beginning, and then once when each of the buttons is announced.

At least the latter seems wrong, so I've submitted a change to drop that:
https://gerrit.libreoffice.org/c/core/+/157637

One approach to avoid announcing the explanation each time and announcing the content instead would be dropping the accessible description for the dialog, since it's still easily possible to get that info by pressing the "Help" button in the dialog.

I've submitted a change to do that, but am currently waiting for feedback from the documentation/help team on whether that's OK, since that would also mean that the text is no longer shown as a tooltip when extended tips are enabled in the LibreOffice options.

As a potential alternative, if you're primarily interested in the document word count, that info is more quickly available in the status bar.
NVDA+End will announce it from NVDA 2023.2 on.
(This was implemented in NVDA for LibreOffice in https://github.com/nvaccess/nvda/pull/14933 .)

As a side note, when I tested that just now, I noticed that this needs another update to work with the current development version of LibreOffice and to make the functionality work with status bars in dialogs as well. Pending/Suggested changes:
https://gerrit.libreoffice.org/c/core/+/157658
https://gerrit.libreoffice.org/c/core/+/157659
https://github.com/nvaccess/nvda/pull/15592

But as far as I can tell, if you're using NVDA 2023.2 and LibreOffice 7.5 or 7.6, this should work fine.

My second point is about automatic spell checking. I find that my
screen reader will only inform me of a spelling error if the cursor
happens to land on the word. I don't know if I can make it any
clearer, but for instance if reading a line back in this email, NVDA
will announce "spelling error" each time it encounters a mis-spelled
word. In LO writer, I will only be told each mis-spelled word when the
cursor is on it. Pretty little thing this, but it would be nice if it
could be corrected.
I think that's a screen reader issue. You should probably report it to NVDA.

Unfortunately I am not sure. I Cc Joanmarie Diggs, main Orca developer, who can confirm or give you technical explanations. DOnt hesitate to subscribe to the orca mailing list where all the community activity takes place:
https://www.freelists.org/list/orca

I think if the screen reader is unable to announce a mismelled word while speaking the current line or saying all the document, it is because it does not get the info from the accessibilit tree.

Best regards,


I can reproduce this, e.g. with a paragraph containing this text:

"Hello world, wrrong spelling."

Moving to that paragraph using the cursor up/down key, NVDA announces "spelling error" when using Word right away, but not for Writer.

I plan to take a look into that, but cannot say yet when I'll get to it.


My third problem is potentially quite important, because if you're
using a braille display, if you prefer to work without speech, which I
often do, it can make editing and proofing quite challenging. Along
the top of a braille display is a row of buttons called 'router keys'.
When pressed, the cursor is moved to that place in the document.
Cursor routing keys worked for me under Linux with a braille display and the Orca screen reader when I last used them. It might be a Windows or NVDA-specific issue.


Can you please provide a detailed description of how to reproduce this issue? (What are the exact steps you're taking? What is the actual outcome? What is the expected outcome?)

I noticed that NVDA has a braille viewer ("Tools" -> "Braille Viewer") so tried to reproduce with that, since I don't have any actual hardware. However, I also don't have any previous experience with this and don't really know how this is expected to work.

What I did was this:

1) start NVDA (2023.2) and its braille viewer ("Tools" -> "Braille Viewer"), enable "Hover for cell routing" checkbox
2) start LO Writer
3) type this text: "This is some sample text."
Result: The text and braille equivalent appears in NVDA's braille viewer
4) Hover over one of the braille symbols in the braille viewer (I chose the one just above the letter "p" in the word "sample", but the positions in braille and in "plain text" don't seem to match).

Result:
The cursor moves to be between the "a" and the "m" in the word "sample".
The same things happens when taking the above steps with Word or Notepad++ instead of LO Writer, so that looks like it would likely be correct.

But as I said, I have no previous experience with this and don't know the expected behavior, so would be very helpful for more detailed input regarding this.

Regards,
Michael




--
To unsubscribe e-mail to: accessibility+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/accessibility/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.