- About This Workshop
- Is This For Me?
- Getting Started
- Screen Readers and Accessibility
- GitHub Accounts and Authentication
- Navigating GitHub on the Web
- Issues
- Pull Requests
- Merge Conflicts
- Branches and Forks
- Markdown
- Labels, Milestones, and Projects
- Notifications
- VS Code
- Git and Source Control in VS Code
- GitHub Copilot
- Accessibility Agents
- Issue Templates
- Code Review
- The Learning Room
- Workshop Logistics
- After the Workshop
- Concepts and Terminology
- Still Stuck?
A: No. While it focuses on GitHub (a platform developers use), the concepts apply to anyone collaborating on projects. Documentation improvements, issue filing, accessibility testing, and code reviews are all valuable contributions that require no coding. Start: Chapter 1 - no coding required.
A: Not for most chapters. Chapters 0-9 teach GitHub concepts without requiring code knowledge. Chapters 10-16 introduce programming tools and concepts but explain them for beginners. If you are non-technical, you can skip code examples and still understand the workflows.
A: Depends on your path:
- Core path (Day 1 only): ~7.5 hours of structured time
- Full curriculum (Day 1 + Day 2): ~15 hours total
- Just the essentials: 3-4 hours (Chapters 0, 1, 4, 5)
- Self-paced: Read at your own speed - there is no timer
A: You can do most of the workshop solo. The chapters, exercises, and appendices are self-contained. A few exercises in the Learning Room (Chapter 3) involve peer review and are designed for groups, but you can still practice the individual challenges on your own.
A: Day 1 uses the GitHub web interface only - everything happens in your browser. Day 2 moves to VS Code on the desktop and introduces GitHub Copilot and Accessibility Agents. Day 1 skills are prerequisite for Day 2 - the agents only make sense when you understand what they automate.
A: The GitHub Skills modules (used during Day 1) award completion badges on your GitHub profile. These are visible to anyone who visits your profile. The workshop itself does not issue a separate certificate, but your merged PR to community-access/accessibility-agents on Day 2 is permanent proof of contribution.
A: See the Course Guide for the full table of contents, chapter sequence, timing, and exercises at a glance.
A: Start with Chapter 0 (Pre-Workshop Setup) to install tools, then Chapter 1 (Understanding GitHub Web Structure). Both assume zero prior knowledge.
A: Yes. Chapter 4 (Working with Issues) and Chapter 5 (Working with Pull Requests) will deepen your understanding. Then jump to Chapter 14 (Accessible Code Review) for best practices.
A: Chapter 8 (Labels, Milestones & Projects) → Chapter 15 (Issue Templates) → Chapter 16 (Accessibility Agents). These focus on organizing projects and automating common tasks.
A: Yes, read the full curriculum first. Also read FACILITATOR.md, DAY1_AGENDA.md, and DAY2_AGENDA.md for lesson plans and pacing tips.
A: Yes. This guide was designed for screen reader users from the beginning. Every chapter includes screen reader instructions and keyboard-only workflows. Start with Appendix B (Screen Reader Cheat Sheet) for a quick command reference.
A: Absolutely. All content is keyboard-navigable. Sighted participants benefit from the same structured approach to GitHub, and the accessibility-first perspective teaches habits that make all collaboration better.
A: All technical terms are defined in Appendix A (Glossary). The language is intentionally simple and direct. If anything is unclear, open an issue on GitHub or check QUICK_REFERENCE.md.
A: Read Chapters 0, 1, 4, and 5. That covers setup, GitHub structure, issues, and pull requests - enough to start contributing to any project.
A: See TROUBLESHOOTING.md → "Problem: Git is not installed". It has platform-specific steps for Windows, macOS, and Linux.
A: You likely need to set up authentication (SSH key or HTTPS personal access token). See Chapter 0 (Pre-Workshop Setup) or Appendix D (Git Authentication).
A: No. Branching is covered in Chapter 5 (Pull Requests) and merge conflicts are covered in Chapter 6. You learn as you go.
A: For Day 1 (browser only):
- A modern web browser (Chrome, Edge, Firefox, or Safari)
- Git (for cloning repositories)
- A GitHub account (free tier is fine)
For Day 2 (VS Code):
- Visual Studio Code
- GitHub Copilot and Copilot Chat extensions
- GitHub Pull Requests and Issues extension
Full instructions: Chapter 0 (Pre-Workshop Setup)
A:
- NVDA: Firefox or Chrome both work well. Firefox has slightly better ARIA support.
- JAWS: Chrome or Edge are recommended. JAWS has strong support for Chromium-based browsers.
- VoiceOver: Safari is the most compatible browser on macOS.
A: No. A free GitHub account is sufficient for everything in this workshop, including creating repositories, filing issues, opening pull requests, and participating in discussions. GitHub Copilot has a free tier with limited usage, but a paid subscription (~$10/month) provides full access for Day 2 content.
A: Day 1 (browser-based) works on any device with a modern browser and a keyboard. Day 2 requires Visual Studio Code, which runs on Windows, macOS, and Linux desktops. If you have a Chromebook, consider GitHub Codespaces as an alternative to a local VS Code install.
A: The workshop is tested with:
- NVDA 2025.3.3 on Windows
- JAWS 2026 on Windows
- VoiceOver on macOS Sonoma and later
Other screen readers (Narrator, Orca, BRLTTY) may work but are not tested.
A: The main thing to verify is:
- Browse mode (also called virtual mode or document mode) should be active for web navigation
- Hovercards should be turned off in GitHub settings (they interfere with screen reader navigation)
Detailed setup is in Chapter 0 (Pre-Workshop Setup), Step 4.
A:
- Browse Mode (virtual/document mode): Your screen reader intercepts keystrokes and uses them for navigation (H for headings, B for buttons, K for links). Use this when reading web pages.
- Focus Mode (forms/application mode): Keystrokes go directly to the web page or application. Use this when typing in text fields, dropdown menus, or interactive widgets.
- Toggle: NVDA uses
NVDA+Space, JAWS toggles automatically (orInsert+Zto force), VoiceOver usesVO+Shift+F5.
A: Several possible causes:
- You may be in Focus Mode instead of Browse Mode - press
NVDA+Space(NVDA) orInsert+Z(JAWS) to toggle - Hovercards may be enabled - go to GitHub Settings → Accessibility → turn off "Hovercards"
- The page may not have loaded fully - wait a few seconds and try again
- See TROUBLESHOOTING.md → "Screen Readers & Accessibility" for more solutions
A: Yes. NVDA and JAWS both support braille output. The workshop documents render as standard text. VS Code supports braille through your screen reader's braille driver. No special configuration is needed beyond your normal braille setup.
A: The most important ones:
H- Jump to next heading (Browse Mode)D- Jump to next landmarkB- Jump to next buttonK- Jump to next linkF- Jump to next form fieldTab- Move to next interactive elementCtrl+Enter- Submit text on GitHubNVDA+F7/Insert+F3/VO+U- Elements List / Rotor
Full reference: Appendix B (Screen Reader Cheat Sheet)
A:
- NVDA:
Tjumps to next table. Once inside, useCtrl+Alt+Arrow keysto move between cells. - JAWS:
Tjumps to next table.Ctrl+Alt+Arrow keyswithin cells. - VoiceOver:
VO+Right/Leftthrough cells, or use the Rotor (VO+U) set to "Tables."
A: Yes. GitHub's web interface is responsive. Use Ctrl++ (or Cmd++ on Mac) to zoom in. The HTML versions of workshop documents (in the html/ folder) are also responsive and work at any zoom level.
A: Your screen reader announces the role of each element - "button," "link," "edit text," "checkbox," etc. If it announces "clickable" without a more specific role, it may not be fully accessible. In that case, try Enter or Space to activate it.
A: Go to https://github.com/password_reset, enter your email, and follow the reset link. If you use two-factor authentication (2FA) and lost access to your second factor, see GitHub's account recovery documentation.
A:
- SSH: More secure, no password prompts after setup, recommended for regular use
- HTTPS with Personal Access Token: Easier initial setup, works through corporate firewalls that block SSH
- Recommendation: Use SSH if you can. See Appendix D (Git Authentication) for setup instructions for both.
A: GitHub no longer allows password authentication for Git operations over HTTPS. A PAT is a generated string that replaces your password. Create one at https://github.com/settings/tokens. Give it repo scope for full repository access. Treat it like a password - do not share it.
A:
- Windows:
git config --global credential.helper manager(stores securely in Windows Credential Manager) - macOS:
git config --global credential.helper osxkeychain(stores securely in Keychain) - Linux:
git config --global credential.helper cache(temporary - expires after 15 minutes by default) or use a keyring-based helper
Never use credential.helper store on shared or multi-user systems - it saves credentials in plaintext.
A: Go to https://github.com/settings/security → "Enable two-factor authentication." GitHub supports authenticator apps (recommended), security keys, and SMS. After enabling 2FA, you will need recovery codes - save them somewhere safe.
Security note: We strongly recommend enabling 2FA on your GitHub account. If you cannot enable 2FA, you may still participate by adding an SSH key or creating a Personal Access Token (PAT) with repo scope for Git operations. Contact the workshop organizers if you need help.
A: Yes. After authenticating with SSO, you may need to authorize your SSH key or PAT for that organization. Go to https://github.com/settings/tokens → find your token → click "Configure SSO" → authorize for your org.
A: Every repository has these tabs:
- Code - File tree, README, branch selector
- Issues - Bug reports, feature requests, discussions
- Pull Requests - Proposed changes waiting for review
- Actions - Automated workflows (CI/CD)
- Projects - Project boards for organizing work
- Settings - Repository configuration (owner/admin only)
Navigate between tabs using the D key to find the "Repository navigation" landmark, then arrow through the tabs.
A: Press T on any repository page to open the file finder. Start typing the filename - results filter as you type. Press Enter to open the file. This works with your screen reader in Browse Mode.
A: Navigate to the file in the Code tab and click (or press Enter) on its name. The file opens in a rendered view (for Markdown) or a code view (for code files). Use H to navigate headings in Markdown files.
A: On the Code tab, find the branch selector button (it shows the current branch name, usually "main"). Press Enter to open it, type the branch name, and select from the filtered list. Screen reader tip: use B to find the button.
A: GitHub has built-in keyboard shortcuts. Press ? on any GitHub page to see the full list. Key shortcuts:
GthenI- Go to IssuesGthenP- Go to Pull RequestsT- Open file finder.- Open the repository in github.dev (VS Code in your browser)/- Focus the search bar
Full reference: Appendix B (Screen Reader Cheat Sheet)
A: GitHub regularly updates its interface. The core structure (tabs, headings, landmarks) remains consistent, but specific button labels or layout may change. If something does not match the guide, navigate by role (use B for buttons, H for headings) rather than relying on exact position.
A: Use the search bar (/ to focus it) with qualifiers:
is:issue is:open label:bug- Find open bug issuesis:pr is:open review-requested:@me- Find PRs awaiting your reviewlanguage:python stars:>100- Find popular Python repositories
Full reference: Appendix J (Advanced Search)
A:
- Issue = A problem or request (e.g., "Fix login bug" or "Add dark mode")
- Pull request = Your solution - the actual changed code or documentation that fixes the issue
- An issue describes what needs to happen. A PR makes it happen.
- See Chapter 4 for issues and Chapter 5 for PRs.
A:
- Open an issue if: You found a bug, want to suggest a feature, have a question, or want to discuss something
- Open a PR if: You already have the changes ready to fix or improve something
- Both? Open the issue first, discuss with maintainers, then open a PR that references the issue
A: A good issue includes:
- Clear title - Describe the problem, not the solution ("Screen reader skips navigation landmark" not "Fix thing")
- Steps to reproduce - What did you do? What happened? What did you expect?
- Environment - Your operating system, browser, screen reader, and versions
- Screenshots or recordings - If possible and relevant
- Labels - Apply the most relevant label (bug, enhancement, accessibility, etc.)
A: A label that maintainers add to issues that are suitable for first-time contributors. These issues are typically well-defined, small in scope, and have clear instructions. Filter for them: Issues tab → filter by label → good first issue.
A: Type # followed by the issue number (e.g., #42). GitHub auto-links it. For issues in other repositories, use the full format: owner/repo#42.
A: Include one of these keywords followed by the issue number in your PR description:
Closes #42Fixes #42Resolves #42
When the PR is merged, the issue closes automatically.
A: Yes. Navigate to the closed issue and click "Reopen issue." Only people with write access to the repository can reopen issues filed by others.
A: On the issue sidebar, find the "Notifications" section. Click "Subscribe" to get notified of all comments, or "Unsubscribe" to stop notifications. You are automatically subscribed to issues you create or comment on.
A:
- A pull request (PR) asks the maintainer to "pull" your changes into their repository
- Literally: "I have changes on my branch. Please pull them into the main branch."
- GitLab calls the same concept a "merge request"
- See Chapter 5 (Working with Pull Requests)
A:
- Conversation - Title, description, comments, timeline, status checks
- Commits - Individual commits in the PR, with author and message
- Files Changed - The diff showing every line added, modified, or removed
Navigate between tabs using your screen reader's heading navigation or landmark navigation.
A: Depends on the project:
- Your organization's repo: Hours to a few days
- Active open-source projects: Days to a week
- Smaller projects: Could be weeks
- Check the project's
CONTRIBUTING.mdfor estimated review times
A: Combining two branches of code. After your PR is approved, it is "merged" into the main branch. Your changes become part of the official codebase.
A:
- Merge commit: Creates a merge commit that ties the two branches together. Preserves full history.
- Squash and merge: Combines all your PR's commits into one commit on main. Cleaner history.
- Rebase and merge: Replays your commits on top of main. Linear history, no merge commits.
- Which to use: Follow the project's convention. When in doubt, "Squash and merge" is usually safe.
A: See Chapter 6 (Merge Conflicts). In short:
- Pull the latest main:
git pull upstream main - Merge main into your branch:
git merge main - Resolve the conflicts in your editor
- Commit and push the resolution
A: Just push more commits to the same branch. The PR updates automatically. No need to close and reopen.
A: On the PR page, find the "Reviewers" section in the sidebar. Click the gear icon and select reviewers. They will be notified.
A: A draft PR signals that your work is not ready for review yet. Reviewers can still look at it, but it cannot be merged. When ready, click "Ready for review" to convert it. Use drafts for work-in-progress when you want early feedback.
A: Only if the PR author checked "Allow edits from maintainers" and you have write access to the target repository. Otherwise, you can suggest changes in a review comment using the suggestion feature.
A: A merge conflict happens when two people edit the same lines of the same file on different branches. Git cannot decide which version to keep, so it asks you to choose. It is not an error - it is a normal part of collaboration.
A: Git marks the conflicting sections with these markers:
<<<<<<< HEAD
Your changes
=======
Their changes
>>>>>>> branch-name
Your screen reader will read these markers as text. See Chapter 6 for how to interpret them.
A: Three approaches:
- Keep your changes: Delete their version and the markers
- Keep their changes: Delete your version and the markers
- Combine both: Edit the file to include the best of both, then delete the markers
After resolving: git add [filename] → git commit -m "Resolved merge conflict"
A: Yes. git merge --abort cancels the merge and returns your branch to its pre-merge state. Nothing is lost.
A:
- Pull from main frequently:
git pull upstream main - Keep PRs small and focused (one change per PR)
- Communicate with your team about which files you are editing
- Avoid editing the same lines as someone else
A:
- Fork = Your complete separate copy of a repository, on your GitHub account
- Branch = A version of the code within a single repository
- Use a fork to: Contribute to someone else's open-source project
- Use a branch to: Work on features in your own repository or your org's repository
A: You do not have write access to most open-source repositories. Forking creates your own copy where you can make changes freely. Then you open a PR from your fork to the original repository.
A:
- Add the original as "upstream":
git remote add upstream https://github.com/ORIGINAL-OWNER/REPO.git - Fetch upstream:
git fetch upstream - Merge into your main:
git checkout main→git merge upstream/main - Push to your fork:
git push origin main
A: Always create a new branch before starting work on a change. Never commit directly to main. Name your branch descriptively: fix/broken-link, feature/dark-mode, docs/update-readme.
A:
- On GitHub: After merging, GitHub shows a "Delete branch" button on the PR page
- Locally:
git branch -d branch-name(safe delete - only works if merged) orgit branch -D branch-name(force delete)
A: A lightweight text formatting language. You write plain text with symbols (# for headings, ** for bold, - for lists), and GitHub renders it as formatted HTML. Every issue, PR, comment, and documentation file on GitHub uses Markdown.
A:
| Syntax | Result |
|---|---|
# Heading 1 |
Large heading |
## Heading 2 |
Medium heading |
**bold** |
bold |
*italic* |
italic |
[text](url) |
A hyperlink |
`code` |
Inline code |
- item |
Bullet list |
1. item |
Numbered list |
> quote |
Blockquote |
- [ ] task |
Checkbox (task list) |
Full reference: Appendix E (GitHub Flavored Markdown)
A: Wrap code in triple backticks. Add a language name for syntax highlighting:
```python
print("Hello, world!")
```
A:
| Column 1 | Column 2 |
|----------|----------|
| Cell 1 | Cell 2 |
| Cell 3 | Cell 4 |
The | characters create columns. The --- row separates the header from the body.
A: GitHub's extended version of Markdown that adds features like task lists (- [ ]), tables, strikethrough (~~text~~), autolinked URLs, emoji (:smile:), alert blocks, Mermaid diagrams, and math expressions. See Appendix E.
A: On GitHub, click the "Preview" tab above any text input area. In VS Code, press Ctrl+Shift+V to open Markdown preview in a new tab, or Ctrl+K V for a side-by-side preview.
A: Labels categorize issues and PRs. Common labels: bug, enhancement, documentation, good first issue, accessibility, help wanted. They help maintainers prioritize and contributors find work. See Chapter 8.
A: On the Issues tab, click "Labels" (or use the filter bar and type label:bug). You can combine labels: label:bug label:accessibility finds issues with both labels.
A: A grouping of issues and PRs that represent a goal or deadline (e.g., "v2.0 Release" or "Hackathon Day 1"). Milestones show a progress bar indicating how many items are complete.
A: A flexible planning tool with boards (Kanban-style columns), tables, and roadmaps. You can add issues and PRs from multiple repositories. See Appendix I (GitHub Projects Deep Dive).
A:
- Go to https://github.com/notifications
- Use filters: Unread, Participating, @mentioned, Assigned
- Mark threads as "Done" (
Ekeyboard shortcut) to clear them - Set watch preferences per repository: "Participating and @mentions" is usually best
- Configure email preferences at https://github.com/settings/notifications
See Chapter 9 (Notifications).
A:
- Watching: You receive notifications for all activity on the repository
- Participating: You are notified about issues/PRs you have commented on or been assigned to
- @mentioned: Someone tagged you specifically with
@your-username
A: Go to https://github.com/settings/notifications → uncheck "Email" under the notification types you want to silence.
A: On the notifications page:
Hto jump between notification groups (by repository)Kto move between individual notificationsEto mark as Done from the listShift+Ito mark as ReadEnterto open the linked issue or PR
A: VS Code has the best built-in accessibility support of any mainstream code editor: dedicated screen reader mode, Accessible Help dialog, Accessible View, Accessible Diff Viewer, and audio cues for editor events. It also has first-party GitHub and Copilot integration.
A: VS Code running in your browser - no installation needed. Press . on any GitHub repository to open it in github.dev. The keyboard shortcuts and screen reader mode are identical to desktop VS Code. github.dev cannot run a terminal, Copilot agents, or local extensions - that is what desktop VS Code adds.
A: VS Code detects NVDA and JAWS automatically. If it does not, press Shift+Alt+F1 to manually enable screen reader mode. Verify: Ctrl+Shift+P → type "accessibility" → look for "Toggle Screen Reader Accessibility Mode" with a checkmark.
A:
| Shortcut | Action |
|---|---|
Ctrl+Shift+P |
Command Palette - search for any command |
Ctrl+P |
Quick Open - search for any file |
Ctrl+Shift+E |
Explorer sidebar (file tree) |
Ctrl+Shift+G |
Source Control panel |
Ctrl+Shift+I |
Open Copilot Chat |
Ctrl+ (backtick) |
Toggle terminal |
Ctrl+, |
Open Settings |
F7 |
Accessible Diff Viewer |
Alt+F2 |
Accessible View |
Shift+Alt+F1 |
Toggle screen reader mode |
Full reference: Appendix M (VS Code Accessibility Reference)
A: See TROUBLESHOOTING.md → "VS Code extensions not loading." Quick fix: Ctrl+Shift+P → "Developer: Reload Window." If that does not work, check the Output panel (View → Output → select the extension name from the dropdown) for error messages.
A: The sidebar has five main views, each with a keyboard shortcut:
Ctrl+Shift+E- Explorer (files)Ctrl+Shift+F- SearchCtrl+Shift+G- Source ControlCtrl+Shift+D- DebugCtrl+Shift+X- Extensions
Within each view, use Tab, Arrow keys, and Enter to navigate.
A: Press Alt+F2 to open the Accessible View. It renders any VS Code content (Copilot Chat responses, hover tooltips, notifications) as a plain text document that your screen reader can read naturally. Use it whenever VS Code's default rendering is hard to navigate.
A: VS Code can play short sounds for events like errors, warnings, breakpoints, and diff changes. Configure them at Settings → search accessibility.signals. Each signal can be set to "on," "off," or "auto" (only when a screen reader is detected). See Appendix M.
A: Ctrl+Shift+P → type "Git: Clone" → paste the repository URL → choose a local folder → VS Code opens the cloned repo.
A:
- Make your changes in the editor
- Open Source Control:
Ctrl+Shift+G - Review changed files (they appear in "Changes")
- Stage files: select a file and press
+(or right-click → "Stage Changes") - Type your commit message in the text box
- Press
Ctrl+Enterto commit
A: After committing, click "Sync Changes" in the Source Control panel (or run Ctrl+Shift+P → "Git: Push"). If your branch is not yet on GitHub, VS Code will ask to publish it.
A: Click the branch name in the bottom-left status bar (or Ctrl+Shift+P → "Git: Create Branch"). Type the new branch name and press Enter. VS Code switches to the new branch automatically.
A: The Source Control panel (Ctrl+Shift+G) shows:
- Changes - Files you have modified but not staged
- Staged Changes - Files ready to be committed
- Merge Changes - Files with merge conflicts (if any)
- The commit message input box
- Buttons for Commit, Sync, and more
A: In the Source Control panel, click any changed file. VS Code opens a side-by-side diff view. For accessible navigation, press F7 to open the Accessible Diff Viewer, which reads changes sequentially.
A: An AI-powered coding assistant that runs inside VS Code. It offers two main features:
- Inline suggestions - Copilot predicts what you will type next and offers completions. Press
Tabto accept. - Copilot Chat - A conversational interface (
Ctrl+Shift+I) where you can ask questions, get explanations, and generate content.
See Chapter 13 (GitHub Copilot).
A: GitHub Copilot now offers a free tier with limited usage. For full access including chat and agents, you need:
- Copilot Individual: ~$10/month or $100/year
- Copilot Business/Enterprise: Through your organization
- Students/Educators: Free access at https://education.github.com/
A: Press Ctrl+Shift+I. The Chat panel opens as a sidebar. Type your question and press Enter. Use Alt+F2 (Accessible View) to read Copilot's response with your screen reader.
A: Press Alt+F2 to open the Accessible View. This renders Copilot's response as plain text that your screen reader can read sequentially. This is the recommended workflow for screen reader users.
A: Copilot can generate significant amounts of code or documentation, but you should always review and edit its output. Copilot is a writing partner, not a replacement for your judgment. Its output may contain errors, outdated information, or tone mismatches.
A: Prefixes like @workspace, @vscode, @terminal that tell Copilot to focus on a specific context:
@workspace- Ask about your entire project@vscode- Ask about VS Code settings and commands@terminal- Ask about terminal commands- Agent names like
@daily-briefing- Use a specific Accessibility Agents agent
A: Commands starting with / that trigger specific behaviors:
/explain- Explain the selected code/fix- Suggest a fix for the selected code/tests- Generate tests/doc- Generate documentation- Custom commands from Accessibility Agents (28 available)
Full reference: Appendix W (GitHub Copilot Reference)
A: See TROUBLESHOOTING.md → "Copilot Chat freezes or stops responding." Quick fix: Close the chat panel, reopen with Ctrl+Shift+I. Check your internet connection and Copilot subscription status.
A: Yes. In Copilot Chat, click the model selector (announced by your screen reader near the input field) to choose from available models. Different models have different strengths. See Appendix X (Copilot AI Models).
A: An ecosystem of 55 AI-powered agents organized into three teams (Accessibility, GitHub Workflow, Developer Tools), running on five platforms. It includes 54+ slash commands and is an MIT-licensed open-source project at community-access/accessibility-agents that you will fork, use, and contribute to during the workshop. See Chapter 16 (Accessibility Agents).
A: The ecosystem spans three teams:
| Team | Agents | Focus |
|---|---|---|
| Accessibility | 26 | Web, document, mobile, ePub auditing and remediation |
| GitHub Workflow | 12 | Issue triage, PR review, analytics, templates, repo management |
| Developer Tools | 6 | Python, desktop, wxPython accessibility patterns |
See Appendix V for the complete list of all 55 agents.
A: No separate installation. Agents are defined as .agent.md files in your repository's .github/agents/ folder. When you fork accessibility-agents, the agents come with it. You need GitHub Copilot (paid subscription) for agents to function.
A: The agents automate skills you learn in the workshop. Using them without understanding what they do is like using a calculator without understanding math - you cannot tell when it is wrong. That is why Day 1 comes first.
A: Copy .github/agents/preferences.example.md to .github/agents/preferences.md and edit it with your GitHub username, preferred repositories, and output format preferences.
A: Yes. Create a new .agent.md file in .github/agents/ following the existing file format. The file is plain Markdown with YAML frontmatter. See Appendix V (Accessibility Agents Reference).
A: Templates guide people to provide the right information when filing issues. Well-structured templates save time for maintainers and help screen reader users navigate the form. See Chapter 15 (Issue Templates).
A: Check:
- The file is in
.github/ISSUE_TEMPLATE/your-template.yml(not.md, not in the wrong folder) - The YAML syntax is valid (check at https://www.yamllint.com/)
- The file is committed to the
mainbranch - Try a hard browser refresh:
Ctrl+Shift+R
See TROUBLESHOOTING.md → "Template not showing in GitHub" for full diagnostics.
A: YAML is a simple format for writing structured data - easier to read than JSON or XML. GitHub uses it for issue form templates because it is human-readable and supports validation. You do not need to be an expert - Chapter 15 teaches you everything you need.
A: Yes. The @template-builder agent in Copilot Chat walks you through creating templates interactively. It asks questions and generates the YAML for you. See Chapter 16 (Accessibility Agents).
A: Accessible code review means:
- Using keyboard shortcuts instead of mouse
- Testing that diffs are screen reader navigable
- Writing descriptive review comments (not just "LGTM")
- Using the Accessible Diff Viewer (
F7) in VS Code - See Chapter 14 (Accessible Code Review)
A: Two approaches:
- On GitHub: Navigate to the Files Changed tab. Use arrow keys to move through lines. Added lines start with
+, removed lines start with-. - In VS Code: Open the changed file in the Source Control panel, then press
F7to open the Accessible Diff Viewer. It reads changes sequentially and announces whether each change is an addition, deletion, or modification.
A: A useful comment includes:
- What you noticed
- Why it matters
- A suggestion (optional but helpful)
Example: "The alt attribute on this image is empty. Screen readers will skip it entirely, which means blind users miss the chart. A description like 'Bar chart showing monthly downloads' would help."
A: "Looks Good To Me" - a common shorthand for approval. However, a more descriptive comment explaining what you checked is more helpful, especially for the PR author's learning.
A:
- Comment: General feedback, no explicit approval or rejection
- Approve: You are satisfied the changes are ready to merge
- Request Changes: You have identified issues that must be fixed before merging
A: A shared practice repository (learning-room/) where participants make their first real contributions during the workshop. It contains intentionally incomplete documents and accessibility issues for you to find and fix. See Chapter 3 (The Learning Room).
A: Two types:
- 12 individual challenges - Progressive tasks you complete on your own (find broken links, fix headings, add alt text, etc.)
- 7 group challenges - Collaborative exercises requiring coordination with other participants
Details in learning-room/docs/CHALLENGES.md and learning-room/docs/GROUP_CHALLENGES.md.
A: When you open a PR in the Learning Room, an automated bot reviews your changes within about 30 seconds. It checks for broken links, heading hierarchy, image descriptions, link text quality, and formatting. Every issue includes an explanation of why it matters and how to fix it.
A: Yes. Fork the repository, and the individual challenges work in your fork. Group challenges are designed for a live session but you can still practice the technical steps solo.
A: This is completely normal. Each chapter is self-contained - you can continue at your own pace. The facilitator will provide catch-up guidance during breaks. The GitHub Skills modules (Day 1) are yours permanently - Mona is always waiting for you.
A: Yes. Screen reader listening is cognitively demanding work. The schedule includes regular breaks. Take additional breaks whenever you need them.
A: Day 1 is self-contained - you can use GitHub confidently after completing it alone. Day 2 builds on Day 1 and requires its skills. You cannot meaningfully attend Day 2 without Day 1.
A: Yes. The chapters are designed to be read sequentially, but nothing stops you from reading ahead. Just be aware that some Day 2 exercises depend on having completed Day 1 activities.
A: Yes. All materials are in the repository and can be read at any time. The GitHub Skills modules are available indefinitely. The only thing you miss is live interaction and facilitated group exercises.
A: Contact the facilitator. This workshop is designed for flexibility - if you need a specific accommodation (higher contrast, different font size, alternative input method, longer break time), ask.
A: Yes. See CONTRIBUTING.md for how to submit improvements, suggest new topics, or fix issues.
A: Yes. The curriculum is licensed under CC BY 4.0 - you are free to share and adapt with attribution required.
A: Yes. Fork this repository and customize it for your needs. Attribution to the original is required under CC BY 4.0.
A:
git remote add upstream https://github.com/community-access/learning-room.git
git fetch upstream
git checkout main
git merge upstream/main
git push origin mainThen rebuild the HTML: npm run build:html
A:
- Contribute to open-source accessibility projects - see Appendix T (Contributing to Open Source)
- Explore GitHub Skills for more guided modules
- Browse the GitHub Accessibility Discussions
- Read our Resources appendix for comprehensive links
A: See Appendix Y (Accessing Workshop Materials) for complete instructions - clone via Git, download as ZIP, or read individual files on GitHub.com.
A:
- Fork = Your complete separate copy of a repository (on GitHub)
- Branch = A version of the code within a repository
- Use fork to: Contribute to someone else's open-source project
- Use branch to: Work on features in your own repository
See Chapter 1 for detailed explanation.
A:
- Git = A version control system that runs on your computer. It tracks changes to files over time.
- GitHub = A website and service that hosts Git repositories online and adds collaboration features (issues, PRs, Actions, etc.)
- Git works without GitHub. GitHub requires Git.
A: A project folder tracked by Git. It contains your files plus the entire history of changes. On GitHub, a repository also includes issues, PRs, settings, and community features.
A: A snapshot of your changes at a point in time. Each commit has a message describing what changed and why. Think of it as a save point with a note.
A: The default branch of a repository - the official, current version of the project. New branches are created from main, and finished work is merged back into main. Older repositories may use master instead.
A: A comparison showing what changed between two versions of a file. Added lines are marked with + (green), removed lines with - (red), and unchanged lines provide context. Screen readers announce additions and deletions.
A: Continuous Integration / Continuous Deployment - automated systems that run tests, build code, and deploy software when you push changes. On GitHub, this is done through GitHub Actions. See Appendix Q (GitHub Actions).
A: Web Content Accessibility Guidelines - the international standard for web accessibility. WCAG 2.2 defines criteria in three levels: A (minimum), AA (recommended), and AAA (highest). See Appendix C (Accessibility Standards Reference).
A: Accessible Rich Internet Applications - A set of HTML attributes that add accessibility information to web elements. For example, aria-label provides a text description for screen readers, and role identifies the purpose of an element (button, navigation, main content, etc.).
This FAQ does not cover your question? Try these resources in order:
- QUICK_REFERENCE.md - Commands, keyboard shortcuts, file locations
- TROUBLESHOOTING.md - Common problems and step-by-step solutions
- Appendix A (Glossary) - Term definitions
- Appendix B (Screen Reader Cheat Sheet) - NVDA, JAWS, VoiceOver keyboard commands
- Appendix U (Resources) - External documentation and links
- GitHub Issues - Search existing issues or open a new one
- FACILITATOR.md - If you are leading a workshop
Last updated: February 2026
Have more questions? Open an issue or discussion on GitHub!