[accesswatch]

Two enforced rules for Open Source Accessibility Framework, Community actions 2 (respond constructively to accessibility reports) and 4 (recognize contributions publicly), as asked by @accesswatch. The same files are installed in accessibility-agents, quill, glow and git-going-with-github; only .github/a11y-community.json differs.

Rule 1: accessibility-reports.yml

A report is an issue with the accessibility label, opened on or after 2026-10-29 (installDate) by someone who is not OWNER, MEMBER, COLLABORATOR or a bot.

• Opened or first labelled: one acknowledgement (status and next step within 5 business days, link to known limitations, optional environment details, nothing about disability), label a11y: awaiting response.
• A maintainer comments: a11y: awaiting response and a11y: response overdue come off.
• Daily sweep: still awaiting after 5 business days (Monday to Friday, UTC) gets a11y: response overdue and one reminder mentioning the owner.
• Closed: needs a closed timeline event with a commit, a cross-referenced merged pull request, or a maintainer comment with an Outcome: line after the reporter's last comment. Otherwise it is reopened, with one explanation. Closed as completed with an outcome: one validation invite and a11y: validation requested. Not planned or duplicate: outcome needed, no invite.
• Events whose sender is a bot are skipped, so the rule's own reopen and comments never retrigger it.

Rule 2: accessibility-credits.yml

• A merged pull request with the accessibility label, or one whose body closes a same-repository accessibility issue, from a non-maintainer; and a report closed as completed with an outcome: one credit question, label credit: asked, never twice on one item.
• Only the contributor's reply counts: credit: @handle, credit: name <Name>, credit: anonymous or credit: no, giving credit: yes, credit: anonymous or credit: no and a short confirmation. A chosen name is stored only in the bot's confirmation, as <!-- a11y-credit: choice="name" name="..." reply="..." -->. A later reply changes the choice.
• node .github/scripts/a11y-credits.mjs --since <tag-or-date> prints the release-notes block (code and other contributions, described by item title), and warns on standard error about credit: asked items unanswered after 14 days.

Design notes

• .github/scripts/a11y-community.mjs is dependency-free and takes an injected client; workflows run it through actions/github-script, the release script through plain Node with fetch.
• Every handler re-reads the issue's comments rather than trusting one event, so an event the per-issue concurrency queue drops is repaired by the next one (the daily sweep also clears awaiting where a maintainer did reply).
• Permissions: contents: read, issues: write, pull-requests: read for reports. The credits workflow has pull-requests: write, because GitHub requires it to comment on and label a pull request; it runs on pull_request_target, checks out only the base branch's .github folder and runs no pull request code. No secrets beyond GITHUB_TOKEN.
• The install date applies to every report rule, not only the overdue sweep, so closing or labelling an existing issue is not affected.
• Framework progress is unchanged: actions 2 and 4 stay unchecked until real reports and real credits exist.
• Labels (seven, not six: three a11y: and four credit:) were created in the repository with descriptions.

In this repository

• Tests: npm run test:automation now also runs .github/scripts/__tests__/*.test.mjs (134 tests pass locally, 29 of them new); the Automation Tests workflow already runs it on .github/scripts/** changes. actionlint 1.7.12 is clean.
• Docs: "How we respond" and "Recognizing contributions" in ACCESSIBILITY.md, with html/ACCESSIBILITY.html rebuilt by npm run build:html; Authoritative Sources sections unchanged and validate:authoritative-sources passes; the docs accessibility check reports no new findings.
• Release step: this project releases by cohort and quarter, so the step is a line in the checklist of the quarterly review issue that accessibility-review-reminder.yml opens, pre-filled with the quarter's start date.

---

Generated by Claude Code

[github-actions]

Peer Review Assigned

Hi @accesswatch! Your PR has been automatically paired with @taylorarndt for peer review.

For @taylorarndt:

This is a great opportunity to practice code review skills! Here's what to look for:

Content Quality:

• Does the change accomplish what the issue describes?
• Is the writing clear and helpful?
• Are there any typos or grammar issues?

Accessibility:

• Proper heading hierarchy (H1 → H2 → H3, no skips)?
• Descriptive link text (not "click here")?
• Alt text on images?
• [TODO] markers removed?

Documentation:

• Code blocks are properly formatted?
• Tables have headers?
• References/links work correctly?

Review Guidelines:

• Be kind and constructive
• Suggest improvements, don't just point out problems
• Ask questions if something is unclear
• Approve when ready or request changes with explanation

Resources:

• How to Review PRs
• Writing Good Review Comments

---

Pairing by Learning Room Grouping Engine