Hi,

The UIA issues I’m talking about can be caused either by the app in question or NVDA not knowing certain UIA properties fully. The former is the case with older Chromium Edge releases where UIA implementation from Edge is incomplete, the latter was the case when NVDA didn’t know about notification event for several weeks during Version 1709 era (October 2017-April 2018).

As for bringing Windows 10 App Essentials to NVDA, as I stated a few days ago, parts of it are available in NVDA now, and I plan to transfer more code from that add-on to NVDA. In fact, NVDA 2020.4 includes support for Windows 10 Calculator, which came directly from Windows 10 App Essentials. The next version of the add-on will include code that may become part of NVDA later, specifically initial support for updated emoji panel being tested by Windows Insiders on development channel (build 21300 series); it is too early to put that code into NVDA because the feature can change without notice, hence I’m letting folks give it a try by incorporating it into WinTenApps first.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Jaffar Sidek
Sent: Thursday, January 28, 2021 2:25 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] message announced by NVDA

 

Hi Joseph.  Correct me if I am wrong, but what you seem to be saying is that while WxWidgets uses MSAA as it's accessibility go to, NVDA itself relies on both the native Windows dialog and UIA to function properly, particularly with the more newly built apps.  If my assumption is correct, then your win10 issentials AddOn is bridging the gap so as to cause less of a conflict with access issues?  Would it then be better to embed Win10 issentials into NVDA itself?  Cheers!

On 28/1/2021 1:36 pm, Joseph Lee wrote:

Hi,

I think there’s another aspect to account for: it isn’t NVDA that has control over how messages are presented/announced: it is really wxWidgets that controls this. Part of the reason why NVDA’s user interface is accessible is because it isn’t NVDA that instructs Windows that its own message boxes are dialogs; rather, it is wxWidgets that reveals MSAA information to Windows about controls. Therefore, NVDA can announce its own dialog content simply because it is retrieving whatever accessibility API information Windows says about controls.

Speaking of GUI toolkits and NVDA: I’m researching how NVDA will work under more recent wxPython releases (currently NVDA is powered by wxPython 4.0.3 based on wxWidgets 3.0.5). More recent wxPython releases such as 4.1.1 are powered by wxWidgets development code, and tests show most NVDA controls and scenarios will work apart from a weird bug where you can’t perform NVDA commands while NVDA menu is opened and a huge lag when message boxes are open. So far, wxWidgets will use MSAA to reveal information about controls to Windows, and in extension, to NVDA. As opposed to this, QT offers an option to use UIA to communicate control information to Windows and NVDA, and anyone who have experimented with Windows 10 apps may have come across all sorts of UIA issues with apps such as Settings and Mail (these are powered by all sorts of GUI toolkits which uses UIA to talk about controls; UIA issues is another reason why I release Windows 10 App Essentials development builds on a weekly basis).

Hope this helps.

Cheers,

JOseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of bering.p
Sent: Wednesday, January 27, 2021 9:24 PM
To: nvda@nvda.groups.io
Subject: [nvda] message announced by NVDA

 

Thank you Joseph for your reply.
I am satisfied with the general behavior of NVDA regarding the announcement of the object description.
But I think in the case of a message issued by NVDA using gui.messageBox and which
presents only a dialog box with a text and one or two buttons, the text must be announced whatever the state of the option.
obviously, this is a point of view and I am perhaps the only one to deactivate the announcement of the description of the objects for the "normal configuratio" profiln.
Best regards
Paul.

Paul.

Le 28/01/2021 04:36, Joseph Lee a écrit :

Hi,

An object’s description is typically retrieved through accessibility API’s, although screen readers can customize certain behavior. This is the approach used by NVDA: NvDA defines dialog text as a dialog’s description. As you’ve observed, if report object descriptions is off, NVDA will not announce description text for controls such as dialog text.

As for defining messages NVDA should announce all the time, in theory, it might be possible. In practice though, think about the following:

1. Different people have different ways to define what “essential” messages are. Some would say dialog text should be announced all the time, while others may say NVDA should announce clipboard operations including in places where you can’t copy or paste things.
2. Screen readers do not possess hundreds of magnifying glasses; that is, screen readers cannot announce everything on the screen.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of bering.p
Sent: Wednesday, January 27, 2021 7:10 PM
To: nvda courrier <nvda@nvda.groups.io>
Subject: [nvda] message announced by NVDA

 

Hi.
I am surprised that this question is not answered .
So I return in my box with it.
Best regards.
Paul.

Le 23/01/2021 09:56, bering.p a écrit :

Hi to all.
I am sharing with you an observation I made concerning the announcement of messages by NVDA and which may be the subject of a PR.

When the option "Report object descriptions" is disabled, NVDA does not speak the text in dialog boxes.
This is annoying when it comes to a message informing the user or questioning him.
For example:
- following a manual search for update request.
- when an add-on uses "gui.messageBox" to query the user.

In this case, it is necessary to read the contents of the dialog box using "NVDA + b".

I think that any message emitted by NVDA should be announced regardless of the state of activation of the option.
What do you think ?
And if you agree, please do the PR.
best regards.
Paul.