moodle-accessibility

Moodle Accessibility (WCAG 2.1 AA)

Overview

Moodle targets WCAG 2.1 AA. UI in plugins must follow same standard for inclusion. Boost theme + Bootstrap 5 + Moodle's component library do most of the heavy lifting — your job is to use them correctly.

When to Use

• Building any UI (Mustache template, modal, custom form element)
• Reviewing PR for accessibility regression
• Submission to moodle.org plugin directory (a11y is reviewed)
• Responding to a user-reported a11y bug

Top rules

1. Use semantic HTML: <button> for actions, <a> for navigation, <h1>–<h6> in order
2. Every interactive element keyboard-reachable with visible :focus
3. Every image has alt; decorative images: alt=""
4. Color contrast ≥ 4.5:1 (text), 3:1 (UI components)
5. Forms: <label for> linked to every input
6. Don't use color alone to convey meaning
7. Modals trap focus, restore on close

Semantic Mustache

{{! BAD }}
<div class="btn" onclick="...">Save</div>

{{! GOOD }}
<button type="submit" class="btn btn-primary">{{#str}}save, core{{/str}}</button>

Headings:

<h2 id="ann-heading">{{#str}}announcements, local_example{{/str}}</h2>
<section aria-labelledby="ann-heading">...</section>

Skip levels = WCAG fail. <h2> then <h4> is wrong.

Forms — formslib

MoodleQuickForm outputs <label for> automatically. Don't bypass:

$mform->addElement('text', 'name', get_string('name', 'local_example'));
$mform->setType('name', PARAM_TEXT);
$mform->addRule('name', null, 'required', null, 'client');

// Help button — adds aria-described relationship
$mform->addHelpButton('name', 'name', 'local_example');

For required fields, addRule('required') adds aria-required="true".

Buttons / links

Element	Use for
<button type="submit">	Form submit
<button type="button">	JS action
<a href="...">	Navigation to a URL

Never <a href="#" onclick> — use <button>. Never <div role="button"> unless you also handle keyboard (Enter + Space) and focus.