Re: [libreoffice-accessibility] some issues with screen reader accessibility

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