Kernel connection failure in the IPython Console component leaves assistive technology status unannounced

Question

Spyder's IPython Console relies on a persistent IPython kernel process. When the kernel crashes or the socket connection is lost, the console becomes non-interactive and execution controls are disabled. Today this transition is conveyed primarily through visual cues in the console and status bar, creating an unresolved decision about how the same state should reach screen reader and keyboard-only users.

The open question is whether Spyder should map kernel connection state to native accessible objects and live-region announcements, or instead expose a separate simplified accessible status view. Because custom panes and shortcuts change across major Spyder releases, and Qt accessibility behavior varies by platform and version, any solution must account for environment-specific differences.

What is the intended accessibility contract for kernel disconnection in the IPython Console? Should the disabled execution controls and non-interactive console state be announced automatically, or surfaced only through a dedicated accessible status pane? What validation approach works across supported Qt versions without relying on visual inspection?

Tasadduq Burney · Answer

Answer
The intended accessibility contract is that kernel disconnection should be announced automatically to assistive technology through updates to the console widget's accessible state and, when supported, a live‑region announcement. A separate accessible status pane is not required.
Confirmed facts

Spyder's IPython Console currently signals kernel loss only via visual changes (console background, status bar).
  No Qt accessibility properties or accessibility events are updated when the kernel disconnects.

Likely explanation
Treat kernel disconnection as a state change of the console widget and its execution controls:

Set the console widget's accessibleDescription to a message such as "Kernel disconnected – execution disabled".
  Set the execution controls' accessible state to include QAccessible::State::Disabled.
  Emit QAccessible::eventStateChanged for those objects.
  If the Qt version in use provides live‑region support (Qt 5.12+), also emit QAccessible::eventLiveRegionChange or use QAccessible::announce() to guarantee immediate screen‑reader output.

Cross‑Qt validation approach

Write a unit test that simulates a kernel crash.
  After the simulated disconnect, query the console widget's QAccessibleInterface to verify that state() includes Disabled and that accessibleDescription contains the disconnection message.
  Install a root object handler (QAccessible::installRootObjectHandler) to capture StateChanged (and, when applicable, LiveRegionChange) events and assert that at least one such event is emitted.
  Perform manual verification with NVDA (Windows), JAWS (Windows), and VoiceOver (macOS) on the minimum Qt version Spyder supports to confirm the announcement is heard.
  If live‑region is used, check that the announcement occurs even when the console widget does not receive focus, by inspecting the screen reader's output log.

Missing diagnostic detail needed to finalize the recommendation: the minimum Qt version that Spyder officially supports. If that version is older than Qt 5.12, live‑region announcements cannot be relied upon and the fallback is to use only accessible description/name changes and StateChanged events.

Kernel connection failure in the IPython Console component leaves assistive technology status unannounced

1 answer

Answer

Confirmed facts

Likely explanation

Cross‑Qt validation approach

Your perspective belongs here.

0 question comments