Brian - Windows 10, 64-Bit, Version 21H1, Build 19043  

I do not understand why some seek to separate a person from their actions.  The self is composed of an individual’s thoughts, actions, and expression, which are contained in and actuated by the body.  What you do and say is the clearest indicator of who you are.

      ~ Brian Vogel

It happens for a few lines and then stops.

Brian - Windows 10, 64-Bit, Version 21H1, Build 19043  

I do not understand why some seek to separate a person from their actions.  The self is composed of an individual’s thoughts, actions, and expression, which are contained in and actuated by the body.  What you do and say is the clearest indicator of who you are.

      ~ Brian Vogel

Windows Magnifier

• Author: Cyrille Bougot
• NVDA compatibility: 2018.3 and beyond
• Download stable version
• Download development version

This add-on improves the use of Windows Magnifier with NVDA.

Features

• Allows to report the result of some native Magnifier keyboard commands.
• Allows to reduces the cases where table navigation command conflict with Magnifier's commands.
• Adds some keyboard shortcuts to toggle various Magnifier options.

Settings

The setting panel of Windows Magnifier extension allows to configure how NVDA reacts to native Windows Magnifier commands. You may want to have more or less commands reported according to what you are able to see. This panel may be opened choosing Preferences -> Settings in the NVDA menu and then selecting the Windows Magnifier category in the Settings window. The keyboard shortcut NVDA+Windows+O then O also allows to open this settings panel directly.

The panel contains the following options:

• Report view moves: controls what is reported when you move the view with Control+Alt+Arrows commands. The three options are:

  • Off: Nothing is reported
  • With speech: a speech message indicate the position of the zoomed view on the dimension the view is being moved.
  • With tones: a tone is played and its pitch indicates the position of the zoomed view on the dimension the view is being moved.

  This option only affects full view mode.

• Report turn on or off: If checked, the Magnifier's state is reported when you use Windows++ or Windows+Escape commands to turn it on or off.
• Report zoom: If checked, the Magnifier's zoom level is reported when you use Windows++ or Windows+- zoom commands.
• Report color inversion: If checked, the color inversion state is reported when you use the control+Alt+I toggle command.
• Report view change: If checked, the view type is reported when you use a command that changes the view type (Control+Alt+M, Control+Alt+F, Control+Alt+D, Control+Alt+L)
• Report lens or docked window resizing: If checked, a message is reported when you use the resizing commands (Alt+Shift+Arrows). In docked window mode, the height or the width is reported. In lens mode, the new dimension cannot be reported for now. These resizing command do not seem to be available on all versions of Windows; if your Windows version does not support them, you should keep this option unchecked.

• In documents and list views, pass control+alt+arrows shortcuts to Windows Magnifier: There are three possible choices:

  • Never: The command is not passed to Windows Magnifier and standard NVDA table navigation can operate. When used in documents out of a table, Control+Alt+Arrow commands report a "Not in a table" error message. This is the standard behaviour of NVDA without this add-on.
  • Only when not in table: In table or in list views, Control+Alt+Arrow commands perform standard table navigation. When used in documents out of a table, Control+Alt+Arrow commands perform standard Magnifier view move commands. If you still want to move Windows Magnifier view while in table or in list view, you will need to press NVDA+F2 before using Control+Alt+Arrow commands. This option is the best compromise if you want to use Control+Alt+Arrow for both Magnifier and table navigation.
  • Always: Control+Alt+Arrow commands moves the Magnifier's view in any case. This option may be useful if you do not use Control+Alt+Arrow to navigate in table, e.g. because you have changed table navigation shortcuts in NVDA or because you exclusively use Easy table navigator add-on for table navigation.

Commands added by this add-on

In addition to native Magnifier commands, this add-on provide additional commands that allow to control Magnifier's options without opening its configuration page. All the commands added to control Magnifier options are accessible through the Magnifier layer command NVDA+Windows+O:

• NVDA+Windows+O then C: Toggles on or off caret tracking.
• NVDA+Windows+O then F: Toggles on or off focus tracking.
• NVDA+Windows+O then M: Toggles on or off mouse tracking.
• NVDA+Windows+O then T: Toggles on or off tracking globally.
• NVDA+Windows+O then S: Toggles on or off smoothing.
• NVDA+Windows+O then R: Switches between mouse tracking modes (within the edge of the screen or centered on the screen); this feature is only available on Windows 10 build 17643 or higher.
• NVDA+Windows+O then X: Switches between text cursor tracking modes (within the edge of the screen or centered on the screen); this feature is only available on Windows 10 build 18894 or higher.
• NVDA+Windows+O then V: Moves the mouse cursor in the center of the magnified view (command available in full screen view only).
• NVDA+Windows+O then O: Opens Windows Magnifier add-on settings.
• NVDA+Windows+O then H: Displays help on Magnifier layer commands.

There is no default direct gesture for each command, but you can attribute one normally in the input gesture dialog if you wish. The same way, You can also modify or delete the Magnifier layer access gesture (NVDA+Windows+O). Yet, you cannot modify the shortcut key of the Magnifier layer sub-commands.

Magnifier's native commands

The result of the following Magnifier native commands may be reported by this add-on, according to its configuration:

• Start Magnifier: Windows++ (on alpha-numeric keyboard or on numpad)
• Quit Magnifier: Windows+Escape
• Zoom in: Windows++ (on alpha-numeric keyboard or on numpad)
• Zoom out: Windows+- (on alpha-numeric keyboard or on numpad)
• Toggle color inversion: Control+Alt+I
• Select the docked view: Control+Alt+D
• Select the full screen view: Control+Alt+F
• Select the lens view: Control+Alt+L
• Cycle through the three view types: Control+Alt+M
• Resize the lens with the keyboard: Shift+Alt+Left/Right/Up/DownArrow. Note: although this does not seem to be documented, this shortcut seems to have been withdrawn in recent Windows versions such as Windows 2004.
• Move the magnified view: Control+Alt+Arrows (reporting only affects full screen mode)

Here is also a list of other Magnifier native commands, just for information:

• Control+Alt+mouseScrollWheel: Zooms in and out using the mouse scroll wheel.
• Control+Windows+M: Opens the Magnifier's settings window.
• Control+Alt+R: Resizes the lens with the mouse.
• Control+Alt+Space: Quickly shows the entire desktop when using full screen view.

None of the Magnifier native commands can be modified.

Notes

• For computers equipped with an Intel graphic card, control+alt+arrow (left/right/up/down) are also shortcuts to modify the orientation of the screen. These shortcut are enabled by default and conflict with Windows Magnifiers shortcuts to move the view. You will need to disable them to be able to use them for the Magnifier. They can be disabled in the Intel control panel or in the Intel menu present in the system tray.

• Depending on your Windows version, Alt+Shift+Arrow are Windows Magnifier shortcuts to resize the magnified view (lens or docked). When Magnifier is active (even in full screen mode), these shortcuts are captured by Magnifier and cannot be passed to the application, even if you press NVDA+F2 before. To use these shortcuts in the current application, you need to quit the Magnifier (Windows+Escape) and re-open it after (Windows++). For example in MS word, to decrease title level:

  • Press Windows+Escape to quit Magnifier.
  • Press Alt+Shift+RightArrow to decrease current title level.
  • Press Windows++ to re-open the Magnifier.

• For more information about Windows Magnifier's features and shortcuts, you may want to consult the following pages:

  • Use Magnifier to make things on the screen easier to see
  • Windows keyboard shortcuts for accessibility

Change log

Version 1.0

• Initial release.

Hi all,

As Luke and others pointed out, there are lists dedicated to programming, and in case of NVDA specifically, there is NVDA Development list. I think both lists are good, but that won't solve the issue the original poster is looking into, and you can indeed create accessible GUI-based applications (although counterintuitive, NVDA is an accessible GUI-based application if you think about it). What I'm going to write comes from my experience as a programmer who spent years working on screen readers and have been advocating for accessibility and usability (like Luke, I'm blind, although I was a low vision user until my early teens, which was early 2000's):

As you may know, the first task of programming is looking for a problem to solve. The fact that you wish to write an app that is accessible is very notable, in that you may have found some issues you wish to solve by writing apps, along with looking at app design at the same time. So I'll assume you did your first task, so let's move onto design and accessibility aspects.

Accessibility is about designing products so it is approachable by different audiences (the task of actually using such products with help from assistive tools falls under "usability"). The question to ask when designing products with accessibility in mind is, "what are limitations and workarounds specific audiences need, and how can the product help bridge the gap that might be present for audiences?" For people with disabilities, the question falls under limitations of specific disabilities and tools that can expose your product functionality to specific audiences; for blind people, the obvious choice is using tools to help folks "see" screen content i.e. screen readers, magnifiers, color contrast, and so on; for deaf communities, using text to convey sounds, sign language output and what not. Then you would look for a way to make programs expose needed information so audiences (users) can use your product effectively, and one common scenario is using accessibility API's to communicate information to users of assistive technologies.

In GUI programming (something that's possible for blind people to do although with assistance if required), one would design data representation style (specific GUI controls for things such as text, forms, and many others). Although things may look colorful and intuitive for the majority (the term "majority" depends on language, country, and culture), without effort from humans and tools (along with mindset), the product would not be discoverable (wqord of mouth, review,s etc.), approachable (promotion, demos, etc.), and accessible (these three things must work together when accessibility is concerned, because people with disabilities are some of the most neglected communities when it comes to access to information (what I would term "information blackout"), although that is changing).

So to enhance how the product is seen by people with disabilities and to make them accessible (and usable), API's such as Microsoft Active Accessibility, UI Automation, IAccessible2 were created to help programmers design products with accessibility and usability in mind. These API's consist of at least three parts:

1. Client/consumer: an assistive technology such as screen readers (including NVDA) is an accessibility client. The job of a client is to ask accessibility API's for information about a control a user is working on, and to perform specific actions required to help people use specific applications such as reading state changes.
2. Server/producer: the application in question is a server because it serves clients by exposing crucial information for use by different assistive technologies. For screen readers, this means using text labels for graphical buttons, using facilities such as accessibility events to communicate activities such as screen content changes. How such info is communicated to users is the job of the client (assistive technology), and it is up to users as to what to do with information coming from the app.
3. Accessibility bridge: API's such as MSAA and UIA serve as a bridge between servers (apps) and clients (assistive technologies). The job of accessibility API bridges is to serve as a "middle man" between users and apps by exposing server-side information (whatever the app says) in a way clients can understand, process, and present to users. At the same time, bridges accept interaction tasks (such as keyboard input) from users, communicates these facts to applications, and see what the app says.

A basic grasp of accessibility concepts is one of the steps involved in improving app accessibility (the first obvious step is understanding the culture the target audience comes from, a task you have accomplished well based on the original post). The next task is actually using assistive technologies and apps to better understand what folks are talking about. After that, it comes down to designing programs in a way that is accessible for diverse audiences such as adding labels for GUI controls and using accessibility API's to expose needed information (if using GUI toolkits, I recommend using ones known to have high accessibility marks such as wxWidgets and more recent versions of QT and WinUI/XAML). And don't forget to test your ideas with target audiences (testing, gathering feedback, etc.) early because it is more costly to "improve" accessibility later.

Before I close, one thing you may wish to ponder: if you think carefully about it, NVDA and other screen reader friends are sophisticated data processors. Their job is to gather needed information for blind people with help from facilities provided by the operating system + accessibility API's + apps + standards, process gathered information in a way suitable for presentation through multiple channels (speech, braille, sound, etc.), and presenting information to users. That's the core of screen readers, and when folks talk about screen reader development, we are talking about refining these elements (supporting newer accessibility standards, dealing with apps with no control labels, support for text-to-speech engines and braille displays, keeping an eye on operating system changes, etc.). Of course folks can customize screen readers to their liking (settings, code, add-ons, etc.). at the same time, app accessibility and usablity falls upon the responsibility of app developers, made better when they collaborate with users (this is why I always ask users to send feedback to developers to point out possible accessibility improvements).

Hope this helps a lot.

Cheers,

Joseph