Alex: Welcome back. This one connects your capstone work to something much bigger than a workshop assignment.

Jamie: I like that framing, because by the end of a capstone, it can feel like, okay, I made the thing, I submitted the thing, and now what?

Alex: Exactly. The important part is that you practiced habits that real accessibility work depends on. You identified a user need, described a barrier or opportunity, proposed a focused change, tested or explained what happened, and invited review.

Jamie: So the capstone is not just proof that someone followed instructions. It is proof that they can make an accessibility contribution that another person can understand and evaluate.

---

Alex: GitHub describes its mission as accelerating human progress through developer collaboration. That is a big statement, but accessibility makes it practical: who gets to collaborate, who gets to build, and who gets to benefit.

Jamie: And the scale is huge. GitHub's accessibility program talks about enabling about 1.3 billion people with disabilities to benefit from and contribute to that progress.

Alex: Right. Accessibility is not a side quest or a nice extra. It is part of belonging in open source, because open source depends on people being able to show up, learn the tools, report problems, propose changes, and take part in decisions.

Jamie: That lands. If the tools, docs, events, or contribution paths exclude people, then the project is not really open to everyone.

---

Alex: GitHub describes four strategic accessibility priorities, and the first one starts inside the company. Supporting employees with disabilities means improving the everyday systems people use to do their jobs.

Jamie: So accessibility starts with the people building and maintaining the platform, not only with external users.

Alex: Yes. That includes required accessibility training for GitHub teams, improvements to internal tools and systems, and support for employee communities such as NeuroCats and AccessCats.

Jamie: And it includes accommodations and career growth too, right? Because access is not only about whether a button has a label. It is also about whether disabled employees can do meaningful work and advance.

---

Alex: The second priority is developers with disabilities. GitHub says every developer should feel welcome and be able to use GitHub products, documentation, training, support, events, and community spaces.

Jamie: That is broader than the website interface. It includes the whole experience around becoming a developer and staying active as one.

Alex: Exactly. Accessibility is listed as a GitHub Fundamental, which means product teams have clear expectations, testing requirements, and processes. There is also accountability through GitHub Fundamentals scorecards, along with regular audits and compliance tracking.

Jamie: I appreciate that word, accountability. Good intentions matter, but people also need checks, standards, and follow-up.

---

Alex: The third priority is customers building on GitHub. This is about sharing tools and practices so organizations can improve accessibility in their own work.

Jamie: What kinds of tools are we talking about?

Alex: One example is a Figma annotation toolkit for accessible design collaboration. GitHub also points to patterns for accessible README files, contributing guides, and issue templates, which lines up with a lot of what learners practiced earlier.

Jamie: And there is a scanner too, right?

Alex: Yes. The GitHub Accessibility Scanner is an action you can add to your repository's continuous integration checks. Continuous integration, or CI, is the automated process that runs checks when code changes, so accessibility issues can be caught earlier instead of waiting for a manual review at the end.

Jamie: There is also the Copilot angle: writing accessibility-focused custom instructions so AI assistance nudges people toward better audits, clearer findings, and more useful fixes.

---

Alex: The fourth priority is open source at scale. GitHub has pledged to help improve accessibility across open source, not just inside one product or one team.

Jamie: That sounds ambitious, but also necessary. Open source is where so many tools, libraries, templates, and learning paths begin.

Alex: The pledge includes empowering people with disabilities to contribute to open source projects, increasing free and open source assistive technologies, improving the accessibility of mainstream open source projects, and providing resources, tools, and guidance to maintainers.

Jamie: So the goal is not only better software for disabled people. It is also more disabled people shaping the software everyone uses.

---

Alex: This is where your capstone evidence habits connect directly. A strong accessibility contribution usually makes the need visible, explains the barrier, proposes a change that is small enough to review, and gives maintainers a way to respond.

Jamie: And in the current capstone, that contribution can happen in Accessibility Agents, GLOW, or another meaningful repository. Accessibility Agents is a living catalog, so it can grow over time, but it is not the only valid target.

Alex: Right. Review-ready drafts and contribution plans can also count as valid evidence when they are clear and actionable. That matters because real accessibility work often starts before a merge: with research, issue writing, test notes, design changes, or a plan a maintainer can trust.

Jamie: So a learner should not hear, if it did not merge, it did not matter. The evidence can still show professional judgment and real contribution value.

---

Alex: The bigger reason this matters is that these habits scale. If thousands of projects receive clearer accessibility issues, better test notes, more focused pull requests, and more respectful review conversations, open source starts to change.

Jamie: And it changes what people expect. Accessibility becomes part of normal engineering work instead of a special cleanup phase later.

Alex: It also changes who has a voice. Contributors with disabilities, and contributors with accessibility expertise, bring lived experience and technical insight into tool design, documentation, issue triage, and review.

Jamie: That is a powerful shift. The work is not separate from engineering. It is engineering, with more people included in the process.

---

Alex: After the workshop, the reference episodes go deeper into optional tools and advanced workflows. They are useful, but the most important pattern is already in your hands.

Jamie: Find a real need, communicate clearly, make a focused change, and leave enough evidence that someone else can review it.

Alex: When you need current facts, go back to official sources: GitHub's documentation, the changelog on the GitHub Blog, and the GitHub Accessibility site. Product details change, so checking the source keeps your contribution accurate.

Jamie: And that is especially important with accessibility tools, because a stale instruction can become a barrier for the next contributor.

Alex: Exactly. The real work continues in real repositories: finding issues, collaborating with maintainers, reviewing code, building tools, and making accessibility visible in everyday project decisions.

Jamie: Which is a good place to end. The capstone was not the finish line. It was practice for the kind of open source work that matters every day.