Accessibility: Difference between revisions
Jun Pataleta (talk | contribs) |
Jun Pataleta (talk | contribs) |
||
Line 5: | Line 5: | ||
On the 10th of November, Moodle has been given the WCAG 2.1 Level AA accreditation for the pages that have been evaluated in this audit. | On the 10th of November, Moodle has been given the WCAG 2.1 Level AA accreditation for the pages that have been evaluated in this audit. | ||
[[File: | [[File:MoodleWCAG21AA20201110Accreditation.svg|center|thumb|link=https://www.webkeyit.com/accessibility-services/accessibility-accreditations/moodle/|WCAG 2.1 Level AA accreditation badge for Moodle issued on 10 November 2020]] | ||
== Moodle Accessibility Collaboration Group == | == Moodle Accessibility Collaboration Group == |
Revision as of 06:04, 11 November 2020
Moodle is designed to provide equal functionality and information to all people. This means that there should be no barriers for people regardless of disabilities, assistive technologies that are used, different screen sizes and different input devices (e.g. mouse, keyboard and touchscreen).
Accessibility focus
As part of our ongoing commitment to provide an accessible platform and to continuously improve our compliance with WCAG 2.1 Level AA, Moodle has been working with an external auditor to review the platform since January 2020. Key pages within Moodle were audited with automated tools and user journey testing. The WCAG 2.1 Level A and Level AA issues raised from this audit have all been addressed in Moodle 3.10 and Moodle 3.9.3 (both released on November 9th 2020). A large number of these accessibility improvements have also been back-ported to Moodle 3.7.5+ and Moodle 3.8.2+, where possible.
On the 10th of November, Moodle has been given the WCAG 2.1 Level AA accreditation for the pages that have been evaluated in this audit.
Moodle Accessibility Collaboration Group
To improve the accessibility and usability of Moodle, we have established this collaboration group to work together with Moodle developers, accessibility experts, administrators, IT professionals, and other interested entities and individuals. We welcome anyone who is interested in improving the accessibility of Moodle to join this group. You don’t need to be a technical guru or accessibility expert to join; however, it is expected that you are familiar with the basics of accessibility and are willing to dedicate a few hours each month to this collaboration effort.
Visit http://collaborate.athenpro.org/group/moodle to join the email list.
To review past meetings or to see upcoming meetings visit http://collaborate.athenpro.org/group/moodle/teleconferences/
Authoring features
Moodle can be used by users to author content for other users. In some cases, accessibility features have been added to the authoring tools so that the content that is produced is as accessible as possible. An example is the “Atto text editor” which includes an “Accessibility checker” and an “Accessibility helper” which provide additional information for content authors on the accessibility of their content (like checks for sufficient contrast). The equations produced by the MathJax content filter have full accessibility enabled so they can be passed directly to the screen reader as maths content.
Coding standards
All components in Moodle need to be available to 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, it is better to use no ARIA than it would be to use it incorrectly (W3C no Aria).
Bootstrap and Bootstrap components do not support accessibility by default and all features implemented with Bootstrap need to be checked and enhanced where necessary. The Boost theme contains an “aria” javascript module that does add accessibility to some default Bootstrap features (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, which varies depending on the size of the text. This can be tested with the WebAIM Web Accessibility Evaluation Tool.
Additionally, colour alone cannot 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.
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.
WCAG requirement for text alternatives
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.
WCAG requirement for target size
Keyboard Support
All components should be entirely operable through a keyboard-only interface.
WCAG requirement for keyboard accessibility
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. ARIA focus management.
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). ARIA keyboard navigation inside components.
Forms
Moodle forms created with the standard forms library are designed to be accessible. Any custom (e.g. 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.
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).
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.
Page Titles
All pages should have a unique title that describes the current page.
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 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
- W3C Accessibility Standards Overview
- Accessible Rich Internet Applications (WAI-ARIA) 1.1
- WAI-ARIA Authoring Practices 1.1
- Web Content Accessibility Guidelines (WCAG) 2.1
- Authoring Tool Accessibility Guidelines (ATAG) 2.0
- User Agent Accessibility Guidelines (UAAG) 2.0
Accessibility Tools
Moodle officially supports the following screen reader/browser configurations:
- Microsoft Edge, Jaws 15+ (Latest version recommended)
- Mozilla Firefox, NVDA 2014.1+ (Latest version recommended)
Screen readers:
- NVDA Screen Reader (Windows)
- JAWS Screen Reader (Windows)
- Chromevox Screen Reader (Linux, Chrome OS, Windows, Mac OS X)
- Orca Screen Reader (Linux)
Accessibility tools:
- WebAIM Web Accessibility Evaluation Tool (Chrome, Firefox)
- Chrome Accessibility Dev Tools (Chrome)
- W3C Accessibility Tool Listing
International Legislation
USA
UK
- Equality Act 2010
- Public sector equality duty
- SENDA - Special Educational Needs and Disability Act/Bill
Germany
France