Target: microsoft/vscode
Issue: microsoft/vscode#247522
PR: microsoft/vscode#320877
Field Lab: https://github.com/scarab-systems/scarab-field-lab
This field test targeted a Visual Studio Code accessibility regression where mouse echo stopped working correctly with screen readers such as NVDA and JAWS.
The visible issue is user-facing and serious:
- a screen reader is running
- mouse echo is enabled
- the user moves the mouse over text in the VS Code editor
- the screen reader no longer announces the text under the pointer
- the behavior reportedly worked in older VS Code versions
For affected users, this is not a cosmetic regression. Mouse echo is part of how some users inspect and navigate visible text through assistive technology.
But the important diagnostic question was not simply:
How do we fix mouse echo?
The better question was:
Which part of this failure does VS Code actually own?
Field Lab record
The public case record for this field test is available in the Scarab Field Lab:
https://github.com/scarab-systems/scarab-field-lab
SDS result
This was run in full SDS field-test posture against a disposable VS Code arena.
The completed run used product-level diagnose with a full audit profile and full execution mode. It scanned the VS Code target broadly rather than using a bespoke one-off query aimed at the final patch.
That matters because the final repair was not pre-baked into the diagnostic.
SDS did not surface a literal instruction that said:
Add Chromium feature flags.
That is not what happened.
Instead, SDS surfaced the surrounding runtime, configuration, accessibility, and Electron boundary strongly enough to support a bounded repair.
That distinction matters.
A diagnostic system should not have to invent a patch to be useful. Sometimes the correct diagnostic output is the neighborhood: the owned surface where the project can act without pretending to own the entire root cause.
In this case, that owned surface was VS Code’s runtime argument and Electron startup configuration path.
Failure shape
The reported regression sits at the intersection of several layers:
- VS Code editor behavior
- assistive technology behavior
- Windows screen readers such as NVDA and JAWS
- Electron
- Chromium accessibility-provider behavior
- VS Code desktop runtime startup configuration
That is a dangerous shape for a patch.
When a bug crosses that many layers, it is easy to repair the wrong thing.
A patch could try to change editor rendering.
A patch could try to alter screen-reader interaction.
A patch could try to encode assumptions about NVDA or JAWS.
A patch could pretend VS Code owns a Chromium/Electron provider regression that actually sits lower in the stack.
That would be too broad.
The better repair lane was smaller:
VS Code can expose a persistent way to pass Chromium feature flags through its own runtime configuration path.
That does not fix the underlying provider bug.
But it gives maintainers and affected users a stable way to apply Chromium/Electron feature-flag diagnostics or workarounds while the deeper accessibility regression is investigated.
Boundary
The boundary here is:
VS Code-owned runtime configuration
versus
Chromium/Electron accessibility-provider behavior
VS Code does not own every part of the accessibility-provider stack.
It does not own NVDA.
It does not own JAWS.
It does not own Chromium.
It does not own every Electron-level accessibility behavior.
But VS Code does own part of the path by which Electron and Chromium startup switches are configured and allowed through.
That is the repair surface.
The patch stays inside that surface.
It does not change editor rendering.
It does not change screen-reader APIs.
It does not change mouse-hit testing behavior.
It does not assert that one Chromium feature combination is correct for every user.
It adds a persistent runtime feature-flag path through VS Code’s existing argument/configuration machinery.
That is a boundary repair, not a root-cause claim.
What changed
The PR adds support for:
enable-features
and
disable-features
across VS Code’s native runtime argument path.
The patch wires those switches through:
- native parsed args
- CLI parser options
- the argv.json schema
- the supported Electron switch allowlist
The values are documented as comma-separated Chromium feature names.
Default behavior is unchanged. These switches are only forwarded when explicitly configured.
That last point is important.
This patch does not impose a feature flag on all users. It does not decide which Chromium accessibility-provider behavior is correct. It creates a supported path for maintainers and affected users to persist runtime flags when they need to test or apply a workaround.
Focused tests cover the parser behavior, including empty and repeated values.
Why this was not an editor rendering fix
The obvious place to look is the editor.
The failure is experienced in the editor. The user moves the mouse over editor text. The screen reader does not announce what it used to announce.
But “where the user feels the bug” and “where the project owns a safe repair” are not always the same place.
That is especially true in desktop applications built on Electron.
A user-facing accessibility regression may pass through VS Code UI, Electron accessibility APIs, Chromium accessibility-provider behavior, and external screen-reader expectations before it becomes visible.
If VS Code does not yet own the root lower-level behavior, a narrow patch should not pretend it does.
The safer repair is to expose a configuration path that allows the lower-level behavior to be tested or worked around without distorting editor code.
That is what this patch does.
It keeps the repair in the runtime startup boundary instead of pushing speculative accessibility logic into the editor surface.
Why the diagnostic result mattered
This case is useful because SDS did not produce a magic answer.
It produced a bounded evidence neighborhood.
That is closer to how real debugging often works.
The value was not:
SDS found the exact patch.
The value was:
SDS narrowed the relevant ownership area enough that the patch could stay small.
For a cross-layer accessibility regression, that matters.
The stack has too many tempting surfaces. A coding agent could easily chase symptoms into editor code, screen-reader assumptions, or Electron internals. A human could do the same.
The diagnostic question kept the repair grounded:
Which surface does VS Code own that can help maintainers and users investigate this regression without claiming to fix the lower-level provider bug?
The answer was the native argument/configuration/Electron switch path.
Validation
The patch was validated with VS Code project checks and a focused parser test.
The focused test confirmed the Chromium feature switches are recognized through the argument parser.
For the full validation record and public status, see the Field Lab case record:
https://github.com/scarab-systems/scarab-field-lab
Field test result
This was a bounded runtime-configuration repair candidate for a VS Code accessibility regression.
The issue reduced to:
- mouse echo is broken for affected screen-reader users
- the root regression appears to involve Chromium/Electron accessibility-provider behavior
- VS Code should not claim to own the entire lower-level provider bug
- VS Code does own its runtime startup argument/configuration surface
- adding enable-features and disable-features gives maintainers and affected users a persistent feature-flag path
- default behavior remains unchanged unless the switches are explicitly configured
That is the repair lane.
This patch does not claim to fix NVDA.
It does not claim to fix JAWS.
It does not claim to fix Electron.
It does not claim to fix Chromium.
It gives VS Code a cleaner owned configuration path while the deeper accessibility-provider regression is investigated.
That is the Scarab boundary:
do not claim the root bug when the evidence supports a narrower owned surface.
Public claim
The correct claim for this field test is:
Scarab/SDS helped drive a bounded repair candidate for microsoft/vscode#247522, an accessibility regression involving mouse echo behavior with screen readers such as NVDA and JAWS. A full SDS field-test diagnose surfaced the runtime/configuration/accessibility/Electron boundary strongly enough to support a narrow VS Code-owned repair path. The upstream PR adds enable-features and disable-features to VS Code’s native argument parser, argv.json schema, and Electron switch allowlist so maintainers and affected users have a persistent Chromium feature-flag path while investigating the lower-level accessibility-provider regression. This does not claim to fix the root NVDA, JAWS, Electron, or Chromium bug.
Disclosure: This field report was prepared with AI-assisted editing from my own field-test notes, public issue and PR records, validation summary, and repair record. The technical claims and final wording were reviewed before publication.
Top comments (5)
This is a fantastic example of boundary-aware diagnostics in complex software systems. I really appreciate how you distinguished between the user-facing bug and the owned repair surface, keeping the patch within VS Code’s runtime configuration while respecting the Chromium/Electron accessibility-provider layer. The approach of surfacing a bounded neighborhood for maintainers instead of overstepping into assumptions about NVDA, JAWS, or Electron is a lesson in safe and responsible patching.
I’d love to collaborate and explore similar approaches for cross-layer debugging and accessibility diagnostics, perhaps combining automated field tests with AI-assisted analysis to identify safe repair lanes. If you’re open, we could exchange methodologies, test strategies, and even prototype tools that help developers identify the minimal owned surface for complex regressions.
Would you be interested in discussing a joint experiment in this space?
I am always interested in collaborating on cross lane ideas and experiments.... to be clear though Scarab is fully AI autonomous... the only part that AI actually comes in is for the narrow bounded repair.... so the evidence for the bounded repair is surfaced in a completely mechanical deterministic fashion... and yes lets talk more!
I'd love to hear your ideas!
Thanks — and quick correction to my wording above: I meant Scarab/SDS is not AI-autonomous. The diagnostic layer is mechanical/deterministic; AI may assist later with a bounded repair or explanation, but it does not decide the diagnostic finding.
I’m open to talking further. Before moving to a call, could you share a GitHub profile, project link, or short public write-up of the kind of cross-layer/accessibility debugging experiment you have in mind? That would help me understand the fit and keep the collaboration grounded.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.