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

Accessibility improvement paths for Spyder's custom widgets

Spyder 5.x relies on Qt5/Qt6 for baseline accessibility (AT-SPI, UIA, VoiceOver), yet custom components such as the Variable Explorer and IPython Console do not fully expose roles, states, or focus information to screen readers. Two documented strategies exist:

• Approach A – implement QAccessibleInterface for each custom widget, providing granular ARIA-like roles and live regions.
• Approach B – ship a high-contrast theme and a comprehensive keyboard-shortcut overhaul that leverages Qt's existing accessibility tree without per-widget code.

Constraints shaping the decision

Maintainer bandwidth is limited and competes with feature development. Qt's cross-platform abstraction does not guarantee identical behavior on Windows, macOS, and Linux. Third-party plugins may ignore accessibility guidelines, and high-contrast palettes can clash with editor syntax-highlighting schemes.

Open questions

1. Given the contributor capacity, should Spyder invest in per-widget QAccessibleInterface implementations (Approach A) or prioritize a global theme and shortcut layer (Approach B)?
2. How can the project validate that either strategy delivers consistent screen-reader exposure across all three desktop platforms without a dedicated accessibility test matrix?
3. What governance mechanism would ensure third-party plugins adhere to the chosen accessibility baseline?