From ee475808913da8128bb6e89416d88e569fbdaaf1 Mon Sep 17 00:00:00 2001
From: M Fahmi Husaini HSB <327989351+FahmiHusaini0@users.noreply.github.com>
Date: Mon, 9 Nov 2026 01:40:41 +0700
Subject: [PATCH 1/2] Fix typo in ACCESSIBILITY.md

Corrected a typo in the expectations section of the accessibility document.
---
 ACCESSIBILITY.md | 95 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 ACCESSIBILITY.md

diff --git a/ACCESSIBILITY.md b/ACCESSIBILITY.md
new file mode 100644
index 00000000000..fb118d9cce2
--- /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 proces.
+
+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.
+-->

From 088222983e8fa166956a4df7fdcdc7bf030fc5c6 Mon Sep 17 00:00:00 2001
From: M Fahmi Husaini HSB <327989351+FahmiHusaini0@users.noreply.github.com>
Date: Mon, 9 Nov 2026 01:42:31 +0700
Subject: [PATCH 2/2] Fix typos and improve clarity in ACCESSIBILITY.md

Clarified the accessibility document by correcting typographical errors and enhancing the language for better understanding.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---
 ACCESSIBILITY.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ACCESSIBILITY.md b/ACCESSIBILITY.md
index fb118d9cce2..1b1d5498dfe 100644
--- a/ACCESSIBILITY.md
+++ b/ACCESSIBILITY.md
@@ -4,7 +4,7 @@
 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 proces.
+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