diff --git a/general/development/policies/accessibility/coding-guidelines.md b/general/development/policies/accessibility/coding-guidelines.md
new file mode 100644
index 000000000..f5bc64e0f
--- /dev/null
+++ b/general/development/policies/accessibility/coding-guidelines.md
@@ -0,0 +1,741 @@
+---
+title: Coding guidelines
+tags:
+  - Accessibility
+  - Coding guidelines
+keywords:
+  - accessibility
+  - accessibility coding guidelines
+---
+
+All features in Moodle _must_ be accessible to all users regardless of their abilities. Therefore, accessibility must be built in from the planning and design stage through to development and testing, to ensure we release features that are accessible by default.
+
+## Semantic HTML
+
+It is highly recommended to use [semantic HTML](https://developer.mozilla.org/en-US/curriculum/core/semantic-html/). Doing so is important because using HTML elements for their intended purpose (for example, using `<button>` for a button and `<h1>` for a main heading) provides essential information to assistive technologies like screen readers. This helps users of these technologies understand and interact with the user interface components effectively.
+
+In addition, using semantic HTML for interactive elements, such as buttons, links, and form controls, allows you to leverage the built-in keyboard support in browsers.
+
+Moodle supports HTML5, so incorporating semantic HTML5 elements when building the user interface for your plugin or core contribution is a significant step towards ensuring accessibility.
+
+<ValidExample title="Using semantic button element">
+
+Below are some examples of using a semantic HTML button element in Mustache templates.
+
+- A button labelled by the button's text.
+
+```html
+<button type="button" class="btn btn-secondary">
+    {{#str}} deletecategory, customfield, {{name}} {{/str}}
+</button>
+```
+
+- An icon button labelled by its `aria-label` attribute.
+
+```html
+<button type="button" class="btn icon" aria-label="{{#str}} deletecategory, customfield, {{name}} {{/str}}">
+    {{#pix}} t/delete, core {{/pix}}
+</button>
+```
+
+- An icon button with a visually hidden text label.
+
+```html
+<button type="button" class="btn btn-icon">
+    {{#pix}} t/delete, core {{/pix}}
+    <span class="visually-hidden">
+        {{#str}} deletecategory, customfield, {{name}} {{/str}}
+    </span>
+</button>
+```
+
+</ValidExample>
+
+:::warning Using non-semantic HTML: A link element as a button
+
+Consider the following example where a link element is used as a button:
+
+```html
+<a href="#" class="btn btn-secondary" role="button">
+    {{#str}} deletecategory, customfield, {{name}} {{/str}}
+</a>
+```
+
+For assistive technologies to properly recognise the link element as a button, we need to set a value of `button` for the `role` attribute. Additionally, as specified in the [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/patterns/button/), buttons are activated when pressing `Space` or `Enter` keys. Given that links are natively activated by pressing the `Enter` key only, links that act as buttons need to implement an event handler in JavaScript for the `Space` key press event.
+
+:::
+
+## Accessible Rich Internet Applications (ARIA)
+
+ARIA is a set of special attributes added to HTML to improve accessibility. It bridges the gap between HTML's native accessibility and the complex interactions of modern web applications.
+
+ARIA helps assistive technologies, like screen readers, understand dynamic and interactive web content.
+
+It defines:
+
+- Role (`toolbar`, `tooltip`, `button`, `menu`, `dialog`, etc.)
+- States (`aria-expanded`, `aria-hidden`, etc.)
+- Properties (`aria-haspopup`, `aria-label`, `aria-describedby`, etc.)
+
+to communicate what elements are and how they behave, and it is especially useful for making custom widgets and dynamic content accessible.
+
+### When to use ARIA?
+
+We typically use ARIA when creating interactive widgets for which there is no native HTML equivalent. Some examples include autocomplete form elements, searchable combo boxes, dropdown menus, and tabbed interfaces.
+
+We also use ARIA attributes to clarify relationships between elements on the page or their states. For example, we need to display a validation error message on a form field. We then use the `aria-describedby` attribute to indicate that the error message pertains to the form field with the invalid input.
+
+Another use of ARIA attributes is to enhance dynamic content updates, such as defining `aria-live` regions on parts of the page that are updated dynamically. This is especially important for assistive technology users, so they are promptly notified of changes when performing actions on the page.
+
+### What ARIA is not
+
+ARIA is not a replacement for semantic HTML. Sure, we can create a button element using a `<span>` tag and assign it an ARIA role of `button`, but we already have the semantic `<button>` HTML element that works out of the box. We should use semantic HTML as much as possible and utilise ARIA as necessary to further enhance the element.
+
+There's also a common misconception that adding ARIA attributes to custom widgets will make them automatically accessible. This is not the case. We need to write JavaScript to:
+
+- Ensure that the custom widget is operable by keyboard-only users
+- Manage keyboard focus so users will know where they are as they operate the custom widget
+- Update ARIA states and properties as needed
+  - For example, updating a menu button's `aria-expanded` attribute to let screen reader users know whether the button is collapsed or expanded.
+
+ARIA attributes also do not affect visual styling. For example, we have a [listbox widget](https://www.w3.org/WAI/ARIA/apg/patterns/listbox/) and update the `aria-selected` attribute of the currently selected list item via JavaScript. This is great for screen reader users because they can tell which list item is selected via the `aria-selected` attribute. However, the `aria-selected` attribute does not affect the listbox items' visual styling. So we must ensure that we apply the appropriate CSS styles to indicate the current selection for sighted users.
+
+There's a saying that "No ARIA is better than bad ARIA". We should remember not to overuse ARIA attributes. Improper use of ARIA attributes can lead to confusion and a worse user experience for assistive technology users.
+
+<InvalidExample title="Using a <span> tag to create a button">
+
+```html
+<span class="btn btn-secondary" role="button" tabindex="0">
+    {{#str}} deletecategory, customfield, {{name}} {{/str}}
+</span>
+```
+
+For this to work and behave as a button, we need to do the following:
+
+- Set a value of `button` for the `role` attribute.
+- Implement event handlers in JavaScript for both `Space` and `Enter` key press events, in addition to the `click` event.
+- Make the element focusable by adding a `tabindex` attribute with a value of `0`. This is because `<span>` elements are not natively focusable, so we need to add the `tabindex` attribute to include it in the page's tab sequence.
+- Most likely, we'll also have to write extra CSS styles to make the appearance consistent with other native button elements.
+
+</InvalidExample>
+
+## Bootstrap
+
+Moodle uses [Bootstrap](https://getbootstrap.com/) as its front-end framework. Bootstrap's pre-designed components make it easy for Moodle developers to build responsive user interfaces for Moodle core and plugins, and help us meet zoom-related accessibility requirements, such as the WCAG Success Criteria [1.4.10 Reflow (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) and [1.4.4 Resize Text (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html).
+
+However, while Bootstrap's components are designed to be [operable by touch, mouse, and keyboard](https://getbootstrap.com/docs/5.3/getting-started/accessibility/), we need to ensure that the Bootstrap components we use are accessible enough to convey the intended functionality to assistive technology users. Where necessary, we need to implement additional JavaScript to update the relevant ARIA attributes or improve keyboard operability. The default Boost theme includes an `aria` JavaScript module that enhances the accessibility of Bootstrap components, such as dropdown menus, combo boxes, toolbars, etc.
+
+## Developing accessible Moodle features
+
+Moodle is committed to accessibility. As Moodle developers, we must ensure that the features that we create for Moodle and its plugins are designed and developed with accessibility in mind. Below are some ways to help you develop accessible features for your plugin or core contribution.
+
+### Page titles
+
+The page title is the first piece of information announced by screen readers when the page is loaded. Therefore, it is essential to ensure that page titles are unique, concise, and informative enough to convey the page's purpose without requiring the user to read the content.
+
+Some tips for providing a meaningful page title:
+
+1. **Accurate and informative**
+   - Describe the page's content or purpose; reflect any change of context (for example, search results).
+2. **Concise**
+   - Keep it brief while still being meaningful.
+3. **Unique**
+   - Each page title should be distinct within the site.
+4. **Front-loaded**
+   - Put the most identifying information first (Example: "`Gradebook setup | Physics 101`" rather than "`Physics 101 | Gradebook setup`").
+
+:::note change of context
+
+(not to be confused with Moodle's `\core\context` class and its implementations)
+
+According to the [WCAG Understanding docs](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html#dfn-changes-of-context), a change in context is a major change that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. It can include changes of user agent, viewport, focus, or content that changes the meaning of the web page.
+
+:::
+
+#### Example
+
+Consider that a student is on the submission page of an assignment activity called `Kinetics problem set 1` in the `Physics 101` course on the `Mount Orange School` Moodle site.
+
+Then a suitable page title for the page would be something like:
+
+<ValidExample>
+
+The most unique identifying information first represented by the activity name and its sub-page, then followed by broader identifiers such as the course name and the site name.
+
+`Kinetics problem set 1: Submit assignment | Physics 101 | Mount Orange School`
+
+</ValidExample>
+
+<ValidExample>
+
+The most unique identifying information first represented by the name of the sub-page, followed by the activity name that the page belongs to, then followed by broader identifiers such as the course name and the site name.
+
+`Submit assignment | Kinetics problem set 1 | Physics 101 | Mount Orange School`
+
+</ValidExample>
+
+#### Separating components of a page title
+
+To separate the components of the page title, use the `moodle_page::TITLE_SEPARATOR` constant.
+
+<ValidExample>
+
+```php
+[$course, $cm] = get_course_and_cm_from_cmid($id);
+// Activity name and its sub-page as the unique identifying information.
+$pagename = format_string($cm->name) . ': ' . get_string('view');
+// Course name.
+$coursename = format_string($course->fullname);
+// Set the page title, combining the activity page's name and course name using the title separator constant.
+$PAGE->set_title($pagename . moodle_page::TITLE_SEPARATOR . $coursename);
+```
+
+</ValidExample>
+
+#### Site name on the page title
+
+There is no need to add the name of the site when setting the page title using `$PAGE->set_title()`. The site name is automatically appended to the end of the page title in the correct format when using `$PAGE->set_title()`.
+
+:::info
+
+Administrators can use the `sitenameinititle` configuration setting to configure how this is shown in the title with possible options including:
+
+- the _full name_ of the site, for example, "Mount Orange School"
+- the _short name_ of the site, for example: "MOS"
+
+This is automatically handled by `$PAGE->set_title()`.
+:::
+
+#### Useful resources
+
+- [Understanding Success Criterion 2.4.2: Page Titled (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/page-titled)
+- [Technique G88: Providing descriptive titles for Web pages](https://www.w3.org/WAI/WCAG22/Techniques/general/G88)
+
+### Headings
+
+A proper heading structure on a page helps screen reader users navigate the page easily by heading. To enable this, we must use semantic headings, such as `h1`-`h6` heading tags. We should not use fake headings, which are text designed to look like headings via CSS but lack semantic meaning.
+
+We should also ensure that the page does not skip headings. For example, the page has an `h1` heading, but the next heading is `h3`. This can cause confusion among screen reader users who navigate the page by heading.
+
+We also must ensure that there is only one `h1` page heading. Ideally, the page heading reflects the page title.
+
+We set the page heading by calling `$PAGE->set_heading()` and outputting it on the header via `$OUTPUT->header()`.
+
+We can set successive headings using the `$OUTPUT->heading()` method.
+
+<ValidExample title="Setting page headings">
+
+```php
+// Set the page's main heading (h1).
+$PAGE->set_heading(format_string($course->fullname));
+// Output the page header that contains the main heading.
+echo $OUTPUT->header();
+
+// Output a level 2 heading.
+echo $OUTPUT->heading(get_string('pluginname', 'mod_yourmodulename'));
+
+// Output a level 3 heading.
+echo $OUTPUT->heading(get_string('someheading', 'mod_yourmodulename'), 3);
+```
+
+</ValidExample>
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.3.1: Info and Relationships (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)
+- [Understanding Success Criterion 2.4.6: Headings and Labels (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html)
+
+### Colours and contrast
+
+All text must be displayed in a colour with sufficient contrast against its background colour so that it is legible for all users. The required contrast ratio depends on the size of the text:
+
+- **Normal text** (under 18pt, or under 14pt if bold): a contrast ratio of at least **4.5:1**.
+- **Large text** (18pt and above, or 14pt and above if bold): a contrast ratio of at least **3:1**.
+
+For more information about testing colour contrast, check out the [Accessibility testing > Colour contrast checkers](./testing#colour-contrast-checkers) developer documentation.
+
+#### Do not rely on colour alone to convey meaning
+
+Colour alone **must not** be used to convey information, indicate an action, prompt a response, or distinguish a visual element. When colour is used to communicate meaning, an additional visual cue (such as text, an icon, or a pattern) must also be provided.
+
+<InvalidExample title="Using colour alone to indicate an error">
+
+In this example, the error message is styled in red via the `.text-danger` CSS class, but there is no other indication that it represents an error. Users who cannot perceive colour differences may not recognise the message as an error.
+
+```html
+<p class="text-danger">The username field is required.</p>
+```
+
+</InvalidExample>
+
+<ValidExample title="Using colour combined with an icon and text to indicate an error">
+
+In this example, the error message includes an error icon and is explicitly prefixed with "Error:" in addition to being styled in red. This provides multiple cues to convey the error state.
+
+```html
+<p class="text-danger">
+    {{#pix}} i/invalid, core {{/pix}}
+    Error: The username field is required.
+</p>
+```
+
+</ValidExample>
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.4.3: Contrast (Minimum) (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)
+- [Understanding Success Criterion 1.4.1: Use of Color (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html)
+
+### Icons
+
+Icons in Moodle are typically used as part of an interactive element, such as a button or a link, to visually represent the action that will be performed when the element is activated. Icons within interactive elements are considered decorative content and should be hidden from assistive technologies. The accessible name should be placed within the button or link itself. This can be achieved using an `aria-label` attribute, or a visually hidden text label within the element itself and not the icon's markup.
+
+<ValidExample title="Icon link with visually hidden text in a Mustache template">
+
+In this example, leaving the `alt` parameter of the `pix` helper empty ensures that the icon is hidden from screen readers. The accessible name for the link is provided by the visually hidden text within the link.
+
+```html
+<a href="{{url}}">
+    {{#pix}} i/settings, core {{/pix}}
+    <span class="visually-hidden">
+        {{#str}} settings, core {{/str}}
+    </span>
+</a>
+```
+
+</ValidExample>
+
+<ValidExample title="Icon button with an aria-label attribute">
+
+```html
+<button type="button" class="btn btn-icon" aria-label="{{#str}} delete, core {{/str}}">
+    {{#pix}} t/delete, core {{/pix}}
+</button>
+```
+
+</ValidExample>
+
+<ValidExample title="A link that opens in a new window with a decorative icon">
+
+This example markup for a link that opens in a new window uses a decorative icon as an indication for sighted users that clicking on it will open the link in a new window. For screen reader users, the visually hidden text lets them know that it opens in a new window.
+
+```html
+<a href="{{url}}" target="_blank" rel="noopener">
+    {{linkname}}
+    {{#pix}} i/externallink, core {{/pix}}
+    <span class="visually-hidden">
+        {{#str}} opensinnewwindowbracketed, core {{/str}}
+    </span>
+</a>
+```
+
+</ValidExample>
+
+#### Informative icons
+
+In some cases, an icon may be used to provide additional information that is not already conveyed by the text. For example, an icon next to a form field label to indicate that the field is required. In this case, the icon should have an appropriate accessible name to convey its meaning.
+
+<ValidExample title="An informative icon with an aria-label attribute">
+
+This example passes a `required` language string to the Mustache `pix` helper for the icon's accessible name.
+
+```html
+<span>
+    {{#pix}}req, core, {{#str}} required, core {{/str}}{{/pix}}
+</span>
+```
+
+This renders an icon with an accessible name "Required" (or the equivalent in the user's language), and is visible to assistive technologies, such as screen readers.
+
+```html
+<i class="icon fa fa-circle-exclamation text-danger fa-fw " title="Required" role="img" aria-label="Required"></i>
+```
+
+</ValidExample>
+
+#### Target size
+
+It is important to ensure that an icon button's/link's target size (the clickable/touch area) is large enough and has sufficient spacing around it so that it can be easily activated by mouse, touch, and other pointer inputs.
+
+- The minimum target size for interactive elements is **24 by 24 CSS pixels**, as specified by [WCAG 2.2 Success Criterion 2.5.8: Target Size (Minimum) (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html).
+- For an enhanced experience, a target size of **44 by 44 CSS pixels** is recommended, as outlined in [WCAG 2.2 Success Criterion 2.5.5: Target Size (Enhanced) (Level AAA)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html).
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.1.1: Non-text Content (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html)
+- [Understanding Success Criterion 2.5.8: Target Size (Minimum) (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)
+
+### Keyboard support
+
+All interactive components must be fully operable through a keyboard-only interface. This ensures that users who cannot use a mouse, including those who rely on assistive technologies, can access and interact with all features.
+
+Some important things to keep in mind:
+
+- All interactive components must be focusable via the keyboard (that is, they are reachable using the `Tab` key).
+- It must be possible to move focus away from any component using only the keyboard. A component must never "trap" focus.
+  - For example, if a modal dialogue is open, the user should be able to close it (for example, by pressing `Escape` or activating a `Close` button) and return focus to the element that triggered the dialogue using only the keyboard.
+- The element that currently has focus must have a visible focus indicator.
+
+#### The `tabindex` attribute
+
+The `tabindex` attribute controls whether and how an element participates in the tab sequence. Only the following values should be used:
+
+- `tabindex="0"`: Adds the element to the natural tab order. Use this when a non-interactive element (such as a `<div>` or `<span>`) needs to be focusable. Interactive elements like `<button>`, `<a>`, and `<input>` are already focusable by default and do not need `tabindex="0"`.
+- `tabindex="-1"`: Removes the element from the tab order but allows it to be focused programmatically via JavaScript (using `element.focus()`). This is useful for managing focus within custom widgets.
+
+:::warning Avoid positive `tabindex` values
+
+Using `tabindex` values greater than `0` (for example, `tabindex="1"`, `tabindex="5"`) is an anti-pattern. Positive values override the natural tab order, making keyboard navigation unpredictable and confusing, especially for sighted keyboard users who expect focus to follow the visual layout.
+
+:::
+
+#### Visible focus indicators
+
+The element that currently has keyboard focus must have a clearly visible focus indicator. Moodle overrides the default browser focus styles on most elements to ensure sufficient visibility.
+
+However, when creating custom components, you may need to add additional CSS rules or use CSS utility classes for rendering accessible focus indicators, such as `.aalink` and `.aabtn` classes.
+
+#### Focus management in composite components
+
+In some cases, a single component contains many smaller focusable elements (for example, a toolbar with multiple buttons). To keep the tab sequence manageable, only the parent component should exist in the tab order. Focus among child elements should then be managed using arrow key navigation. This can be implemented using either the **roving `tabindex`** technique or the **`aria-activedescendant`** technique.
+
+For more information, see the W3C's guidance on [keyboard navigation inside components](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#keyboardnavigationinsidecomponents).
+
+#### Useful resources
+
+- [Understanding Success Criterion 2.1.1: Keyboard (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)
+- [Understanding Success Criterion 2.1.2: No Keyboard Trap (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html)
+- [Understanding Success Criterion 2.4.7: Focus Visible (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html)
+- [ARIA APG: Developing a Keyboard Interface](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)
+
+### Links
+
+Links should have descriptive, meaningful text that clearly conveys the purpose of the link without requiring the surrounding context. Avoid generic link text such as "click here", "read more", "more info", "learn more," or "here".
+
+<InvalidExample title="Non-descriptive link text">
+
+```html
+<p>
+    To learn about accessibility guidelines, <a href="{{url}}">click here</a>.
+</p>
+```
+
+</InvalidExample>
+
+<ValidExample title="Descriptive link text">
+
+```html
+<p>
+    Learn more about the <a href="{{url}}">Moodle accessibility coding guidelines</a>.
+</p>
+```
+
+</ValidExample>
+
+If multiple links on the same page share identical visible text but point to different destinations, add visually hidden text to make each link unique for screen reader users.
+
+<ValidExample title="Adding visually hidden text to differentiate links">
+
+```html
+<a href="{{url1}}">
+    {{#str}} view, core {{/str}}
+    <span class="visually-hidden">{{activityname1}}</span>
+</a>
+
+<a href="{{url2}}">
+    {{#str}} view, core {{/str}}
+    <span class="visually-hidden">{{activityname2}}</span>
+</a>
+```
+
+</ValidExample>
+
+#### Useful resources
+
+- [Understanding Success Criterion 2.4.4: Link Purpose (In Context) (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html)
+- [Technique G91: Providing link text that describes the purpose of a link](https://www.w3.org/WAI/WCAG22/Techniques/general/G91)
+
+### Forms
+
+Moodle forms created with the standard [Moodle Forms API (moodleform)](/docs/apis/subsystems/form) are designed to be accessible. However, any custom form, whether built in PHP, JavaScript, or a Mustache template, must also meet accessibility requirements.
+
+#### Form labels
+
+Every form field must have a corresponding label.
+
+There are several ways to label form elements:
+
+| Method                                   | Visibility                         | Recommended?                                          | Notes                                                                                                                                         |
+|:-----------------------------------------|:-----------------------------------|:------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------|
+| **Explicit `<label>`** (with `for`/`id`) | Visible                            | ✅ **Yes** (Best method)                               | Creates unambiguous association; clicking label focuses the input; broadest support across browsers and assistive technologies                |
+| **Implicit `<label>`** (wrapping input)  | Visible                            | ⚠️ Acceptable                                         | Support may vary across some assistive technology and browser combinations                                                                    |
+| **`aria-labelledby`**                    | Visible (references existing text) | ⚠️ Use when using a `<label>` element is not possible | Clicking the referenced text does NOT focus the input; useful for complex labeling situations                                                 |
+| **`aria-label`**                         | Invisible                          | ⚠️ Use sparingly                                      | Completely invisible to sighted users; useful only for screen reader users; appropriate when no visible label is needed (e.g., search fields) |
+| **`title` attribute**                    | Invisible (tooltip on hover)       | ⚠️ Generally not recommended                          | Tooltip display on keyboard focus may be inconsistent across browsers; intended for extra, non-essential information                          |
+| **`placeholder`**                        | Visible (until user types)         | ❌ **Highly discouraged**                              | Disappears when typing; default styling fails contrast; intended for hints, not labels                                                        |
+
+<ValidExample title="A text input with a visible label">
+
+```html
+<label for="username">{{#str}} username, core {{/str}}</label>
+<input type="text" id="username" name="username">
+```
+
+</ValidExample>
+
+#### Keyboard operability
+
+All form fields must be focusable and operable using only the keyboard. The form must be submittable without a mouse.
+
+#### Error identification and messaging
+
+When a form field contains an invalid entry:
+
+- The field should be marked with `aria-invalid="true"` to indicate its invalid state to assistive technologies.
+- The error message should be programmatically associated with the field using the `aria-describedby` attribute, so that screen readers announce the error when the field receives focus.
+- Error messages must be visible, clear, and descriptive, explaining what went wrong and how to fix it.
+
+<ValidExample title="A form field with an associated error message">
+
+```html
+<label for="email">{{#str}} email, core {{/str}}</label>
+<input type="email" id="email" name="email" aria-invalid="true" aria-describedby="email-error">
+<span id="email-error" class="text-danger">
+    {{#str}} invalidemail, core {{/str}}
+</span>
+```
+
+</ValidExample>
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.3.1: Info and Relationships (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)
+- [Understanding Success Criterion 3.3.1: Error Identification (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html)
+- [Understanding Success Criterion 3.3.2: Labels or Instructions (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html)
+
+### Decorative content
+
+Any component that is purely decorative — meaning it conveys no information or functionality that is not already provided by other elements on the page — can be hidden from assistive technologies.
+
+To hide decorative content from screen readers, use one of the following techniques:
+
+- Set `aria-hidden="true"` on the element.
+- Set `role="presentation"` (or `role="none"`) on the element.
+- For images, set an empty `alt` attribute (`alt=""`).
+
+<ValidExample title="Hiding a decorative image from assistive technologies">
+
+```html
+<img src="decorative-banner.png" alt="">
+```
+
+</ValidExample>
+
+:::note A layout table
+
+Before the days of responsive CSS, tables in Moodle were often used for page layout. When using tables for layout purposes, the table must be hidden from assistive technologies by adding `role="presentation"` to the `<table>` element.
+
+```html
+<table role="presentation">
+    <tr>
+        <td>{{definition}}</td>
+        <td>{{#str}}byname, core, {{authorname}} {{/str}}</td>
+    </tr>
+    <tr>
+        <td colspan="2">{{description}}</td>
+    </tr>
+</table>
+```
+
+**Note**: This is for example purposes only of the use of the `presentation` role. Please avoid using layout tables in your Moodle code. Layout tables are discouraged because they misuse semantic markup and can confuse users. Modern CSS layout techniques are the preferred approach.
+
+:::
+
+:::warning
+
+Only use these techniques on truly decorative content. Hiding meaningful content from assistive technologies will make the interface inaccessible to screen reader users.
+
+:::
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.1.1: Non-text Content (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html)
+- [WCAG definition of "pure decoration"](https://www.w3.org/TR/WCAG22/#dfn-pure-decoration)
+
+### Landmark regions
+
+The layout of each page should be divided into meaningful landmark regions, where each region has the correct landmark role and a unique label. Landmarks help screen reader users understand the structure of the page and quickly navigate to different sections.
+
+Common landmark roles include:
+
+| Role            | HTML element | Purpose                                         |
+|-----------------|--------------|-------------------------------------------------|
+| `banner`        | `<header>`   | The site-wide header area.                      |
+| `navigation`    | `<nav>`      | A group of navigation links.                    |
+| `main`          | `<main>`     | The primary content of the page.                |
+| `complementary` | `<aside>`    | Supporting content related to the main content. |
+| `contentinfo`   | `<footer>`   | The site-wide footer area.                      |
+| `search`        | `<search>`   | A search functionality.                         |
+
+When multiple landmarks of the same type exist on a page (for example, multiple `<nav>` elements), each must have a unique accessible label using `aria-label` or `aria-labelledby` to distinguish them.
+
+<ValidExample title="Labelling multiple navigation landmarks">
+
+```html
+<nav aria-label="{{#str}} sitemenubar, admin {{/str}}">
+    <!-- Site navigation links -->
+</nav>
+<nav aria-label="{{#str}} course, core {{/str}}">
+    <!-- Course navigation links -->
+</nav>
+```
+
+</ValidExample>
+
+:::note
+
+In Moodle, landmark regions are typically defined in the layout files of the theme. When building pages or components, ensure your content is placed within the appropriate landmark region.
+
+:::
+
+#### Useful resources
+
+- [ARIA Landmarks Example](https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/general-principles.html)
+- [Understanding Success Criterion 1.3.1: Info and Relationships (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)
+
+### Dynamic content
+
+When parts of a page are updated dynamically via JavaScript (for example, loading search results, updating a status message, or refreshing a list), it is important to ensure that these changes are communicated to assistive technology users.
+
+#### Live regions
+
+Use ARIA live regions to announce dynamic content changes to screen readers. A live region is defined by adding the `aria-live` attribute to a container element. When the content within that container changes, screen readers will announce the update.
+
+- `aria-live="polite"`: The update is announced when the user is idle. Use this for non-urgent updates.
+- `aria-live="assertive"`: The update is announced immediately, interrupting the user's current task. Use this sparingly, only for urgent information such as error messages or time-sensitive alerts.
+
+<ValidExample title="A status message container using a polite live region">
+
+```html
+<div aria-live="polite" id="status-message">
+    <!-- Status updates will be announced to screen readers when inserted here. -->
+</div>
+```
+
+</ValidExample>
+
+#### Busy states
+
+While content within a live region is being updated, set `aria-busy="true"` on the container to prevent screen readers from announcing intermediate or incomplete updates. Once the update is complete, remove the attribute or set it to `false`.
+
+<ValidExample title="Using aria-busy during a content update">
+
+```html
+<div aria-live="polite" aria-busy="true" id="results-container">
+    <!-- Content is loading... -->
+</div>
+```
+
+Once the content has finished loading:
+
+```html
+<div aria-live="polite" aria-busy="false" id="results-container">
+    <!-- Updated results are displayed here. -->
+</div>
+```
+
+</ValidExample>
+
+#### Focus management
+
+When dynamic updates significantly change the page content (for example, opening a modal dialog or navigating to new content), focus must be managed appropriately:
+
+- Move focus to the new content so the user is aware of the change.
+- When the new content is dismissed (for example, closing a modal), return focus to the element that triggered the change.
+
+#### Useful resources
+
+- [MDN: ARIA live regions](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions)
+- [Understanding Success Criterion 4.1.3: Status Messages (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)
+
+### Advanced UX widgets
+
+When building advanced interactive components that rely on JavaScript (such as custom dropdown menus, tabbed interfaces, tree views, or modal dialogs), a set of accessibility principles must be applied to ensure the feature provides equal functionality and information to all users.
+
+Each custom widget should:
+
+- Be fully operable using only the keyboard.
+- Map to a recognised widget pattern from the [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/patterns/).
+- Implement all keyboard interactions described in the relevant APG pattern.
+- Use the correct WAI-ARIA roles, states, and properties as specified for that pattern.
+
+<ValidExample title="A tab interface implementing the ARIA Tabs pattern">
+
+The following example demonstrates the expected ARIA roles, states, and properties for a tabbed interface following the [APG Tabs pattern](https://www.w3.org/WAI/ARIA/apg/patterns/tabs/).
+
+```html
+<div role="tablist" aria-label="{{#str}} coursetabs, core {{/str}}">
+    <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
+        {{#str}} overview, core {{/str}}
+    </button>
+    <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
+        {{#str}} grades, core {{/str}}
+    </button>
+</div>
+<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
+    <!-- Tab 1 content -->
+</div>
+<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
+    <!-- Tab 2 content -->
+</div>
+```
+
+In addition to the HTML structure, the following keyboard interactions must be implemented in JavaScript:
+
+- `Left Arrow` / `Right Arrow`: Move focus between tabs.
+- `Home` / `End`: Move focus to the first or last tab.
+- `Space` or `Enter`: Activate the focused tab.
+
+</ValidExample>
+
+#### Useful resources
+
+- [ARIA Authoring Practices Guide (APG) Patterns](https://www.w3.org/WAI/ARIA/apg/patterns/)
+- [ARIA APG: Developing a Keyboard Interface](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)
+
+### CSS and visual presentation
+
+CSS choices can have a direct impact on accessibility. The following areas require particular attention.
+
+#### Zoom and reflow
+
+Pages must remain usable when zoomed to 200% and 400%. Content should reflow into a single column at 400% zoom without horizontal scrolling or overlapping elements. Using Bootstrap's responsive grid system and relative units (such as `rem` and `em`) helps meet this requirement.
+
+#### CSS order versus DOM order
+
+If CSS is used to visually reorder elements differently from the DOM order (for example, using `order` in Flexbox or Grid), keyboard navigation will still follow the DOM order. This discrepancy can confuse keyboard users. Ensure that the visual order matches the DOM order, or provide custom keyboard navigation to account for the difference.
+
+#### Animations
+
+CSS animations and transitions can cause discomfort for users with vestibular disorders. From Moodle 4.3 onwards, CSS animations can be marked as non-essential by using the `optional-animation` SCSS mixin, which respects the user's `prefers-reduced-motion` system setting.
+
+#### Useful resources
+
+- [Understanding Success Criterion 1.4.4: Resize Text (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html)
+- [Understanding Success Criterion 1.4.10: Reflow (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html)
+- [Understanding Success Criterion 2.3.3: Animation from Interactions (Level AAA)](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html)
+
+## External resources
+
+<!-- cspell:ignore ATAG -->
+<!-- cspell:ignore Deque -->
+<!-- cspell:ignore UAAG -->
+
+- [W3C Accessibility Standards Overview](https://www.w3.org/WAI/standards-guidelines/)
+- [Accessible Rich Internet Applications (WAI-ARIA) 1.2](https://www.w3.org/TR/wai-aria-1.2/)
+- [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/)
+- [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
+- [Authoring Tool Accessibility Guidelines (ATAG) 2.0](https://www.w3.org/TR/ATAG20/)
+- [User Agent Accessibility Guidelines (UAAG) 2.0](https://www.w3.org/TR/UAAG20/)
+- [WebAIM: Web Accessibility In Mind](https://webaim.org/)
+- [Deque University Web Accessibility Checklist](https://dequeuniversity.com/checklists/web/)
diff --git a/general/development/policies/accessibility/index.md b/general/development/policies/accessibility/index.md
index dd58ee281..9d55beab5 100644
--- a/general/development/policies/accessibility/index.md
+++ b/general/development/policies/accessibility/index.md
@@ -129,163 +129,6 @@ One example of this is in the "Atto text editor" which includes an "Accessibilit
 
 All accessibility features of the "MathJax" content filter are enabled as standard, allowing screen readers to read math content directly.
 
-## Coding standards
-
-All components in Moodle _must_ be available for use by all users. Accessibility needs to be part of the design of every new feature in Moodle.
-
-For simple features with no requirement for an advanced user interface, simple adherence to standard HTML5 does provide an accessible feature. In this case, [advice from W3C](https://www.w3.org/TR/wai-aria-practices/#no_aria_better_bad_aria) is not to use ARIA at all than to use it incorrectly.
-
-Bootstrap and Bootstrap components [do not support accessibility by default](https://getbootstrap.com/docs/4.0/getting-started/accessibility/#color-contrast). All features implemented using Bootstrap components _must be_ checked and enhanced where necessary. Moodle has created an "aria" JavaScript module which improves accessibility features of some default Bootstrap features, including menus.
-
-### Colours
-
-All text that is presented needs to be displayed in a colour with sufficient contrast to its background colour so that the text is legible for all users. The foreground and background colours should meet the [WCAG requirement for contrast](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html), which varies depending on the size of the text. This can be tested with the [WebAIM Web Accessibility Evaluation Tool](https://wave.webaim.org/).
-
-It is worth noting that colour alone **must not** be used to imply meaning. An example of a failure for this would be to display error messages in "red" with no other information to convey that this is an error message.
-
-See [the W3C advice on the use of colour](https://www.w3.org/TR/WCAG22/#use-of-color) from WCAG 2.2 for more information.
-
-### Icons
-
-Icons (Images) can be displayed in a variety of ways, and the correct use of icons will depend on the context in which they are used.
-
-See [the WCAG 2.2 requirement for text alternatives](https://www.w3.org/TR/WCAG22/#text-alternatives) for more information.
-
-#### Solitary Icons
-
-Icons displayed on their own, as part of a link or as informative content must include accessible text to convey the meaning of the icon. For an image tag, this can be the `"alt"` attribute for the image tag. It can be valid to include both the `"alt"` attribute and the "title" attribute (shown when hovering with the mouse) so that all users can access the textual meaning of the icon.
-
-#### Icons and Text
-
-When an icon is displayed immediately before or after some text that also describes the meaning of the icon, it is redundant to repeat the same text twice. In this case, it is correct to hide the icon from screen readers by setting the "role" attribute to "presentation" or hiding it with the "aria-hidden" attribute set to "true".
-
-#### Multiple icons
-
-When multiple icons are displayed in a row as links, it is important that each icon is large enough and has sufficient space around it so the icon can be easily clicked with the mouse.
-
-The minimum valid size for a link target is 44 by 44 pixels.
-
-See [the WCAG 2.2 requirement for target size](https://www.w3.org/TR/WCAG22/#target-size) for more information.
-
-### Keyboard Support
-
-All components should be entirely operable through a keyboard-only interface.
-
-See [the WCAG 2.2 requirement for keyboard accessibility](https://www.w3.org/TR/WCAG22/#keyboard-accessible) for more information.
-
-Some important things to consider is that all components should be focusable with the keyboard (available in the tab sequence), and should allow the focus to be moved away using only the keyboard.
-
-The element that currently has focus should have a visual focus indicator. The W3C provide information on [ARIA focus management](https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_discernable_predictable) as part of it's ARIA best practices.
-
-In some cases, a single component can contain many smaller components. In order to not pollute the page tab sequence, the parent element can exist in the tab sequence once and should maintain focus within its smaller components with arrow key navigation (roving `tabindex` or active descendant). The W3C provide information [ARIA keyboard navigation inside components](https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_general_within) as part of it's ARIA best practices.
-
-### Forms
-
-Moodle forms created with the standard forms library are designed to be accessible. Any custom (for example JavaScript) form or custom form elements must also be accessible.
-
-- All form elements must have a label
-- The form must be able to be completed entirely with the keyboard
-- Invalid entries in the form fields should be indicated with the "aria-invalid" attribute set to "true"
-- Warning messages for invalid form fields should be associated with the invalid field using the "aria-describedby" attribute. See [the WCAG 2.2 success criteria for Error Identification](https://www.w3.org/TR/WCAG22/#error-identification) for further information on this.
-
-### Presentation Only
-
-Any component that contains no information or functionality that is not provided by other components on the page can be considered decorative only. Content that meets this description can be hidden from screen readers using a suitable technique (aria-hidden or presentation role).
-
-See [the WCAG 2.2 description of pure decoration](https://www.w3.org/TR/WCAG22/#dfn-pure-decoration) for more information.
-
-### Landmark regions
-
-The layout of each page of content should be separated into valid regions where each region has a unique label and the correct landmark role. This is typically done in the layout files of the theme.
-
-See [the ARIA best practice advice on landmarks](https://www.w3.org/TR/wai-aria-practices-1.1/#aria_landmark) for further information.
-
-### Page Titles
-
-All pages should have a unique title that describes the current page.
-
-Some tips for providing a meaningful page title:
-
-- The page title must be accurate and informative.
-- If the page causes a _change of context_ (for example, a search functionality), it should describe the result or change of context to the user.
-- It should be concise.
-- If possible, it should uniquely identify the page.
-- The most identifying information should come first.
-
-:::note change of context
-
-(not to be confused with Moodle's `\core\context` class and its implementations)
-
-According to the [WCAG 2.2 Understanding Docs](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html#dfn-changes-of-context), a change in context is a major change that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. It can include changes of user agent, viewport, focus, or content that changes the meaning of the web page.
-
-:::
-
-#### Example
-
-Consider that a student is on the submission page of an assignment activity called `Kinetics problem set 1` in the `Physics 101` course on the `Mount Orange School` Moodle site.
-
-Then a suitable page title for the page would be something like:
-
-<ValidExample>
-
-The most unique identifying information first represented by the activity name and its sub-page, then followed by broader identifiers such as the course name and the site name.
-
-`Kinetics problem set 1: Submit assignment | Physics 101 | Mount Orange School`
-
-</ValidExample>
-
-<ValidExample>
-
-The most unique identifying information first represented by the name of the sub-page, followed by the activity name that the page belongs to, then followed by broader identifiers such as the course name and the site name.
-
-`Submit assignment | Kinetics problem set 1 | Physics 101 | Mount Orange School`
-
-</ValidExample>
-
-#### Separating components of a page title
-
-When separating the components of the page tile, please use the `moodle_page::TITLE_SEPARATOR` constant.
-
-<ValidExample>
-
-```php
-[$course, $cm] = get_course_and_cm_from_cmid($id);
-// Activity name and its sub-page as the unique identifying information.
-$pagename = format_string($cm->name) . ': ' . get_string('view');
-// Course name.
-$coursename = format_string($course->fullname);
-// Set the page title, combining the activity page's name and course name using the title separator constant.
-$PAGE->set_title($pagename . moodle_page::TITLE_SEPARATOR . $coursename);
-```
-
-</ValidExample>
-
-#### Site name on the page title
-
-You should not add the name of the site when setting the page title using `$PAGE->set_title()`. The site name is automatically appended to the end of the page title in the correct format when using `$PAGE->set_title()`.
-
-:::info
-
-Administrators can use the `sitenameinititle` configuration setting to configure how this is shown in the title with possible options including:
-
-- the _full name_ of the site, for example, "Mount Orange School"
-- the _short name_ of the site, for example: "MOS"
-
-This is automatically handled by `$PAGE->set_title()`.
-:::
-
-#### Useful resources
-
-- [Understanding Success Criterion 2.4.2: Page Titled (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/page-titled)
-- [Technique G88: Providing descriptive titles for Web pages](https://www.w3.org/WAI/WCAG22/Techniques/general/G88)
-
-### Advanced UX Widgets
-
-When it is determined that an advanced interface is required (typically one that relies on JavaScript), a minimum set of principles need to be applied to make sure that the feature "provides equal functionality and information to all people". Each use case is different, but a minimum set of things to be checked are:
-
-- Does this component work entirely when accessed only via the keyboard?
-- Does this component map to any widget from the [ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices-1.1/) document and if so, does it implement all of the "Keyboard Interaction" and "WAI-ARIA Roles, States and Properties" listed for that widget?
-
 ## External Resources
 
 <!-- cspell:ignore ATAG -->
diff --git a/general/development/policies/codingstyle/index.md b/general/development/policies/codingstyle/index.md
index 04c0ba880..c7ac15d55 100644
--- a/general/development/policies/codingstyle/index.md
+++ b/general/development/policies/codingstyle/index.md
@@ -2022,4 +2022,4 @@ This document was drawn from the following sources:
 - [Coding](../../policies.md)
 - [CodeSniffer](../../policies/codingstyle/index.md)
 - [Code Checker plugin](https://moodle.org/plugins/local_codechecker)
-- [Accessibility coding guidelines](../accessibility/index.md#coding-standards)
+- [Accessibility coding guidelines](../accessibility/coding-guidelines.md)
diff --git a/general/development/process/peer-review/accessibility-checklist.md b/general/development/process/peer-review/accessibility-checklist.md
index 012438271..61abd8497 100644
--- a/general/development/process/peer-review/accessibility-checklist.md
+++ b/general/development/process/peer-review/accessibility-checklist.md
@@ -7,188 +7,300 @@ tags:
 sidebar_position: 4
 ---
 
-<!-- cspell:ignore ACTIVITYNAME, Deque -->
+<!-- cspell:ignore Deque -->
 
-This document proposes a checklist for accessibility reviews. Not all aspects of accessibility can be checked automatically, so this checklist is intended to guide reviewers when doing an accessibility check to a patch.
+This checklist helps reviewers perform an accessibility review of a patch. It is designed to be used alongside the [Accessibility coding guidelines](../../policies/accessibility/coding-guidelines.md) and the [Accessibility testing](../../policies/accessibility/testing.md) documentation.
 
-:::tip Identify the Nature of Changes
+:::tip Before you start: identify the nature of the changes
 
-1. **Are the changes on the backend only (webservices, database updates, events, hooks...)?**
-    - If yes, no accessibility review is needed.
-2. **Are there changes to the HTML, CSS, or JavaScript?**
-    - If yes, an accessibility review is necessary.
-3. **Do the changes only involve standard HTML elements without altering default browser behaviour?**
-    - If yes, a quick accessibility check is recommended, but a complete review may not be necessary.
+- **Backend only** (web services, database, events, hooks)? → No accessibility review needed.
+- **Changes to HTML, CSS, or JavaScript?** → Accessibility review is necessary. Use this checklist.
+- **Only standard HTML elements, no custom behaviour?** → A quick check is recommended, but a full review may not be needed.
 
 :::
 
-## Do an automated check
+## Quick-reference checklist
 
-Use the automatic accessibility checks via [Axe DevTools](https://www.deque.com/axe/devtools/) or [WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/)) to check for common issues. If there are any issues, the changes must be fixed before continuing.
+Use this as a quick scan. If any item fails or you are unsure, refer to the detailed section linked in each item.
 
-When possible, run an HTML validator and check for errors. For example, using [Nu HTML validator](https://validator.w3.org/nu/#textarea).
+### Automated
 
-## General Checks
+- [ ] Run [Axe DevTools](https://www.deque.com/axe/devtools/) or [WAVE](https://wave.webaim.org/) on the affected page(s). Fix any issues before continuing.
 
-Those are some quick checks you can do to ensure that the changes are accessible.
+### Structure and semantics
 
-### Use of tabindex
+- [ ] The page has a descriptive, unique **page title** with the most specific information first. ([Details](#page-title-and-headings))
+- [ ] There is exactly one **`h1`** heading and the heading hierarchy has no skipped levels. ([Details](#page-title-and-headings))
+- [ ] **Semantic HTML** elements are used (for example, `<button>` for buttons, `<nav>` for navigation). ([Details](#buttons))
 
-Tabindex > 0 is wrong. Using any tabindex value other than 0 (for focusable elements) or -1 (for non-focusable elements) is an anti-pattern. It can cause unexpected behaviour for keyboard users.
+### Keyboard and focus
 
-### Zoom test
+- [ ] All interactive elements are **reachable and operable** using only the keyboard. ([Details](#keyboard-operability))
+- [ ] No element uses `tabindex` greater than `0`. ([Details](#tabindex-values))
+- [ ] Every focused element has a clearly **visible focus indicator**. ([Details](#visible-focus-indicators))
+- [ ] No component **traps** keyboard focus. ([Details](#keyboard-operability))
 
-Test the page in 200% and 400% zoom. If the page is not usable or elements are overlapped, the changes must be fixed before continuing.
+### Visual presentation
 
-### Icons and images
+- [ ] Text and interactive elements meet **colour contrast** requirements. ([Details](#colour-and-contrast))
+- [ ] The page is **usable at 200% and 400% zoom** without overlap or horizontal scrolling. ([Details](#zoom-and-reflow))
+- [ ] **Colour is not the only** means of conveying information. ([Details](#colour-and-contrast))
+- [ ] CSS **visual order matches DOM order**, or custom keyboard handling compensates. ([Details](#css-order-versus-dom-order))
+- [ ] CSS animations respect `prefers-reduced-motion`. ([Details](#animations))
 
-If the patch uses icons or images, check if they has a proper `alt` text.
+### Content and alternatives
 
-Most icons should have an empty alt text for icons, particularly in interactive containers such as buttons or links. This will assist mouse users, particularly when hovering over the icon button/link, which will display a tooltip without hovering over the icon itself.
+- [ ] **Icons** inside buttons/links are hidden from assistive technologies; the accessible name is on the interactive element. ([Details](#icons-and-images))
+- [ ] Decorative images have `alt=""`. Informative images have meaningful alt text. ([Details](#icons-and-images))
+- [ ] **Link text** is descriptive — no "click here" or "read more". ([Details](#link-text))
+- [ ] **Buttons** without visible text have an accessible name (`aria-label` or visually hidden text). ([Details](#buttons))
 
-Decorative images should have an empty alt text (alt=""). In contrast, icons should have a descriptive alt text unless the alt text will be redundant with the surrounding elements.
+### Dynamic content and custom widgets
 
-### Buttons
+- [ ] Dynamic updates use **`aria-live`** regions so screen readers are notified. ([Details](#dynamic-content))
+- [ ] Custom widgets follow an [ARIA APG pattern](https://www.w3.org/WAI/ARIA/apg/patterns/) with correct roles, states, and keyboard interactions. ([Details](#custom-components))
 
-Buttons with no comprehensive text should have an `aria-label` or `aria-labelledby` attribute.
+### Forms
 
-However, for the buttons with only icons:
+- [ ] Every form field has a **`<label>`** (with matching `for`/`id`). ([Details](#forms))
+- [ ] Invalid fields use `aria-invalid` and error messages are linked via `aria-describedby`. ([Details](#forms))
 
-- The icon itself should have an empty `alt` attribute so assistive technologies will ignore it.
-- Extra text must added to the button using a `span` with the `sr-only` class. This text will be only visible for assistive technologies.
+---
 
-```html title="An example of a button with a descriptive sr-only text"
-<button type="button" class="btn btn-primary">
-  <img src="./pix/add_user.png" alt="">
-  <span class="sr-only">Add a new user</span>
-</button>
-```
+## Detailed guidance
 
-```html title="Another example using fontawesome icons"
-<button type="button" class="btn btn-primary">
-  <i class="icon fa-user-plus fa-fw " aria-hidden="true"></i>
-  <span class="sr-only">Add a new user</span>
-</button>
-```
+The sections below provide more context for each checklist item. For full explanations and code examples, refer to the [Accessibility coding guidelines](../../policies/accessibility/coding-guidelines.md).
 
-### Visible focus
+### Run an automated check
 
-All focusable elements should have a visible focus indicator that should be **different** from the default browser focus indicator. The focus indicator should be visible in all states (normal, hover, focus, active, disabled).
+Run an automated accessibility checker on the affected page(s) before starting the manual review:
 
-By default, Moodle overrides the focus indicator of most HTML elements to ensure accessibility. However, in some cases, it is necessary to add extra CSS rules to ensure the focus indicator is visible and has enough contrast. For those cases, Moodle provides some CSS helpers:
+- [Axe DevTools](https://www.deque.com/axe/devtools/) or [WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/)
+- An HTML validator such as the [Nu HTML validator](https://validator.w3.org/nu/#textarea)
 
-- Adding `aalink` to a link (or any other element acting as a link) will ensure the focus indicator is visible.
-- The CSS class `focus-visible` should be used to ensure the focus indicator is only visible when the element is focused using the keyboard.
-- In action menus or action menu sub panels, you can use `dropdown-item-outline` to ensure the focus indicator is visible on all the item and not only in the link element within.
+Any reported issues must be fixed before continuing with the manual review.
 
-### Page headers and title
+<details>
+<summary>Related documentation</summary>
 
-Each new page should have a specific and descriptive page title.
+- [Accessibility testing > Automated testing](../../policies/accessibility/testing.md#automated-testing) — browser extensions, built-in dev tools, and Behat accessibility tests
 
-:::info Example
+</details>
 
-Use "Settings in forum ACTIVITYNAME" instead of just "Activity settings".
+### Page title and headings
 
-:::
+- The page must have a descriptive, unique **page title**. The most specific information should come first (for example, "Submit assignment | Kinetics problem set 1 | Physics 101" rather than "Physics 101 | Activity").
+- There must be exactly **one `h1`** heading on the page. It should reflect the page title.
+- Headings must follow a **strict hierarchy** — no skipped levels (for example, `h2` followed directly by `h4`).
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > Page titles](../../policies/accessibility/coding-guidelines.md#page-titles)
+- [Coding guidelines > Headings](../../policies/accessibility/coding-guidelines.md#headings)
+
+</details>
+
+### Keyboard operability
+
+- **Tab** through every interactive element on the page. Ensure all buttons, links, form fields, and custom widgets are reachable.
+- **Activate** elements using `Enter` and/or `Space` as appropriate.
+- Confirm that focus is **never trapped** — you must always be able to leave a component (for example, pressing `Escape` to close a modal).
+- Complete typical user tasks using only the keyboard.
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > Keyboard support](../../policies/accessibility/coding-guidelines.md#keyboard-support)
+- [Accessibility testing > Keyboard navigability and operability tests](../../policies/accessibility/testing.md#keyboard-navigability-and-operability-tests)
+
+</details>
+
+### `tabindex` values
+
+- `tabindex` greater than `0` (for example, `tabindex="1"`) is **always wrong**. Only `0` and `-1` are acceptable.
+- If `tabindex="0"` is on a natively focusable element (`<button>`, `<a>`, `<input>`, etc.), it should be removed.
+- If `tabindex="0"` is on a non-interactive element, the element must also have an appropriate `role` (for example, `role="button"`).
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > The `tabindex` attribute](../../policies/accessibility/coding-guidelines.md#the-tabindex-attribute)
+
+</details>
+
+### Visible focus indicators
+
+- Every interactive element must show a **clearly visible focus indicator** when focused via keyboard.
+- Moodle overrides default browser focus styles. For custom components, use CSS utility classes such as `.aalink` and `.aabtn`, or add custom focus styles.
 
-Each page should have one, and only one, `H1` element. The test of the title should be as descriptive and specific as possible.
+<details>
+<summary>Related documentation</summary>
 
-Most assistive technologies can enumerate the page titles. To ensure the structure is clear, it is mandatory that all headers follow an strict heading hierarchy. For example, a `H2` element should not be followed by a `H4` element.
+- [Coding guidelines > Visible focus indicators](../../policies/accessibility/coding-guidelines.md#visible-focus-indicators)
+- [Accessibility testing > Keyboard navigability and operability tests](../../policies/accessibility/testing.md#keyboard-navigability-and-operability-tests)
 
-You can read more information about page titles in this [Accessibility policies page section](../../policies/accessibility/index.md#page-titles).
+</details>
 
-## Usability accessibility Checks
+### Colour and contrast
 
-Some more checks related to the changes:
+- Text and interactive elements must meet the required **contrast ratios** (4.5:1 for normal text, 3:1 for large text).
+- Colour must **not be the only** means of conveying information. If colour indicates a state (for example, red for errors), an additional cue such as text or an icon must also be present.
 
-### Do the UI uses colors or icons to indicate states or relevant information?
+<details>
+<summary>Related documentation</summary>
 
-If yes, it should provide an alternative textual alternative compatible for assistive technologies.
+- [Coding guidelines > Colours and contrast](../../policies/accessibility/coding-guidelines.md#colours-and-contrast)
+- [Accessibility testing > Colour contrast checkers](../../policies/accessibility/testing.md#colour-contrast-checkers)
 
-Usually, this means adding a text in the same element (for example, a badge text); or adding a `description`, `title` or `alt` attribute depending on the HTML element.
+</details>
 
-### Do all links in the page have a correct descriptive text?
+### Zoom and reflow
 
-The readable text of the link should be descriptive enough to understand the link purpose without the need to read the surrounding text. For example, avoid using "click here" or "more" as link text, instead use "Click here to read more about the accessibility guidelines".
+- Set the browser viewport to **1280px wide** and zoom to **200%**. Verify the page remains usable.
+- Set the viewport to **320px wide** (or 1280px at **400% zoom**). Verify content reflows into a single column without horizontal scrolling or overlapping elements.
 
-Another important aspect is to ensure the link text is unique. If there are two links with the same text, it can be confusing for screen reader users. In those cases, it is recommended to add some extra text to the link to make it unique, read below to know how to do it.
+<details>
+<summary>Related documentation</summary>
 
-In some cases, parts of the link text can be hidden using CSS so it is only readable by assistive technologies. To do so you can use several methods:
+- [Coding guidelines > Zoom and reflow](../../policies/accessibility/coding-guidelines.md#zoom-and-reflow)
+- [Accessibility testing > Reflow and resize text](../../policies/accessibility/testing.md#reflow-and-resize-text)
+
+</details>
+
+### CSS order versus DOM order
+
+If CSS visually reorders elements (for example, using Flexbox `order`), keyboard navigation will still follow the DOM order. This discrepancy confuses keyboard users. Ensure the visual order matches the DOM order, or provide custom keyboard navigation.
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > CSS order versus DOM order](../../policies/accessibility/coding-guidelines.md#css-order-versus-dom-order)
+
+</details>
+
+### Animations
+
+CSS animations should respect the user's `prefers-reduced-motion` setting. From Moodle 4.3 onwards, use the `optional-animation` SCSS mixin to mark animations as non-essential.
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > Animations](../../policies/accessibility/coding-guidelines.md#animations)
+
+</details>
+
+### Icons and images
+
+- **Icons inside buttons or links** (decorative): Hide the icon from assistive technologies (empty `alt`, or `aria-hidden="true"`). The accessible name should be on the button/link itself (`aria-label` or a `<span class="visually-hidden">`).
+- **Informative icons** (conveying meaning not provided by surrounding text): Give the icon an accessible name (for example, via the `alt` attribute).
+- **Decorative images**: Use `alt=""`.
+
+<details>
+<summary>Related documentation</summary>
+
+- [Coding guidelines > Icons](../../policies/accessibility/coding-guidelines.md#icons)
+- [Coding guidelines > Decorative content](../../policies/accessibility/coding-guidelines.md#decorative-content)
+
+</details>
+
+### Buttons
+
+- Buttons without visible descriptive text must have an accessible name.
+- For icon-only buttons, hide the icon from assistive technologies and provide the accessible name on the button using `aria-label` or a `<span class="visually-hidden">`.
+
+```html title="Icon button with visually hidden text"
+<button type="button" class="btn btn-primary">
+    <i class="icon fa-user-plus fa-fw" aria-hidden="true"></i>
+    <span class="visually-hidden">Add a new user</span>
+</button>
+```
 
-- Add a span with `sr-only` class to the element. The `sr-only` class is only visible for assistive technologies.
-- If parts of the link meaning is represented by an icon, add an `alt` text to the icon so it will be read with the rest of the link text.
+<details>
+<summary>Related documentation</summary>
 
-### Is CSS ordering elements different than DOM?
+- [Coding guidelines > Semantic HTML](../../policies/accessibility/coding-guidelines.md#semantic-html)
 
-If yes, it can cause unexpected behaviour for keyboard users. The patch should provide an ad-hoc keyboard navigation using an AMD module.
+</details>
 
-### When the new elements are focused, do the down and tab keys still work in the default way?
+### Link text
 
-If not means the code has a pointer cancellation. In this case the patch should implement a proper custom component pattern. See [Review Custom Components](#review-custom-components) for more information.
+- Link text must clearly describe the link's purpose. Avoid "click here", "read more", "here", or "more info".
+- If multiple links share the same visible text but go to different destinations, add visually hidden text to make each link unique.
 
-### Does Any of the elements have a CSS animation?
+<details>
+<summary>Related documentation</summary>
 
-If yes, it is recommended the patch should provide a way to stop the animation.
+- [Coding guidelines > Links](../../policies/accessibility/coding-guidelines.md#links)
 
-From Moodle 4.3 onwards, any CSS animation could be marked as optional by importing the `optional-animation` SCSS mixin.
+</details>
 
-### Does the patch adds tabindex="0" to any element?
+### Custom components
 
-If yes, there are a few things you need to check:
+When the patch introduces custom interactive widgets (for example, tabs, modals, dropdown menus), check that:
 
-- If the element is a link, a button or a form control, then the `tabindex` should be removed.
-- Otherwise, the element should also provide a proper `role` attribute to indicate the assistive technology how to interact with it. For example, if the element acts a a button it should have a `role="button"` attribute.
+- The widget follows a recognised [ARIA APG pattern](https://www.w3.org/WAI/ARIA/apg/patterns/).
+- All keyboard interactions from the APG pattern are implemented.
+- The correct ARIA roles, states, and properties are used and updated via JavaScript.
 
-### Does the page use visuals like empty space, indentations or colors to represent structure or precedence?
+<details>
+<summary>Related documentation</summary>
 
-If yes, then this structure should also be represented in the HTML (nested lists, or by adding [`role="list"`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/List_role)) or using explanatory
-textual elements.
+- [Coding guidelines > Advanced UX widgets](../../policies/accessibility/coding-guidelines.md#advanced-ux-widgets)
+- [Accessibility testing > Keyboard navigability and operability tests](../../policies/accessibility/testing.md#keyboard-navigability-and-operability-tests)
+- [Accessibility testing > Screen reader testing](../../policies/accessibility/testing.md#screen-reader-testing)
 
-### Does the page have elements that only appear on hover or focus?
+</details>
 
-If yes, then the patch should provide a way to make those elements visible for keyboard users.
+### Dynamic content
 
-Disappearing elements should be avoided when possible. However, in some pages decluttering the UI is necessary. In those cases, Moodle provides some CSS helpers to ensure the element will still be visible for keyboard users:
+If parts of the page are updated dynamically via JavaScript, check that:
 
-1. Add a `focus-control` class to the parent container. It is important the parent container has some visible focus element (for example, a link or a button), otherwise it cannot be browsable using the keyboard.
-2. Add `v-parent-focus` to all elements that should appear only when the parent container has a focus within.
+- The container uses **`aria-live`** (`"polite"` for non-urgent updates, `"assertive"` for urgent ones) so screen readers announce changes.
+- While loading, the container has **`aria-busy="true"`** (removed once complete).
+- **Focus is managed** — if content is inserted, focus moves to it; if content is removed, focus returns to the triggering element.
 
-## Review Custom Components
+<details>
+<summary>Related documentation</summary>
 
-Custom JavaScript keyboard controls should be implemented when creating custom interactive elements using non-interactive HTML elements, or when dealing with complex widgets like tabs, modals, or custom select menus. However, these custom controls should mimic the standard browser navigation as closely as possible.
+- [Coding guidelines > Dynamic content](../../policies/accessibility/coding-guidelines.md#dynamic-content)
+- [Accessibility testing > Screen reader testing](../../policies/accessibility/testing.md#screen-reader-testing)
 
-Conduct an in-depth review focusing on proper usage of ARIA roles and attributes, keyboard accessibility, and interaction feedback. Any custom component should fit one of the [patterns](https://www.w3.org/WAI/ARIA/apg/patterns/) defined by the ARIA Authoring Practices Guide.
+</details>
 
-### Review Dynamic Content
+### Forms
 
-If the patch partially update the page content using JavaScript, check:
+Unless the patch uses custom form fields, Moodle forms (moodleforms) are already accessible. For **custom forms**, check:
 
-- If the changes are announced to screen readers. This can be done by using the [`aria-live`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live) attribute.
-- While the element is updating, the element should have a [`aria-busy="true"`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-busy) attribute to prevent the user from interacting with the element until the update is finished. Once the update is finished, the attribute should be removed.
-- The focus is managed correctly. For example, if the focus is moved to a new element, the focus should be moved back to the original element when the new content is removed.
+- Every field has a **`<label>`** with a `for` attribute matching the field's `id`.
+- The form is **fully operable by keyboard**.
+- Invalid fields are marked with **`aria-invalid="true"`** and error messages are linked via **`aria-describedby`**.
+- Error messages are **visible, clear, and descriptive**.
 
-You can read more about dynamic content in the [ARIA live regions reference documentation](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions).
+When a patch introduces ad-hoc forms, ensure they follow the [forms guidelines](../../policies/designing-usable-forms.md).
 
-## Forms checks
+<details>
+<summary>Related documentation</summary>
 
-Unless custom forms fields are used, all moodleforms are considered accessible.
+- [Coding guidelines > Forms](../../policies/accessibility/coding-guidelines.md#forms)
 
-When a patch introduce adhoc forms, it is important they follow the [forms guidelines](../../policies/designing-usable-forms.md).
+</details>
 
-### Checks for custom forms (not using moodleforms)
+### Other visual checks
 
-- All form fields should have an `id` attribute and a `label` elements with the same value in the `for` attribute. The label can be visible or hidden using CSS, but it should be present in the HTML.
-- The form should be usable with the keyboard only. This means that all form fields should be focusable and the form should be submittable using the keyboard only.
-- If the form have data validation:
-  - The error messages should be visible and announced.
-  - The messages should be clear and descriptive.
+- **Visual structure**: If empty space, indentation, or colour is used to convey hierarchy, the same structure must be represented in the HTML (for example, nested lists, headings, or [`role="list"`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/List_role)).
+- **Hover/focus-only elements**: If elements only appear on hover, ensure keyboard users can also reveal them. Moodle provides the `focus-control` (on the parent) and `v-parent-focus` (on the child) CSS classes for this.
 
-## Provide Feedback
+## Provide feedback
 
-If any accessibility issues are found, provide constructive feedback. Explain the issue, why it's a problem, and how it can be fixed. If possible, provide references to the relevant WCAG guidelines.
+If accessibility issues are found, explain:
 
-Remember, the goal of accessibility is to ensure that everyone, regardless of their abilities or disabilities, can use and interact with web content. This workflow is designed to help developers ensure that their changes meet this goal.
+1. **What** the issue is.
+2. **Why** it is a problem (who is affected).
+3. **How** to fix it (with a reference to the relevant [WCAG success criterion](https://www.w3.org/TR/WCAG22/) or [coding guideline](../../policies/accessibility/coding-guidelines.md) section where possible).
 
-## More advanced checks
+## Further reading
 
-Once you control all the points in this checklist, you can read the [Deque University Web Accessibility Checklist](https://dequeuniversity.com/checklists/web/) to learn more about accessibility in Moodle.
+- [Accessibility coding guidelines](../../policies/accessibility/coding-guidelines.md) — detailed guidance with code examples
+- [Accessibility testing](../../policies/accessibility/testing.md) — automated and manual testing techniques
+- [Deque University Web Accessibility Checklist](https://dequeuniversity.com/checklists/web/) — a more comprehensive general-purpose checklist