Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-67973

Forms library does not generate accessible forms



    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.7.4, 3.8.1, 3.9
    • Fix Version/s: None
    • Labels:


      Forms generated by Moodle's forms library do not currently meet WCAG 2.1 Level AA which also includes Level A. Here is a list of issues that I have identified off the top of my head. I have not done any in-depth evaluation for accessibility yet.

      1. The handling of errors in all Moodle forms do not currently addresses accessibility requirements as described under WCAG 2.1 Success Criteria 3.3.1: Error identification. For example, if there are 5 data entry errors in a long form (be it from incorrect formatting, missing required fields, etc), it is difficult to find the errors. The fix implemented in MDL-67876 starts to address this by automatically scrolling to the first error. However, there is still no easy way to find the other errors. I have seen the frustration from users first hand and even experienced it myself, especially with the profile page when a new custom required field is added. There is nothing to indicate that new information is required. The Edit Profile page just comes up. If you don't notice the error and click submit, it just loads the page again. I can just imagine what the experience would be for someone who uses a screen magnifier, screen reader or has mobility issues and needs to try to find the error.
      2. The error messages are in a small font and fail colour contrast ratio requirements: 
      3. Notice that the error itself is below the field, not above. So when you scroll down the page, you may not scroll far enough to see right away if there is an error. For more information, see WCAG 2.1 Success Criteria 3.3.1 Error Identification.
      4. The font of error messages is small and its colour fails colour contrast ratio requirements which is a problem for people who are affected by colour blindness. And if the person can't see red, they may not even be able to see that this text is different from any other text on the page. Could just be a field description. What can you do about it? Add multiple visual queues to highlight the error. Make the text bold. This will cause screen readers to read the error louder than regular text. Fix the colour contrast by making the text black over a light red background. Add a solid bar to the left of the error message. Prefixed by the error message with the word error. Example: "Error 1:". For more information, see WCAG 2.1 Success Criteria 3.3.1 Error Identification, 1.4.1 Use of Color, and 1.4.3 Contrast (Minimum).
      5. Required fields are not identified when listening to the form with a screen reader. For more information, see WCAG 2.1 Success Criteria 3.3.2 Labels or Instructions.
      6. When the form contains errors, a screen reader may or may not read the same error message or any error message at all, depending on the type of field. For more information, see WCAG 2.1 Success Criteria 3.3.2 Labels or Instructions.
      7. There is a message at the bottom of the page indicating that "There are required fields in this form marked " (icon actually in a red circle). If the form was designed to be accessible, there would be no need for this message since the word "Required" should be part of the field definition instead icons which are not part of the label and therefore not read by screen readers. If you did still want to include the message, it should really be placed at the top of the page as people don't get to the bottom of the form until they are ready to submit. In fact, the message is actually below the form so they may never even scroll down to the very bottom of the page. For more information, see WCAG 2.1 Success Criteria 3.3.2 Labels or Instructions.
      8. Many of the icons fail minimum colour contrast ratio accessibility requirements. For more information, see WCAG 2.1 Success Criteria 1.4.1 Use of Color
      9. There appears to be a dependency on the title attribute. While this is nice when hovering with a mouse to see the tooltip show up, it does not help keyboard-only users or people using screen readers if they don't read title attributes.

      In general, WCAG 2.1 principle 4: Robust says: "Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.". Also, although it is for Level AAA, there is an important note on the use of title attibutes, especially when depended upon to communicate important information to the user: https://www.w3.org/WAI/WCAG21/Techniques/html/H89.html

      Here are working examples of forms that are 100% fully accessible. My recommendation would be to implement form design and error handing in a similar way. https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html. Try submitting either of the two forms without filling them out.

      So there you go, an initial assessment just off the top of my head. I think these issues need to be fixed before a more in-depth accessibility review is done.

      This testing was done in Google Chrome Version 79.0.3945.130 (Official Build) (64-bit) using the following tools:

      • Chromevox Classic extension
      • WAVE extension
      • NVDA for Windows
      • Windows 10 screen magnifier
      • Moodle 3.8.1+ 2020-02-07 weekly release
      • Greenshot for screen captures.

      Let me know if you have any questions.

      Michael Milette




            michael-milette Michael Milette
            Component watchers:
            Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias, Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias
            1 Vote for this issue
            3 Start watching this issue