diff --git a/ACCESSIBILITY.md b/ACCESSIBILITY.md
new file mode 100644
index 00000000000..1b1d5498dfe
--- /dev/null
+++ b/ACCESSIBILITY.md
@@ -0,0 +1,95 @@
+# Accessibility
+
+<!--
+Include a brief statement describing why accessibility matters to your
+project, who should be able to use and contribute to it, and what this
+document covers, such as your accessibility commitments, contributor
+expectations, and issue-reporting process.
+
+Write for people who may read this after encountering a barrier. Use plain
+language and describe user experiences rather than relying on legal
+language, technical jargon, or standards codes.
+-->
+
+## Priorities
+
+<!--
+Describe the outcomes the project prioritizes and how it works toward them.
+If you name a WCAG level as an accessibility target, make clear that it is
+an aspirational goal rather than a verified conformance claim. Only claim
+conformance after an evaluation, and identify the evaluated scope, date,
+method, and evaluator. Also describe the areas you prioritize, such as
+keyboard, screen reader, content, or language support.
+-->
+
+## Contributor expectations
+
+<!--
+Describe the accessibility guardrails that apply to contributions,
+including relevant testing, documentation, and continuous integration
+checks. Name specific tools only when the project uses them, and explain
+what evidence contributors should include with user-facing changes.
+-->
+
+## Reporting accessibility issues
+
+<!--
+Provide a direct, accessible way to report a barrier or request help.
+Invite useful context such as the affected task, URL, observed behavior,
+browser, operating system, and assistive technology. Make screenshots or
+recordings optional and do not require disability disclosure.
+-->
+
+### Severity
+
+<!--
+If your project uses severity levels, define them and give practical
+examples based on how strongly a barrier affects a user's ability to
+complete a task. Keep labels consistent with your issue template and
+resolution targets if those processes exist. Maintainers can assign or
+confirm severity during triage; reporters do not need to.
+-->
+
+### How we respond
+
+<!--
+Explain what reporters can expect after submitting an accessibility issue,
+including acknowledgement, status updates, workarounds, expected timelines,
+and opportunities to verify a fix. Use commitments your project can
+consistently uphold.
+-->
+
+## Ownership and maintenance
+
+<!--
+Identify the team, role, or maintainer responsible for accessibility and
+describe their responsibilities to the project. Include the review cadence
+and how ownership transfers when responsibilities change.
+-->
+
+## Supported environments
+
+<!--
+List the platforms, devices, browsers, input methods, and assistive
+technologies the project supports or has tested. Include versions where
+useful, note partial support, and avoid implying support for combinations
+that have not been evaluated.
+-->
+
+## Known limitations
+
+<!--
+Describe known barriers in terms of the affected user experience, such as
+"videos do not have captions," rather than standards codes. Include
+available workarounds or equivalent access and link to tracked issues. If
+no limitations are currently documented, describe what has been tested
+instead of claiming that no barriers exist.
+-->
+
+## Feedback and improvements
+
+<!--
+Explain how users and contributors can suggest improvements to this
+statement or the project's accessibility practices. Direct active
+accessibility barriers to the reporting process above.
+-->