OnDebugBreak

Plays a signal - sound (audio cue) and/or announcement (alert) - when the debugger stopped on a breakpoint.

{
  "accessibility.signals.onDebugBreak": {
    "sound": "auto",
    "announcement": "auto"
  } // default
}

Type

object

Default

{
  "sound": "auto",
  "announcement": "auto"
}

Object Properties

KeyTypeDefaultRangeDescription
"sound"string"auto""auto", "off", "on"Plays a sound when the debugger stopped on a breakpoint.
"announcement"string"auto""auto", "off"Announces when the debugger stopped on a breakpoint.

Description

Controls if sound and announcement signals are played when the Debugger stops on a breakpoint.

When "sound" is set to "auto", the sound signal will play whenever the Debugger stops on a breakpoint and a screen reader is detected or "editor.accessibilitySupport": "on". When set to "off", the sound signal will never play even when a screen reader is detected or "editor.accessibilitySuport": "on". When set to "on", the sound signal will always play even when a screen reader is not detected or "editor.accessibiltySupport": "off".

When "announcement" is set to "auto", the screen reader will make the announcement whenever the Debugger stops on a breakpoint and a screen reader is detected. When set to "off", the screen reader will never make an announcement even when a screen reader is detected.

NOTE: This is plays the same sound as accessibility.signals.lineHasBreakpoint and if you are debugging you will hear the sound and announcement twice since hitting a breakpoint in Debugging focuses the line that has the breakpoint. To avoid this, have "accessibility.signals.lineHasBreakpoint": "on" and "accessibility.signals.onDebugBreak": "off" or vice versa. I prefer this way since I get signals in the normal Editor and while debugging.

accessibility.signals.lineHasBreakpoint