Appendix U: Resources

Listen to Episode 38: Resources and Links - 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, During, and After the Workshop

This is your permanent reference. Every link, tool, guide, and community resource from the two-day workshop in one place. Bookmark this page in your fork so it travels with you.

Table of Contents

1. The Central Project - Accessibility Agents
2. GitHub Accessibility Guides
3. GitHub Skills Learning Modules
4. Screen Reader Downloads and Documentation
5. VS Code Resources
6. GitHub Copilot Resources
7. GitHub Agentic Workflows
8. Spec-Driven Development - Spec Kit
9. GitHub CLI, Desktop, and Copilot CLI
10. GitHub Mobile Apps
11. GitHub Best Practices and Power Features
12. Finding More Contributions
13. Accessibility Standards and References
14. GitHub Keyboard Shortcuts
15. Community and Support
16. Your Workshop Documentation - Offline Reference

1. The Central Project - Accessibility Agents

The project you forked, contributed to, and carry home.

Your Personal Fork

After the workshop, your fork lives at:

https://github.com/[your-username]/accessibility-agents

Quick access from VS Code

1. Clone your fork: git clone https://github.com/[your-username]/accessibility-agents.git
2. Open in VS Code: cd accessibility-agents && code .
3. Open Copilot Chat: Ctrl+Shift+I
4. Type: @daily-briefing morning briefing

Personalizing Your Fork

1. Copy preferences.example.md to preferences.md in .github/agents/
2. Add your GitHub username, your most-used repositories, and your preferred output format
3. Commit the file - now the agents know who you are and what you work on

2. GitHub Accessibility Guides

Official guides from the GitHub Accessibility team. These were the primary research sources for this workshop's documentation.

3. GitHub Skills Learning Modules

GitHub Skills is GitHub's free, self-paced interactive learning platform. Every course runs entirely inside GitHub - no external site, no separate login, no video to watch. Each course uses the template-copy pattern: you copy the course repository to your account, and Mona (GitHub's official education bot) activates and teaches you entirely through issues and pull requests.

How GitHub Skills Works

Unlike a conventional course where you watch videos or read slides, GitHub Skills teaches through doing:

1. Copy the course: Select "Start course" → "Use this template" → "Create a new repository." This copies the course scaffold to your own account.
2. Mona activates: A GitHub Actions workflow automatically runs - within 20 seconds, Mona opens your first lesson as an Issue in your new repository.
3. Read and act: The issue contains step-by-step instructions. You do the task (commit a file, open a PR, resolve a conflict) in the same repository.
4. Mona validates: Another GitHub Actions workflow detects what you did, checks if it's correct, and either advances you to the next step or gives you feedback to try again.
5. Repeat until done: All feedback arrives as issue comments and new issues. The course is complete when Mona closes the final issue with a success message.

Screen Reader Navigation of a GitHub Skills Course

Since everything happens in GitHub, the accessibility skills from this workshop apply directly:

Starting a course:
  Navigate to the module URL
  B → "Start course" button → Enter
  B → "Use this template" → Enter
  B → "Create a new repository" → Enter
  Fill in repo name → Tab → "Create repository" → Enter

Following lessons:
  Navigate to your new repo's Issues tab (G then I)
  H or 3 → find "Step 1:" issue heading → Enter to open it
  Read instructions with ↓ in Browse Mode
  Complete the task described → commit / PR / edit as instructed
  Wait ~20 seconds → Mona posts a follow-up comment or opens the next issue
  9 (NVDA/JAWS) → navigate to comments to read Mona's feedback

After This Workshop - Your Learning Path

GitHub Skills courses are available 24/7 and are completely free. Recommended order after this workshop:

Relationship to this workshop: The introduction and PR courses reinforce everything you practiced here. The GitHub Actions course is the foundation for understanding the CI/CD workflows that run inside accessibility-agents.

4. Screen Reader Downloads and Documentation

NVDA (Windows)

Key commands (quick reference)

• Toggle browse/focus mode: NVDA+Space
• Elements list: NVDA+F7
• Next heading: H | Next link: K | Next button: B | Next form field: F

JAWS (Windows)

Key commands (quick reference)

• Virtual PC Cursor on/off: Insert+Z
• Elements list: Insert+F3
• Next heading: H | Next link: Tab or U | Next button: B

VoiceOver (macOS / iOS - built in)

Key commands (quick reference)

• Start/stop VoiceOver: Cmd+F5
• VO modifier: Caps Lock or Ctrl+Option
• Rotor: VO+U
• Next heading: VO+Cmd+H

Other Screen Readers (Reference)

5. VS Code Resources

Install the GitHub PR extension quickly

1. Open VS Code Extensions (Ctrl+Shift+X)
2. Search: GitHub Pull Requests
3. Install: publisher is "GitHub"

6. GitHub Copilot Resources

7. GitHub Agentic Workflows

GitHub Agentic Workflows are in technical preview as of February 2026. Access, feedback channels, and setup information:

How Agentic Workflows connect to what you learned

During the workshop, you learned:

1. Standard GitHub Actions (YAML workflows - triggers, jobs, steps)
2. Accessibility Agents agents (.agent.md files - plain English instructions, Copilot Chat executor)
3. GitHub Agentic Workflows (.md files in .github/workflows/ - plain English instructions, cloud-based coding agent executor)

All three live in .github/. All three are plain text. The only difference is where they run and how sophisticated their executor is.

8. Spec-Driven Development - Spec Kit

The core idea: Write the intent of a feature before anyone builds it. The specification is a living document - AI uses it to plan tasks, contributors use it to stay aligned, the community uses it to evaluate whether the outcome matched the intention.

Quick start

uvx --from git+https://github.com/github/spec-kit.git specify init YOUR_PROJECT_NAME

Slash commands

• /specify - open a new specification session
• /plan - convert a spec into a development plan
• /tasks - break the plan into trackable tasks

Works with GitHub Copilot, Claude Code, and Gemini CLI.

9. GitHub CLI, Desktop, and Copilot CLI

GitHub CLI (gh)

# Install
winget install GitHub.cli     # Windows
brew install gh               # macOS

# Most useful commands for contributors
gh issue list                 # List issues in current repo
gh issue view 42              # Read issue #42
gh pr list                    # List open PRs
gh pr view 14                 # Read PR #14
gh pr create                  # Create a PR interactively
gh pr merge 14                # Merge PR #14
gh repo fork                  # Fork the current repo
gh repo clone owner/repo      # Clone a repository

Copilot in the CLI (gh copilot)

# Install the extension
gh extension install github/gh-copilot

# Ask Copilot to explain a command
gh copilot explain "git rebase -i HEAD~3"

# Ask Copilot to suggest a command
gh copilot suggest "undo my last commit but keep the changes staged"

GitHub Desktop

10. GitHub Mobile Apps

GitHub's official mobile apps bring the full GitHub experience to your phone or tablet. Perfect for reviewing PRs, triaging issues, and staying connected when away from your computer.

What You Can Do in GitHub Mobile

• Browse repositories - navigate code, read files, view commits
• Manage issues - create, edit, comment, close, and label issues
• Review pull requests - read diffs, leave comments, request changes, approve, merge
• Manage notifications - triage your inbox on the go
• Interact with GitHub Copilot - chat with Copilot Chat on mobile (as of Feb 2026)
• View GitHub Actions - monitor workflows and check build status
• Manage Discussions - participate in community conversations

Accessibility Features

Both apps support:

• Native screen reader gestures (VoiceOver on iOS, TalkBack on Android)
• Dynamic text sizing
• Dark mode / high contrast
• Keyboard navigation (when using external keyboard with tablet)

Pro tip: Enable push notifications for mentions and reviews so you can respond quickly when your input is needed.

11. GitHub Best Practices and Power Features

Essential tips and lesser-known features that make you a more effective contributor.

Saved Replies

Saved replies let you create reusable text templates for common responses. Perfect for:

• Thanking first-time contributors
• Requesting more information with a friendly tone
• Explaining common setup issues
• Closing duplicate issues

How to set up

1. Go to github.com/settings/replies
2. Click "Add a saved reply"
3. Give it a short label (e.g., "welcome-first-time")
4. Write your template text (can include Markdown)
5. Save

How to use

• When writing any comment, press Ctrl+. (period) to open the saved replies menu
• Select your saved reply
• Edit as needed before posting

Pinned Issues

Pin important issues to the top of your repository's Issues tab. Perfect for:

• FAQs and getting started guides
• Known issues and workarounds
• Roadmap and project status updates
• Community guidelines

How to pin an issue

1. Open the issue you want to pin
2. In the right sidebar, click the three-dot menu (⋯)
3. Select "Pin issue"
4. It now appears at the top of the Issues list

You can pin up to 3 issues per repository. Pinned issues are visible to everyone, even those who haven't starred or watched your repo.

Pinned Comments (New: Feb 2026)

You can now pin a single comment within an issue thread to keep important information visible. Perfect for:

• Workarounds or temporary solutions
• Decisions made during discussion
• Links to related issues or PRs
• Status updates from maintainers

How to pin a comment

1. Find the comment you want to pin
2. Click the three-dot menu (⋯) on the comment
3. Select "Pin comment"

Only repository collaborators can pin comments. There can be only one pinned comment per issue.

Linking to Specific Lines of Code

Share precise references to code by including line numbers in GitHub URLs.

Syntax

• Single line: github.com/owner/repo/blob/main/file.js#L42
• Line range: github.com/owner/repo/blob/main/file.js#L42-L58

How to create these links

1. Navigate to a file on GitHub
2. Click the line number (in screen readers: navigate to the line and activate the number link)
3. Hold Shift and click another line number to select a range
4. Copy the URL from your browser - the line numbers are automatically included

Screen reader tip: Line numbers are links announced as "Line 42 link" (or similar). They're in the left margin of the code view.

Permalinks - Stable Links That Never Break

When you link to code on GitHub using a branch name (main, develop), that link can break if the code changes or the file moves. Permalinks use the commit SHA instead of the branch name, creating a permanent snapshot link.

Why this matters: When you file a bug report or reference code in a discussion, you want the link to show exactly what you were looking at - not what the code looks like weeks later after someone refactored it.

How to create a permalink

1. View any file on GitHub
2. Press Y while viewing the file - the URL changes from /blob/main/file.js to /blob/a1b2c3d4.../file.js
3. Copy the new URL - it now points to that specific commit

Shortcut: Y = "Yank permalink" (borrows from Vim terminology)

Converting Issues to Discussions

Not every issue is a bug or feature request. Some are questions, proposals, or open-ended conversations. GitHub Discussions provide a better home for these.

When to convert

• Questions that don't require a code change ("How do I configure X?")
• Proposals that need community feedback before becoming actionable
• General discussion about the project's direction
• Show-and-tell or community showcases

How to convert an issue to a discussion

1. Open the issue
2. In the right sidebar, click "Convert to discussion"
3. Select which discussion category it belongs in
4. Confirm

All comments and history are preserved. The issue is closed and replaced with a link to the new discussion.

Team Mentions - Notify a Whole Group

In organizations, you can mention entire teams instead of individuals: @org-name/team-name

Example: @github/accessibility notifies everyone on GitHub's accessibility team.

Why this matters

• You don't need to know who's on a team - just mention the team
• Teams can subscribe to notifications as a group
• CODEOWNERS files use team mentions for automatic reviewer assignment

Permission: You can only mention teams you have visibility to. Public teams in public orgs can be mentioned by anyone.

Collapsible Sections in Markdown

Keep long issue descriptions or PR descriptions scannable by hiding details in collapsible sections.

Syntax

<details>
<summary>Click to expand: Full error stack trace</summary>

(Your detailed content here - code blocks, lists, anything)

</details>

Use for

• Long error messages or logs
• Optional context that most readers don't need
• Large screenshots or code samples
• Step-by-step troubleshooting instructions

Accessibility note: Collapsible sections are announced as "disclosure triangles" or "expandable" regions by most screen readers. The summary text is always visible.

Co-Authored Commits

Credit multiple people for a single commit using the Co-authored-by trailer in your commit message.

Syntax

Fix keyboard navigation in modal dialog

This addresses the issue where focus was lost when the modal closed.

Co-authored-by: Alex Chen <alex@example.com>
Co-authored-by: Jordan Smith <jordan@example.com>

Why this matters

• Pair programming - both people get credit in the Git history
• Crediting someone who provided the solution but didn't write the code
• GitHub recognizes these trailers and shows all co-authors on the commit

Screen reader tip: When viewing a commit with co-authors on GitHub, screen readers announce "Co-authored-by" in the commit details.

Understanding Watch, Star, and Fork

Three ways to interact with a repository - each means something different:

Watch settings

• All activity - every issue, PR, and discussion
• Participating (default) - only threads you comment on or are @mentioned in
• Releases only - just new releases
• Ignore - unsubscribe completely

Pro tip: Star repos for discovery; Watch repos you actively contribute to.

CODEOWNERS - Automatic Reviewer Assignment

The CODEOWNERS file automatically requests reviews from specific people or teams when files in their area are changed.

Location: .github/CODEOWNERS in your repository

Syntax

# Documentation team reviews all docs changes
/docs/ @org-name/docs-team

# Accessibility specialist reviews UI changes
/src/components/ @username

# Security team reviews authentication code
/src/auth/ @org-name/security-team

# Default owner for everything else
* @project-lead

How it works

1. Someone opens a PR that changes files in /docs/
2. GitHub automatically requests a review from @org-name/docs-team
3. The PR can't be merged until the required review is approved (if branch protection requires it)

Use for

• Ensuring domain experts review specialized code
• Distributing review responsibilities
• Preventing changes from being merged without appropriate oversight

GitHub Sponsors

Support open source maintainers financially through GitHub Sponsors. If a project you use has a "Sponsor" button, consider supporting them.

How it works

• Maintainers set up a Sponsors profile
• You can sponsor with a monthly recurring amount or one-time payment
• GitHub doesn't take a fee (as of 2026)

Why sponsor

• Open source maintainers often work for free in their spare time
• Your sponsorship helps them dedicate more time to the project
• Many maintainers offer perks to sponsors (early access, prioritized issues, etc.)

How to sponsor

1. Visit a repository with a "Sponsor" button
2. Click the button
3. Choose a sponsorship tier
4. Complete payment through GitHub Sponsors

Advanced Markdown Features

GitHub supports several powerful Markdown features beyond the basics:

Task Lists

- [x] Completed task
- [ ] Pending task
- [ ] Another pending task

Tables with alignment

| Left-aligned | Center-aligned | Right-aligned |
|:-------------|:--------------:|--------------:|
| Text         | Text           | Text          |

Mermaid Diagrams

```mermaid
graph TD
    A[User opens issue] --> B{Is it a bug?}
    B -->|Yes| C[Label: bug]
    B -->|No| D[Label: enhancement]
```text

Math Expressions (LaTeX)

Inline math: $E = mc^2$

Block math:
$$
\sum_{i=1}^{n} i = \frac{n(n+1)}{2}
$$

Footnotes

Here is a statement that needs citation[^1].

[^1]: Source: Documentation link

Alerts (Callout blocks)

> [!NOTE]
> Useful information that users should know

> [!WARNING]
> Critical content requiring immediate attention

> [!TIP]
> Helpful advice for better outcomes

12. Finding More Contributions

After the workshop, use these resources to find your next open source contribution.

GitHub search queries to bookmark

is:open is:issue label:good-first-issue topic:accessibility
is:open is:issue label:help-wanted topic:screen-reader
is:open is:issue label:accessibility no:assignee

13. Accessibility Standards and References

Accessibility Testing Tools

Interactive Git Learning

14. GitHub Keyboard Shortcuts

The most important shortcuts to memorize

14b. Learning Pathways

Not sure where to start after the workshop? Use these suggested paths.

By Role

By Time Available

15. Community and Support

GitHub Accessibility

Accessibility Agents Community

Open Source Accessibility Community

16. Your Workshop Documentation - Offline Reference

Every guide from this workshop lives in your fork. Clone your fork once and the complete documentation works offline - no internet required.

git clone https://github.com/[your-username]/accessibility-agents.git

The documentation set is in the docs/ folder of this learning repository (separate from the accessibility-agents fork). If your workshop facilitator shared a repository link for the learning materials, clone that too.

Quick Navigation

Back: Issue Templates Start over: README ← Reference: Screen Reader Cheat Sheet