NVDA no longer reads form control identifiers, nor help text when F1 is hit, when using a Microsoft Word Fillable Form

[britechguy]

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: NVDAJAWS&_Narrator_with_Fillable_Form_Instance_MP3s.zip

BusNote_MS-Word_DOTX.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

[britechguy]

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.

NVDAJAWS&_Narrator_with_Fillable_Form_Instance_MP3s.zip

[XLTechie]

@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

[enessaribas]

hi, Could this be because this form opens in compatibility mode? With Office 365 this is opening that way.

[marrie]

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)

[britechguy]

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.

[britechguy]

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.

[britechguy]

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).

[CyrilleB79]

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.

[CyrilleB79]

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.

[britechguy]

@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.

[marrie]

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.

[britechguy]

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.

[marrie]

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.

[enessaribas]

why is this marked Open office? My understanding is this exists with MS office.

[britechguy]

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.

[seanbudd]

@enessaribas - accident, thanks

[marrie]

Any headway on this issue? This seems like a very important bug to fix. Thank you so much.

[XLTechie]

CC @michaelDCurran

"The first principle is that you must not fool yourself and you are the easiest person to fool." - Richard P. Feynman

[britechguy]

@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.

[britechguy]

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?

[lukaszgo1]

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:

1. 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_).
2. 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
3. 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.

[britechguy]

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.

[lukaszgo1]

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.

[britechguy]

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.

[lukaszgo1]

OK. Right now I'm on 2023.3beta2.

Yes, this version is fine.

[britechguy]

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.

[lukaszgo1]

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?

[britechguy]

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

[marrie]

Look in %temp% and nvda log old with the word debug after you restart nvda wherein debugging is then turned off.

Thanks

[lukaszgo1]

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:

1. 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.
2. 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.

[britechguy]

There are two problems:

1. 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.
2. 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.

As to issue #1, I cannot say, either, whether it's an NVDA fix versus a Microsoft fix, but it needs to be fixed. At the time of the initial report of this issue, JAWS was announcing both the field labels/states as well as help text invoked via F1. I did not test with Narrator, but can if anyone wishes me to do so. While Word fillable forms have not "taken the world by storm" they are particularly useful for accessibility, or were, in the case of NVDA.

As to issue #2, I have not disabled anything, and by that I mean that I've clean installed NVDA recently and I know that I have never touched that setting. In any case, I do not thing that help text in a help dialog should, under any circumstances, fall under the category of "Object Description." The object is the dialog box itself, and its object description should be something akin to "help dialog." F1 is a quasi-universal help invocation in Windows, not just here, and if there is help to be invoked via that method, the screen reader should be reading it. I will be happy to create an issue, if that's the best course of action, but I'm flagging @michaelDCurran for input on this, too, as I don't know exactly how I should report this in a way that would be meaningful to the development team. A bit of guidance before creating an issue would be welcomed.

[josephsl]

Hi, whenever you suspect a UIA problem, do test with Narrator and see which side should take the initiative to resolve issues; in this case, this is a good situation for testing with Narrator. Thanks

[britechguy]

@josephsl

I'm not trying to be stupid here, but want to make sure that I understand "the directionality" involved. I am presuming you are saying this, in a nutshell, "If it works in Narrator, then NVAccess should be fixing NVDA's behavior in regard to UIA."

If that's not correct, then please make plain what one gets out of testing with Narrator and what certain behaviors indicate about whose lap an issue lands in when it comes to issues suspected to have a connection to UIA.

[josephsl]

Hi,

Narrator will announce things according to what Word tells it to do via UI Automation. If things announce correctly with Narrator, then the issue may lie with NVDA - either the UIA support code, an add-on or two, user configuration, or any combination of them. But that does not mean Microsoft is free from blame - Narrator may announce thins based on whatever it is told to say, so it may as well be something going on with Word's UIA implementation itself.

Thanks.

[britechguy]

I am bumping this again because I think it's important and I do not know what to do.

Neither NVDA nor Narrator are behaving "as expected" when navigating an MS-Word Fillable form that has been created with legacy controls (be they edit boxes, checkboxes, etc.) while JAWS is, and has been for as long as I've been working with fillable forms.

I can make recordings of what I hear when using JAWS (and if anyone has a suggestion for a utility to do this on the PC while working, please share) versus NVDA, versus Narrator. Narrator is no better than NVDA other than it will read what is in the on-demand help if you press F1, but it announces every form field and checkbox as "Invalid" and often repeats itself.

I have used MS-Word Fillable Forms as an accessibility tool for almost 15 years now, and it is only very recently that the screen readers other than JAWS have stopped working as expected with them, which is very frustrating. I don't think there is anything I can do to fix this, as I don't think the issue lies with the use of legacy form controls, which are easier to work with, in my experience, and still work fine with JAWS. This may be something that I need to report to Microsoft as well, too, but I'm not certain about that and if anyone has an opinion and/or guidance in that regard, please share as well.

[britechguy]

Strangely enough, when trying this again this morning with NVDA 2023.3.3, at least the form controls - edit boxes, checkboxes (and their states), etc., are back to being announced correctly.

The issue with the help text not being read when F1 is hit remains. The help dialog is announced, the help text is there, but not read aloud, and then the OK button (which has focus) is read.

I'll try other MS-Word fillable forms I have later, but since one is now working (and it wasn't) I suspect the others will too. I'll be checking again after NVDA 2024.1 hits the streets.

[Adriani90]

@britechguy make sure you update you rMS Word version to the latest build since Microsoft seem to improve UIA on a regular basis but this is not really well documented.

[britechguy]

@Adriani90

Good advice, and I give it myself. In virtually all other auto-update situations with Microsoft products, they're prompt and never lag weeks to months behind. I have not found this to be the case with M365 updates. I've advised doing an ALT + F, D, R, U, every once in a while from within any M365 Office Suite program to make sure things are up to date.

I did one less than 3 weeks ago and doing one just now is downloading and installing the latest updates. Auto-update is on. Why it doesn't do this by itself I do not know.

[britechguy]

Still present with NVDA 2024.1 and with a forced update having been done to M365 just a couple of days ago.

NVDA 2024.1.0.31547

Word 265 Version 2404 Build 17531.20152 Click-to-Run

BUT, it appears to be an issue with an add-on at this point, because if I restart with Add-Ons disabled the behavior reverts to precisely what it should be, with each edit box or checkbox announced when you land in it. Here is an issue where, if I had the ability to generate a list of add-ons installed, I would. I asked for that here: https://github.com/nvaccess/nvda/issues/14613

Someone reading would likely have an idea regarding "plan of attack" for disabling and reenabling based on knowledge of the add-on internals that I do not have.

[Adriani90]

Ok this seems fixed in MS Word now, and it is an issue with an add-on. The most probable add-on I can think of is the global extensions add-on or the Microsoft Word NVDA add-on. As we don't know which add-on could be precisely, and this issue does not occur with add-ons disabled, I am closing this issue as it is not caused by NVDA core.

[marrie]

Being that I use neither of those addons and I should have stated this, it did break with add ons disabled last year. I'll have to try this gain the next time I get a fillable form in word.

Thanks.

[josephsl]

Hi,

Breaks with add-ons disabled... If yes, we are back to square one. Brian, can you try with biary search on add-ons?

Thanks.

[britechguy]

Brian, can you try with biary search on add-ons?

Joseph, I'll be glad to retest, but I'm really not sure which add-on or add-ons you're asking me about. Are you requesting a "divide and conquer" approach where I disable half of my add-ons, see if things are OK, if so enable half of the disabled half, lather rinse repeat?

[josephsl]

Hi, yes please, thanks.

[britechguy]

Curiouser and curiouser.

First, if all add-ons are disabled I am definitely getting the edit box names and checkbox names read. However, in rechecking the help text that should be read when F1 is struck still is not, only the OK button is read. I cannot make that help text read.

Whatever triggers this issue is not going to be easy to flesh out. I am getting all form fields and checkbox names read at the moment with all add-ons enabled, but, they have "died out" when I was doing the divide by halves with disabling add-on technique and would not come back even when what was disabled was shifted. Yet, if I closed the document in MS-Word, and reopened it again by activating the DOTX file to create a new blank copy, then suddenly the fields were being announced again. It's just insanely weird and I have no idea why, if NVDA stops speaking in an instance of the document, I cannot get it to start speaking those names again no matter what add-ons I flip-flop. But if I close the instance of the document, and then re-open a fresh instance from the same DOTX file, and also restarting NVDA but NOT changing the add-ons that had been enabled/disabled when it wasn't working, it works for reading those fields again.

[marrie]

Have you gone log diving to see what is going on? I'm grasping at straws here.. 😕

[XLTechie]

@britechguy my Version Collector add-on is still available in the beta channel of the store. It would do what you want as far as listing your add-ons in a copyable way.

And Joseph meant "binary search", I believe.

[Adriani90]

Testing with NVDA 2024.2 Beta in MS Office 365 as well as MS Office 2016, I cannot reproduce this issue with add-ons disabled. All form fields are reported properly with UIA disabled. However, if your UIA is set to the default value, the form will become totally inaccessible.