VS Code Setup & Accessibility Basics

Listen to Episode 11: VS Code Setup and Accessibility - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.

Your Accessible Development Environment - The Foundation

Day 2, Block 1 Material

This chapter is the bridge between GitHub's browser interface (Day 1) and real contribution work in VS Code (Day 2). You will learn how to launch VS Code, sign in to your GitHub account, verify GitHub Copilot is active, configure screen reader mode, navigate every major surface area, and master the accessibility tools that make VS Code one of the most accessible code editors available.

Prerequisites: Complete Day 1 walkthrough of GitHub's browser interface before working through VS Code material.

Workshop Recommendation (Chapter 5)

For this workshop, Chapter 5 is a guided setup chapter with a lightweight completion challenge.

• Challenge count: 1 guided walkthrough
• Automation check: none - setup state is local/account-level and cannot be validated by the Learning Room PR bot
• Evidence: structured completion comment on your assigned challenge issue
• Pattern: open, configure, navigate, verify

Chapter 5 Challenge Set

1. VS Code accessibility baseline - open VS Code (github.dev or desktop), enable screen reader mode, sign in to GitHub, verify Copilot status, and navigate core surfaces.

Challenge 5.1 Step-by-Step: VS Code Accessibility Baseline

Goal: Confirm you can access VS Code (github.dev or desktop), enable screen reader support, sign in to GitHub, check Copilot status, and perform core navigation.

Where you are working: github.dev (VS Code in the browser) or desktop VS Code if you installed it in Block 0.

Estimated time: 10-15 minutes.

1. Open the learning-room repository on GitHub.com.
2. Press . (the period key) on your keyboard. This launches github.dev - a full VS Code editor running in your browser. Wait a few seconds for it to load.
3. Enable screen reader mode:
   • Windows (NVDA/JAWS): Press Shift+Alt+F1. You should hear an announcement confirming screen reader mode is on.
   • Mac (VoiceOver): Screen reader mode is usually already optimized. If navigation feels wrong, open Command Palette (Cmd+Shift+P) and run Toggle Screen Reader Accessibility Mode.
4. Open the Explorer panel with Ctrl+Shift+E (Mac: Cmd+Shift+E). Your screen reader should announce the file tree.
5. Navigate to and open README.md from the file tree. Use arrow keys to move through files and Enter to open.
6. Open the outline/symbols view with Ctrl+Shift+O (Mac: Cmd+Shift+O). This shows all headings and sections in the current file - a key navigation tool for screen reader users.
7. Open the Command Palette with Ctrl+Shift+P (Mac: Cmd+Shift+P). Type any command name (for example, Toggle Word Wrap) and press Enter to run it. Press Escape to close without running.
8. Check the Accounts button in the Activity Bar (bottom-left of the sidebar). If you are signed in, your screen reader announces your GitHub username. If not, activate it and sign in with GitHub.
9. Check the Status Bar at the bottom of the window. Tab or arrow through it to find GitHub Copilot status. If Copilot is active, you hear an indicator showing it is ready.

You are done when: You have successfully opened github.dev, enabled screen reader mode, signed in to GitHub, confirmed Copilot status, opened a file, viewed its outline, and run a command from the Command Palette.

Completing Chapter 5: Submit Your Evidence

Return to GitHub.com, open your assigned Chapter 5 challenge issue, and post a completion comment:

Chapter 5 completed:
- Opened github.dev: yes / no
- Screen reader mode enabled: yes / no
- Signed in to GitHub: yes / no
- Copilot status checked: yes / no
- Opened file in Explorer: yes / no
- Opened outline/symbols: yes / no
- Opened Command Palette: yes / no

If any step was "no," add a note explaining where you got stuck so the facilitator can help. Close your Chapter 5 challenge issue when done.

Expected Outcomes

• Student can launch and navigate github.dev or desktop VS Code.
• Student can enable screen reader mode and hear navigation announcements.
• Student has signed in to GitHub and can see their account status.
• Student has verified GitHub Copilot is active (or knows it requires desktop VS Code).
• Student can open core navigation surfaces (Explorer, Outline, Command Palette).
• Student is ready for VS Code-based contribution chapters (6-16).

If You Get Stuck

1. Nothing happens when you press .? Make sure you are on the repository's main page (not inside an issue or PR). The . shortcut only works on repository code pages.
2. Screen reader mode toggle did not announce anything? Open Command Palette (Ctrl+Shift+P) and type Screen Reader to find the toggle manually.
3. Explorer panel is empty? VS Code may still be loading the repository. Wait 5-10 seconds and press Ctrl+Shift+E again.
4. On Mac with VoiceOver, navigation feels wrong? Run Toggle Screen Reader Accessibility Mode from Command Palette. VoiceOver sometimes needs the explicit toggle.
5. Cannot find the Accounts button? Open Command Palette and type Accounts to manage sign-in from there.
6. Copilot not showing in the status bar? github.dev does not support Copilot - you need desktop VS Code or a Codespace.
7. Shortcut not working? Use Command Palette as a fallback for any action - type what you want to do and VS Code will find the command.
8. Ask facilitator for a side-by-side demo and repeat the same steps.

Learning Moment

Tool setup is part of contribution skill. A stable, accessible editor reduces stress and increases contribution quality. The surfaces you just tested - github.dev launch, screen reader mode, GitHub sign-in, Copilot status, Explorer, Outline, and Command Palette - are the foundation for everything in Day 2.

Learning Pattern Used in This Chapter

1. Open the tool in the simplest way possible (. key for github.dev).
2. Sign in and verify your identity and tools are ready (Accounts, Copilot).
3. Configure accessibility before doing any work (screen reader mode first).
4. Verify each navigation surface works with your assistive technology.
5. Record what worked and what didn't (evidence comment).

Table of Contents

1. Why VS Code for Open Source Contribution
2. The Bridge: github.dev - VS Code in Your Browser
3. Screen Reader Mode in VS Code
4. The VS Code Interface Tour
5. The Accounts Button and GitHub Sign-In
6. Verifying GitHub Copilot Status
7. The Status Bar
8. The Menu Bar
9. Settings Sync
   • Profiles
10. The Settings Editor
11. The Keyboard Shortcuts Editor
12. Essential Keyboard Navigation and Find/Filter
13. The Problems Panel
14. The Terminal
15. Copilot Chat Window
16. Accessible Help, Accessible View, and Accessible Diff
17. Accessibility Signals
18. VS Code Speech - Voice Input and Output
19. Git Operations Inside VS Code

1. Why VS Code for Open Source Contribution

GitHub's browser interface is excellent for reviewing, discussing, and triaging. VS Code is where you create. The difference:

For Markdown contributions (which is most of what accessibility-agents needs), VS Code gives you Copilot assistance, live preview, and the same Git workflow - with less tab switching and with agents available on every file you open.

2. The Bridge: github.dev - VS Code in Your Browser

Before you install anything: try VS Code right now in your browser

GitHub provides a web-based version of VS Code called github.dev. It runs entirely in your browser with zero installation. The keyboard shortcuts, screen reader mode, and editor experience are identical to the desktop app.

How to Access github.dev

Method 1: The Period Key Shortcut (Fastest)

From any GitHub repository page:

1. Press . (period key - just the period, no modifier keys)
2. The page transforms into VS Code
3. You are now editing in github.dev
4. The URL changes to github.dev/owner/repo
5. Screen reader mode works exactly as it does in desktop VS Code (toggle with Shift+Alt+F1)

Where it works

• Repository home pages
• File view pages
• Pull request pages
• Any branch or commit view

Screen reader note: The period key shortcut is a single keypress - no modifier keys. It is GitHub's universal "open this in VS Code" command.

Alternative: Press > (Shift+Period) to open github.dev in a new tab. This preserves your GitHub page and is the preferred method when you want to keep both interfaces open.

Method 2: Direct URL

Change the domain in any GitHub URL:

• github.com/owner/repo becomes github.dev/owner/repo
• Works for any branch, file, or commit URL

Method 3: From the Repository Page

What You Get in github.dev

Everything in the list below works exactly like desktop VS Code:

• Full text editor with syntax highlighting
• All VS Code keyboard shortcuts (see Section 11: Keyboard Shortcuts Editor and Appendix M)
• Screen reader mode (Shift+Alt+F1 to activate - Mac: Shift+Option+F1)
• File Explorer (Ctrl+Shift+E - Mac: Cmd+Shift+E) - browse the entire repository
• Search across files (Ctrl+Shift+F - Mac: Cmd+Shift+F)
• Source Control (Git) (Ctrl+Shift+G - Mac: Cmd+Shift+G) - stage, commit, push changes
• Markdown preview (Ctrl+Shift+V - Mac: Cmd+Shift+V)
• Command Palette (Ctrl+Shift+P - Mac: Cmd+Shift+P) - access every VS Code command
• Go to File (Ctrl+P - Mac: Cmd+P) - instant file picker
• Go to Symbol (Ctrl+Shift+O - Mac: Cmd+Shift+O) - navigate by headings in Markdown
• Multiple editor tabs and split view
• Settings sync - if you sign in, your VS Code settings apply here too

What github.dev Does NOT Have

• No terminal - cannot run shell commands, npm, git CLI
• No GitHub Copilot - Copilot requires the desktop app or a Codespace
• No Accessibility Agents - agents rely on extensions that need desktop VS Code
• No extension installation - extensions are disabled in github.dev
• No debugger - debugging requires a local environment
• No live server or preview - except Markdown preview, which does work

These limitations are why desktop VS Code exists. github.dev is for quick edits and reading code. Desktop is for Copilot, agents, terminal workflows, and full development.

Why github.dev Matters for This Workshop

It is the bridge. You spend Day 1 in the GitHub browser interface. You spend Day 2 in desktop VS Code. github.dev sits in between:

• Same keyboard shortcuts as desktop VS Code (you learn them once)
• Same screen reader mode (you configure it once)
• Same file navigation patterns (Explorer, Ctrl+P / Mac: Cmd+P, Ctrl+Shift+O / Mac: Cmd+Shift+O)
• But accessible instantly from any GitHub page with one keystroke

Use github.dev when

• You want to edit a file quickly without switching apps
• You are on a machine where you cannot install software
• You want to browse code with VS Code navigation (symbols, search, split view)
• You are reviewing a PR and want to see the full file context

Use desktop VS Code when

• You need Copilot inline suggestions
• You want to run Accessibility Agents
• You are making multi-file changes that benefit from AI assistance
• You need a terminal for git commands or running scripts

Screen Reader Experience in github.dev

Activate screen reader mode immediately

1. Press . on any GitHub repository to open github.dev
2. Press Shift+Alt+F1 (Mac: Shift+Option+F1) to enable screen reader mode
3. VS Code announces "Screen reader optimized"

What changes

• Focus behavior adjusts for keyboard navigation
• Code suggestions are announced via ARIA live regions
• Error messages are announced when you navigate to them
• Inline decorations are suppressed to reduce noise

Navigation

• Use Ctrl+Shift+E to open the Explorer (file tree)
• Use Up/Down Arrow to navigate files
• Press Enter on a file to open it in the editor
• The editor behaves like a standard text area - your screen reader's reading commands work normally

NVDA/JAWS users

• You remain in Browse/Virtual mode for the overall interface
• When focus enters the editor text area, you are automatically in Forms/Focus mode
• All standard cursor movement works: Home, End, Ctrl+Home, Ctrl+End, Ctrl+F to find

VoiceOver users

• Quick Nav OFF when inside the editor (Left Arrow + Right Arrow to toggle)
• Use VO+Shift+Down to interact with the editor area
• Standard text navigation (Control+A for line start, Control+E for line end, etc.)

Try It Right Now

Before reading the rest of this guide:

1. Open github.com/community-access/learning-room in your browser
2. Press . (period key)
3. github.dev opens
4. Press Shift+Alt+F1 (Mac: Shift+Option+F1) to enable screen reader mode
5. Press Ctrl+Shift+E (Mac: Cmd+Shift+E) to open the Explorer
6. Navigate to README.md and press Enter
7. Press Ctrl+Home (Mac: Cmd+Up) to go to the top of the file
8. Press Ctrl+Shift+O (Mac: Cmd+Shift+O) to see the outline (all headings)
9. Close the tab when done

You just used VS Code. The desktop version in the rest of this guide is the same experience - with Copilot, agents, and a terminal added.

3. Screen Reader Mode in VS Code

Who needs this section? If you use NVDA, JAWS, VoiceOver, or another screen reader, read this section before continuing. If you are not using a screen reader, you can skip to Section 4 - VS Code works fully without enabling this mode.

VS Code has built-in accessibility support designed for screen reader users. It changes how focus moves, how announcements work, and how navigation behaves.

Activating Screen Reader Mode

Verify it is active

Open Settings (Ctrl+, - Mac: Cmd+,) then search for accessibility support then confirm it shows on (not auto).

What Changes in Screen Reader Mode

NVDA-Specific Settings for VS Code

VS Code uses a web-based renderer. Configure NVDA for best results:

1. Open NVDA Menu then Preferences then Settings then Browse Mode
2. Set "Maximum length of text on a single line" to 10000 (prevents truncation in long lines)
3. Under Object Presentation: set "Report tooltip delay" to off
4. Recommended: use NVDA + Google Chrome for the integrated browser panels

JAWS-Specific Settings for VS Code

1. JAWS should detect VS Code automatically and switch to PC Cursor mode for the editor
2. If the editor feels unresponsive, press Insert+Z to toggle virtual cursor off
3. For the integrated terminal: use Insert+Z to enter forms/PC mode, then interact with the terminal

VoiceOver-Specific Settings for VS Code (macOS)

1. Open VS Code then Shift+Alt+F1 (Mac: Shift+Option+F1) to confirm screen reader mode
2. In VoiceOver Utility: Verbosity then set "Punctuation" to "All" for reading code
3. Use Quick Nav OFF (Left+Right Arrow) when inside the editor - standard cursor navigation is more predictable
4. Use VO+Shift+Down to interact with the editor, VO+Shift+Up to stop interacting

4. The VS Code Interface Tour

Before diving into individual features, here is how VS Code is organized. Every area is reachable by keyboard.

The Five Major Regions

+----------------------------------------------------------+
|  Menu Bar (File, Edit, View, Go, Run, Terminal, Help)    |
+------+---------------------------------------------------+
|      |                                                    |
| A    |  Editor Area                                       |
| c    |  (your files open here)                            |
| t    |                                                    |
| i    |                                                    |
| v    |                                                    |
| i    +---------------------------------------------------+
| t    |                                                    |
| y    |  Panel (Terminal, Problems, Output, Debug Console) |
|      |                                                    |
| B    +---------------------------------------------------+
| a    |  Status Bar (line, column, language, Git branch,   |
| r    |   Copilot status, encoding, notifications)         |
+------+---------------------------------------------------+

Text description of the layout above: VS Code has five major regions arranged in a grid. The Menu Bar spans the full width across the top. Below it, the Activity Bar runs vertically along the left edge (it contains icons for Explorer, Source Control, Search, Extensions, and more). The Sidebar appears to the right of the Activity Bar and shows content for the selected activity (file tree, search results, etc.). The Editor Area fills the large central region where your files open. Below the Editor Area, the Panel stretches across the bottom and contains the Terminal, Problems, Output, and Debug Console tabs. Finally, the Status Bar runs along the very bottom showing line number, column, language mode, Git branch, Copilot status, encoding, and notifications.

Navigating Between Regions

Key insight: Press F6 repeatedly to cycle focus through the major regions: Sidebar, Editor, Panel, Status Bar, and back. This is the universal "where am I, take me somewhere else" key in VS Code.

Learning Cards: Finding Your Way Around VS Code

5. The Accounts Button and GitHub Sign-In

The Accounts button sits at the bottom of the Activity Bar (the vertical icon strip on the left side of VS Code). It manages your authentication with GitHub, Microsoft, and other services.

Why Sign In Matters

• GitHub Copilot requires an active GitHub sign-in to function
• Settings Sync requires sign-in to synchronize your preferences across machines
• GitHub Pull Requests extension needs authentication to create and review PRs from VS Code
• Your GitHub identity appears in commits you make from VS Code

Signing In

From the Accounts Button

1. Press F6 until you hear the Activity Bar, then arrow down to the Accounts button (it is at the very bottom of the bar)
2. Press Enter to open the Accounts menu
3. Select "Sign in with GitHub to use GitHub Copilot" (or a similar prompt)
4. A browser window opens for GitHub OAuth authorization
5. Authorize VS Code, then return to the editor
6. Your screen reader announces your GitHub username in the Accounts button

From the Command Palette

1. Press Ctrl+Shift+P then type sign in
2. Select "GitHub: Sign In"
3. Complete the browser OAuth flow and return to VS Code

Verifying You Are Signed In

• Accounts button: Press F6 to reach the Activity Bar, arrow down to Accounts. A screen reader announces your username.
• Command Palette: Ctrl+Shift+P then type GitHub Copilot: Status. If Copilot shows ready, you are signed in.
• Status Bar: Look for (or hear) the Copilot icon in the status bar at the bottom of the window.

Learning Cards: GitHub Sign-In

6. Verifying GitHub Copilot Status

GitHub Copilot is your AI pair programmer. Before starting any contribution work, confirm it is active and responding.

Where to Check Copilot Status

Status Bar Indicator

The Copilot icon appears in the Status Bar at the bottom-right of the VS Code window.

Command Palette Check

1. Press Ctrl+Shift+P
2. Type GitHub Copilot: Status
3. The output shows whether Copilot is signed in, active, or has errors

Quick Test

1. Open any .md file in the editor
2. Start typing a sentence (for example, ## Getting Started with)
3. If Copilot is active, a gray ghost-text suggestion appears after a brief pause
4. Press Tab to accept or Escape to dismiss

Troubleshooting Copilot

Learning Cards: Copilot Status

7. The Status Bar

The Status Bar is the thin strip at the bottom of the VS Code window. It provides real-time information about your workspace, file, and active tools.

What the Status Bar Contains (Left to Right)

Navigating the Status Bar with a Keyboard

1. Press F6 until your screen reader announces the Status Bar
2. Use Tab to move between items from left to right
3. Press Enter on any item to activate it (open a picker, toggle a setting, etc.)
4. Press Escape to return to the editor

Learning Cards: Status Bar

8. The Menu Bar

The Menu Bar runs along the top of the VS Code window and provides structured access to every command category.

Menu Bar Structure

Accessing the Menu Bar

Learning Cards: Menu Bar

9. Settings Sync

Settings Sync synchronizes your VS Code configuration across multiple machines and between desktop VS Code and github.dev. When you sign in and enable sync, your settings, keyboard shortcuts, extensions, UI state, and profiles travel with you.

What Gets Synced

Enabling Settings Sync

1. Open the Accounts button (Activity Bar, bottom-left) or press Ctrl+Shift+P then type Settings Sync: Turn On
2. Sign in with your GitHub account (or Microsoft account)
3. Select which categories to sync (recommended: sync everything)
4. VS Code syncs immediately and on every subsequent change

Conflict Resolution

If settings differ between machines, VS Code shows a merge editor where you choose which version to keep. This is similar to a Git merge conflict but for settings.

Learning Cards: Settings Sync

Profiles

VS Code Profiles let you create named collections of settings, extensions, keyboard shortcuts, snippets, tasks, and UI state. Each profile is independent - switching profiles changes your entire VS Code configuration instantly. This is useful when you work in different contexts (workshop vs. daily development) or need to present with different display settings.

Creating a Profile

When creating a profile, you choose what to include:

• Settings - editor preferences, accessibility options, theme
• Keyboard Shortcuts - all custom keybindings
• Extensions - which extensions are installed and enabled
• Snippets - code snippet definitions
• Tasks - task runner configurations
• UI State - sidebar position, panel layout, view visibility

You can start from the current configuration, an empty profile, or an existing profile template.

Switching Profiles

The active profile name appears in the VS Code title bar and Status Bar so you always know which configuration is active.

Workshop Profile Recommendations

Create these profiles before the workshop:

Exporting and Sharing Profiles

Profiles can be exported and shared:

1. Ctrl+Shift+P then type Profiles: Export Profile
2. Choose what to include (settings, extensions, etc.)
3. Export as a GitHub gist (shareable link) or a local file
4. Share the link or file with others

To import: Ctrl+Shift+P then Profiles: Import Profile and paste the gist URL or select the file.

Workshop tip: Facilitators can export a pre-configured Workshop profile as a GitHub gist and share the link. Students import it in one step and immediately have all accessibility settings configured.

Profiles and Settings Sync

Profiles sync across machines through Settings Sync. When you create a profile on one machine and have Settings Sync enabled, the profile appears on every other machine where you are signed in. Each profile syncs independently - changes to one profile do not affect others.

Learning Cards: Profiles

10. The Settings Editor

The Settings Editor is where you customize VS Code. There are two views: the graphical settings UI and the raw settings.json file.

Opening the Settings Editor

Navigating the Settings Editor

The graphical Settings UI has a search box at the top. Type any keyword and the settings list filters instantly.

Special Search Filters

Key Accessibility Settings to Configure

{
  "editor.accessibilitySupport": "on",
  "editor.minimap.enabled": false,
  "editor.wordWrap": "on",
  "editor.renderWhitespace": "none",
  "editor.fontSize": 16,
  "accessibility.signals.lineHasError": "on",
  "accessibility.signals.taskCompleted": "on",
  "accessibility.signals.chatResponseReceived": "on"
}

Learning Cards: Settings Editor

11. The Keyboard Shortcuts Editor

The Keyboard Shortcuts Editor lets you view, search, and customize every keyboard shortcut in VS Code.

Opening the Keyboard Shortcuts Editor

Searching for Shortcuts

The editor has a search box that supports:

• Command name: Type toggle terminal to find the terminal toggle shortcut
• Keystroke recording: Click the keyboard icon (or press the record keys button) to record a key combination and find what it does
• When clause: Find shortcuts that only apply in specific contexts

Customizing a Shortcut

1. Find the command in the list
2. Double-click the keybinding column (or press Enter on the row, then Enter again on the keybinding)
3. Press your desired key combination
4. Press Enter to confirm

Learning Cards: Keyboard Shortcuts Editor

12. Essential Keyboard Navigation and Find/Filter

Panels and Areas

Mac users: Substitute Cmd for Ctrl and Option for Alt in all shortcuts below.

Within the Editor

Find in Current File (Ctrl+F)

When the Find widget opens, three toggle buttons refine what matches:

Screen reader interactions inside the Find widget

• Toggles are announced as checkboxes - press Space to toggle each one
• Match count is announced as you type (example: 3 of 12 matches)
• F3 / Shift+F3 move through matches while the widget stays open
• Escape closes the widget and returns focus to your last cursor position

Replace (Ctrl+H): Opens the Find widget with a second input for the replacement text.

• Ctrl+Shift+1 - replace the current match
• Ctrl+Alt+Enter - replace all matches at once

Global Search Across the Workspace (Ctrl+Shift+F)

The global Search panel has a rich filtering system - all keyboard-accessible:

Glob pattern examples for this workshop

docs/*.md          - all Markdown files in the docs folder
*.agent.md         - all agent definition files
.github/**         - everything inside the .github folder
!node_modules/**   - exclude node_modules folder

Type-to-Filter in Tree Views

In the Explorer file tree and the Source Control changes list, type characters to narrow visible items:

1. Focus the Explorer (Ctrl+Shift+E)
2. Start typing a filename - a filter input appears at the bottom of the tree
3. The tree instantly narrows to matching files
4. Press Escape to clear the filter and restore full view

Go to Symbol with Inline Filtering (Ctrl+Shift+O)

In any Markdown file, Ctrl+Shift+O opens a symbol picker populated by every heading. Type to narrow the list, then press Enter to jump.

Explorer (File Tree) Navigation

13. The Problems Panel

The Problems panel (Ctrl+Shift+M) shows all errors, warnings, and informational messages from linters, compilers, and extensions for every open file in your workspace.

Opening the Problems Panel

• Keyboard: Ctrl+Shift+M
• Status Bar: Click the errors/warnings count (bottom-left of window)
• Menu Bar: View then Problems
• From the editor: Press F8 to jump to the next problem (cycles through errors in the current file)

Navigating Problems

Understanding Problem Entries

Each entry shows:

• Severity icon: Error (red circle with X), Warning (yellow triangle), Info (blue circle with i)
• Message: Description of the problem
• Source: Which tool reported it (e.g., "markdownlint", "eslint", "Pylance")
• File and line: Where the problem is located

Learning Cards: Problems Panel

14. The Terminal

VS Code includes a fully featured integrated terminal. You can run shell commands, Git operations, and scripts without leaving the editor.

Opening and Managing Terminals

Terminal Shell Integration

VS Code's shell integration enhances the terminal with:

• Command decoration marks - visual indicators showing where each command started and whether it succeeded or failed
• Run recent command (Ctrl+R in terminal) - VS Code's quick pick of your recent commands, searchable by name
• Terminal IntelliSense (Ctrl+Space) - completion suggestions for shell commands, file paths, and arguments

Enable Terminal IntelliSense: Settings (Ctrl+,) then search terminal.integrated.suggest.enabled then set to on.

Terminal Accessibility

Learning Cards: Terminal

15. Copilot Chat Window

The Copilot Chat window (Ctrl+Shift+I) is your conversational AI assistant within VS Code. It can answer questions, generate code, explain code, fix problems, and help with documentation.

Opening Copilot Chat

Chat Modes

Switch modes using the mode picker at the top of the Chat view, or use keyboard shortcuts:

• workbench.action.chat.openAsk - Ask mode
• workbench.action.chat.openEdit - Edit mode
• workbench.action.chat.openAgent - Agent mode

Using Chat Participants

Type @ in the chat input to see available participants:

• @workspace - Ask questions about your entire codebase
• @vscode - Ask about VS Code settings and features
• @terminal - Run commands or explain terminal output

Learning Cards: Copilot Chat

16. Accessible Help, Accessible View, and Accessible Diff

VS Code has a family of purpose-built accessibility features that give screen reader users complete, structured access to content that is otherwise conveyed visually or through dynamic regions. These three are the most important to know before working with Copilot and diffs.

16.1 Accessible Help - Context-Aware Keyboard Guide

Every interactive area of VS Code - the editor, the terminal, the diff view, the Copilot Chat panel - has its own keyboard commands. Accessible Help surfaces those commands in a plain-text, fully readable dialog, tailored to exactly where your focus is right now.

How to open Accessible Help

The dialog is announced with a heading and a complete list of keyboard shortcuts for that specific widget. Navigate with Up/Down Arrow. Press Escape to dismiss and return focus to where you were.

Why this matters: You do not need to memorize every shortcut in every panel. Open Accessible Help in any unfamiliar area and VS Code will tell you exactly what you can do there. It is the built-in answer to "what can I press from here?"

Example output when pressing Alt+H in the editor

Accessible Help: Editor

Press F8 to jump to the next error or warning.
Press Shift+F8 to jump to the previous error or warning.
Press Ctrl+Shift+M to open the Problems panel.
Press F12 to go to a definition.
Press Alt+F12 to peek a definition inline.
Press Ctrl+Shift+O to go to a symbol in this file.
Press Alt+F2 to open the Accessible View.
Press Alt+H to view this help content again.

Use Accessible Help as your first action whenever you land somewhere new in VS Code.

16.2 Accessible View - Reading Dynamic and Streamed Content

Accessible View (Alt+F2) gives screen reader users a clean, static, fully readable version of content that is otherwise presented dynamically, in tooltips, or in streaming form.

How to open Accessible View

What Accessible View provides

Recommended workflow for Copilot Chat

1. Type your prompt in the Chat input
2. Wait for the response to finish (NVDA: live region announcements stop; JAWS: typing indicator disappears; VoiceOver: busy state clears)
3. Press Alt+F2 - Accessible View opens with the complete response
4. Navigate with Up/Down Arrow through the response
5. Press Escape to return to the chat input

Recommended workflow for hover documentation

1. Navigate to a symbol or link with keyboard
2. Press Ctrl+K I to trigger hover programmatically (no mouse needed)
3. Press Alt+F2 to open Accessible View with the full hover content
4. Press Escape to dismiss

16.3 Accessible Diff Viewer - Reading Changes Without Visual Scanning

When you open a file diff - in Source Control, in the GitHub PR extension, or during a merge conflict - VS Code normally shows it as a side-by-side or inline visual view. For screen reader users, tracking which lines changed and how can be difficult without a structured reading mode.

The Accessible Diff Viewer presents the same diff as a plain, navigable list of changed lines - organized by hunk, labeled by change type (added, removed, unchanged), with the line number announced for each line.

How to open the Accessible Diff Viewer

What the Accessible Diff Viewer announces

For each hunk (a block of related changes), the viewer announces:

• The hunk number and total hunk count (Hunk 2 of 5)
• The line range affected
• Each line, prefixed with its change type:

Hunk 1 of 3 - lines 12 to 18
  Unchanged: ## Screen Reader Cheat Sheet
- Line removed: > Quick reference for NVDA users.
+ Line added: > Quick reference for NVDA, JAWS, and VoiceOver users.
  Unchanged:
  Unchanged: Use this document during the workshop.

This gives you the complete picture of what changed, in reading order, without visual diff scanning.

Practical uses during this workshop

• Before approving a PR: Open the diff then F7 to enter the first hunk then navigate each change then F7 for next hunk then repeat until all hunks reviewed
• During a merge conflict: The conflict markers (<<<<<<<, =======, >>>>>>>) appear as lines in the viewer - you can read both conflicting versions before deciding which to keep
• After Copilot generates an edit: Open the diff (Ctrl+Shift+G then navigate to the changed file then Enter) then review exactly what Copilot changed vs. what was there before

Audio cues for diffs

With accessibility.signals.diffLineInserted and accessibility.signals.diffLineDeleted both set to on in Settings, VS Code plays a distinct tone when your cursor moves over an added line (higher pitched) or a removed line (lower pitched). You receive change-type information through sound before the line text is announced.

17. Accessibility Signals

VS Code communicates editor state through Accessibility Signals -- non-verbal cues that tell you what is happening as you move through code, run commands, and interact with Copilot. Signals replaced the older "Audio Cues" system (deprecated since VS Code 1.85) and are significantly more powerful.

Official documentation: VS Code Accessibility -- Accessibility Signals

How Signals Work: The Dual-Channel Architecture

Every accessibility signal has two independent channels that you control separately:

Each channel accepts one of these values:

This means you can enable sounds for everyone while keeping announcements on auto so they only fire when a screen reader is attached. Or you can turn on announcements without sounds. Full independent control.

Discovering Signals: The Two Essential Commands

VS Code provides two commands that let you browse every available signal, hear what each one sounds like, and toggle them on or off without editing settings.json:

These are the fastest way to configure signals. You do not need to memorize setting names.

Volume Control

Control signal volume independently from your system volume:

Set this in Settings (Ctrl+,) by searching "signal volume" or add it to settings.json:

{
  "accessibility.signalOptions.volume": 70
}

Complete Signal Reference

VS Code registers 30+ accessibility signals organized into categories. The tables below list every signal, its setting key, the sound it plays, and whether it supports announcements.

Editor Signals

These fire when your cursor moves to a line or position with a specific marker:

Line vs Position signals: The lineHasError signal fires once when your cursor enters the line. The positionHasError signal fires when the cursor reaches the exact character where the error starts. Both can be enabled simultaneously for layered feedback.

Diff Signals

These fire when navigating changes in the diff editor or reviewing pull requests:

These are critical for pull request review. You hear the type of change before reading the content.

Terminal Signals

Workshop tip: Enable taskCompleted and taskFailed immediately. When you run git push or npm test in the terminal, you hear whether it succeeded without switching back to the terminal panel.

Chat and Copilot Signals

Why four response sounds? chatResponseReceived plays a randomly chosen variant each time (responseReceived1 through responseReceived4). This prevents habituation -- your brain stays alert to the signal instead of filtering it out after hearing the same sound repeatedly. This is an intentional accessibility design pattern.

Debug Signals

Editor Action Signals

These fire on user-triggered actions and use the "userGesture" value to distinguish manual saves from auto-saves:

Set these to "userGesture" rather than "on" if auto-save is enabled, to avoid a sound on every keystroke pause:

{
  "accessibility.signals.save": {
    "sound": "userGesture",
    "announcement": "off"
  }
}

Voice Signals

Code Action Signals

Debounce Settings for Position Signals

When you hold an arrow key and your cursor moves rapidly through lines, position-based signals (error/warning at position) could fire dozens of times per second. VS Code debounces these by default:

The announcement delay is intentionally longer (3 seconds) because screen reader interruptions are more disruptive than brief sounds.

Recommended Workshop Profile

Add this to your VS Code settings.json (Ctrl+Shift+P then "Preferences: Open User Settings (JSON)"):

{
  "editor.accessibilitySupport": "on",

  "accessibility.signalOptions.volume": 70,

  "accessibility.signals.lineHasError": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.lineHasWarning": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.lineHasFoldedArea": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.lineHasBreakpoint": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.taskCompleted": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.taskFailed": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.terminalCommandSucceeded": {
    "sound": "on",
    "announcement": "off"
  },
  "accessibility.signals.chatResponseReceived": {
    "sound": "on",
    "announcement": "auto"
  },
  "accessibility.signals.diffLineInserted": {
    "sound": "on",
    "announcement": "off"
  },
  "accessibility.signals.diffLineDeleted": {
    "sound": "on",
    "announcement": "off"
  },
  "accessibility.signals.save": {
    "sound": "userGesture",
    "announcement": "off"
  },

  "editor.minimap.enabled": false,
  "editor.renderWhitespace": "none",
  "editor.wordWrap": "on"
}

This profile enables core sounds for everyone and sets announcements to auto so they activate only when a screen reader is detected. The save signal uses userGesture to avoid noise from auto-save. Diff signals are sound-only because rapid line navigation with announcements would overwhelm a screen reader.

Migrating from Legacy Audio Cues

If you previously configured the older audioCues.* settings (deprecated since VS Code 1.85), VS Code automatically maps them to the new accessibility.signals.* namespace. However, the new settings offer the dual sound/announcement structure that the old settings did not have. Review your configured signals using Help: List Signal Sounds and Help: List Signal Announcements to take advantage of the new independent controls.

Note: minimap.enabled: false in the recommended profile removes the visual minimap that adds no value for screen reader users and can cause some accessibility tools to announce additional regions.

18. VS Code Speech - Voice Input and Output

The VS Code Speech extension adds speech-to-text and text-to-speech capabilities to VS Code. All voice processing happens locally on your machine - no audio data is sent to any online service. This makes it useful for dictation, talking to Copilot Chat, and having Chat responses read aloud.

Installing VS Code Speech

1. Open Extensions: Ctrl+Shift+X (Mac: Cmd+Shift+X)
2. Search for VS Code Speech
3. Find VS Code Speech (publisher: Microsoft, identifier: ms-vscode.vscode-speech)
4. Press Enter to open the extension detail page, then Tab to "Install" and press Enter

After installation, a microphone icon appears in all Chat input fields and new voice commands become available in the Command Palette.

Microphone permissions: On macOS, go to System Settings, Privacy and Security, Microphone, and confirm Visual Studio Code is enabled. On Windows, go to Settings, Privacy and security, Microphone, and confirm that "Let desktop apps access your microphone" is on. Without this permission, voice input fails silently.

Editor Dictation - Type with Your Voice

Editor dictation lets you speak and have your words appear as text wherever your cursor is. This works in the code editor, the SCM commit input box, and the comments field when reviewing pull requests.

When dictation is active, a small microphone icon appears at the cursor position. Speak naturally and your words are transcribed into text. Press Escape to stop.

Walky-talky mode: Press and hold the keyboard shortcut instead of tapping it. Voice recognition stays active as long as you hold the keys. When you release, dictation stops automatically. This is the fastest way to dictate a short phrase.

Voice in Copilot Chat - Talk to Copilot

Instead of typing prompts, you can speak them. This works in the Chat panel, inline chat, and quick chat.

When voice chat is active, a microphone icon appears in the chat input field. Speak your prompt naturally. When you pause, the prompt is automatically submitted.

Automatic submission: By default, VS Code submits your voice prompt after a pause. You can adjust the wait time with the accessibility.voice.speechTimeout setting (in milliseconds), or set it to 0 to disable auto-submit entirely so you can review before sending.

Walky-talky mode in chat: Press and hold Ctrl+I (Mac: Cmd+I). Speak your prompt. When you release the keys, voice recognition stops and the prompt is submitted automatically.

Text-to-Speech - Listen to Chat Responses

VS Code Speech can read Copilot Chat responses aloud. Each chat response shows a speaker icon you can activate to hear that specific response.

Automatic read-aloud after voice input

Enable this setting to have every Chat response automatically spoken aloud when you used voice to ask the question:

{
  "accessibility.voice.autoSynthesize": true
}

When auto-synthesize is on:

1. You speak a question using voice chat
2. Copilot responds in text
3. The response is automatically read aloud
4. To stop playback mid-sentence, press Escape or activate the stop icon

Manual read-aloud for any response

Even without autoSynthesize, every Chat response has a speaker icon. Activate it to hear that specific response read aloud. This works for responses from typed prompts too, not just voice prompts.

"Hey Code" - Hands-Free Activation

You can configure VS Code to listen continuously for the wake phrase "Hey Code" to start a voice chat session without touching the keyboard.

Enable it in Settings:

{
  "accessibility.voice.keywordActivation": "chatInView"
}

When "Hey Code" listening is active, a microphone icon appears in the status bar to show that VS Code is listening for the wake phrase.

Privacy note: Even with "Hey Code" enabled, all processing is local. No audio leaves your machine. The extension listens for the wake phrase only and starts transcription only after detecting it.

Language Configuration

VS Code Speech supports 26 languages. By default it matches your VS Code display language. To change it:

{
  "accessibility.voice.speechLanguage": "en-US"
}

When you start speech recognition for the first time with a new language, VS Code may install an additional language extension automatically.

All Voice Settings Reference

All Voice Commands Reference

Custom Keybindings for Voice

You can assign your own shortcuts for voice commands. Open the Keyboard Shortcuts editor (Ctrl+K Ctrl+S) and search for "voice" or "dictation". Example custom keybinding in keybindings.json:

[
  {
    "key": "ctrl+u",
    "command": "workbench.action.chat.startVoiceChat",
    "when": "!voiceChatInProgress"
  },
  {
    "key": "ctrl+u",
    "command": "workbench.action.chat.stopListeningAndSubmit",
    "when": "voiceChatInProgress"
  },
  {
    "key": "ctrl+d",
    "command": "workbench.action.editorDictation.start",
    "when": "!editorDictation.inProgress"
  },
  {
    "key": "ctrl+d",
    "command": "workbench.action.editorDictation.stop",
    "when": "editorDictation.inProgress"
  }
]

The when clauses ensure the same key toggles the feature on and off.

Supported Platforms

On Linux, the extension requires the ALSA shared library (libasound). Install it with sudo apt install libasound2 on Debian/Ubuntu if it is not already present.

19. Git Operations Inside VS Code

This section previews the key Git operations you will perform inside VS Code. Chapter 11 (Git & Source Control) covers each in full detail with step-by-step walkthroughs. This is your orientation.

Cloning a Repository

What it does: Downloads a complete copy of a GitHub repository to your local machine.

Screen reader tip: After cloning, VS Code asks "Would you like to open the cloned repository?" Press Enter to open it immediately.

Forking a Repository

What it does: Creates your own copy of someone else's repository under your GitHub account.

Forking happens on GitHub.com, not inside VS Code. After forking:

1. Go to your fork on GitHub.com (github.com/your-username/repo)
2. Clone your fork using the steps above
3. VS Code's Git extension automatically tracks your fork as the origin remote

Pulling Changes

What it does: Downloads and applies new commits from the remote repository to your local copy.

Fetching Changes

What it does: Checks for new commits on the remote without applying them. Fetch is "look but do not touch."

After fetching, the Status Bar shows if you are behind the remote (e.g., "0 up, 3 down" means 3 commits to pull).

Pushing Changes

What it does: Uploads your local commits to the remote repository.

Branching

What it does: Creates an isolated workspace for your changes without affecting the main branch.

Staging and Committing

What it does: Staging selects which changes to include. Committing saves them as a permanent snapshot.

1. Open Source Control (Ctrl+Shift+G)
2. Navigate the changes list with Up/Down Arrow
3. Press Enter on a file to see the diff
4. Press + (or use the stage button) to stage a file
5. Move to the commit message input at the top
6. Type your commit message
7. Press Ctrl+Enter to commit

Learning Cards: Git in VS Code

Next: Working with Pull Requests Back: Working with Issues Related: Git & Source Control in VS Code | GitHub Pull Requests Extension | GitHub Copilot | Screen Reader Cheat Sheet | VS Code Accessibility Reference