-
-
Notifications
You must be signed in to change notification settings - Fork 637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow "report notifications" to toggle UIA notification announcements #10956
Comments
In File Explorer, also Wifi enabling/disabling is reported when using dedicated HW button. |
Hi, the biggest issue to note is that it might or might not be possible to separate volume change announcements from the rest. As part of UIA notification event, an activity Id is generated, which describes which activity triggered such an announcement. For Word 365 problems, it is possible to prevent announcement of certain things because activity Id’s are different, which may not be so for File Explorer (that is, if the activity Id is same for volume and brightness change announcements, we run into a problem). As for announcing volume and brightness changes from everywhere, this can be done by asking File Explorer app module to not pass this event onto default event handler (defined in UIA objects collection), as the default handler will ignore events from background apps. Thanks.
|
Hi, A few months later... JAWS 2021 implements the second alternative from above: a dedicated checkbox inside Settings Center to toggle UIA notification announcement. Given that UIA notifications are really meant for AT's and are quite different than typical notifications such as ones shown in Action Center, I propose implementing a dedicated checkbox (only visible if Windows 10 Fall Creators Update/Version 1709 or later) to toggle this. Thanks. |
…nvaccess#10956. Toasts, help balloons and others are not really the same thing as UIA (accessible event) notifications. Therefore add a completley different setting to toggle UIA notification announcements. The key mentions UIA notifications because that's where accessible event messages come from.
…o do so by users. Re nvaccess#10956. By default, UIA notification events will be handled, but if it isn't, return early from notification event handler.
… checkbox. Re nvaccess#10956. Separate from 'report notifications' setting, add a checkbox to toggle UIA (accessible event) notification announcement.
…ses earlier than Version 1709 (Fall Creators Update). Re nvaccess#10956. As UIA notification event (part of IUIAutomation5) was introduced in Version 1709, disable this checkbox if using earlier releases.
nvaccess#10956. In order to support announcing UIA notifications from the foreground (focused) app, change UIA notification announcement setting from a boolean to an option list. The available settings are 'always', 'focused app', and 'off'.
…or is coming from a background app. Re nvaccess#10956. Do not announce UIA notifications if: * Notifications are off. * Notifications are coming from background apps when NVDA is asked to announce notifications from the focused app.
…cations' from a checkbox to a combo box. Re nvaccess#10956. Suggested by Leonard de Ruijter: add a possibility to limit UIA notification announcement to focused app. To do this, change accessible event notifications control from a checkbox to a combo box. Also, add a dedicated tuple containing settings and labels for UIA notifications combo box and refer to it when setting and retrieving values when saving object presentation settings.
…w 'focused app'. Re nvaccess#10956. Reviewed by Leonard de Ruijter: for backward compatibility, default notification value is focused app - announce notifications coming from the app the user is using at the moment.
nvaccess#10956. Suggestion from Leonard de Ruijter (subtle optimization): swap focused app and app module check: app modules will be compared if UIA notification setting is set to 'focusedApp', otherwise return early.
…oreground'. Re nvaccess#10956. Suggestion from Leonard de Ruijter: rename 'focused app' to something more descriptive that informs users that notifications will be announced from focused apps.
Suggestion from Reef Turner (NV Access): add an extra parentheses to clarify focused app check syntax and semantics. Co-authored-by: Reef Turner <feerrenrut@users.noreply.github.com>
…ns. Re nvaccess#10956. Comment from Reef Turner (NV Access): contextualize accessible event (UIA notification) options through pgettext.
…ions -> report UIA accessible event notifications. Re nvaccess#10956. Reviewed by Reef Turner (NV Access): object presentation settings panel inclues 'report notifications' setting to announce help balloons and toasts, and adding a setting called 'accessible event notifications' can confuse users as to what 'accessible event notifications' are. Therefore clarify that the new setting refers to UIA notifications. This change is also applied to the user guide.
Hi, Update: based on #11590 discussion, a more generalist approach would be better:
The biggest advantage is that it is future-proof - UIA notifications can be treated as app notifications just like alerts in web browsers. So if the accompanying PR is successful, it will open up opportunities to let contributors take advantage of the new settings. To help with feature discoverability, I think a new property should be added to NVDA objects to specify if an object should report notifications and alerts if raised (separate issue). Thanks. |
…ification event. Re nvaccess#10956. UIA notification event should be handled if: 1. App notifications is on. 2. And NVDA is told to announce foreground notifications and the user is using the app in question. 3. Or all app notifications can be announced provided that app notifications is on. Subclasses can change this behavior in their own UIA notification event handlers.
…ification values, remove 'off'. Re nvaccess#10956. Rename notification values to app notification values, and remove 'off' due to report notifications UI redesign (next commit).
Hi,
A more generic request (see #10626 for specifics):
Is your feature request related to a problem? Please describe.
IN Windows 10 Version 1709/IUIAutomation5, UIA notification event was introduced to let screen readers such as NVDA and Narrator announce useful information. This is used in various apps, including:
Although UIA notification announcements are important, they can become annoying, particularly when announcements are repeated in quick succession. For example, as discussed in #10626, whenever a user changes volume, UIA notification event is fired by File Explorer to announce new values every time volume up/down buttons are pressed. Similarly, as documented in #10851, certain editing functions in recent Word 365 releases present results via UIA notification message.
Describe the solution you'd like
As discussed in #10626, let "report notifications" checkbox in object presentation settings panel toggle UIA notification announcement as well. This may mean redefining what a notification is in the user guide. The obvious advantage of this change is ability to configure app-specific profiles to silence UIA notifications, but this change won't solve notifications coming from background processes (Microsoft and app vendors must be reminded about using this event under specific circumstances).
Describe alternatives you've considered
Two alternatives:
Additional context
For practical issues, see #10626, #10851, and #10950 (the last one is important for translators as it will result in double speaking and/or odd text being announced for editing functions as opposed to what translators specified for earlier Word releases).
Thanks.
The text was updated successfully, but these errors were encountered: