nvaccess
NVDA no longer reads form control identifiers, nor help text when F1 is hit, when using a Microsoft Word Fillable Form
Steps to reproduce:
Note: So that all files I reference in this issue will remain available, I am attaching them as ZIP files immediately below. I will leave the original report text as it was, but any files alluded to are in one of these clearly named ZIP files: NVDA_JAWS_&_Narrator_with_Fillable_Form_Instance_MP3s.zip
Open any Microsoft Word Fillable Form in NVDA and tab through the various form fields, regardless of type. MS-Word Fillable Form template used to generate actual instance of form for filling: BusNoteForm.dotx. I cannot attach a DOTX file, so a link to the one I'm using for testing that resides in my Google Drive is included. Once you have downloaded that file (and turned off protected mode, if necessary) simply activate it and a fresh copy of a fillable form is created, leaving the DOTX untouched. The form itself can be saved afterward. Please also see extensive discussion of this issue on the Groups.io NVDA Group in topic: Call for Assistance/Replication: BusNoteForm.dotx - JAWS 2022 works, NVDA 2023.1 doesn't
Actual behavior:
Recording of NVDA interacting with the form (Google Drive - MP3 format)
None of the edit boxes or checkboxes are announced as expected. All use MS-Word Legacy Form Controls and Help Text for both the status bar (which is what's typically announced by screen readers upon entry into the control) as well as Help Key (F1) help text to allow the field name to be re-announced on demand or, on more complex forms, for more explanation about what the user is expected to enter for a given control.
Expected behavior:
As one traverses a "blank" instance of the form, when landing in each edit box or checkbox, the name of the control given in the Status Bar help should be announced, as well as the state of controls like checkboxes. JAWS 2022 interacting with the same form.
NVDA logs, crash dumps and other attachments:
N/A
System configuration
NVDA installed/portable/running from source:
Recording is from NVDA 2023.1, installed. Previously referenced topic on Groups.io includes information about all the various portable versions I tried this with and the results.
NVDA version:
2023.1
Windows version:
Windows 11 Pro Version 22H2
Name and version of other software in use when reproducing the issue:
Office 2016, Version 16.0.15726.20188, 32-bit (Word, specifically, obviously)
Other information about your system:
Other questions
Can the list of allowable attachment types please be updated to include MP3 audio and DOTX Word document template files?
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes, see previous note
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
I have reports of issues with the MP3 files that I've recorded with NVDA, JAWS, and Narrator not downloading properly, so I have created a ZIP file containing these so that you can listen to precisely what's happening.
Narrator also does not "play well" with Word Fillable Forms, but never having tried to use it with them in the past I have no idea if this is a change or not. But the fact that it is reading what is protected text (very strange) while not correctly announcing the actual field, as well as it reading across a whole line that has a checkbox, protected text, and two additional text boxes might be diagnostically significant.
NVDA_JAWS_&_Narrator_with_Fillable_Form_Instance_MP3s.zip
@britechguy
Name and version of other software in use when reproducing the issue:
Please update the issue to include your version of Microsoft Word in this section.
Can the list of allowable attachment types please be updated to include MP3 audio and DOTX Word document template files?
Agreed, but please file an issue with GitHub itself for this. Https://support.github.com/contact/bug-report
hi, Could this be because this form opens in compatibility mode? With Office 365 this is opening that way.
I can reproduce this. I'll upload a test form in templet form so someone can have a play. Here is the file. Notice tghatthe form boxes don't read at all when arrowing. f1 works if and only if you alt tab away then back to the document.
Windows 11 22H2 (AMD64) build 22621.1555
NonVisual Desktop Access (NVDA)
Version: 2023.1 (2023.1.0.27913)
Please update the issue to include your version of Microsoft Word in this section.
Done. That was an "oops, my bad" sort omission.
On the attachments, I want to be certain that this is a GitHub limitation, as opposed to "what does a project under GitHub allow" limitation. It strikes me as quite odd that MP4 is allowed, but MP3 is not, and that this is unlikely to be at the level of GitHub rather than the project administrator not checking whatever checkbox it might be to allow specific file types.
I'll upload a test form in templet form so someone can have a play. Here is the file.
I will note that in both JAWS and NVDA, the student name combo box in the document that is generated by that template file is inaccessible as far as being able to actually drop it down via keyboard commands and select one of the options. The only way I can get it to open is via point and click on the actual dropdown button that's part of the control.
NVDA announces nothing for documents generated by this template (as Sarah noted) but JAWS 2022 announces the various controls based on what she has entered for the status bar help text. The combo box control is announced by JAWS as a combo box even though interacting with it via keyboard to get the dropdown to open for "arrow down selection" is not working.
Could this be because this form opens in compatibility mode?
It should not be. NVDA has no issue with myriad other MS-Word documents that I've received that open in compatibility mode. All that means is that the formatting is such that it is compatible with all older versions of MS-Word, but that's what I was expecting when creating this fillable form template as well. It's incredibly simple and uses none of the more recent options for formatting. It even uses legacy form controls, as I've found those work better with screen readers (when the screen readers were still working with the form itself).
First of all, thanks Brian for having opened this issue.
You write:
On the attachments, I want to be certain that this is a GitHub limitation, as opposed to "what does a project under GitHub allow" limitation. It strikes me as quite odd that MP4 is allowed, but MP3 is not, and that this is unlikely to be at the level of GitHub rather than the project administrator not checking whatever checkbox it might be to allow specific file types.
No, according to this page, the possible file types are defined at GitHub level, not at project level.
Brian,
Also for any other type of file that is not supported, you can zip it and upload the .zip which is supported. Please update the initial description with files uploaded in GitHub rather than links in your drive; this is a more permanent solution in case wee need them many years later.
@CyrilleB79
Thanks for the definitive answer. I'll put in a GitHub ticket with GitHub on this one. Allowing video, but not audio, really makes little sense. I also don't know why the full range of MS-Office file types should not be allowed as well.
Can you alt tab away from and back to the form to see the help text? Also, is the combo box and text fields being unreadable a regression in office 365 or nvda. I don’t use jaws and due to a lot of things taking up my time, cannot test at this point in time with said screen reader.
T.
file an issue with GitHub itself for this.
Done. For those who wish to rattle GitHub's chain regarding allowable file types for attaching when reporting issues, please add a supportive comment to: Allowed attachment file types for GitHub itself #2134681
If there are other specific file types not mentioned on the page: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files that you'd like to have allowed as attachment types, please add those in the comment.
In my case I’m running Microsoft® Word for Microsoft 365 MSO (Version 2303 Build 16.0.16227.20202) 64-bit, sorry if I forgot to include that.
why is this marked Open office? My understanding is this exists with MS office.
This is definitely an MS-Office problem. All of us reporting the issue are encountering it in MS-Word 2016 or more recent. It might exist in earlier versions depending on what the root cause of this issue happens to be.
Any headway on this issue? This seems like a very important bug to fix. Thank you so much.
CC @michaelDCurran
"The first principle is that you must not fool yourself and you are the easiest person to fool." - Richard P. Feynman
@marrie and @XLTechie
Thanks for giving this a nudge and trying to "wave down" someone who is likely the one to fix it.
I have another NVDA user asking me about using MS-Word fillable forms and until this is fixed I don't consider it to be a practical option with NVDA. It's got to work, and it does work with the other screen readers.
This does strike me, still, as an important issue to resolve, but there seems to be no indication that it's actually slated for a fix. What is the current status?
This is not reproducible for me with Microsoft® Word for Microsoft 365 MSO (Version 2308 Build 16.0.16731.20182) 32-bit, latest Alpha of NVDA, and Windows 10 22H2. @britechguy Could you please perform the following tests:
- Open the document in question with NVDA running, press NVDA+Numpad minus, just to make sure your navigator object is set to the document, press NVDA + F1, copy and paste the developer info for the control (that is all text from the caret position to the end of the log viewer to this issue_).
- When focused on one of the form controls press F1 to force help dialog to appear, Press NVDA+numpad minus, move the navigator object level up to the dialog by pressing NVDA+numpad 8, and once again paste the developer info for the dialog here, in the same way as for the control above
- Open NVDA's settings, go to advanced panel, set 'Use UI Automation to access Microsoft Word document controls' to 'Only when necessary', and retry - this should at least make labels of the fields to be read properly.
Lukasgo1,
I try, as best I can, to avoid alpha builds entirely. If you give me a link to where I can snag the version of NVDA you wish me to use, I will try this using it as a portable copy.
You can perform the tests I asked for in my last comment using stable version of NVDA. If my hypothesis is correct the difference in our results stems from the fact that you're running on Windows 11 and not from version of NVDA, but to be able to confirm I need the developer info for these controls.
OK. Right now I'm on 2023.3beta2. If that's OK, I'll go ahead and test later today. If it's not, then please let me know what you'd prefer I use.
Where in the heck does NVDA put its debug log when you restart with debug level logging?
I've run the tests you've asked for, and will send along the log once I can find it.
Making that tweak to UIA use in Advanced settings did get me back to having the various fillable form field names announced, as well as their state when things like checkboxes are used.
In the %temp%\nvda-old.log. However The full log is not needed. I've explained how you can copy the needed developer info from NVDA's log viewer, any particular reason why you didn't followed this description?
Scratch that last request for NVDA log location information. I thought I'd written a tutorial about this, and I had, and I located that tutorial.
The NVDA log is attached. If you need me to do this again with add-ons disabled I can do so.
I didn't follow the exact description because I learned, long ago, that the folks who request log information generally know how to get to exactly what they want, and I am not good at dissecting logs. I've also frequently gotten requests for follow-up material from the same log.
The log is attached. nvda.log
Look in %temp% and nvda log old with the word debug after you restart nvda wherein debugging is then turned off.
Thanks
Thanks for the log file. While I certainly understand that uploading the entire log may avoid back and forth between user and developer, in this particular case by not following the instructions you have missed a step where I have asked for pressing NVDA+F1 which not only opens the log viewer, but, more importantly, captures the developer info for a particular object. Thankfully the remaining content of the log was sufficient for me to understand the issues, so there is no need to upload a new log. There are two problems:
- With UIA for Word documents enabled (which is the default for sufficiently recent versions of MS Word on Windows 11) labels of form fields are not read. This is not NVDA regression as such - it didn't occur in the older versions just because UIA was not default for MS Word. I have no idea if this can be fixed on NVDA's side, or by Microsoft. I also have no idea if this is serious enough to reconsider making UIA default on Windows 11. Cc @michaelDCurran for awareness.
- Content of the help dialogs invoked with F1 not being read for you is caused by the fact that you have disabled 'Report object descriptions' in the 'Object presentation' settings. This unfortunately causes content of the dialogs not to be announced. If you think that announcement of the dialog content should not be tied to reporting of object descriptions this should be handled in a separate issue.