Skip to content

00 pre workshop setup

Jump to bottom
taylorarndt edited this page Mar 7, 2026 · 1 revision

Pre-Workshop Setup - GIT Going with GitHub

Listen to Episode 1: Pre-Workshop Setup - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.

Everything You Need Before Day 1 Begins

A Community Access workshop.

Please complete this guide at least one day before the workshop. If you run into any issues, file an issue so we can help - we want Day 1 to start with everyone ready to go, not troubleshooting.

Table of Contents

  1. What You Will Need
  2. Step 1 - Create Your GitHub Account
  3. Step 2 - Configure GitHub Accessibility Settings
  4. Step 3 - Configure Your Profile
  5. Step 4 - Check GitHub Feature Preview Settings
  6. Step 5 - Set Up Your Screen Reader and Browser
  7. Step 6 - Install Git and Visual Studio Code
  8. Step 7 - Configure Git Identity
  9. Step 8 - Install VS Code Extensions
  10. Step 9 - Verification Checklist
  11. Other GitHub Access Methods (Reference Only)
  12. Getting Help Before the Event

What You Will Need

Hardware

  • A computer running Windows or macOS
  • A reliable internet connection
  • Headphones (recommended - screen reader audio during group sessions)

Software - Day 1

  • A modern web browser: Chrome or Firefox recommended
    • Both have strong compatibility with GitHub's interface and screen readers
    • Edge is also acceptable on Windows
    • Safari is the recommended browser on macOS with VoiceOver
  • A screen reader (see options below)
  • A GitHub account (free tier is fine)

Software - Required Before the Workshop

  • Git - Download Git (Windows/Linux) or Xcode Command Line Tools (macOS)
  • Visual Studio Code (free) - download here (GitHub Copilot is included automatically)
  • A GitHub Copilot subscription or Free tier access (Copilot Free is available to all GitHub users)

Screen Reader Options

You only need one of these. Use whichever you are most comfortable with.

Screen Reader Platform Cost Download
NVDA (NonVisual Desktop Access) Windows Free Download NVDA
JAWS (Job Access With Speech) Windows Paid (trial available) Download JAWS
VoiceOver macOS / iOS Built-in (free) Included with macOS - press Cmd+F5 to activate

Note: All workshop exercises are designed to work with any of these screen readers. Where specific key commands differ, we will note all three. You are not disadvantaged by using any particular screen reader.

Step 1 - Create Your GitHub Account

If you already have a GitHub account, skip to Step 2.

Before you begin: Have your email address and a chosen password ready. The signup form is a single-page form with several fields - your screen reader will encounter a verification puzzle partway through (see note below).

Create an account

  1. Open your browser and navigate to the GitHub signup page

  2. The page loads with focus on the first field: "Enter your email address"

    • Type your email address and press Tab or activate Continue

  3. The next field is "Create a password"

    • Choose a password of at least 8 characters (15+ recommended). Press Tab or Continue

  4. The next field is "Enter a username"

    • Your username appears on every issue, PR, and comment you make. Guidelines:
      • Use lowercase letters, numbers, and hyphens only
      • Keep it professional - it represents you in the open source community
      • GitHub will tell you immediately if the name is taken
    • Press Tab or Continue

  5. The next question asks whether you want to receive product updates by email

    • Press Tab to reach the "y" or "n" options and press Enter, or type y or n directly

  6. Human verification step

    Visual / mouse users

    GitHub presents a visual CAPTCHA puzzle to verify you are human. Follow the on-screen prompts - typically clicking images that match a category, or checking a box. If the puzzle does not load, try refreshing the page.

    Screen reader users

    GitHub's visual CAPTCHA is a known accessibility barrier. After the CAPTCHA appears:

    • Look for a button or link labeled "Audio" or "Try an audio challenge" - an audio CAPTCHA alternative may be available
    • If no audio option appears, or if neither challenge is accessible, contact the workshop organizer before the event - they can assist with account verification
    • If you complete an audio challenge, you will hear words or digits to type into a text field

  7. Activate the Create account button

  8. GitHub sends a launch code (a short numeric code) to your email inbox

    • Check your email, copy the code, return to the browser, and type it into the verification field
    • If you don't receive it within a few minutes, check your spam folder

  9. You will land on a "Welcome to GitHub" personalization page - you can skip it or answer the questions; it does not affect your account functionality

Verify your email address

GitHub also sends a separate email verification link after account creation. Check your inbox for an email from GitHub with subject "Please verify your email address" and activate the link inside it. Some GitHub features (including creating repositories) require a verified email.

Enable two-factor authentication (2FA): detailed guidance and workshop policy

Two-factor authentication (2FA) adds a second verification step each time you sign in, protecting your account if your password is compromised. For this workshop, 2FA is required. We recommend using the GitHub Mobile app for the smoothest experience - see the options below.

Quick steps to enable 2FA

  1. Open the GitHub security settings page while signed in.
  2. Under Two-factor authentication, choose Enable and follow the prompts.
  3. Choose one of the second-factor methods (recommended order):
    • GitHub Mobile app (recommended for this workshop): Install the free GitHub Mobile app on your phone. Once linked to your account, GitHub sends a push notification to your phone each time you sign in. You simply tap Approve - no codes to type. The app is available for iOS and Android and supports VoiceOver and TalkBack.
    • Authenticator app: Microsoft Authenticator, Google Authenticator, Authy - generates time-based 6-digit codes.
    • Security key / passkey (most secure): hardware security keys (YubiKey, etc.) or platform passkeys (biometric device credentials).
    • SMS / text message (least preferred): can be used if other options are unavailable.

Detailed setup notes

  • Authenticator app (recommended):

    • Visual users: scan the QR code with your authenticator app and enter the 6-digit code shown.
    • Screen reader users: choose the link labeled "enter this text code" or "can't scan the barcode?" to reveal the secret (a 32-character key). Use the authenticator app's manual/key-entry option to add the account.

  • Security key / passkey:

    • Follow the on-screen prompts to register a hardware key or platform passkey. These are highly recommended for long-term security and are supported by modern browsers and devices.

  • SMS / text message:

    • Enter your phone number and verify the code sent via text. Use only if authenticator apps or keys are unavailable.

Recovery and backup

  • After enabling 2FA, GitHub will display recovery (single-use) codes. Immediately copy, download, or securely store these codes (password manager or physically secure location). They are the only fallback if you lose your second-factor device.
  • Consider registering more than one second-factor method (e.g., authenticator app + a hardware key) to avoid account lockout.

Authenticating Git with GitHub: browser-based sign-in (OAuth)

When you use Git inside VS Code or GitHub Desktop, you do not need to manage passwords, tokens, or SSH keys manually. These tools use browser-based OAuth sign-in - the same "Sign in with GitHub" flow you use on any website:

  1. The first time you push or pull code, VS Code (or GitHub Desktop) opens your default web browser to a GitHub authorization page.
  2. Sign in to GitHub in the browser (including your 2FA step - a push notification if you use GitHub Mobile, or a code from your authenticator app).
  3. Approve the authorization request.
  4. Switch back to VS Code. Your credentials are securely stored by your operating system's credential manager, so you will not be prompted again on this machine.

That is it. No tokens to generate, no keys to create, no strings to paste. If you are using GitHub Mobile for 2FA, the entire flow is: type your password, tap Approve on your phone, and you are authenticated.

Screen reader note: The authorization page opens in your default browser. After approving, the browser shows a message saying you can return to VS Code. Use Alt+Tab (Windows) or Cmd+Tab (macOS) to switch back.

Tip - GitHub Mobile for push notification 2FA: If you have not already, install the free GitHub Mobile app (iOS and Android). Once linked to your account, every 2FA prompt becomes a single tap on a push notification instead of typing a 6-digit code. The app supports VoiceOver (iOS) and TalkBack (Android).

Workshop policy

For this workshop, participants need a GitHub account with 2FA enabled. The browser-based sign-in described above handles all Git authentication automatically - no additional setup is required beyond having a working GitHub account.

If you run into any authentication issues before the workshop, contact the workshop organizers at the email or issue link in this guide so we can help.

Step 2 - Configure GitHub Accessibility Settings

These settings make GitHub significantly more usable with a screen reader. Do not skip this section - one setting in particular (hovercards) adds significant noise to every page if left on.

Navigate to Accessibility Settings

The fastest path for everyone: navigate directly to GitHub Accessibility Settings while signed in.

If you prefer to navigate through the interface:

Visual / mouse users
  1. Click your profile picture (avatar) in the top-right corner of any GitHub page
  2. A dropdown menu appears - click Settings
  3. On the Settings page, scroll the left sidebar and click Accessibility
Screen reader users (NVDA / JAWS)
  1. On any GitHub page, switch to Browse Mode if you are not already in it (NVDA+Space / JAWS virtual cursor should be on by default in browsers)
  2. Press B repeatedly until you hear "Open user navigation menu, button" (top-right of the page) and press Enter
  3. Navigate the menu with ↓ or K until you hear "Settings" and press Enter
  4. On the Settings page, press D to move through landmark regions until you reach the left sidebar navigation
  5. Press K or ↓ to navigate through sidebar links until you hear "Accessibility" and press Enter
Screen reader users (VoiceOver on macOS)
  1. Press VO+U to open the Rotor, arrow to Buttons, find "Open user navigation menu" and press Enter
  2. Press VO+Down Arrow to find "Settings" and press VO+Space
  3. On Settings, press VO+U, go to Links, find "Accessibility" and press Enter

Settings to configure

Work through each setting below. All are on the Accessibility settings page unless noted.

1. Disable Hovercards (highest priority)

Do this first. Hovercards are the most disruptive default setting for screen reader users on GitHub. When enabled, every link announces its hover keyboard shortcut (H) as you navigate past it, dramatically slowing page reading.

Visual / mouse users

On the Accessibility settings page, look for a checkbox or toggle labeled "Link previews" or "Hovercards". If it is turned on, click it to turn it off. The change saves automatically.

Screen reader users
  1. On the Accessibility settings page, switch to Browse Mode if not already active
  2. Press F or X to jump through form controls until you hear "Link previews" or "Hovercards"
  3. If it is announced as checked or on, press Space to turn it off
  4. The change saves automatically - no Submit button required

2. Enable Link Underlines

Visual / mouse users

Find the Link underlines checkbox or toggle and turn it on. This adds underlines to all links on GitHub, making them distinguishable without relying on colour alone.

Screen reader users
  1. Press F or X to navigate form controls until you hear "Link underlines"
  2. If it is announced as unchecked, press Space to enable it
  3. The change saves automatically

3. Character Key Shortcuts

  1. Find "Character key shortcuts"
  2. Single-key shortcuts (H for next heading, I for next issue, etc.) speed up navigation but can conflict with screen reader quick-navigation keys
    • If your screen reader uses letters for navigation in Browse Mode (NVDA, JAWS), GitHub's single-key shortcuts are suppressed when Browse Mode is active, so conflicts are rare in practice
    • If you notice unexpected behavior, return here and turn them off
  3. Leave at the default unless you have a reason to change it

4. Set Your Theme (Appearance Settings)

Theme is on a separate page: GitHub Appearance Settings

  1. Navigate to that page
  2. Find the "Theme mode" or "Theme" section
  3. Options available:
    • Light default - standard white background
    • Dark default - dark background, easier on some eyes
    • High contrast light - maximum contrast, recommended for low vision
    • High contrast dark - maximum contrast on dark background
    • Colorblind variants - Protanopia, Deuteranopia, Tritanopia
  4. Select your preferred theme and activate Save if prompted (some changes apply immediately)

Step 3 - Configure Your Profile

Your GitHub profile is your public identity in the open source community. Setting it up properly helps maintainers know who you are.

Update your profile

  1. Navigate to Settings → Public profile
  2. Fill in:
    • Name - your real name or display name (not the same as your username)
    • Bio - a short description (e.g., "Accessibility advocate and open source contributor")
    • Location - optional but builds trust in the community
    • Website or social links - optional
    • Pronouns - GitHub supports adding pronouns to your profile

Add a profile picture (optional)

A profile picture humanizes your contributions. It can be a photo or any image. If you prefer not to use a photo, GitHub generates a default avatar based on your username.

Set your notification email

  1. Navigate to Settings → Notifications
  2. Add a custom routing email if you want GitHub notifications to go to a different address than your account email

Step 4 - Check GitHub Feature Preview Settings

GitHub continuously rolls out improvements to its interface. Some enhancements start as opt-in Feature Previews before becoming the standard experience. Two features matter most for screen reader users working through this workshop:

  • New Issues Experience - improves heading hierarchy, ARIA landmark structure, and live-region announcements on the Issues pages
  • New Files Changed Experience - adds proper landmark structure, an accessible file tree, and better keyboard navigation to the Files Changed tab in Pull Requests

Both have been broadly rolled out and may already be active on your account. Check before the workshop begins.

How to Check and Enable Feature Previews

Source: accessibility.github.com/documentation/guide/issues/ and accessibility.github.com/documentation/guide/pull-requests/

Visual / mouse users
  1. Sign in to GitHub and go to any page
  2. Click your profile picture (avatar) in the top-right corner
  3. In the dropdown menu, click Feature preview
  4. A panel opens on the right side of the screen listing available features
  5. Click on New Issues Experience to expand its details
  6. If an Enable button appears, click it. If you see Disable, the feature is already active - no action needed.
  7. Return to the feature list and repeat for New Files Changed Experience
Screen reader users (NVDA / JAWS)

NVDA or JAWS (Windows)

  1. Sign into GitHub and open any page
  2. Switch to Browse Mode if not already active (NVDA+Space / JAWS virtual cursor)
  3. Press H or Shift+H to navigate to the "Navigation Menu" heading, or press D to navigate landmark regions to the navigation section
  4. Press B to jump to buttons, navigating until you hear "Open user navigation menu, button" - this button is in the top-right corner of the page
  5. Press Enter to activate it - a dropdown menu opens
  6. Press ↓ or K to move through the menu items until you hear "Feature preview"
  7. Press Enter to select it - the Feature Preview panel opens
  8. Navigate through the list of features with ↓ or I (list item navigation)
  9. When you reach "New Issues Experience", press Enter or Space to select it - its detail panel expands
  10. Press Tab to move to the end of the feature detail section, where you will find either:
    • An "Enable" button - press Enter to enable the feature
    • A "Disable" button - the feature is already enabled; no action needed
  11. Go back and repeat steps 9-10 for "New Files Changed Experience"
Screen reader users (VoiceOver on macOS)
  1. Sign into GitHub and open any page
  2. Press VO+U to open the Rotor and navigate to the Buttons list
  3. Find "Open user navigation menu" and press Enter to activate it
  4. Use VO+Down Arrow to navigate the dropdown until you hear "Feature preview"
  5. Press VO+Space to activate it - the Feature Preview panel opens
  6. Use VO+Down Arrow or VO+Right Arrow to navigate through the feature list
  7. When you reach "New Issues Experience", press VO+Space to select it
  8. Press Tab to move to the end of the feature detail section
  9. If you hear "Enable", press VO+Space to activate it. If you hear "Disable", it is already on.
  10. Repeat for "New Files Changed Experience"

What "Not Listed" Means

If you open Feature Preview and neither "New Issues Experience" nor "New Files Changed Experience" appears in the list at all - that is good news. It means both features have graduated to the standard GitHub interface and are active automatically for every user. No action needed.

What Each Feature Enables

Feature What it improves for screen reader users
New Issues Experience Issues list uses proper <ul> list structure. Issue titles are h3 headings. ARIA live regions announce filter result updates. Toolbar uses arrow key navigation. Close issue via Ctrl+Shift+Enter from the comment box.
New Files Changed Experience Files Changed tab includes a navigable file tree region. Diffs are structured as tables with row/column navigation. Filter changed files field is reachable with E. Inline comment mode activates with Enter on a focused diff line.

Why this matters: Without these features enabled, the keyboard and screen reader workflows described throughout this workshop will not match what you see on screen. Enabling them before you begin ensures everything works as documented.

Step 5 - Set Up Your Screen Reader & Browser

NVDA (Windows)

Install NVDA if you haven't already:

  1. Download from the NVDA download page
  2. Run the installer - you can install to your computer or run portably
  3. After launch, NVDA speaks "NVDA started" when running

Configure NVDA for web browsing

  1. Open NVDA Menu (NVDA+N)
  2. Go to Preferences → Settings → Browse Mode
  3. Enable "Use screen layout" - this helps with GitHub's landmark navigation
  4. Under Document Formatting, disable announcements you find too verbose

Recommended NVDA voice settings

  • Rate: 60-75% (fast enough to be efficient, slow enough to be clear)
  • Punctuation: "Most" (reads important symbols like # and @ without reading every period)

Your NVDA key: By default it is Insert. It can also be set to Caps Lock in NVDA preferences if that is more comfortable.

JAWS (Windows)

If using a trial: JAWS runs in 40-minute sessions without a license. Restart it if you need more time.

Configure JAWS for web browsing

  1. Open JAWS Settings Center: Insert+F2 → Settings Center
  2. Ensure "Virtual cursor" is active for web browsing
  3. In Chrome or Firefox, JAWS should automatically activate Virtual/Browse mode

Recommended JAWS settings for GitHub

  • Verbosity → Links: Read link text only (disable "opens in new window" if too verbose)
  • Verbosity → Punctuation: "Most" for same reason as NVDA

Your JAWS key: Insert (or Caps Lock if using laptop layout)

VoiceOver (macOS)

Activate VoiceOver: Command+F5 toggles VoiceOver on and off.

Essential VoiceOver setup for web

  1. Open VoiceOver Utility: VO+F8
  2. Go to Web category → Web Rotor
  3. Ensure these are checked: Headings, Landmarks, Links, Buttons, Form Controls, Tables
  4. Recommended browser: Safari (best VoiceOver integration on macOS)
  5. Firefox on macOS also has good VoiceOver support

Your VoiceOver modifier key: VO = Control+Option by default.

Turn on Quick Nav for fast navigation

  • Press Left Arrow + Right Arrow simultaneously to toggle Quick Nav
  • With Quick Nav on: H = next heading, L = next link, B = next button (same as NVDA/JAWS browse mode keys)

Browser Recommendations Summary

Browser Windows macOS Notes
Chrome Recommended Good Best with NVDA and JAWS
Firefox Recommended Good Excellent accessibility support on all platforms
Edge Acceptable Acceptable Chromium-based; works well
Safari Not available Recommended Best for VoiceOver on macOS

Before the workshop: Open GitHub.com in your chosen browser with your screen reader running and confirm you can navigate the page using heading keys.

Step 6 - Install Git and Visual Studio Code

Install Git First

VS Code does not install Git. It detects whether Git is already on your system. If Git is missing, the Source Control panel will display a warning, and all git commands in the terminal will fail. Install Git before installing VS Code.

Windows

  1. Download the Git for Windows installer from Git for Windows download page
  2. Run the installer - default options are correct for most users
  3. On the "Adjusting your PATH environment" screen, keep the default: "Git from the command line and also from 3rd-party software"
  4. Complete the installer and restart any open terminals

Verify installation (Windows)

  1. Open PowerShell or Command Prompt
  2. Type git --version and press Enter
  3. You should see a version number such as git version 2.47.0.windows.2 - any version is fine

macOS

Git is often already present via Xcode Command Line Tools. To check:

  1. Open Terminal (Cmd+Space → type "Terminal")
  2. Type git --version and press Enter
  3. If Git is not installed, macOS will automatically prompt you to install Xcode Command Line Tools - follow the prompt and wait for it to complete
  4. Alternatively, install directly from Git for macOS download page or via Homebrew: brew install git

Screen reader note (Windows terminal verification)

  • PowerShell is accessible with all screen readers via Browse Mode or Forms Mode
  • Type git --version, press Enter, then press ↑ to re-read the output line

Once Git is installed, you will configure your Git identity in Step 7 after VS Code is set up.

Install Visual Studio Code

Visual Studio Code (VS Code) is the development environment used throughout this workshop. It is free, open source, and has excellent built-in accessibility support.

Download and install

  1. Navigate to code.visualstudio.com
  2. Select the download link for your operating system
  3. Run the installer with default options
  4. Launch VS Code when the installer finishes

Enable Screen Reader Mode in VS Code

Do this before anything else in VS Code. Screen Reader Mode changes how the editor renders content - without it, your screen reader may receive incomplete or fragmented output from the editor, diff views, and Copilot Chat.

VS Code may detect your screen reader automatically when it first opens and ask if you want to enable this mode. If it does:

  1. Listen for the dialog - it will say something like "A screen reader is detected. Would you like to enable Screen Reader Optimized mode?"
  2. Press Enter to accept, or Tab to the Enable button and press Space

If VS Code did not prompt you automatically, enable it manually:

Option A - Keyboard shortcut

  1. Press Shift+Alt+F1
  2. VS Code toggles Screen Reader Optimized mode immediately

Option B - Command Palette

  1. Press Ctrl+Shift+P to open the Command Palette
    • Your screen reader will announce "Type to filter" or the palette input field
  2. Type: screen reader - the list filters as you type
  3. Arrow down to "Accessibility: Toggle Screen Reader Accessibility Mode"
  4. Press Enter

How to confirm it is on

  1. Press Ctrl+Shift+P to open the Command Palette again
  2. Type: screen reader optimized
  3. If the status bar at the bottom of the window is accessible to you, it will read "Screen Reader Optimized"
  4. Alternatively: go to File → Preferences → Settings (Ctrl+,), type screenReaderOptimized in the search box, and verify the checkbox is ticked

What Screen Reader Mode changes

  • The editor renders as a plain text region your screen reader can navigate linearly with arrow keys
  • Audio cues are enabled for inline suggestions, errors, warnings, and folder expand/collapse
  • Diffs are presented as readable before/after text instead of a visual side-by-side view
  • The Copilot Chat response panel reads as a structured document

Screen reader note: Once Screen Reader Mode is on, you navigate the editor with Up and Down Arrow to move line by line. Press Enter to open a folded section. Press Escape to leave the editor and move focus back to the activity bar or panels.

VS Code keyboard basics (we will cover these fully in the workshop)

Action Shortcut
Open Command Palette Ctrl+Shift+P
Open file Ctrl+P
Open terminal Ctrl+` (backtick)
Focus Explorer panel Ctrl+Shift+E
Focus editor Ctrl+1

Step 7 - Configure Git Identity

Now that Git is installed, tell it who you are. Git embeds your name and email in every commit you make, and this affects how your contributions appear in project history.

Configure in VS Code

  1. Open Visual Studio Code
  2. Open the integrated terminal:
    • Menu: Terminal → New Terminal
    • Keyboard: Ctrl+` (Windows) or Cmd+` (Mac)
  3. Type the following commands, replacing with your information:
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

What to use

  • user.name: Your real name or the name you want shown on commits (e.g., "Jane Smith")
  • user.email: The email address associated with your GitHub account (must match exactly)

Screen reader note: The terminal in VS Code is accessible with all major screen readers. Press Ctrl+` to move focus to the terminal, type your commands, and press Enter.

Why This Matters

If Git isn't configured, it will either:

  • Use a default name like "Unknown" (looks unprofessional in project history)
  • Refuse to create commits with an error message

Verify Your Configuration

Run this command to see your current settings:

git config --global --list

You should see:

user.name=Your Name
user.email=your-email@example.com

Using the Correct Email

Use the same email you registered with GitHub. If you're concerned about privacy, GitHub offers a no-reply email you can use: username@users.noreply.github.com - find it in Settings → Emails.

Step 8 - Install VS Code Extensions

This workshop uses two VS Code extensions. GitHub Copilot is built into VS Code automatically. The GitHub Pull Requests extension needs to be installed manually. Both authenticate through your browser session - if you are signed into GitHub in your web browser, VS Code picks up the session automatically.

GitHub Copilot (Built In)

GitHub Copilot is automatically included with Visual Studio Code. There is no extension to install separately. It provides both inline code completions and the conversational Agent mode panel used throughout the second half of the workshop.

Activate Copilot

  1. Make sure Screen Reader Mode is enabled (see above)
  2. Make sure you are signed into GitHub in your web browser
  3. Press Ctrl+Shift+I to open Agent mode
    • Your screen reader should announce the chat input field
  4. Type: Hello and press Enter
  5. VS Code will automatically sign you into GitHub Copilot using your browser session - no manual sign-in command is needed
  6. A response will appear in the chat history above the input field
  7. Navigate up with Shift+Tab or Up Arrow to read the response

That is it. You do not need to use the Command Palette to sign in. If you are logged into GitHub in your browser, VS Code handles authentication automatically when you first interact with the agent.

Extension 2 - GitHub Pull Requests

This extension lets you review and manage pull requests without leaving VS Code. It is used in the code review chapters.

Install

  1. Press Ctrl+Shift+X to open the Extensions panel
  2. Type: GitHub Pull Requests
  3. Press Tab to move into the results list
  4. Arrow down to find "GitHub Pull Requests" with publisher "GitHub"
    • This extension was formerly named "GitHub Pull Requests and Issues" - either name is correct
  5. Press Enter to open the details page
  6. Press Tab to the Install button and press Enter or Space
  7. VS Code will announce when installation is complete

Verify it is working

  1. Press Ctrl+Shift+P and type: GitHub Pull Requests: Sign in
    • If you are already signed in from the earlier step, this command may not appear - that means you are already authenticated
  2. To confirm the extension loaded: press Ctrl+Shift+P, type GitHub Pull Requests: Focus on Pull Requests View
    • The Pull Requests panel should open in the sidebar
    • If your repository has open pull requests, they will appear here

Screen reader note: The Pull Requests panel is a tree view. Navigate it with Up and Down Arrow. Press Enter or Right Arrow to expand a node.

Copilot Free tier

Copilot Free is available to all GitHub users at no cost. It includes:

  • Limited inline code completions per month
  • Limited Copilot Chat messages per month

For this workshop, Free tier is sufficient. If you want unlimited access, paid plans are available at GitHub Copilot pricing.

Step 9 - Verification Checklist

Work through this checklist before Day 1. Check off each item:

Pre-Workshop Checklist

GITHUB ACCOUNT
[ ] GitHub account created and email verified
[ ] Two-factor authentication enabled
[ ] Profile name, bio set

GITHUB SETTINGS
[ ] Accessibility settings page visited
[ ] Hovercards / link previews turned OFF
[ ] Theme set to your preferred option
[ ] Confirmed modern GitHub Issues and Pull Request experience is working (see Step 4 - may already be active or enabled via Feature preview)

BROWSER & SCREEN READER
[ ] Screen reader installed and working (NVDA / JAWS / VoiceOver)
[ ] Browser chosen: Chrome, Firefox, Edge (Windows) or Safari (macOS)
[ ] Navigated to github.com with screen reader - page announces headings and landmarks
[ ] Can navigate the GitHub homepage using heading keys (H) without a mouse

GIT & VS CODE (required before the workshop)
[ ] Git installed and verified (run git --version in a terminal)
[ ] Git identity configured (git config --global user.name and user.email)
[ ] Visual Studio Code installed
[ ] Screen Reader Mode enabled in VS Code (Shift+Alt+F1 or Command Palette)
[ ] Signed into GitHub in your web browser
[ ] GitHub Copilot responds in Agent mode (Ctrl+Shift+I, type Hello, get a response)
[ ] GitHub Pull Requests extension installed (publisher: GitHub)
[ ] Pull Requests panel opens (Ctrl+Shift+P → "Focus on Pull Requests View")

Other GitHub Access Methods (Reference Only)

This workshop focuses entirely on GitHub.com in the browser and VS Code. However, you should be aware that other ways to work with GitHub exist. We list them here for your reference - we will not be teaching these in depth.

GitHub Desktop

A graphical desktop application for managing repositories, branches, and commits without using the command line.

  • Download: desktop.github.com
  • Provides a visual interface for cloning, committing, pushing, and creating PRs
  • Has some screen reader support, though the web interface is generally more accessible
  • A good option for those who prefer a visual GUI over the command line

GitHub CLI (gh)

A command-line tool that lets you perform nearly any GitHub action directly from your terminal.

# Examples (reference only - not covered in this workshop)
gh repo clone owner/repo
gh issue create
gh pr create
gh pr review
gh pr merge
  • Download: cli.github.com
  • Excellent for automation and scripting
  • Very accessible - terminal/command-line interfaces work well with screen readers
  • Full documentation: cli.github.com/manual

GitHub Copilot CLI (gh copilot)

An extension to the GitHub CLI that brings Copilot assistance to the terminal. You can ask it to explain or suggest shell commands in plain English.

# Reference examples only
gh copilot suggest "how do I undo my last commit"
gh copilot explain "git rebase -i HEAD~3"

Git (the version control system itself)

GitHub is a platform built on top of Git, which is the underlying version control system. Git runs locally on your computer via a terminal.

We are not covering Git commands in this workshop. If you want to learn Git, these are excellent starting points:

Getting Help Before the Event

If you cannot complete any step in this guide before the workshop:

  1. File an issue - community-access/git-going-with-github - we will help you get set up
  2. File an issue in this repository - describe exactly what step you are on and what is not working
  3. Join the GitHub Accessibility Discussions - GitHub Community Accessibility Discussions - the community is helpful and welcoming

You will not be left behind. Every setup issue we can solve before Day 1 means more time for learning on the day.

Next: Understanding GitHub's Web Structure Back: README

Home

Getting Started

Core Chapters

VS Code and Git

AI and Accessibility

Appendices

Clone this wiki locally