[Affected versions]: - Beta 57.b10, 57.b11 - Nightly 58.0a1 (id: 20171023220222) [Affected platforms]: - Windows 10 x64 [Steps to reproduce]: 1. Install either JAWS / NVDA 2. Navigate to about:support 3. Scroll down to "Accessibility" and check the value of "Accessibility Instantiator" [Expected result]: - The value is that of the installation directory of the screenreader. [Actual result]: - The value is "UIAUTOMATION|" for NVDA on Beta and "NVDA,UIAUTOMATION|" for Nightly - The value is "JAWS|" for JAWS on Beta and Nightly [Regression range]: - I couldn't find a regression range for this issue. This doesn't seem to be a regression. [Additional notes]: -

TL;DR: This is expected behaviour for JAWS. For NVDA, it should at least report NVDA somewhere in the string, but it might not necessarily report the full path. However, sometimes, it only reports UIAUTOMATION; see bug 1407471. 1. The instantiator as reported in about:support consists of two parts: in-proc|out-proc where in-proc specifies the name of any in-process clients that were detected when accessibility was instantiated; and out-proc specifies the full path of the out-of-process executable that instantiated accessibility, but *only if* accessibility was instantiated by an out-of-process caller. 2. JAWS makes calls in-process, so for JAWS, we never see an out-of-process caller and thus we don't get the path. 3. NVDA makes most calls out-of-process. 4. However, NVDA does enable UI Automation; and 5. UI Automation makes calls in-process. 6. It seems UI Automation often manages to query accessibility before NVDA itself does, so we don't get the path (because the instantiation wasn't caused by an out-of-process call).

Note that bug 1407471 suggests changing the way we do this so that we don't gather accessibility client info from the first query only. That would have an impact on this situation.

After bug 1423999, we can detect uiAccess executables which instantiate via UI Automation, so we now log NVDA's path in that case: UIAUTOMATION|C:\Program Files (x86)\NVDA\nvda.exe It's still possible you might just see "NVDA|", though, if UIA didn't get in first. While this is quirky, I don't know that there's anything we can do to fix it, and we do get the right information in some form, so I'd be inclined to argue we should wontfix this bug.

No further action identified.