The State Of The Moodle Accessibility Union: Not Strong

The decentralized nature of Open Source technologies, Moodle included, means that practical initiatives will always have a place. If they are good and useful for many, they will be spread throughout the community. This unique dynamic is what explains the leaps that Moodle has taken to provide inclusive and accessible alternatives to groups in very specific circumstances.

Post Pages - Post Inline - WIRIS

This ability to customize every part of the experience has not only led to designers and developers to implement accessibility practices in their design. It has allowed teachers and instructional designers to consider accessibility in the content creation itself. Furthermore, is has allowed involvement of academic research to assess its efficacy as an LMS to special groups.

The work, however, is not complete. Currently, the official Moodle Developers Documentation features a page on Accessibility, but it does not correspond to a clear outline for development practice. As it stands at the end of writing, it lists resources scattered in sections: Starting points, official guidelines and legislation from a few countries, tools and a list of “coding guidelines” lacking in structure and gravitas.

To be clear, the focus on accessibility on Moodle exemplary. In fact, the volume of contributions in this area are plenty, so much so that sorting solutions out is a more difficult issue than finding them. In short, the problem is not the absence of accessibility, but the absence of comprehensive Moodle Accessibility Guidelines. This is also not to diminish the important work made by groups such as MACG.

To bring order and move the conversation forward, Partner Moodlerooms has published a post on “considerations for universal design of online courses“. It provides four fields of work, which may move the conversation forward; but it also determines an order of action, which I personally disagree. The fields are:

  • Content development.It involves the pieces of content, flow and navigation scheme. But the post suggests that this should come before design, and that one should “refrain from posting any content until the design is complete“. This seems to go against modern, iterative, feedback-based practices in content and application development.
  • Navigation. The post recommends a consistent scheme throughout a course, limiting the number of “clicking and scrolling“, and using “brief for comprehensive text for links”. It is without a doubt commendable practice, but by no means definitive.
  • LMS. It suggests to give “careful consideration to the LMS tools used“, emphasizing evaluation activities that test functionality depending on the available technology. The design must make sure the experience is fully functional in any medium.
  • Colors and Fonts. Again, the post is limited to recommending “good contrast”, no patterns or images behind text, “sans serif fonts” in generous sizes, and avoiding pixelated text.

All good ideas that should only be considered as the beginning of a more coordinated discussion towards Moodle Accesibility Guidelines.

See the pages in the Accessibility Category at the Moodle Developer Documentation.


How could Moodle standardize accessibility for developers and instructors? I’m really looking forward to your comments on this.


moodlerooms-logoThis Moodle Practice related post is made possible by: MoodleRooms the open source learning experience by Blackboard. Rediscover Moodle. Click here to learn more.


Previous articleBlended, Non-Stop Learning At Baltimore County Public School System
Next articleThe Learning Analytics Roadmap: Do All Roads Lead To Forecasting? [LAR Series #7]


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.