Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions ACCESSIBILITY.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
4 changes: 2 additions & 2 deletions html/ACCESSIBILITY.html
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down
Loading