Alex: Welcome back. GitHub Codespaces is one of those tools that can make a workshop feel a lot less fragile. Instead of asking every learner to install the same tools on a local computer, it gives you a VS Code development environment running on a cloud machine.

Jamie: And that cloud part matters because setup is often where people get stuck before they even touch Git.

Alex: Exactly. When you open a Codespace, GitHub creates a virtual machine, clones the repository into it, and connects that machine to a VS Code interface. You can use that interface in the browser, or connect it to VS Code Desktop on your own computer.

Jamie: So my screen reader, magnification, keyboard, and operating system are still local. The code environment is the part that lives somewhere else.

Alex: Right. That is a big accessibility win. You can use VS Code features like Screen Reader Optimized mode, audio cues, accessible diffs, zoom, themes, and the integrated terminal without installing compilers or language runtimes first. It also means everyone in a workshop can start from a similar environment, which makes troubleshooting much easier.

Jamie: When would I choose Codespaces instead of local VS Code?

Alex: Use Codespaces when setup would slow you down, when your local device is low-powered, when you are on a borrowed machine, or when a project needs tools you do not want to install locally. Local VS Code is still great when you already have your environment tuned, when you need offline access, or when you rely on extensions that work best on your desktop.

Jamie: Where does github.dev fit? I know pressing period on a GitHub repository opens a browser editor.

Alex: github.dev is great for quick edits because it opens a lightweight VS Code-style editor in the browser. But it does not give you a full cloud machine with a terminal. Codespaces is the choice when you need to run code, install packages, start a server, run tests, or use a development container.

Jamie: That also makes Codespaces useful on mobile or a low-end laptop, right?

Alex: Yes, with some practical limits. A phone or tablet can open a Codespace in the browser, and the heavy work happens in the cloud, not on the device. The tradeoff is screen size, touch keyboard friction, and browser behavior, so it is better for review and small edits than long coding sessions.

Alex: To create a Codespace from a repository page, open the repository on GitHub and move to the Code button. In the panel that opens, choose the Codespaces tab, then activate Create codespace on main, or the branch name you want.

Jamie: I always wonder what is happening after that click, because sometimes there is a wait and it feels mysterious.

Alex: GitHub is provisioning the virtual machine, attaching storage, cloning the repository, reading any environment configuration, and starting VS Code in a new browser tab. A normal startup may take 30 to 60 seconds, and larger projects can take longer.

Jamie: And there is also a dashboard, not just the repository page.

Alex: Yes. At github.com/codespaces, you can create a new Codespace, search for the repository, choose a branch, select a region, and pick a machine type. The default 2-core machine is enough for general development, documentation, and most workshop exercises. A 4-core machine helps with moderate builds or tests, and an 8-core machine is for heavier builds or multiple services.

Jamie: You mentioned environment configuration. Is that where devcontainer.json comes in?

Alex: Yes. A devcontainer.json file tells Codespaces how to build the development environment for the project. It can define the base image, install tools, recommend extensions, set environment variables, and run setup commands after the repository is created.

Jamie: So instead of saying, install Node, install Python, install this extension, set this folder, the repository can describe that setup.

Alex: Exactly. That is why it is so useful for classes and open source projects. A maintainer can encode the expected environment, and contributors can start with fewer surprises. It does not remove the need to understand the tools, but it removes a lot of local installation trouble.

Alex: Once the Codespace exists, you decide how you want to use it. The browser version opens as VS Code for the Web, with the Explorer, editor, terminal, Source Control view, extensions view, and command palette.

Jamie: Browser choice still matters, though.

Alex: It does. Codespaces works in Chrome, Edge, Firefox, and Safari, but Chrome and Edge tend to be the most consistent with NVDA and JAWS. Some VS Code extensions also are not available in the browser version, especially if they need local desktop capabilities.

Jamie: And if I want my familiar desktop setup?

Alex: Install the GitHub Codespaces extension in VS Code Desktop, sign in to GitHub, open the Command Palette with Ctrl+Shift+P or Cmd+Shift+P, and run Codespaces: Connect to Codespace. Then choose an existing Codespace or create a new one. Your screen reader is interacting with your local VS Code app, while the project and terminal still run on the cloud machine.

Jamie: Let's talk accessibility setup. What should a screen reader user check first?

Alex: VS Code usually detects a screen reader and turns on Screen Reader Optimized mode automatically. You can verify it from the Command Palette by searching for Toggle Screen Reader Accessibility Mode and pressing Enter. This applies in Codespaces the same way it does in desktop VS Code.

Jamie: What actually changes when that mode is on?

Alex: The editor is tuned to read content more predictably, especially line by line. Diff views become easier to review as text comparisons. Inline suggestions, including Copilot suggestions, are announced in a more controlled way instead of interrupting constantly.

Jamie: I also like audio cues because they catch things I miss visually.

Alex: Audio cues work in Codespaces just like in desktop VS Code. You can get tones for errors, warnings, breakpoints, task completion, and suggestion availability. To manage them, open Settings and search for audio cues, or run Help: List Audio Cues from the Command Palette.

Jamie: The terminal is the spot where people often lose their place. What helps there?

Alex: The integrated terminal is a standard terminal, so use the same patterns you use locally. In NVDA, Browse Mode helps you review output, Focus Mode lets you type, and setting maximum line length to 10000 can make long output easier to read. In JAWS, use Virtual Cursor for reading and PC Cursor for editing, often with Insert+Z or Num Pad Plus. On macOS, VoiceOver users can use Quick Nav and the Rotor, and if terminal text is hard to review, put focus in the terminal and press Alt+F2 for Accessible View.

Alex: The keyboard shortcuts are mostly standard VS Code shortcuts, so skills transfer well. Ctrl+Shift+P opens the Command Palette, Ctrl+P opens Quick Open for finding files, Ctrl+` toggles the integrated terminal, and Ctrl+B toggles the sidebar.

Jamie: Give me the panel shortcuts too, because those are easy to forget.

Alex: Ctrl+Shift+E opens Explorer, Ctrl+Shift+G opens Source Control, and Ctrl+Shift+X opens Extensions. In the editor, Ctrl+Shift+K deletes a line, Alt+Up and Alt+Down move a line, Ctrl+/ toggles a comment, and Ctrl+G jumps to a line number. In Source Control, you can review changed files, stage changes, write a commit message, commit, and push back to GitHub.

Jamie: And on a Mac, I should expect some Command-key versions.

Alex: Yes. Many shortcuts use Cmd instead of Ctrl on macOS, and browsers can sometimes intercept a shortcut before VS Code receives it. When in doubt, the Command Palette is the safest route because you can search for the action by name.

Jamie: What about previewing a web app? If the server runs inside the Codespace, how do I open it?

Alex: That is where port forwarding comes in. If your app starts a local server, maybe on port 3000 or 8000, Codespaces can detect that port and offer to forward it. You can open the forwarded address in a browser tab and test the app while it is still running in the cloud environment.

Jamie: Is that preview public by default?

Alex: Usually the forwarded port is private to you unless you change its visibility. Be careful before making a port public, especially if the app exposes test data, admin screens, or unfinished work. For most learning tasks, a private preview is enough.

Alex: Managing Codespaces is part of using them well. A Codespace can be stopped, resumed, or deleted, and those words do not mean the same thing.

Jamie: I want that distinction, because delete sounds scary and stop sounds harmless.

Alex: Stop pauses the cloud machine so it is not actively running, and you can resume it later. Delete removes the Codespace and its unpushed work, so push important commits before deleting. If you committed locally inside the Codespace but did not push, GitHub will not show those changes in the repository yet.

Jamie: And there are usage limits, even if many learners will not hit them in a workshop.

Alex: Personal GitHub accounts include a monthly free allowance for Codespaces, and typical workshop use is usually within that allowance. Still, machine size, running time, and storage can affect usage. Stop Codespaces you are not using, delete ones you no longer need, and check your GitHub billing and Codespaces usage pages if you are unsure.

Jamie: What about preferences that I want every time, like shell settings or editor themes?

Alex: Dotfiles can help with shell preferences, aliases, and setup scripts that you want applied to new Codespaces. VS Code Settings Sync can bring over settings like font size, theme, zoom, and some extension preferences. For low vision users, that means high-contrast themes and zoom choices can follow you into the browser-based editor.

Jamie: Let me throw a few common problems at you. Codespace takes forever, terminal stops reading, audio cues do not work, extensions are missing, or changes do not show up on GitHub.

Alex: If startup is slow, give it a little time, then reload or check whether the project is doing a heavy setup. If terminal output stops reading, use the screen reader's reading mode or VS Code Accessible View. If audio cues are silent, check VS Code settings, browser audio permissions, and whether the tab is muted. If an extension is unavailable in the browser, connect the Codespace to local VS Code Desktop. And if changes are not visible on GitHub, make sure you pushed, not just committed.

Jamie: So Codespaces is not a replacement for understanding Git or VS Code. It is a way to remove setup barriers and give everyone a workable starting point.

Alex: Yes. You still need the habits: know where your files are, use Source Control, commit clearly, push before cleanup, and verify the result on GitHub. But Codespaces can make the environment more predictable, especially for learners using screen readers, magnification, mobile devices, or low-end hardware. Because limits and interface names can change, the official GitHub Codespaces documentation is the place to check for current details.