Keyboard‑only operation limits in Blender’s keymap and operator system

Keyboard Accessibility in Blender 4.0

Blender 4.0 does not support complete keyboard-only interaction across all interface elements. While most operators can be triggered via the keyboard, the software's custom UI toolkit and reliance on coordinate-based modal operators create fundamental gaps in keyboard-only accessibility.

UI Components Lacking Documented Keyboard Shortcuts

Several components rely on mouse-driven events that are not mapped to discrete keyboard shortcuts by default:

• Color Pickers: Selecting a specific hue or saturation from the visual color wheel requires mouse coordinates.
• Drag-to-Adjust Fields: While numeric values can be typed, the "click-and-drag" interaction for rapid adjustment of sliders lacks a universal keyboard equivalent.
• Coordinate-Dependent Modals: Operators like bpy.ops.transform.translate (Grab) or rotate rely on mouse delta movement. While these can be constrained to axes (X, Y, Z) and modified by numeric input, the initial target selection and free-form movement are mouse-centric.
• Context-Sensitive Region Switching: Moving focus between disparate UI panels (e.g., from the Outliner to the Properties panel) often requires mouse clicks or specific, non-intuitive keymap assignments.

Verifying Operator Accessibility

To determine if a specific UI action can be performed without a mouse, use the following verification workflow:

1. Identify the Operator: Enable Developer Extras and Python Tooltips in Edit > Preferences > Interface. Hover over the UI element to see the Python operator name (e.g., bpy.ops.mesh.subdivide()).
2. Test via Search: Press F3 to open the Search menu and type the operator name. If the operator executes successfully from the search menu, it is keyboard-accessible.
3. Check Keymap: Navigate to Preferences > Keymap and search for the operator name to see if a default shortcut exists or if one can be assigned.

Reference for Assistive Technology Planning

There is no stable, exhaustive reference in the official manual that lists all "mouse-only" gaps. Because Blender uses a custom UI toolkit rather than standard OS widgets, it does not expose a standard accessibility tree to screen readers. Planning for assistive technology requires a manual audit of the specific workflow, as accessibility is often achieved through a combination of the F3 search menu and custom keymap assignments.

Assumptions and Limitations

This analysis assumes a standard Blender 4.0 installation. It is uncertain whether third-party accessibility plugins have bridged these gaps, as these are not part of the core documented system. One diagnostic detail required for further refinement: Are you targeting a specific accessibility standard (e.g., WCAG) or a specific assistive device (e.g., screen reader vs. switch access)?