Free tools Windows power users keep installed
One-click scans. No signup required.
GitHub now highlights a repository’s ACCESSIBILITY.md file on its overview page when it is saved in the repository root, .github/, or docs/. The file gives maintainers a visible place to describe accessibility priorities, known barriers, supported environments, and how people can report problems. It is a useful commitment and communication tool—not proof that the software conforms to WCAG or that every requirement has been tested.
Where GitHub looks for ACCESSIBILITY.md
GitHub checks these locations, in this order: .github/, the repository root, then docs/. It surfaces the file on the repository overview. If a repository has no accessibility page, it can inherit one from an organization-owned repository named .github. See GitHub’s documentation on default community health files for details.
As an Amazon Associate I earn from qualifying purchases.
GitHub’s October 1, 2026 changelog says the feature is available on all plans on github.com. It also announced availability in GitHub Enterprise Server 3.24; for a self-hosted instance, check whether that version is installed and the feature is available there. The GitHub changelog announcement describes the rollout.
How to add the file
You can start from GitHub’s Community Standards flow for a public repository or create the Markdown file yourself. GitHub recommends using a pull request when changing the default branch.
#1 Best Overall
Use the Community Standards flow
- Open the public repository on GitHub.
- Go to Insights → Community Standards.
- Under Additional community file, choose Accessibility.
- Add or propose the file, review the Markdown, then commit the change or open a pull request.
Create it manually
- In the repository, create a file named
ACCESSIBILITY.mdin the root,.github/, ordocs/. - Write the page in Markdown. Include the project-specific information readers and contributors need, rather than making claims the project has not verified.
- Commit the file directly if appropriate, or open a pull request for review and merge it into the default branch.
GitHub documents both creation methods in its guide to creating a file with accessibility information.
What to put in an accessibility file
Make the page useful to the person trying to use or contribute to the project. GitHub suggests covering priorities, supported environments, known barriers, contributor expectations, how to report barriers, ownership, and maintenance. W3C WAI’s guidance on accessibility statements also recommends explaining the standard applied, if one has actually been selected, relevant limitations, measures taken, tested environments, technical prerequisites, and contact information.
- Scope and ownership: Name the product or project, say what the page covers, and identify the person or team responsible for it.
- Current approach: Describe accessibility priorities and work already done. Name a standard such as WCAG 2.2 only if the project has adopted it as a target.
- Known barriers and tested environments: Describe limitations in terms people can understand. State which browsers, devices, assistive technologies, or other environments have been tested—and do not imply broader testing than took place.
- Reporting route: Give a usable contact method or issue-reporting path. Explain what information helps, and how reports are handled.
- Contributor expectations and maintenance: Tell contributors how accessibility fits into changes and reviews. Say who will maintain the page and when it will be revisited.
Use plain language. For example, say “videos do not have captions” rather than relying only on the name of an unmet WCAG criterion. W3C WAI also recommends making the statement easy to find and using consistent link names.
This outline is a practical combination of GitHub’s project guidance and W3C WAI’s user-facing recommendations, not an official required template. Do not publish empty placeholders or claim a WCAG target the project has not chosen.
Rank #3
What the file does—and does not—claim
An ACCESSIBILITY.md file makes information easier to discover; it does not remove barriers from the software itself. Accessibility still depends on design, implementation, testing, and ongoing maintenance. W3C WAI explains that an accessibility statement is not a technical assessment or declaration of conformity, though it can refer to assessments that support its claims.
Keep three kinds of document distinct:
| Document | What it communicates | What it establishes |
|---|---|---|
| Project commitment page | Priorities, current knowledge, supported environments, contributor expectations, and reporting routes. | What the project says it is doing; not conformance. |
| User-facing accessibility statement | How people can use the product, known limitations, and how to report a problem. | Useful access information; not, by itself, a technical assessment. |
| Technical conformance report | Assessment results against a defined standard and scope. | Evidence tied to the assessment; its scope and method still matter. |
GitHub lists Accessibility Conformance Reports separately. Its collection is based on the WCAG edition of VPAT version 2.5, defined by the Information Technology Industry Council; a repository statement is not a substitute for such a report. See GitHub’s Accessibility Conformance Reports. A community-maintained accessibility.md template also cautions that the file is not automatically a public-facing statement, conformance claim, ACR/VPAT, legal advice, or evidence that every requirement was tested; that is template guidance, not an official GitHub rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why repository visibility matters, and what it cannot show
A 2024 study, “Analyzing the Accessibility of GitHub Repositories for PyPI and NPM Libraries”, examined repository URL availability for package libraries, not software accessibility or WCAG conformance. The authors collected data on February 16, 2024, and reported maxima across analyzed subsets of up to 73.8% for individual PyPI libraries and 69.4% for individual NPM libraries; for libraries within full dependency chains, the maxima were 80.1% and 81.1%, respectively. These are study-specific repository metadata figures, not current ecosystem measurements and not evidence that an accessibility file improves discovery or accessibility.
The study authors wrote: “Package maintainers should address this issue and update the repository information to enable monitoring of their libraries.” That recommendation concerns repository metadata and monitoring; it does not establish the effects of GitHub’s newer accessibility-file feature.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
