Give your repository an accessibility page people can use

A repository can have accessibility work underway and still leave users guessing where to report a barrier, what environments have been checked, or what contributors should test. GitHub now gives that information a recognizable home: an ACCESSIBILITY.md file that appears on the repository overview.

The feature is available on GitHub.com across plans. GitHub looks for the file in .github/, the repository root, or docs/, in that order. An organization can also provide a shared statement through its .github repository. For public repositories, maintainers can start from a template under Insights > Community Standards. GitHub’s documentation explains the locations and setup.

The useful change is discoverability. A visitor does not have to know which issue label or contribution document contains the information. That is only valuable if the page answers practical questions accurately.

Write down what you can stand behind

A short statement can cover four things:

• What you support or have checked: Name relevant platforms, input methods, or assistive technologies only when you have evidence. Say what was evaluated and when.
• Known barriers and workarounds: Describe the affected task and link to an issue or other tracked work when possible.
• How to report a barrier: Provide a direct route and tell people what information helps. Make screenshots or recordings optional, and do not ask anyone to disclose a disability.
• What happens next: Explain who reviews reports and what updates people can expect. Promise only a response process the maintainers can sustain.

For an example with concrete workarounds and candid limits, read the GitHub CLI accessibility statement. It describes settings, known screen-reader barriers, a command-line alternative, and the scope of its testing. That level of detail is more useful than a general statement that accessibility matters.

Don’t turn a target into a claim

A project can name a standard it aims to meet, but a target is not proof of conformance. GitHub’s guidance says a conformance claim needs an evaluation that identifies its scope, date, method, and evaluator. Its announcement also recommends describing the project’s actual practices and limitations, rather than using a fixed template as a substitute for them.

Treat the file like other repository guidance: review it when support changes, a known barrier is fixed, or ownership moves. If nobody can keep a statement current, keep it narrower. Add the page when it helps people understand the project and report problems; don’t use its presence as a badge for work you haven’t verified.