Alex: Welcome back. This episode is a companion reference for VS Code accessibility. The main chapters help you get comfortable; this one is the place you come back to when you need the exact setting, shortcut, or screen reader behavior.

Jamie: So the goal is not to memorize every setting path. It is to know where to look when VS Code starts feeling noisy, quiet, confusing, or hard to navigate.

Alex: Exactly. The appendix supports the VS Code interface and accessibility chapters, and it points back to the official VS Code accessibility documentation as the source of truth. VS Code changes over time, so if a setting name shifts, the current docs and the Settings UI are the final check.

Jamie: And because this is a long reference, there are some practical ways to use it. Go to Line with Ctrl+G, Go to Symbol with Ctrl+Shift+O, jump between tables with T in browse mode, and use larger zoom or a high contrast theme before scanning dense tables. If your setup has the bookmark command on Ctrl+K Ctrl+K, bookmark the file so you can return quickly.

Alex: Most accessibility settings are available in two places: the Settings UI with Ctrl+comma, or settings.json through the Command Palette with Ctrl+Shift+P, then Open User Settings JSON. The Settings UI is safer for browsing. settings.json is faster when you already know the exact setting path.

Jamie: The one I hear about most is `editor.accessibilitySupport`. What does it actually control?

Alex: That setting tells VS Code whether to use screen reader optimizations. `auto` tries to detect NVDA, JAWS, or VoiceOver. `on` forces those optimizations, and `off` disables them. When it is active, VS Code may show a Screen Reader Optimized indicator in the status area and adjust how editor content is exposed to assistive technology.

Jamie: What changes when screen reader mode is active? Is it only an announcement label?

Alex: It is more than a label. VS Code changes how it presents editor text, paging, hover content, suggestions, and some complex views. `editor.accessibilityPageSize` controls how many lines Page Up and Page Down read in screen reader mode. Hover content is still available, but the reliable way to read it is Accessible View with Alt+F2.

Jamie: That helps. And there are settings that are mostly visual, right?

Alex: Yes. Bracket guides, indentation guides, occurrence highlights, and the minimap can be useful visually, but they are not usually helpful through speech. Many screen reader users turn `editor.minimap.enabled` off, set `editor.renderWhitespace` to `none`, and set `editor.wordWrap` to `on`. Some people also set `workbench.editor.enablePreview` to `false` so each file opens in a real tab instead of replacing the preview tab.

Jamie: What about diffs, terminals, and notifications? Those are the places where I lose track fastest.

Alex: For diffs, `diffEditor.diffAlgorithm` set to `advanced` usually creates cleaner change groups, `diffEditor.ignoreTrimWhitespace` set to `true` cuts down noise, and `diffEditor.renderSideBySide` set to `false` gives an inline diff that is easier to read with speech. For the terminal, `terminal.integrated.screenReaderMode` can be `auto` or `on`, `terminal.integrated.enableBell` can add useful sound feedback, and Accessible View can read terminal output. For announcements, the `accessibility.verbosity` settings control how much VS Code says about comments, the diff editor, the editor, hovers, inline chat, inline completions, notebooks, panel chat, settings, keybindings, and the terminal.

Jamie: Audio cues are one of those features people either love immediately or turn off after five minutes. What is the balanced way to approach them?

Alex: Start by opening Settings with Ctrl+comma and searching for audio cue, or edit the same values in settings.json. Most cue settings accept `auto`, `on`, or `off`. `auto` means play the sound only when screen reader mode is active, `on` means always play it, and `off` means never play it.

Jamie: And each sound has a meaning, not just a decorative beep.

Alex: Right. There are signals for clearing the terminal or output, sending a Copilot Chat request, waiting for a chat response, and receiving that response. There are debugger signals for breakpoints, diff signals for deleted, inserted, and modified lines, and editor signals for formatting, errors, warnings, folded code, inline suggestions, and lines that have breakpoints. A low-value signal such as no inlay hints is often left off.

Jamie: Where do text announcements fit in? Are those separate from sound?

Alex: They are related but not identical. Audio cues are non-verbal sounds, while accessibility announcements are text-based status updates that your screen reader can speak. Verbosity settings decide which parts of VS Code talk more, and signal priority helps you keep urgent items like errors more noticeable than routine items. If a message arrives at the wrong time or repeats too much, adjust the related verbosity before you redesign the whole setup.

Jamie: Can people customize the actual sounds?

Alex: Where your VS Code version supports custom signal sounds, use short, clear files in a common audio format and keep them in a stable folder. Avoid long music clips, quiet files, and sounds that are hard to tell apart. The test is simple: when you hear it during real work, you should know immediately whether it means error, warning, diff change, chat response, or terminal event.

Jamie: Diffs are where accessibility settings become very real. Reviewing a pull request is hard if you cannot tell what changed.

Alex: The Accessible Diff Viewer is for exactly that moment. Use it when a visual side-by-side diff is too much, when a pull request has many changes, when whitespace is getting in the way, or when you need a keyboard-friendly way to review code changes.

Jamie: I always hear the word hunk in diff tools. What is a hunk?

Alex: A hunk is a block of related changes. In an accessible diff, you usually get the file, then each hunk, then the lines inside that hunk. Lines are marked by prefix: a plus sign for an inserted line, a minus sign for a deleted line, and an unchanged context line so you know where the change lives.

Jamie: How do you open it without hunting around visually?

Alex: Start from a changed file in Source Control or an open diff. Use the Command Palette to search for accessible diff, and in diff workflows use F7 and Shift+F7 to move between differences when those keybindings are available. If a merge conflict is involved, the accessible diff path is usually clearer than relying on visual conflict decorations alone.

Jamie: The appendix recommends inline view for screen readers. Why is side-by-side harder?

Alex: Side-by-side diff is designed for visual comparison: old file on one side, new file on the other. Speech has to jump between panes, and it is easy to forget which side you are on. Inline view keeps the old and new lines in one flow, so `diffEditor.renderSideBySide` set to `false` is often the better default.

Jamie: Does navigation change by screen reader?

Alex: A little. NVDA and JAWS users often move between focus mode and browse-style reading depending on where focus lands. VoiceOver users may need to interact with groups before moving inside the diff content. In all three cases, listen for hunk boundaries, line prefixes, and context lines; those are the clues that make the change understandable.

Jamie: Let us talk about screen reader-specific setup. People often ask, should I configure VS Code, or should I configure my screen reader?

Alex: Usually both, but lightly. For NVDA, keep it current, make sure focus mode is working well in edit fields, and choose punctuation and indentation feedback that helps you read code. There is no magic add-on required for everyone, but if your organization recommends a current VS Code-related NVDA add-on, install it from a trusted source and test it with your normal files.

Jamie: And the commands to lean on are mostly VS Code commands, not secret screen reader commands.

Alex: Yes. Use Ctrl+Shift+O for symbols, Ctrl+G for a line number, Alt+F2 for Accessible View, Ctrl+Shift+M for Problems, and the Command Palette when you forget a shortcut. NVDA commands still matter for switching interaction modes and reviewing speech, but the most portable workflow comes from VS Code itself.

Jamie: How does JAWS fit into that?

Alex: With JAWS, keep the version current, check that application or forms interaction behaves correctly in the editor, and tune typing echo and verbosity so code is readable but not overwhelming. Some workplaces use JAWS scripts for VS Code; if you do, confirm that the scripts match your VS Code version. JAWS commands can help with virtual cursor behavior, but again, VS Code commands like Go to Symbol, Problems, Source Control, and Accessible View are the core path.

Jamie: And VoiceOver on macOS has its own rhythm.

Alex: It does. In VoiceOver Utility, set keyboard and verbosity options so code editing is responsive, then practice interacting with VS Code groups using Control+Option+Shift+Down Arrow and backing out with Control+Option+Shift+Up Arrow. The rotor can help you inspect structure, and Quick Nav can be useful for reading, but you may need to turn Quick Nav off when VS Code needs arrow-key chords or editor navigation.

Jamie: I want the keyboard map. Not every shortcut in the universe, but the ones that keep work moving.

Alex: Start with global navigation. Ctrl+Shift+P opens the Command Palette, Ctrl+P opens a file by name, Ctrl+Tab moves through open editors, Ctrl+comma opens Settings, and Ctrl+K Ctrl+S opens Keyboard Shortcuts. The main areas are Ctrl+Shift+E for Explorer, Ctrl+Shift+F for Search, Ctrl+Shift+G for Source Control, Ctrl+Shift+D for Run and Debug, Ctrl+Shift+X for Extensions, and Ctrl+backtick for the terminal.

Jamie: What about inside the editor?

Alex: Use Ctrl+N, Ctrl+O, Ctrl+S, and Ctrl+W for new, open, save, and close. Ctrl+G goes to a line, Ctrl+Shift+O goes to a symbol, F12 goes to definition, and Alt+Left or Alt+Right moves through navigation history. Ctrl+F and Ctrl+H handle find and replace, Ctrl+slash toggles a comment, Alt+Up or Alt+Down moves a line, Shift+Alt+Down copies a line, Ctrl+Space opens suggestions, and Ctrl+period opens quick fixes.

Jamie: Multi-cursor editing scares people because it can change several places at once.

Alex: That is fair. Treat it as optional until you are comfortable. Ctrl+D selects the next match, Ctrl+U backs out of the last cursor action, and Escape cancels the multi-cursor state. Some systems use Ctrl+Alt+Up or Down to add cursors above or below, but that can conflict with operating system or screen reader shortcuts, so check Keyboard Shortcuts before relying on it.

Jamie: And the Git, terminal, Copilot, Problems, diff, and Markdown pieces?

Alex: For terminal work, Ctrl+backtick toggles the terminal and Ctrl+Shift+backtick creates a new one. In Source Control, Ctrl+Shift+G takes you to changes, Enter opens a selected file diff, and Ctrl+Enter from the commit message can commit when your setup allows it. Problems is Ctrl+Shift+M, F8 moves to the next problem, Shift+F8 moves to the previous one, Markdown preview is Ctrl+Shift+V or Ctrl+K V to open beside, and Copilot shortcuts such as inline chat and chat view should be verified in Keyboard Shortcuts because extensions and versions can change them. For accessibility features, remember Alt+F2 for Accessible View and F7 or Shift+F7 for diff movement when those bindings are active.

Jamie: Low vision settings deserve their own attention too. Sometimes the issue is not speech; it is size, contrast, and visual clutter.

Alex: Absolutely. Use Ctrl+K Ctrl+T to choose a theme, including high contrast themes, and use Ctrl+equals to zoom in, Ctrl+minus to zoom out, and Ctrl+0 to reset zoom. You can also set editor font size, terminal font size, and window zoom level directly in Settings.

Jamie: Are there tradeoffs when you zoom or change contrast?

Alex: Yes. Larger zoom can make long lines wrap differently, which is why word wrap should be tested in normal files, diffs, and the terminal. The minimap can help some low vision users orient visually, while others turn it off to reduce clutter. Breadcrumbs and the outline can also help you understand where you are in a large file.

Jamie: The appendix includes settings.json profiles. I like that because people have different tolerance levels for feedback.

Alex: A minimal screen reader profile might force `editor.accessibilitySupport` on, enable word wrap, disable the minimap, hide rendered whitespace, use inline diffs, and keep announcements limited. That works well for people who prefer to call Accessible View manually. A maximum feedback profile turns on more signals, leaves verbosity high, enables the terminal bell, and makes screen reader support explicit in the terminal.

Jamie: Then there are profiles for specific kinds of work.

Alex: For Copilot-heavy work, prioritize chat announcements, inline completion announcements, and sounds for chat request sent, response pending, response received, and inline suggestions. For Git and pull request review, prioritize inserted, deleted, and modified diff line signals, the advanced diff algorithm, inline diff view, and whitespace filtering. For slower machines or large repositories, reduce visual extras, keep the minimap off, limit lower-value signals, and avoid settings that create constant background work.

Jamie: And there is a balanced quick-copy setup for people who just want a reasonable starting point.

Alex: Yes. Use that as a starting profile, not a permanent identity. Paste it into settings.json only after you understand what it changes, then adjust one or two settings at a time so you can tell what improved or got worse.

Jamie: VS Code 1.120 also added or refined some chat, agents window, and Markdown diff behavior. What should listeners take from that?

Alex: The important part is that chat and agent workflows are becoming more keyboard and screen reader aware, but they still need settings support. Keep verbosity on for inline chat, panel chat, and inline completions if you use Copilot. For Markdown diffs, use the same accessible diff habits: inline view, clear line prefixes, and Accessible View when the rendered experience is not enough.

Jamie: Troubleshooting is where this reference probably gets used most. Let us start with the scary one: VS Code is not acting like it knows a screen reader is running.

Alex: Set `editor.accessibilitySupport` to `on` and `terminal.integrated.screenReaderMode` to `on`, then restart VS Code if needed. Also make sure your screen reader is running before VS Code starts. If the status indicator still does not appear, check the official VS Code accessibility docs for the current detection behavior.

Jamie: What if the opposite happens and VS Code will not stop talking?

Alex: Reduce the `accessibility.verbosity` settings for the areas causing noise, such as chat, hover, terminal, or inline completions. Set lower-priority signals to `auto` or `off`, especially repeated pending sounds. If you need a quiet baseline, start from the minimal profile and add feedback back slowly.

Jamie: And if there is not enough feedback?

Alex: Turn on signals for errors, warnings, inline suggestions, diff lines, terminal clear events, and chat completion. Use Ctrl+Shift+M to open Problems, then F8 and Shift+F8 to move through issues. If hover text or terminal output is being missed, open Accessible View with Alt+F2.

Jamie: Diffs can still feel confusing even after settings are changed.

Alex: Then switch to inline view, keep whitespace changes filtered unless you are reviewing whitespace on purpose, use the advanced diff algorithm, and open the Accessible Diff Viewer. Listen for the file name, hunk boundary, plus or minus prefix, and context line. If you can describe the changed block in one sentence, you are oriented enough to keep reviewing.

Jamie: Last one: terminal output or shortcuts are not behaving.

Alex: For terminal output, use Accessible View, keep the setting that returns focus to the terminal after closing Accessible View, and enable the terminal bell if sound helps. For shortcut conflicts, open Keyboard Shortcuts with Ctrl+K Ctrl+S, search the command name, and change one binding at a time. Do not reset everything unless you have to.

Jamie: So the appendix is less of a reading assignment and more of a workbench reference.

Alex: Exactly. Keep it nearby, choose the amount of feedback that fits your brain and your tools, and test settings in real tasks: opening files, editing code, reading a diff, using the terminal, and reviewing chat output. A good VS Code setup is the one that lets you return to the work without fighting the interface.