So today I checked my LMS for accessibility and found the following observations.

First, running the mark-up through the W3C web markup filter I found a few errors. It seems Moodle is using an XHTML 1.0 strict doctype (which is an identifier for what type of HTML a browser should expect to be parsing) and a WYSIWYG editor which is not compatible with this doctype. This type of error is common, almost none of the popular web editors are compatible. Fortunately the types of errors which are produced should still be accessible to users, as the basic structure of the web page is solid, it just includes a few elements and attributes which shouldn’t be there with that doctype. Most web browsers can manage with this type of error present.

Unfortunately there appears to be a closing tag error for one of the divs at the end of the document. Moodle uses a theme, and we insert our information into boxes in the theme and one of these boxes is apparently not closed. This poses a much more serious problem for accessibility as almost all browsers struggle to try and decipher what the web designer wants when a tag is not closed. I cannot do anything about this error without a lot more control over my Moodle site, except possibly point it out to the Moodle developers.

All of the images I have uploaded to the site have the alt attributed filled in. For the equations I was careful to use the equation written in simplified TeX format as the alt tag so that a user with a visual impairment could still read the equations. Some of the diagrams alt attributes are less useful, but in general the diagram is explained in text before the image appears.

There are other ways in which my site could use improving in terms of web accessibility. For example, I use a video my students created for a project in class. The video uses captions which are formatted as part of the video itself, rather than as a separate text overlay. This means that people who have both a visual and an audio impairment will not be able to use this video. Wherever possible audio and video files should have captions which are accessible to screen-readers (Paciello, M.G., 2000).

My LMS site also includes an interactive Java applet. While this is not crucial to the understanding of the material, it is helpful. Unfortunately this applet does not use any hot-keys, and so requires a visual only interface. A user with a visual impairment could not use this applet.

Another issue which is becoming more prevalent is the mobile web market. While users who are using a mobile phone may not have a disability, more and more websites today need to be accessible for mobile browsers. Fortunately you can use a separate style-sheet for a mobile phone, but it is unlikely that this has been implemented for my LMS. A mobile browser could be used by a person who is in a remote location, so in some sense providing this separate mobile CSS stylesheet could be justified under making the LMS more accessible to users in remote locations. Similarly for these users it is important to keep file sizes as small as possible, given the costs associated with mobile browsing, as my friends with smart phones can attest.

One advantage that the Moodle LMS offers to users using a screen reader is the lack of a lot of complicated JavaScript. Although many newer screen reader technologies allow for the use of JavaScript, it can still be quite distracting and difficult for a person with a visual impairment to focus on the content. Moodle uses links for every action, which a screen-reader can tab through, the only JavaScript is on the WYSIWYG editor interface which is not necessary. The only action a person using a screen-reader might have difficulty doing would be uploading an image, as this appears to be tied into the WYSIWYG interface.

In general this LMS site is accessible, and I was pleased with the results of the survey of the site for accessibility.


Paciello, M.G., (2000). Web Accessibility for People With Disabilities. Accessed from on July 29t