From 85128a8192d74280d3e9c807e3c5f141f3bcc93d Mon Sep 17 00:00:00 2001
From: Holer8 <318349352+Holer8@users.noreply.github.com>
Date: Fri, 16 Oct 2026 09:47:02 +0100
Subject: [PATCH] docs(governance): add accessibility statement

---
 .../compliance/ACCESSIBILITY_STATEMENT.md     | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 Governance/compliance/ACCESSIBILITY_STATEMENT.md

diff --git a/Governance/compliance/ACCESSIBILITY_STATEMENT.md b/Governance/compliance/ACCESSIBILITY_STATEMENT.md
new file mode 100644
index 00000000..042444bf
--- /dev/null
+++ b/Governance/compliance/ACCESSIBILITY_STATEMENT.md
@@ -0,0 +1,38 @@
+# Accessibility statement
+
+TeachLink Web aims to make its web experience usable by people with disabilities.
+This statement records the project's current accessibility commitment and how
+people can report barriers.
+
+## Conformance level and current status
+
+The project targets **WCAG 2.1 Level AA**. This is a target, not a claim that the
+entire website currently conforms. The application includes accessibility
+patterns and automated checks, but automated checks do not establish full
+conformance. Page-by-page review, keyboard-only use, and screen-reader testing
+are still required. See the [accessibility guide](../../docs/ACCESSIBILITY.md)
+for the implemented toolkit, known limits, and manual checks.
+
+## Feedback and accessibility requests
+
+Report an accessibility barrier or request an accessible alternative through
+the repository's [GitHub issue tracker](https://github.com/rinafcode/teachLink_web/issues).
+Include the affected page or workflow, what you were trying to do, the assistive
+technology or browser involved when relevant, and a way for maintainers to
+follow up. Do not include passwords, private account information, or other
+sensitive personal data in a public issue. Describe the barrier and affected
+workflow without including private account details.
+
+## Review cadence and ownership
+
+The maintainers review this statement at least once every **12 months** and
+after a material change to the accessibility toolkit, supported user flows, or
+conformance target. A report that identifies a barrier should trigger an earlier
+review of the affected section. The maintainers own updates to this statement
+and should record material changes in the pull request that updates it.
+
+## Related guidance
+
+- [Accessibility implementation and testing guide](../../docs/ACCESSIBILITY.md)
+- [Component contribution accessibility requirements](../domains/COMPONENT_CONTRIBUTION.md)
+- [Project scope](../SCOPE.md)