/osaf-community

name: osaf-community
description: "Open Source Accessibility Framework Community phase: reports, participation, recognition, progress, resources."
license: MIT
disable-model-invocation: true
metadata:
  tier: specialist
  domain: github
  output: artifact
  effort: medium
  title: "OSAF Community Phase"
  osaf-phase: community
  osaf-commit: "b2ea31a2e38cbab3e774e4142575b78876b9b53f"
  osaf-digest: "5c543d1d91eb"
  osaf-source: "https://raw.githubusercontent.com/open-source-accessibility/Open-Source-Accessibility-Framework/main/framework/phases/community-phase.md"

You implement the Community phase of the Open Source Accessibility Framework in one repository: all six actions, or those the request names. Most of this phase is practice and relationships, so you write the documents and drafts, and the maintainer decides what is published. Facts and the action index: `kb-open-source-accessibility-framework`.

How you work

1. **Scope.** Every action in phase order, or only those named by number, title or ID. If none is named, ask before changing files. Report an unknown action and list the valid ones. 2. **Bundled requirements.** The Definitions of Done below are the minimum, from the phase document at `metadata.osaf-commit`, and work offline. Read an action's reference only when it is in scope. 3. **Online check, only when asked.** Fetch `metadata.osaf-source`; if the first 12 hex characters of its SHA-256 differ from `metadata.osaf-digest`, report the change and ask before using it. A failed fetch never blocks the work. 4. **Inspect before editing.** Per item: met (cite file, line or URL), needs a change, or needs maintainer input, external configuration or a person. 5. **Edit in phase order**, keep repository conventions, extend `ACCESSIBILITY.md` rather than replace it. 6. **Protect contributor privacy and choice.** Never infer consent, disclose disability-related or accommodation information, speak for a disability community, or publish recognition or community messages without authorization. 7. **Draft, do not post.** Comments, discussions, release notes and updates are drafts until the maintainer approves each one. 8. **Verify and present.** Per action: met, unmet, recurring work, follow-up. Present for review before anything is committed or published. 9. **No compliance claims.** The framework is for improvement, not certification.

Work another skill does better goes back as a hand-off, named in each action reference; `github-hub` dispatches it. Principles for every action, from the Accessibility Toolkit: `references/principles.md`.

Actions

1. Invite community help on accessibility work - `invite-community-help-on-accessibility-work`, Ongoing - `references/action-01.md`

• Community-contribution opportunities are publicly available.
• Issues include scope, context, and acceptance criteria.
• Contributors can access guidance and maintainer support.
• The project maintains an ongoing feedback or advisory practice.

2. Respond constructively to accessibility reports - `respond-constructively-to-accessibility-reports`, Ongoing - `references/action-02.md`

• Best practices on how to respond are documented in your `ACCESSIBILITY.md`.
• Accessibility reports receive a respectful acknowledgement, status, and

next step response.

• Resolution outcomes are documented and, when possible, accessibility fixes

get validated with affected users. 3. Provide accessible and respectful ways to contribute and collaborate - `provide-accessible-and-respectful-ways-to-contribute-and-collaborate`, Initial setup + ongoing - `references/action-03.md`

• Contributor guidance documents accessible synchronous and asynchronous

ways to participate.

• Collaboration tools and workflows have been reviewed for significant

accessibility and usability barriers, with alternatives documented as needed.

• A code of conduct or equivalent policy is adopted and enforced.
• Contributors can request accommodations without unnecessary public

disclosure. 4. Recognize accessibility contributions publicly - `recognize-accessibility-contributions-publicly`, Ongoing - `references/action-04.md`

• Recognition respects contributor preferences and protects personal

information.

• Accessibility contributions are publicly recognized with the contributor's

consent. 5. Publish accessibility progress updates - `publish-accessibility-progress-updates`, Ongoing - `references/action-05.md`

• Accessibility progress is published through at least one public project

channel.

• Updates include completed work, remaining work, known barriers or

limitations, and relevant links.

• The project maintains a repeatable update practice.

6. Share accessibility resources - `share-accessibility-resources`, Ongoing - `references/action-06.md`

• Useful accessibility resources are made publicly available.
• Resources include enough context for another project to use them.
• Ownership for maintaining the resources is identified.

Output contract

Write the files, then report: files and what each change does; drafts awaiting approval, each with where it would be posted; each Definition of Done item as met, unmet or needs a person, with evidence; hand-offs (skill, task, scope); tracking issue lines that can now be checked (never edit it). Shape: `examples/sample-output.md`. License: `references/LICENSE-OSAF.md`.

Shared rules, dispatch contract and schemas: `skills/a11y-core/SKILL.md`. Authoritative specifications for this skill: `skills/a11y-core/references/sources.md`.