1723422 - [XFA] A11y form field labels not exposed

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):

1. Open this PDF in Firefox: https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033
2. Wait a few seconds for the first page to load.
3. Press control+home to ensure you are at the top of the document.
4. Press NVDA+control+f to open the NVDA Find dialog. (The NVDA key is usually the insert key by default.)
5. Type "Current country" (no quotes) and press enter.
6. Press e to move to the next text box.
   • Expected: NVDA should say "Question 7 C If your immigration status is other, please give details. edit multi line"
   • Actual: NVDA says only "edit multi line"

There are plenty of other form fields in this document that do have associated labels. They don't seem to be the labels the author intended for accessibility purposes, though. For the most part, this isn't a huge concern. I chose the example above because in this case, the author did specify a label, but there is no associated label at all with pdf.js. This makes it impossible for a screen reader user to be certain what they should fill in here.

I'm not sure how XFA encodes this information, but it is picked up by Acrobat Reader. Pdf.js could output these labels in the HTML using the aria-label attribute.

Comment 1

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/13858

Comment 2

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub master push: https://github.com/mozilla/pdf.js/commit/6cf1ee32513bcd2d59a9142f0aa37394fb6d9b5e

Commit merged into master by GitHub
Authored by Brendan Dahl (brendandahl)

Comment 3

[Daniel Bodea [:danibodea]]

James, I would love to receive your opinion on this:

I will do my best to verify this implementation/fix in the three main operating systems, while also addressing concerns, if the case:

• Windows 10 with NVDA: Reads the form field label: "Question 7 C If your immigration status is other, please give details. edit multi line", but the pronunciation is a little confusing. I do not know if that can be considered an issue or not. Please give some feedback.

• Mac OS 11 with VoiceOver: The steps in the description cannot be used since those are made for the use of NVDA, but when the user focuses (by any means) on the "Other" text field from the inside the "7 Current country or territory of Residence" table, VoiceOver will read the field label, with one mistake: "7 C" is read as "7 degrees celsius", instead of simply "7C". Should this be logged as a new bug?

• Ubuntu 20 with ORCA: The steps in the description cannot be used since those are made for the use of NVDA, but when the user focuses (by any means) on the "Other" text field from the inside the "7 Current country or territory of Residence" table, ORCA will read the field label.

Final note: While attempting to verify this implementation, I've also attempted to test the general usability of this PDF with the use of screen readers and I am satisfied with how NVDA, VoiceOver and ORCA read the field labels and make it possible to complete this form. However, the one annoying part is that ORCA will read combo-boxes and some other text field labels as many as 3 times in a row. This is not a severe issue, but it is definitely annoying. Do you think I should log this as a new bug?

Please mention if you have other concerns about the use of SCreen Readers in PDF forms. Thank you!

Comment 4

[James Teh [:Jamie]]

(In reply to Bodea Daniel [:danibodea] from comment #3)

• Windows 10 with NVDA: Reads the form field label: "Question 7 C If your immigration status is other, please give details. edit multi line", but the pronunciation is a little confusing. I do not know if that can be considered an issue or not. Please give some feedback.

I'm not sure specifically what is confusing for you here. Are you referring to the "edit multi line" indicator? NVDA (and JAWS) refer to text boxes as "edits" for brevity, and "multi line" indicates that this text box can accept multiple lines of input. I just tested this myself and NVDA is reporting as expected here.

• Mac OS 11 with VoiceOver: The steps in the description cannot be used since those are made for the use of NVDA, but when the user focuses (by any means) on the "Other" text field from the inside the "7 Current country or territory of Residence" table, VoiceOver will read the field label, with one mistake: "7 C" is read as "7 degrees celsius", instead of simply "7C". Should this be logged as a new bug?

While definitely undesirable, this is not a bug within our control. This is most likely the speech synthesiser incorrectly guessing the context, which is not something we can compensate for.

the one annoying part is that ORCA will read combo-boxes and some other text field labels as many as 3 times in a row. This is not a severe issue, but it is definitely annoying. Do you think I should log this as a new bug?

If this occurs in PDF XFA forms but not in standard HTML forms, then yes, I think this deserves a new bug. As you say, it is certainly lower severity.

Thanks!

Comment 5

[Daniel Bodea [:danibodea]]

Setting a need info for myself to retest.

Comment 6

[Daniel Bodea [:danibodea]]

Regarding NVDA, my confusion about the weird pronunciation is discussed in bug 1723425 and accepted as not an issue of FX.
Regarding VoiceOver, also not an issue of FX.
Regarding ORCA, I've tested several other standard forms in HTML and I got both types of results this issue DOES happen in both PDF forms and standard HTML forms, but it certainly depends on the forms themselves. This being said, I will assume that this does not deserve a new bug, however, I wouldn't know how to investigate this forward.