diff --git a/ACCESSIBILITY.md b/ACCESSIBILITY.md index e276e49b..cd95c2be 100644 --- a/ACCESSIBILITY.md +++ b/ACCESSIBILITY.md @@ -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 diff --git a/html/ACCESSIBILITY.html b/html/ACCESSIBILITY.html index 36929c8a..743896ba 100644 --- a/html/ACCESSIBILITY.html +++ b/html/ACCESSIBILITY.html @@ -420,12 +420,12 @@
The accessibility owner keeps these current. Report a problem with any of them the same way as any other barrier.
We follow the 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, 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 in its four phases and record our progress, action by action, in our public tracking issue, GIT Going with GitHub, issue 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 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:
accessibility label, applied to accessibility reports and work.good first issue and help wanted accessibility issues with acceptance criteria; an owner; documentation checked by the automated check; dependencies and upstream blockers recorded.To suggest an improvement to this document or to how we work, open an issue or a pull request, or write to support@community-access.org. Thank you for helping make GIT Going with GitHub work for everyone.