Per-widget Qt Accessible interfaces vs. global high-contrast theme: which accessibility strategy fits Spyder's contributor bandwidth?

Answer

With limited maintainer bandwidth competing with feature work, Approach B — a global high-contrast theme plus a comprehensive keyboard-shortcut overhaul that relies on Qt's existing accessibility tree — fits Spyder's contributor capacity now. Approach A — per-widget QAccessibleInterface implementations for Variable Explorer, IPython Console and other custom components — delivers better screen-reader semantics but requires sustained C++/Python interface work and ongoing maintenance per widget change.

Confirmed facts

• Spyder 5.x builds on Qt5/Qt6. Qt provides platform bridges: AT-SPI on Linux, UIA on Windows, NSAccessibility on macOS. Baseline accessibility is framework-provided.
• QAccessibleInterface exists in Qt and allows explicit roles, states and live regions for custom widgets. It is per-widget code and must be kept in sync with widget changes.
• Qt styles and keyboard handling are largely platform-agnostic within the framework. A high-contrast palette and shortcut layer can be shipped without custom interface classes.
• High-contrast palettes can clash with editor syntax-highlighting schemes. That is a known coordination cost.

Likely explanation

Contributor bandwidth is the binding constraint. Approach A gives superior screen-reader support by defining granular ARIA-like roles, but it demands high maintenance for every custom widget update and platform-specific validation because Qt's accessibility layer does not guarantee identical behavior on Windows, macOS and Linux.

Approach B requires significantly lower contributor bandwidth because it leverages existing Qt styles and input handling. Keyboard shortcut overhauls are high-leverage and low-cost for accessibility. A global theme does not resolve the fundamental lack of semantic information for screen readers, so the application remains partially inaccessible to visually impaired users. That is a trade-off, not a fix.

Steps needed for this case

1. Audit current exposure. Run Spyder with a screen reader on each desktop and inspect the accessibility tree.
   • Windows: NVDA + Inspect
   • Linux: Orca + AT-SPI tools
   • macOS: VoiceOver + Accessibility Inspector
   Verify whether Variable Explorer and IPython Console are recognized as generic containers or specific functional roles.
2. Ship a high-contrast theme with WCAG contrast checks against syntax themes. Test the palette against the editor and UI shells to avoid clashes.
3. Deliver a keyboard-shortcut overhaul with discoverable shortcuts, focus order and visible focus indicators. Keep shortcuts consistent with Qt conventions.
4. Add governance for plugins. Document an accessibility baseline in CONTRIBUTING and require plugins to use standard Qt widgets and expose names, roles and keyboard focus.

Uncertainty note: QAccessibleInterface implementations can introduce memory leaks if object lifecycles are not managed correctly within the Qt accessibility cache. Reliance on default Qt accessibility roles may lead to inconsistent behavior across OS versions. These risks are marked for human review.

One missing diagnostic detail that changes the recommendation: which Qt major version is targeted for the next Spyder release and whether at least one maintainer can own per-widget accessibility for two release cycles. If Qt6 is locked and a dedicated owner exists, a phased Approach A for the two highest-impact widgets becomes viable.