|
| 1 | +--- |
| 2 | +title: Accessibility testing |
| 3 | +tags: |
| 4 | + - Accessibility |
| 5 | + - Accessibility testing |
| 6 | + - Automated testing |
| 7 | + - Behat |
| 8 | +keywords: |
| 9 | + - accessibility |
| 10 | + - accessibility testing |
| 11 | + - behat |
| 12 | +--- |
| 13 | + |
| 14 | +You should perform accessibility testing when introducing features or bug fixes involving user interface (UI) changes. Combining automated and manual accessibility testing is essential to ensure accessibility of code contributions to Moodle. |
| 15 | + |
| 16 | +## Automated testing |
| 17 | + |
| 18 | +### Browser extensions |
| 19 | + |
| 20 | +The easiest way to check for common accessibility issues on the feature that you're working on is to use automated accessibility testing tools. There are browser extensions that can perform accessibility tests on a webpage, such as: |
| 21 | + |
| 22 | +- [axe DevTools](https://www.deque.com/axe/devtools/extension) |
| 23 | +- [WAVE Web Accessibility Evaluation Tools](https://wave.webaim.org/) |
| 24 | + |
| 25 | +### Built-in browser development tools |
| 26 | + |
| 27 | +In addition to browser extensions, web browsers such as Chrome and Edge include built-in tools to check webpages for accessibility issues. |
| 28 | + |
| 29 | +- Google Chrome's [Lighthouse](https://developer.chrome.com/docs/lighthouse/) can audit webpages for performance, accessibility, progressive web apps, SEO, and more. |
| 30 | +- Microsoft Edge's [Issues tool](https://learn.microsoft.com/en-us/microsoft-edge/devtools/issues/) also provides similar functionality to Lighthouse. |
| 31 | + |
| 32 | +<!-- cspell:ignore Deque --> |
| 33 | +### Accessibility tests using Behat |
| 34 | + |
| 35 | +Moodle LMS uses Deque's open-source automated accessibility testing engine, [axe-core](https://github.com/dequelabs/axe-core), which allows us to run automated accessibility testing using Behat. To write accessibility tests on Behat, it is essential to add the `@accessibility` and `@javascript` tags to the test scenario. |
| 36 | + |
| 37 | +#### Whole-page standard test |
| 38 | + |
| 39 | +A standard Behat step to test the accessibility of the page that you're working on is: |
| 40 | + |
| 41 | +```gherkin |
| 42 | +And the page should meet accessibility standards |
| 43 | +``` |
| 44 | + |
| 45 | +This step performs a whole-page test against WCAG 2.0, 2.1, and 2.2 Level A and Level AA standards. |
| 46 | + |
| 47 | +#### With best-practice extra tests |
| 48 | + |
| 49 | +It is also possible to specify extra tests on the accessibility Behat step. We highly recommend using the `best-practice` extra tests, which also assess the page for accessibility best practices, such as verifying proper heading levels. |
| 50 | + |
| 51 | +```gherkin |
| 52 | +And the page should meet accessibility standards with "best-practice" extra tests |
| 53 | +``` |
| 54 | + |
| 55 | +#### Testing specific areas of the page |
| 56 | + |
| 57 | +If you are introducing a UI change to a specific part of the page, you can also test only that part. In this case, you can specify the part of the page using the: |
| 58 | + |
| 59 | +```gherkin |
| 60 | +And the "<element>" "<selector>" should meet accessibility standards |
| 61 | +``` |
| 62 | + |
| 63 | +#### Testing against specific rules |
| 64 | + |
| 65 | +You may also test against specific [axe-core rules](https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md) by listing them as comma-separated values, like below: |
| 66 | + |
| 67 | +```gherkin |
| 68 | +And the page should meet "wcag131, wcag141, wcag412" accessibility standards |
| 69 | +``` |
| 70 | + |
| 71 | +#### An example of accessibility testing on Behat |
| 72 | + |
| 73 | +<ValidExample title="Accessibility tests on the login page"> |
| 74 | + |
| 75 | +```gherkin |
| 76 | +@javascript @accessibility |
| 77 | +Scenario: The login page must meet accessibility standards |
| 78 | + Given the following config values are set as admin: |
| 79 | + | custommenuitems | -This is a custom item\|/customurl/ | |
| 80 | + When I am on site homepage |
| 81 | + Then the page should meet accessibility standards with "best-practice" extra tests |
| 82 | + And I follow "Log in" |
| 83 | + And the page should meet accessibility standards with "best-practice" extra tests |
| 84 | +``` |
| 85 | + |
| 86 | +</ValidExample> |
| 87 | + |
| 88 | +## Manual testing |
| 89 | + |
| 90 | +It may be tempting to think that automated accessibility checks guarantee the page's accessibility. However, this is not the case. Automated accessibility tests typically cover about 30% to 50% of accessibility issues on a web page. |
| 91 | + |
| 92 | +Combining manual accessibility testing with automated testing is essential to ensure the accessibility of the features that we implement in Moodle. Below are some examples of how we can manually test a page for accessibility issues. |
| 93 | + |
| 94 | +### Keyboard navigability and operability tests |
| 95 | + |
| 96 | +Ensuring that interactive elements, such as buttons, links, form elements, and custom JavaScript widgets, can be navigated to and operated with the keyboard is a strong indicator of accessibility. It helps users perform their tasks in Moodle without barriers. |
| 97 | + |
| 98 | +Keyboard accessibility is crucial, particularly for users who rely on assistive technologies and primarily interact with content via the keyboard rather than a mouse. This includes: |
| 99 | + |
| 100 | +- **Users who are blind or have low vision:** They use screen readers, which depend entirely on keyboard navigation to explore content. |
| 101 | +- **Users with motor disabilities:** They are unable to use a mouse effectively and rely on keyboards, switch devices, or other input methods that mimic keyboard commands. |
| 102 | +- **Users of voice recognition software:** This software frequently emulates standard keyboard commands for interaction. |
| 103 | + |
| 104 | +Some practical tips to test for keyboard navigability and operability: |
| 105 | + |
| 106 | +- **Navigate the page using the keyboard only** |
| 107 | + - Press `Tab` or `Shift-Tab` to navigate between interactive elements, such as buttons, links, form elements, and custom widgets. |
| 108 | + - Pressing `Enter` or `Space` should activate buttons or other controls. Pressing Enter should activate links. |
| 109 | + - Ensure that you can perform tasks on custom JavaScript widgets, such as menus, autocomplete elements, etc., using the keyboard only. |
| 110 | + - Ensure you can complete typical user tasks on the page using only the keyboard. |
| 111 | +- **Check focus visibility and appearance** |
| 112 | + - Ensure that each interactive element receiving keyboard focus has a visible focus indicator (outline or highlight) |
| 113 | + - The interactive element should use the theme's default focus indicator rather than the browser's default focus indicator to maintain a consistent look with other interactive elements on the page. |
| 114 | + - Ensure that other elements do not obscure or hide the focused element and the focus indicator. |
| 115 | +- **Check for logical tab order** |
| 116 | + - Ensure that the tab order follows the visual and logical reading order. |
| 117 | +- **Check for focus traps** |
| 118 | + - Some custom widgets trap focus when keyboard navigation is used, such as menus and modal dialogues. It is essential to verify that users don't get trapped within the widget's container and that there are options to move the focus outside the widget and onto the rest of the page. For example, modal dialogues in Moodle can be closed either by pressing the Escape key or the dialogue's close button. |
| 119 | + |
| 120 | +### Screen reader testing |
| 121 | + |
| 122 | +Screen readers are assistive technologies that help people who are blind or have low vision access digital content. They convert the page's content into speech or braille output, allowing the user to interact with the page using a keyboard or touch gestures. Screen readers rely on well-structured, semantic HTML to help users navigate and interact with the page effectively. |
| 123 | + |
| 124 | +The table below lists some popular screen readers. Browsers in **bold** font indicate the best compatibility with the given screen reader compared to other compatible browsers. |
| 125 | + |
| 126 | +<!-- cspell:ignore ChromeVox --> |
| 127 | + |
| 128 | +| Screen reader | Operating system | Browser compatibility | Used in testing on | |
| 129 | +|---------------------------------------------------------------------------------------------------------------------------------|------------------|-----------------------------------|--------------------| |
| 130 | +| [NVDA](https://www.nvaccess.org/) | Windows | Chrome, Edge, Firefox | LMS | |
| 131 | +| [JAWS](https://www.freedomscientific.com/) | Windows | Chrome, Edge, Firefox | LMS | |
| 132 | +| [Narrator](https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1) | Windows | **Edge**, Chrome, Firefox | | |
| 133 | +| [VoiceOver](https://support.apple.com/guide/voiceover) | macOS, iOS | **Safari**, Chrome, Edge, Firefox | LMS, App | |
| 134 | +| [Talkback](https://support.google.com/accessibility/android/topic/3529932?hl=en&ref_topic=9078845&sjid=13502500306212449126-AP) | Android | **Chrome**, Firefox | LMS, App | |
| 135 | +| [ChromeVox](https://support.google.com/chromebook/answer/7031755) | Chrome OS | **Chrome**, Firefox | | |
| 136 | + |
| 137 | +Some practical tips when testing your Moodle plugin or contribution with screen readers: |
| 138 | + |
| 139 | +- Keyboard accessibility is essential when using a screen reader. Aside from ensuring the page can be navigated with only a keyboard, ensure the accessible names of elements, such as buttons, links, form controls, and other interactive elements, are meaningful and appropriately announced. |
| 140 | +- Ensure you can complete typical user tasks on the page using only the keyboard and a screen reader, and that screen readers provide clear information and feedback. |
| 141 | +- Test custom JavaScript widgets with at least two screen readers to ensure dynamic content is announced consistently across them. |
| 142 | +- Explore screen reader commands. Screen readers typically include keyboard shortcuts that let users navigate page landmarks, headings, links, and form elements. Use these to get an overview of the page structure and ensure the page elements have meaningful accessible names. For a complete list of screen reader commands, check out the following: |
| 143 | + - [JAWS hotkeys](https://www.freedomscientific.com/training/jaws/hotkeys/) |
| 144 | + - [NVDA commands quick reference](https://download.nvaccess.org/documentation/keyCommands.html) |
| 145 | + - [VoiceOver (MacOS) command charts](https://help.apple.com/voiceover/command-charts/) |
| 146 | + |
| 147 | +:::info Notes about screen reader testing |
| 148 | + |
| 149 | +Moodle HQ directly tests with a number of different screen readers when assessing: |
| 150 | + |
| 151 | +- Bug fixes to accessibility issues that require screen reader testing |
| 152 | +- New pages or user interface components that are being developed for new product features or improvements |
| 153 | + |
| 154 | +::: |
| 155 | + |
| 156 | +### Reflow and resize text |
| 157 | + |
| 158 | +As Moodle can be used on a variety of devices with different screen sizes and orientations, it is essential to ensure that the user interface is responsive and usable when displayed on mobile devices or when zoomed in. |
| 159 | + |
| 160 | +You can perform the following tests on the page: |
| 161 | + |
| 162 | +- Set the browser's viewport width to 1280 CSS pixels and increase the page zoom to 200%. Ensure the text resizes without losing content or functionality. This aligns with the [WCAG Level AA Success Criterion 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). |
| 163 | +- Resize the browser viewport to a width of 320 CSS pixels. Alternatively, set the viewport's width to 1280 CSS pixels and increase the page zoom to 400%. Ensure that the user interface elements reflow without causing any horizontal viewport overflow. This aligns with the [WCAG Level AA Success Criterion 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html). |
| 164 | + |
| 165 | +## Other tools for accessible design, development, and testing |
| 166 | + |
| 167 | +### The accessibility tree |
| 168 | + |
| 169 | +The accessibility tree is a representation of a webpage's semantic structure based on the Document Object Model (DOM). It contains accessibility-related information of the page's elements, such as role, state, and value. |
| 170 | + |
| 171 | +We can think of the accessibility tree as a filtered, semantic version of the DOM, containing only information relevant to assistive technologies, which means that hidden elements, such as those with `display: none;` or those with the `aria-hidden="true"` attribute, will not be rendered in the accessibility tree. |
| 172 | + |
| 173 | +Ensuring that your Moodle plugin, or the UI changes you contribute to the core Moodle code, is built using semantic HTML or uses the appropriate ARIA attributes ensures an accurate accessibility tree that is useful for assistive technologies. |
| 174 | + |
| 175 | +Below are several resources about how you can use the accessibility tree in various browsers: |
| 176 | + |
| 177 | +- Chrome and Chromium-based browsers: [Full accessibility tree in Chrome DevTools](https://developer.chrome.com/blog/full-accessibility-tree/) |
| 178 | +- Firefox: [Accessibility inspector](https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/index.html) |
| 179 | + |
| 180 | +<!-- cspell:ignore siegemedia --> |
| 181 | +### Colour contrast checkers |
| 182 | + |
| 183 | +To meet colour contrast requirements, user interface elements must meet the following WCAG success criteria: |
| 184 | + |
| 185 | +- [Success Criterion 1.4.3 Contrast (Minimum) (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) |
| 186 | + - Minimum contrast ratio of **4.5:1** for normal text (small text). |
| 187 | + - Larger text (typically 18pt or 14pt bold and above) requires a minimum contrast ratio of **3:1**. |
| 188 | +- [Success Criterion 1.4.11 Non-text Contrast (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html) |
| 189 | + - Minimum contrast ratio of **3:1** for graphical objects and user interface components. |
| 190 | + |
| 191 | +Meeting these criteria helps users with low vision or colour blindness distinguish text and interface elements. |
| 192 | + |
| 193 | +Automated testing tools and browser developer tools, such as Chrome's element inspector, can help check the colour contrast of text against its background. Colour contrast checker tools are also helpful for developers and designers to ensure colour contrast requirements are met. |
| 194 | + |
| 195 | +There are many colour contrast checker tools available online. Feel free to check out some of the tools: |
| 196 | + |
| 197 | +- [Deque Color Contrast Analyzer](https://dequeuniversity.com/color-contrast) |
| 198 | +- [Contrast Ratio by siegemedia](https://www.siegemedia.com/contrast-ratio) |
| 199 | +- [Colorable](https://colorable.jxnblk.com/) |
0 commit comments