@@ -209,11 +209,11 @@ 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: 19 of 24 as of 28 October 2026. 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. 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. Keyboard, screen reader and manual checks of the core tasks are written down but not yet run and 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.
 
 ## Feedback
 
@@ -2,18 +2,18 @@
 
 This document holds the keyboard-only, screen reader and manual accessibility checks for the tasks every learner must be able to complete with the workshop's own materials, and the record of each time they are run. It is the test plan behind the "Supported environments" and "Known limitations" sections of [ACCESSIBILITY.md](../ACCESSIBILITY.md). For checking a new issue template or form, use the [template testing checklist](ACCESSIBILITY_TESTING.md) instead.
 
-A check counts as run only when a person has done it with the stated browser and assistive technology, and written down the date, the environment and the result. A simulation, a code review or an automated scan is useful preparation and is recorded separately as such; it is never a result here.
+A check counts as run only when a person has done it with the stated browser and assistive technology, and written down the date, the environment and the result. A simulation, a code review or an automated scan is useful preparation and is recorded separately as such; it is never a result here. The one exception is a keyboard-only run made with real key presses in a real browser: the accessibility owner may accept it as a result, and says so in its record. Screen reader and manual visual checks always need a person.
 
 ## Status
 
 The table below shows, for each core task, which records exist and whether they have been run.
 
 | Core task | Keyboard only | Screen reader | Manual visual checks |
 |---|---|---|---|
-| 1. Read a chapter on the website | Not yet run | Not yet run | Not yet run |
-| 2. Search the website | Not yet run | Not yet run | Not yet run |
-| 3. Listen to a companion episode and open its transcript | Not yet run | Not yet run | Not yet run |
-| 4. Opt in on the registration page | Not yet run | Not yet run | Not yet run |
+| 1. Read a chapter on the website | Pass, 28 October 2026 (agent run, accepted) | Not yet run | Not yet run |
+| 2. Search the website | Pass, 28 October 2026 (agent run, accepted) | Not yet run | Not yet run |
+| 3. Listen to a companion episode and open its transcript | Pass, 28 October 2026 (agent run, accepted) | Not yet run | Not yet run |
+| 4. Opt in on the registration page | Pass, 28 October 2026 (agent run, accepted) | Not yet run | Not yet run |
 | 5. Report a barrier with the accessibility bug report form | Not yet run | Not yet run | Not yet run |
 | 6. Read the ePub and braille downloads | Not applicable | Not yet run | Not applicable |
 
@@ -117,7 +117,7 @@ No checks by a person have been run yet.
 
 ## Agent runs
 
-These runs were made by Claude (an AI agent) on the live site, with real key presses in a real browser. By the rule at the top of this document they are preparation, not results: they show what a person's run should find, and they caught one real defect, which is fixed. A person's run still has to be recorded under "Records" before the status table changes.
+These runs were made by Claude (an AI agent) on the live site, with real key presses in a real browser. The keyboard run was accepted as a result by the accessibility owner, Jeff Bishop, on 28 October 2026, under the exception at the top of this document, and the status table shows it. The manual visual run stays preparation only: it caught one real defect, which is fixed, and a person's run still has to be recorded under "Records".
 
 ### Agent run: keyboard, tasks 1 to 4, 28 October 2026
 
@@ -133,7 +133,7 @@ Environment: Chromium in the Claude desktop app's browser pane, Windows, 1280 by
 - Task 4: the enrollment link, "Begin the Adventure (opens in new tab)", is reached by Tab.
 - Task 5 was not run: the form is on GitHub and needs a signed-in account.
 
-Result: no keyboard failures found.
+Result: pass for tasks 1 to 4, no keyboard failures found. Accepted as a result by the accessibility owner on 28 October 2026. Task 5 is GitHub's own issue form and is still to be run while signed in.
 
 ### Agent run: manual visual checks, tasks 1 to 4, 28 October 2026
 
 
@@ -413,11 +413,11 @@ <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: 19 of 24 as of 28 October 2026. 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. 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. Keyboard, screen reader and manual checks of the core tasks are written down but not yet run and 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>
 </ul>
 <h2 id="feedback">Feedback</h2>
 
@@ -221,7 +221,7 @@ <h2 class="onpage-title">On This Page</h2>
   </nav>
       <div id="course-content"><h1 id="accessibility-checks-for-core-flows">Accessibility Checks for Core Flows</h1>
 <p>This document holds the keyboard-only, screen reader and manual accessibility checks for the tasks every learner must be able to complete with the workshop&#39;s own materials, and the record of each time they are run. It is the test plan behind the &quot;Supported environments&quot; and &quot;Known limitations&quot; sections of <a href="../ACCESSIBILITY.html">ACCESSIBILITY.md</a>. For checking a new issue template or form, use the <a href="ACCESSIBILITY_TESTING.html">template testing checklist</a> instead.</p>
-<p>A check counts as run only when a person has done it with the stated browser and assistive technology, and written down the date, the environment and the result. A simulation, a code review or an automated scan is useful preparation and is recorded separately as such; it is never a result here.</p>
+<p>A check counts as run only when a person has done it with the stated browser and assistive technology, and written down the date, the environment and the result. A simulation, a code review or an automated scan is useful preparation and is recorded separately as such; it is never a result here. The one exception is a keyboard-only run made with real key presses in a real browser: the accessibility owner may accept it as a result, and says so in its record. Screen reader and manual visual checks always need a person.</p>
 <h2 id="status">Status</h2>
 <p>The table below shows, for each core task, which records exist and whether they have been run.</p>
 <table>
@@ -235,25 +235,25 @@ <h2 id="status">Status</h2>
 </thead>
 <tbody><tr>
 <td>1. Read a chapter on the website</td>
-<td>Not yet run</td>
+<td>Pass, 28 October 2026 (agent run, accepted)</td>
 <td>Not yet run</td>
 <td>Not yet run</td>
 </tr>
 <tr>
 <td>2. Search the website</td>
-<td>Not yet run</td>
+<td>Pass, 28 October 2026 (agent run, accepted)</td>
 <td>Not yet run</td>
 <td>Not yet run</td>
 </tr>
 <tr>
 <td>3. Listen to a companion episode and open its transcript</td>
-<td>Not yet run</td>
+<td>Pass, 28 October 2026 (agent run, accepted)</td>
 <td>Not yet run</td>
 <td>Not yet run</td>
 </tr>
 <tr>
 <td>4. Opt in on the registration page</td>
-<td>Not yet run</td>
+<td>Pass, 28 October 2026 (agent run, accepted)</td>
 <td>Not yet run</td>
 <td>Not yet run</td>
 </tr>
@@ -348,7 +348,7 @@ <h2 id="records">Records</h2>
 <p>Add each run below, newest first, using the blocks above. Link any issue you file, labeled <code>accessibility</code>.</p>
 <p>No checks by a person have been run yet.</p>
 <h2 id="agent-runs">Agent runs</h2>
-<p>These runs were made by Claude (an AI agent) on the live site, with real key presses in a real browser. By the rule at the top of this document they are preparation, not results: they show what a person&#39;s run should find, and they caught one real defect, which is fixed. A person&#39;s run still has to be recorded under &quot;Records&quot; before the status table changes.</p>
+<p>These runs were made by Claude (an AI agent) on the live site, with real key presses in a real browser. The keyboard run was accepted as a result by the accessibility owner, Jeff Bishop, on 28 October 2026, under the exception at the top of this document, and the status table shows it. The manual visual run stays preparation only: it caught one real defect, which is fixed, and a person&#39;s run still has to be recorded under &quot;Records&quot;.</p>
 <h3 id="agent-run-keyboard-tasks-1-to-4-28-october-2026">Agent run: keyboard, tasks 1 to 4, 28 October 2026</h3>
 <p>Environment: Chromium in the Claude desktop app&#39;s browser pane, Windows, 1280 by 900 and 320 by 720 windows. Pages: the home page, Chapter 05, Chapter 07, the search results page for &quot;merge conflict&quot;, and REGISTER.html.</p>
 <ul>
@@ -362,7 +362,7 @@ <h3 id="agent-run-keyboard-tasks-1-to-4-28-october-2026">Agent run: keyboard, ta
 <li>Task 4: the enrollment link, &quot;Begin the Adventure (opens in new tab)&quot;, is reached by Tab.</li>
 <li>Task 5 was not run: the form is on GitHub and needs a signed-in account.</li>
 </ul>
-<p>Result: no keyboard failures found.</p>
+<p>Result: pass for tasks 1 to 4, no keyboard failures found. Accepted as a result by the accessibility owner on 28 October 2026. Task 5 is GitHub&#39;s own issue form and is still to be run while signed in.</p>
 <h3 id="agent-run-manual-visual-checks-tasks-1-to-4-28-october-2026">Agent run: manual visual checks, tasks 1 to 4, 28 October 2026</h3>
 <p>Same environment. Contrast was measured for every text element against its actual background colour, in light and dark mode.</p>
 <ul>