NVDA doesn't understand option buttons in an exported PDF

I’m trying to create an accessible PDF form with Libre Office Writer.

However, I have difficulties to make radio buttons accessible and the people I’ve asked to test the PDF form have reported that radio buttons don’t work properly with NVDA.

The problem is that NVDA does not read the text labels attached to the radio button (The text which can be edited by right clicking the option button → Control Properties → Label).

Instead, NVDA reads the serial number of the option button (eg. first / second / third option selected), when it should read the given option (Yes / Maybe / No). This happens despite the fact I’ve given all the option buttons proper help texts, names and descriptions.

So, how can I make NVDA (and other screen readers for that matter) read the option buttons properly? Is there any GUI way to do it or do I have to access the underlying XML and do manual edits? If I have to do the latter, then what I’m supposed to do to the radio buttons to make them work properly?

For a record, I don’t use screen reader myself, although I have installed NVDA so that I could debug the issue myself. Unfortunately I’m still too new to NVDA to replciate the issue.


Edit:

I just tested the exported PDF file by using Foxit reader’s read aloud feature (which has nothing to do with NVDA). The read aloud was able to read Help Text parts for all the Form Control objects in the file (ie the text fields which can be edited from Form → Control Properties → Help Text), except the option buttons.

For example, if I write to the check box’s Help text “Check this if you like dogs”, then the read aloud reads it just fine.

But if it were Option/Radio button, then the read aloud just says “Radio button, checked/unchecked”, no matter what I write to the Help text field.

Have you looked up the setting in the Tools>Options>LibreOffice> Accessibility menu ?

See also:

Accessibility
Assistive Tools in LibreOffice
Accessibility in LibreOffice

Maybe you should ask this at an NVDA forum, it’s possible that you need to configure the NVDA reader to read the options aloud instead of manipulating your source file.

1 Like

floris_v wrote:
Maybe you should ask this at an NVDA forum, it’s possible that you need to configure the NVDA reader to read the options aloud instead of manipulating your source file.

This issue has been raised by the people who have been doing the accessibility testing to my PDF form. Are you suggesting that I should tell them how to use NVDA, when even I myself don’t know how to use it properly?

I am personally very reluctant to blame my testers about this issue, so I really want you to double down that this is indeed a user error instead of an error in the ODT file.

I’m not saying that it’s a user error. You didn’t say that your testers reported this. I assumed that you test it yourself. Please, chill.
I’m saying that it may be something in the configuration of NVDA as it comes shipped to the users that needs to be fine-tuned. You could ask the developers or expert users of NVDA how you should mark up your PDF so that the NVDA reads it correctly. You can hardly expect that the average user of LibreOffice knows how to do it.

You didn’t say that your testers reported this. I assumed that you test it yourself

I thought I did say it in the 2nd paragraph of my OP. Also, in the last paragraph I also stated I wasn’t able to reproduce the issue myself.

You could ask the developers or expert users of NVDA how you should mark up your PDF so that the NVDA reads it correctly. You can hardly expect that the average user of LibreOffice knows how to do it.

This is the exact reason why I asked the question in the first place: I consider myself as an average use of the libre office (or maybe even an above average. Is an average libreoffice user expected to make edits to the underlying xml document to fix an accessibility issue?) and I wasn’t able to figure out how to make document behave properly.

I’m still open for the user error explanation, but before that I want to be absolutely sure that there isn’t anything I can do to fix the issue.

@TukeV
Maybe it’s a misunderstanding.
On this web page here, where you have asked your question, users answer you quite predominantly, as also you are one.
All users who answer questions here are very willing to share their knowledge and experience with the questioners.
However, there are some topics, such as the one you presented, that cannot be answered by any user because there is no knowledge about it.
In this respect I agree with @anon87010807 that a NVDA forum can have more users who know about NVDA and also LibreOffice.

However, there are some topics, such as the one you presented, that cannot be answered by any user because there is no knowledge about it.
In this respect I agree with @anon87010807 that a NVDA forum can have more users who know about NVDA and also LibreOffice.

Well, i figured that since I’m trying to create an accessible form with Libre Office, then this should be the first place to go. If the issue is that I’ve missed some built-in tool, menu or feature, then people on this forum should be able to tell me about it.

I also want point out that accessibility and accessible forms are features of Libre Office. If I have problems with Libre’s features, then this should be the right place to ask about them, right?

But you are also quite right that this is a rather niche question and I have easier time to find a person who has encountered this issue on the NVDA help forum than here. However, finding a person who also knows how fix the issue is entirely another matter.


I just tested the exported PDF file by using Foxit reader’s read aloud feature (which has nothing to do with NVDA). The read aloud was able to read Help Text parts for all the Form Control objects in the file (ie the text fields which can be edited from Form → Control Properties → Help Text), except the option buttons.

For example, if I write to the check box’s Help text “Check this if you like dogs”, then the read aloud reads it just fine.

But if it were Option/Radio button, then the read aloud just says “Radio button, checked/unchecked”, no matter what I write to the Help text field (or Name or Description fields).

If Foxit can’t make sense of the radio buttons either, it may be a bug in the conversion filter for PDF in LibreOffice, and not some misbehavior in NVDA. But if that’s the case, a bug report must be filed, then someone has to provide a patch. All of that will cost time. Maybe you can print to another PDF writer app that handles radio buttons correctly.

Yeah, it’s starting to smell like a bug.

Fortunately in my use case I can just replace the radio buttons with checkboxes and avoid the issue altogether.
The radio buttons would’ve been more “correct” way to do it, but if I can’t make them work properly then it is what it is.

I think it would be possible to discuss this interesting topic in more detail if you could upload the example .odt file and the corresponding .pdf file.

Sure thing. Luckily this is rather easy to reprduce.

Here’s an example ODT file which asks which pet user owns, likes and hates.

pet_form.odt (10.3 KB)

The forum does not allow PDF uploads, but anyone can turn this ODT into a PDF file if they wish so.

If I open the PDF file with foxit reader and turn the read-aloud on, the read aloud will first read the whole document aloud… or at least it should. For some reason the read-aloud skips the “Which of the following pets do you have?” label. When Read Aloud reads the whole document, it also reads the radio button labels correctly. Everything is working fine up to this point.

The problem manifests itself, when you start browsing the form with tabulator (remember to have read aloud on). For the Check Box questions, the read aloud reads the help text (eg. Check this if you own a cat, checkbox, unchecked).

However, when browsing the radio buttons, the read aloud just says “Radio button, unchecked”. The expected behaviour is that read aloud reads the help text for the radio buttons too (eg. “Choose this if your favourite pet is cat, radio button, unchecked”).


But this doesn’t necessarily mean that this is a Libre Office’s bug. It could be a bug in the Foxit reader’s read aloud feature for instance.

That wouldn’t explain the feedback from the NVDA users though.

Also, since I haven’t tried how Foxit or NVDA behaves with PDF files created with other tools, there’s still possibility that this is actually an issue in how Foxit and NVDA reads PDF files in general.

This is starting to feel like a rabbit hole I’m not sure do I want to dive into :neutral_face:

Thanks! I think at the beginning we need to see if everything is ok with the Writer document. I’ll try to look tomorrow using the AccessibleContext service.

I looked at your file.
Let’s try the following. In Design Mode, select a control (such as a radio button), and choose Description from the context menu (mouse right-click). Fill in the Description field and then see how your text will affect the further steps (PDF, NVDA).

I did some research and learned how to navigate trough a form file with NVDA shortcuts.

It turns out the form was working just fine in Adobe Acrobat DC, but not in Foxit or browser based PDF readers (I tested Firefox, Edge, Brave and Chrome).

I also did some debugging with all the accessiblity and just like the Foxit’s read aloud, the NVDA also reads the Help texts when opened in the Adobe reader, not the Description tags.

But while doing this I discovered something new…

It turned out that even in Acrobat Reader the first radio button group (the one about Favourite Pet) does not work properly with NVDA.

The expected behaviour of this group is that when you navigate with NVDA trough this group, it would read the Help text for each choise in the group (Choose this if your favourite pet is cat/dog/gold fish. Radio Button Checked / Not Checked). This is how the last question (Which of the following pets you hate the most) behaves.

Instead, NVDA reads “Choose this if your favourite pet is cat. column 1 / 2 / 3”. NVDA just ignores the help text associated to other radio buttons in the first group and defaults to the help text used in the first option.

Anyway, here’s the updated ODT file, which I used to investigate the issue.

pet_form.odt (10.7 KB)

This is getting way too hairy for me. :confused: