@@ -217,12 +217,12 @@ The accessibility owner keeps these current. Report a problem with any of them t
 
 ## Open Source Accessibility Framework
 
-We follow the [Open Source Accessibility Framework](https://open-source-accessibility.github.io/Open-Source-Accessibility-Framework/) in its four phases and record our progress, action by action, in our public tracking issue, [GIT Going with GitHub, issue 55](https://github.com/open-source-accessibility/Open-Source-Accessibility-Framework/issues/55), in the framework's repository. Progress is self-reported, and an action is checked there only when its definition of done is fully met: 20 of 24 as of 28 October 2026. The keyboard-only smoke test is checked: tasks 1 to 4 passed with real key presses in a browser, a run the accessibility owner accepted (see admin/ACCESSIBILITY_CORE_FLOWS.md). Docs accessible by default is checked: the documentation check's 264 findings were fixed in pull request 271, and the 3 left are deliberate bad examples in Appendix C. Accessible interfaces is checked: the site's fixes from issues 265 and 266 were confirmed on the live site in a browser, with a visible focus outline in light and dark mode (5.19:1 and 3.49:1) and a search box named by its visible label. One workflow action described below is in place but stays unchecked for now: dependencies (the two known blockers have no upstream report yet). As of October 2026:
+We follow the [Open Source Accessibility Framework](https://open-source-accessibility.github.io/Open-Source-Accessibility-Framework/) in its four phases and record our progress, action by action, in our public tracking issue, [GIT Going with GitHub, issue 55](https://github.com/open-source-accessibility/Open-Source-Accessibility-Framework/issues/55), in the framework's repository. Progress is self-reported, and an action is checked there only when its definition of done is fully met: 20 of 24 as of 28 October 2026. The keyboard-only smoke test is checked: tasks 1 to 4 passed with real key presses in a browser, a run the accessibility owner accepted (see admin/ACCESSIBILITY_CORE_FLOWS.md). Docs accessible by default is checked: the documentation check's 264 findings were fixed in pull request 271, and the 3 left are deliberate bad examples in Appendix C. Accessible interfaces is checked: the site's fixes from issues 265 and 266 were confirmed on the live site in a browser, with a visible focus outline in light and dark mode (5.19:1 and 3.49:1) and a search box named by its visible label. Responding constructively to reports is checked: [How we respond](#how-we-respond) sets out the guidance, and since 29 October 2026 the accessibility-reports workflow (`.github/workflows/accessibility-reports.yml`) acknowledges every report, reminds the owner after 5 business days without a reply, reopens a report closed without a documented outcome (a merged fix or an `Outcome:` line), and invites the reporter to confirm a fix; the accessibility owner decided that past reports are not reopened. One workflow action described below is in place but stays unchecked for now: dependencies (the two known blockers have no upstream report yet). As of October 2026:
 
 - **Foundational:** this document; the `accessibility` label, applied to accessibility reports and work.
 - **Workflow:** priorities, contributor expectations and interface requirements above, linked from [CONTRIBUTING.md](CONTRIBUTING.md); the accessibility bug report form with an email alternative; severity and response; the pull request checklist; `good first issue` and `help wanted` accessibility issues with acceptance criteria; an owner; documentation checked by the automated check; dependencies and upstream blockers recorded.
 - **Testing:** the documentation accessibility check in CI, with its findings tracked; documentation reviewed; supported environments and known limitations above. A keyboard-only run of the core tasks on the website passed and is recorded; screen reader and manual checks are written down but not yet run by a person.
-- **Community:** a feedback form after each cohort and labeled issues to invite help; documented responses to reports; asynchronous and live ways to take part, a private route for accommodations and a Code of Conduct; quarterly progress updates; reusable materials. Crediting accessibility contributors with their consent is the practice above, and has not yet happened.
+- **Community:** a feedback form after each cohort and labeled issues to invite help; documented responses to reports, enforced by the accessibility-reports workflow; asynchronous and live ways to take part, a private route for accommodations and a Code of Conduct; quarterly progress updates; reusable materials. Crediting accessibility contributors with their consent is the practice above, and has not yet happened.
 
 ## Feedback
 
 
@@ -420,12 +420,12 @@ <h2 id="reusing-our-accessibility-materials">Reusing our accessibility materials
 </ul>
 <p>The accessibility owner keeps these current. Report a problem with any of them the same way as any other barrier.</p>
 <h2 id="open-source-accessibility-framework">Open Source Accessibility Framework</h2>
-<p>We follow the <a href="https://open-source-accessibility.github.io/Open-Source-Accessibility-Framework/">Open Source Accessibility Framework</a> in its four phases and record our progress, action by action, in our public tracking issue, <a href="https://github.com/open-source-accessibility/Open-Source-Accessibility-Framework/issues/55">GIT Going with GitHub, issue 55</a>, in the framework&#39;s repository. Progress is self-reported, and an action is checked there only when its definition of done is fully met: 20 of 24 as of 28 October 2026. The keyboard-only smoke test is checked: tasks 1 to 4 passed with real key presses in a browser, a run the accessibility owner accepted (see admin/ACCESSIBILITY_CORE_FLOWS.md). Docs accessible by default is checked: the documentation check&#39;s 264 findings were fixed in pull request 271, and the 3 left are deliberate bad examples in Appendix C. Accessible interfaces is checked: the site&#39;s fixes from issues 265 and 266 were confirmed on the live site in a browser, with a visible focus outline in light and dark mode (5.19:1 and 3.49:1) and a search box named by its visible label. One workflow action described below is in place but stays unchecked for now: dependencies (the two known blockers have no upstream report yet). As of October 2026:</p>
+<p>We follow the <a href="https://open-source-accessibility.github.io/Open-Source-Accessibility-Framework/">Open Source Accessibility Framework</a> in its four phases and record our progress, action by action, in our public tracking issue, <a href="https://github.com/open-source-accessibility/Open-Source-Accessibility-Framework/issues/55">GIT Going with GitHub, issue 55</a>, in the framework&#39;s repository. Progress is self-reported, and an action is checked there only when its definition of done is fully met: 20 of 24 as of 28 October 2026. The keyboard-only smoke test is checked: tasks 1 to 4 passed with real key presses in a browser, a run the accessibility owner accepted (see admin/ACCESSIBILITY_CORE_FLOWS.md). Docs accessible by default is checked: the documentation check&#39;s 264 findings were fixed in pull request 271, and the 3 left are deliberate bad examples in Appendix C. Accessible interfaces is checked: the site&#39;s fixes from issues 265 and 266 were confirmed on the live site in a browser, with a visible focus outline in light and dark mode (5.19:1 and 3.49:1) and a search box named by its visible label. Responding constructively to reports is checked: <a href="#how-we-respond">How we respond</a> sets out the guidance, and since 29 October 2026 the accessibility-reports workflow (<code>.github/workflows/accessibility-reports.yml</code>) acknowledges every report, reminds the owner after 5 business days without a reply, reopens a report closed without a documented outcome (a merged fix or an <code>Outcome:</code> line), and invites the reporter to confirm a fix; the accessibility owner decided that past reports are not reopened. One workflow action described below is in place but stays unchecked for now: dependencies (the two known blockers have no upstream report yet). As of October 2026:</p>
 <ul>
 <li><strong>Foundational:</strong> this document; the <code>accessibility</code> label, applied to accessibility reports and work.</li>
 <li><strong>Workflow:</strong> priorities, contributor expectations and interface requirements above, linked from <a href="CONTRIBUTING.html">CONTRIBUTING.md</a>; the accessibility bug report form with an email alternative; severity and response; the pull request checklist; <code>good first issue</code> and <code>help wanted</code> accessibility issues with acceptance criteria; an owner; documentation checked by the automated check; dependencies and upstream blockers recorded.</li>
 <li><strong>Testing:</strong> the documentation accessibility check in CI, with its findings tracked; documentation reviewed; supported environments and known limitations above. A keyboard-only run of the core tasks on the website passed and is recorded; screen reader and manual checks are written down but not yet run by a person.</li>
-<li><strong>Community:</strong> a feedback form after each cohort and labeled issues to invite help; documented responses to reports; asynchronous and live ways to take part, a private route for accommodations and a Code of Conduct; quarterly progress updates; reusable materials. Crediting accessibility contributors with their consent is the practice above, and has not yet happened.</li>
+<li><strong>Community:</strong> a feedback form after each cohort and labeled issues to invite help; documented responses to reports, enforced by the accessibility-reports workflow; asynchronous and live ways to take part, a private route for accommodations and a Code of Conduct; quarterly progress updates; reusable materials. Crediting accessibility contributors with their consent is the practice above, and has not yet happened.</li>
 </ul>
 <h2 id="feedback">Feedback</h2>
 <p>To suggest an improvement to this document or to how we work, open an issue or a pull request, or write to <a href="mailto:support@community-access.org">support@community-access.org</a>. Thank you for helping make GIT Going with GitHub work for everyone.</p>