Skip to main content Skip to navigation

Best practice: Creating inclusive Moodle spaces

Moodle is designed on inclusive practice principles. This means that anyone should be able to access the content contained within your Moodle space. This is irrespective of their abilities, the technology they use to open the content or the devices they access the content upon. The latest version of Moodle has received WCAG 2.1 Level AA accreditation. Additionally all Moodle components are accessible via a keyboard.

The HTML editor in Moodle (the Atto toolbar) provides several built-in accessibility features. This is available each time you add an activity or a resource to a Moodle space. The icons on the toolbar are displayed in rows as links. Each icon is sufficiently large and has sufficient space around it that it can be easily clicked with a mouse.

Moodle Atto toolbar

The Accessibility Checker button (the circular accessibility button at the right end of the second row) brings up an automated accessibility checker which checks for common errors in the text, such as:

  • Images with missing or empty alt text tags
  • Poor contrast between text and background colours
  • Long chunks of text with insufficient headings
  • Tables with missing captions and header rows

The Screenreader helper button (the braille pattern button also at the right end of the second row) brings up a tool for screen reader users. It provides a summary of what text styles, images and links are used in the text box.

The equations produced by the MathJax content filter in Moodle have full accessibility enabled so they can be passed directly to the screen reader as maths content.

If you follow the guidance on the relevant best practice pages before adding Word or PowerPoint documents to your Moodle space, they will retain their original accessibility features when you add them to Moodle.

Accessibility tools

Moodle supports the following screen reader/browser configurations:

  • Microsoft Edge, Jaws 15+ (Latest version recommended)
  • Mozilla Firefox, NVDA 2014.1+ (Latest version recommended)

Screen readers

Accessibility tools


Write in plain language and avoid jargon and abbreviations. If you need to use acronyms or specialist language think about using the glossary tool to explain the terms you are using. Avoid using colloquialisms, slang and metaphors. Some of your learners will have English as a second language and may not understand these references. Write in short, simple sentences. If your sentences are more than about 20 words long, they are too long and you should revise your text.


Think about the layout of your Moodle space before you start to add your content. Be consistent with your styling and layout as this will make it much easier for all learners to find resources and activities on your space. Remember if you can't find something easily, the chances are your learners won't be able to either.

Always complete (and enable) the Description field when adding content and make the description meaningful as this will help all learners understand what they are clicking on and the type of resource or activity that it will open.

Use proper headings (e.g. Heading (large), Heading (medium) etc.). Do not use bold or underlined text as headings and try to be logical with your use of headings. Main section headings should be styled with a larger heading (e.g. Heading (large)). Sub-section headings should be styled with a smaller heading (e.g. Heading (medium)).

Use the Paragraph style for all body text. Left justify your text and consider how you use white space on the page. Does the page look crowded? If so then you probably need to rethink the layout.

Use proper list formatting for numbered or bulleted lists. Screen readers will then recognise that the text is part of a list and treat it as such.

If you are going to provide lots of activities are they listed in a logical order? Do you have to scroll down several screens to access content? If so can you use the Make available option to hide an item on a page and link to it from a more logical location (e.g., a book page or an HTML page)?


Do not use colour as the only way of conveying meaning. If you want to use colour you should always provide a text alternative for learners with visual impairments. In the first table below, the mandatory module is shown in red and the optional module is shown in green. This is not suitable for learners with red/green colour blindness or for learners who rely on screen readers, as the colours will not be picked up by the software.

Introduction to grammar
Intermediate grammar

A simple accessible alternative is:

Introduction to grammar (mandatory)
Intermediate grammar (optional)

Visual content

Visual content includes images, SmartArt graphics, shapes, groups, charts and embedded objects. The guidance on using visual content in documents is the same as the more general guidance on using this type of content. Please see the accessibility page for further information. Any images that you add to your Moodle space should be added inline with the text rather than floated or aligned left or right. This will ensure that the alt text tag works correctly for screen readers. Finally think about whether you really need to use images. If they are just for decoration, can you do without them?


Keep your tables as simple as possible and do not use nested tables (tables embedded within tables) as this is really poor practice from an accessibility perspective.


Ensure you use descriptive links when adding links to your Moodle space. Alternatively include a very clear description either above or below the link to explain what will happen when the learner clicks on it.

Naming documents

Think about how you name your documents. Is it clear what the document is about if the learner just hovers their cursor over the link to it? The University of Edinburgh have produced some useful guidance on naming files which is available on their website at the link below:


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, therefore:

  • All form elements should 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.