Reconsidering NVDA's default global gestures through the Magnifier case

[cary-rowen]

NVDA 2026.2 introduces a built-in Magnifier, which is an important step for low vision support. The feature has clear value. Many low vision users rely on a combination of speech, braille, screen magnification, color filtering, and keyboard control. Existing Magnifier discussions also show that keyboard zooming, panning, and cursor/focus tracking can be essential for some users, not just a convenience.

However, the Magnifier also raises a broader long-term design question: when a visual magnification feature is deeply integrated into a screen reader, how many default global gestures should it take up?

This is not an argument against the Magnifier, nor an attempt to exclude low vision users from NVDA's core audience. NVDA serves blind and vision impaired users. The question here is how NVDA should manage default global input gestures as a limited shared resource.

Default global gestures are limited

In theory, keyboards offer many possible combinations. In practice, the number of combinations suitable for default global gestures is much smaller.

As a rough back-of-the-envelope example, on a compact modern laptop keyboard, we might assume around 70 relatively stable non-modifier keys and around 8 reasonably pressable and memorable NVDA modifier patterns. That gives an upper bound of roughly 560 combinations before considering real-world constraints.

This rough number still does not account for:

• keys missing or awkwardly placed on compact laptops;
• conflicts with Windows or application shortcuts;
• combinations that are unstable on localized keyboard layouts;
• the difficulty of pressing three-key or four-key combinations;
• existing NVDA commands, user habits, and add-on ecosystems.

Therefore, the practical pool of comfortable, memorable, conflict-free default gestures is much smaller than the theoretical number of combinations. Default gestures are not just implementation details. They affect user memory, add-on compatibility, and NVDA's long-term interaction model.

The Magnifier case

The Magnifier currently adds a group of default global gestures, including:

• NVDA+shift+w: toggle Magnifier;
• NVDA+shift+= / NVDA+shift+-: zoom in and out;
• NVDA+shift+i: cycle color filters;
• NVDA+shift+l: show an overview of the entire screen;
• NVDA+alt+arrow keys: pan the magnified view;
• NVDA+shift+alt+arrow keys: move to screen edges.

Each command has a reasonable use case. The concern is not that any single command is useless. The concern is that, as a command family, the Magnifier now occupies a significant amount of default global gesture space.

This also raises a product boundary question. On Windows, Narrator and Magnifier are both accessibility features, but they are not treated as the same product. Narrator does not absorb the Magnifier's full shortcut model into its own command set. The features can coexist and complement each other, but their command namespaces are relatively separate.

It makes sense for NVDA to integrate a Magnifier, especially because NVDA can make the magnified view follow the browse mode cursor, navigator object, review cursor, and other screen reader concepts that external magnifiers cannot easily track. But precisely because this integration is deep, NVDA needs clearer boundaries: which Magnifier commands deserve default global gestures, which should be bindable but unassigned by default, and which should be exposed through a command palette or prefix/layered gesture model?

Settings panel shortcuts are another example

The Magnifier is not the only example. NVDA's existing settings panel shortcuts show a similar issue.

NVDA currently uses several NVDA+control+letter gestures to open specific settings panels directly, such as General, Speech, Keyboard, Mouse, Object Presentation, Browse Mode, Document Formatting, Magnifier settings, and others.

These shortcuts are convenient, but from the perspective of default global gesture allocation, this is an expensive use of gesture space. NVDA+control+letter combinations are relatively memorable, pressable, and well suited to global commands. Using many of them only to open individual settings categories reduces the space available for higher-frequency or more central commands.

One possible alternative would be to keep or introduce a single default gesture that opens NVDA Settings and places focus on the category list. From there, users can quickly choose General, Speech, Keyboard, Mouse, Browse Mode, Document Formatting, Magnifier, and other panels.

This would free several NVDA+control+letter default global gestures while preserving access to all settings panels. Power users could still bind gestures to the panels they use frequently. This also aligns with the direction from #4898, where settings panels can be exposed as bindable commands without all needing default bindings.

Related discussions

This issue overlaps with several existing discussions:

• Magnifier: Gestures that do not activate the Magnifier should only take effect while the Magnifier is running. #20074 directly discussed whether some Magnifier gestures should only take effect while Magnifier is enabled. Although that request was closed, it still highlights a broader design problem involving feature state, user custom bindings, and add-on conflicts.
• InputGestures: A facility to allow definition of layered gestures via an input capture method #3687 discusses prefix / layered gestures as a way to reduce global gesture collisions.
• NVDA Command Palette #17209 proposes a command palette so commands without default gestures remain searchable and executable.
• Have NVDA report keyboard shortcut/input gesture collisions for add-ons at load time #15242 discusses reporting input gesture collisions when add-ons load.
• Warn user when overriding a pre-existing input gesture #3605 discusses warning users when they override an existing gesture.
• allow users to set key commands for dialogues which haven't one. #4898 shows that many dialogs and settings panels can be exposed as bindable commands without necessarily having default bindings.

Together, these discussions point to the same underlying problem: NVDA needs clearer default gesture allocation principles, rather than having each new feature compete for global gesture space independently.

Proposal

I suggest that the community use the Magnifier default gestures as a concrete case for discussing a clearer default global gesture allocation policy.

Possible principles:

1. Default global gestures should be reserved primarily for commands that are high-frequency, core to NVDA operation, safety/privacy related, or difficult to access otherwise.

2. Subcommands within a larger feature family should generally be bindable but unassigned by default.
   For example, toggling Magnifier and basic zoom commands may deserve defaults, but panning, edge jumps, mode changes, and similar commands should be reviewed more carefully before receiving default global gestures.

3. Command-heavy features should prefer alternative access models where appropriate.
   For example, the Input Gestures dialog, a command palette (NVDA Command Palette #17209), prefix / layered gestures (InputGestures: A facility to allow definition of layered gestures via an input capture method #3687), or routing based on feature state or context where this can be done safely and predictably.

4. NVDA should improve gesture conflict visibility.
   Collision reporting and override warnings, as discussed in Have NVDA report keyboard shortcut/input gesture collisions for add-ons at load time #15242 and Warn user when overriding a pre-existing input gesture #3605, would help users understand why a gesture does not run the command they expected.

5. Existing default gestures should also be reviewed carefully.
   This discussion should not only affect future features. NVDA has accumulated many historical default gestures. Some may have been justified when introduced, but may no longer deserve default global bindings today. Low-frequency commands, commands with clear alternative access paths, commands with narrow product scope, or commands that mainly open a specific settings panel could be considered for changing to "bindable but unassigned by default." This should not be a sudden disruptive change. It should happen gradually, with documentation, migration notes, and community discussion. The goal is to return valuable gesture space to users and add-on authors.

Summary

The Magnifier is an important addition to NVDA and has real value for low vision users. This discussion is not about weakening the Magnifier.

The broader question is: as NVDA increasingly acts as a screen reader, a platform for visual enhancements, and a foundation for an add-on ecosystem, how should it manage default global gestures?

I hope the Magnifier default gesture set can serve as a concrete starting point for re-evaluating NVDA's default gesture allocation principles, gradually freeing low-frequency defaults where appropriate, and keeping NVDA's command system clear, predictable, and sustainable as the project continues to grow.

[hwf1324]

CC: @CyrilleB79

[CyrilleB79]

Thanks @cary-rowen for opening this discussion.

I globally agree with your observations regarding the scarcity of available acceptable gestures. While many gestures are still free, in practice, we can see that everyone fight for the same subset of gestures: gestures with few modifiers, letters (as opposed to punctuation for example) or arrow / pgUp/Down keys. I'll call them most appreciated gestures.

Quite recently, we have seen tension around gesture attribution when introducing new features with many global context gestures. That is the case for Magnifier, but it has also been the case for Remote Access.

On the other hand, introducing features with mostly unassigned gestures gives a very bad first impression. Often, the user first want to give a try and experiment a bit before actually adopting a new feature. If main gestures are already assigned, this can be done quite easily. If not, the user has to assign gestures just to test, and to unassign them after testing. It is a barrier to new feature adoption IMO.

Looking at Jaws/Zoomtext, they do not experience this shortage of most appreciated gestures. Compared to NVDA, they have 2 advantages:

• they use CapsLock for Zoomtext gestures and Insert for Jaws ones
• they have layered gestures

IMO the best solution to our most appreciated gesture shortage is to have one or both of these capability implemented in NVDA. This would not only open a lot of possible new appreciated gestures but this would be the opportunity to reorganize existing ones. For example, put all the gestures opening settings dialogs/panels in a dedicated layer, e.g. NVDA+o, G = open general settings, NVDA+o, u open audio settings, etc.

In the meantime until this is implemented (if only it is in the future), we can follow principles of points 1 and 2. And globally, I think we actually try to. But these principle are here to guide our reflection, they are not hard rules. For example:

• Remote Access is not a core feature and is used only be a subset of users. Though, providing the already assigned gesture needed by the assisted person was quite mandatory.
• Magnifier introduces a lot of gestures. It's useful to think twice before assigning them (point 2).
  • I have been one advocating for default panning / jump to edge gestures. But on the other hand for people using them, panning / jump commands are high frequency: they are used quite frequently and each time they are used, they are used repeatedly to adjust the view position.
  • Full screen overview (NVDA+shift+l) is a feature with no other way to access it. If we remove the shortcut this will very likely make this feature used much less often and less discovered / experimented by new users. Then this questions the usefulness of the feature itself. I am personnally not a user of this feature. But the fact that Magnifier has added an 1x toggle command quite recently seems to prove it is useful for some.
  • Color filter (NVDA+shift+I): I'd say that this one is the one that can more logically be unassigned by default since there is a corresponding setting. Though, early Magnifier versions had not this command assigned, and its assignment has been explicitly requested and implemented. So such question would need to be discussed with ones who have requested this.

More generally, there are a lot of special cases. For example regarding Magnifier again. Even if it takes a lot of gestures, to me, it makes sense to have most of them assigned by default. When people gradually lose their sight, they first try to use Magnifier to see better things on screen. But trainers quickly push them as much as possible to use keyboard rather than mouse which becomes less easy to use. Unassigned gestures is one more barrier in this process.

If I'd have to write a rule of thumb to define if commands should be assigned or not, I'd say that commands to modify a setting should be unassigned and all other ones should.

At last, an additional question: @cary-rowen, what does "core to NVDA operation" exactly mean for you?

[wmhn1872265132]

I believe that features such as remote access and the magnifier, which are not used by all users, should not have non-essential gestures defined globally. Instead, they should be defined within their respective modules, similar to how browse mode works. This way, the impact on users who do not use these features is minimized.

Specifically:

• Remote access: When the feature is disabled, all default gestures should be released. This behavior is also consistent with the disappearance of the corresponding menu item from the Tools menu when the feature is disabled.
• Magnifier: Only the zoom in and enable/disable gestures should be defined globally. All other gestures should be released when the magnifier is disabled.

[CyrilleB79]

I disagree with the proposal to disable gestures for users who are not using Magnifier or Remote access. Disabling these gestures does not actually free them for other uses.

For example, imagine that the control+alt+arrow panning gestures are disabled whenever Magnifier (or Magnifier command mode) is inactive. If those gestures are then assigned to another core feature, such as a new sound management core feature like in some add-ons, what happens when a Magnifier user also wants to use that sound management feature?

They would have to disable Magnifier (or exit Magnifier command mode) just to access the sound controls and reenabling it just after, which would make the workflow less fluid and less convenient.