Dependable Systems Lab Dependable Systems Lab

An Accessibility Checker for Moodle

Digital media offers great education opportunities for handicapped people. Yet course material and on-line resources are often inaccessible due to technical barriers. This projects aims to improve the situation by empowering teachers to publish accessible course material.

The heart of the project is a plugin for the Moodle course management platform. It checks, whenever a teacher uploads a PDF file, whether it is accessible. The plugin also supports teachers in improving the accessibility of their documents: it provides context-sensitive instructions to solve the detected problems.

For more information about the accessibility checker, please contact Quentin Cosendey or Jonas Wagner.

The plugin can be freely downloaded.

Introduction

This Moodle plugin encourages teachers to make accessible course material by checking, each time they upload a PDF file, if it is accessible.

If it is not accessible, or only partially because potential problems have been detected, the plugin notifies teachers that their file isn’t accessible, shows which problems there are, and what teachers should do to improve the document.

Rather than being generic and technical like most other accessibility checkers, advice given by this plugin is as simple as possible and contextualized depending on the word processing software used to produce the PDF file. Thus teachers not familiar with accessibility-related issues can understand easily what the issues are about, and how to fix them in their favorite programs.

There is no doubt that, if problems and the way to solve them are explained simply, teachers are likely to fix them. People are often ready to help in accessibility, if they are shown what to do.

In contrast, deeply technical checkers are of no help with people that may not be familiar with accessibility, word processing advanced concepts, or computers in general. It has been observed that, most often, documents on the web aren’t accessible because of ignorance, not because of unwillingness or lack of time.

For advanced users, detailed error messages are still present in the analysis report, but only briefly at the end. Internally, the checker uses a subset of the Matterhorn protocol. Priority has been put on points in the protocol that have the most impact on general accessibility, and were not too hard to check. The principal goal is to let teachers achieve reasonably correct accessibility, not absolute perfection. Anyway, in term of accessibility, perfection is extremely hard and time consuming to reach.

Installing the plugin

This accessibility checker plugin is composed of multiple parts, so its installation is unfortunately not as easy as one would like.

Patching Moodle

First step is installing Moodle, or patching it if Moodle is already installed.

The patch adds the possibility for a plugin to be notified when a teacher uploads a file. This functionality has long been available for students, to allow auto-grading, anti-cheat checking and the like, but what instructors upload has never been verified in any way before. Thus this feature needs to be added.

You can download the entire Moodle distribution already patched, only the patch alone, or the set of modified files. Version 2.6.2 of Moodle has been used as a base. If you are already using a different version, you might have to apply the patch manually.

The patch has been created with git diff. In the best case, it means that it should be patched with git apply. If you left the file name of your download unchanged, the exact command would be git apply moodle.patch.

Adding the Plugin to Moodle

Once Moodle is running and patched, you need to install the plugin itself.

Download the plugin. All files must go under local/accessibilitycheck/.

Once all files have been copied, connect to Moodle administration at http://.../admin. It should automatically notify you that new plugins are going to be installed. Follow instructions given by Moodle.

Installing pdfinfo

The plugin uses an utility called pdfinfo to collect meta-information on uploaded PDF files. If you are on Linux, your standard packet manager should let you install it easily. Sometimes, it is part of the XPDF library. A windows version exists as a part of GNUWin32 project, or you can download it directly here.

Installing Java 7

The plugin also uses a Java program to analyze PDF files. Java must be installed if it isn’t already. You will find the Java Runtime Environment on http://www.java.com. You must install the JRE 7 or JDK 7; it may work with Java 6, but it hasn’t been tested.

Installing the iText Library for Java

The Java program which analyzes PDF files is using a PDF library called iText. You can download it from http://www.itextpdf.com. You need at least version 5.5; newer versions should work as well.

Some PDF files are encrypted and/or signed and iText will try to decrypt/verify them if it is allowed to. To be able to decrypt and verify signatures, you must download some parts of the bouncycastle library. Go to http://www.bouncycastle.org/latest_releases.html Here, download bcmail-jdk15on-150.jar, bcpkix-jdk15on-150.jar, bcprov-ext-jdk15on-150.jar and bcprov-jdk15on-150.jar.

To simplify your life, all needed jar files mentioned above can be downloaded in a single zip file.

Put all downloaded jar files from iText and bouncycastle in lib/ext/ or jre/lib/ext directory of your Java installation. This directory is sometimes called extensions directory, or automagic directory. Alternatively, you can add them to your system classpath or specify them explicitly on program’s command line.

Configuring the plugin

Before you can effectively use the plugin, there are small configurations to do. You must specify where to find pdfinfo, and how to launch the analyzer program. You must also allow PHP to run external programs.

Configuring PHP

Moodle, which is written in PHP, will use a binary program, pdfinfo, as well as another program written in Java. In order to have all that working, PHP must be allowed to use the function called exec.

Many web hosts explicitly disallow PHP to use functions like exec or system, which allow it to run external programs. They usually do so for security reasons. Unfortunately, since the plugin uses programs that haven’t been programmed in PHP and that wouldn’t have been doable easily in PHP, it won’t work if these functions are disallowed.

To ensure they aren’t disallowed, check that:

  • SAFE_MODE is disabled
  • The DISABLE_FUNCTIONS entry doesn’t explicitly contain one or more of exec, system, shell_exec, escapeshell, escapeshellarg
  • pdfinfo and the jar file to execute have correct rights, and aren’t forbidden by the OPEN_BASEDIR directive

All that must be configured in php.ini. In many Linux and UNIX like distributions, you will find it under /etc/php5/apache2/php.ini.

A very simple way to check your PHP configuration and locate the php.ini is to use the phpinfofunction. In case of doubt, upload a PHP file containing only <?php phpinfo(); ?> to your web server and navigate to it in your browser; you should see a very detailed page describing all PHP configuration.

Configuring the plugin itself

Open local/accesssibilitycheck/checker/main.php in your favorite text editor, and edit the two definitions at the top of the file:

define('PDFINFO_PATH', 'C:\\wamp\\www\\moodle\\local\\accessibilitycheck\\checker\\pdfinfo.exe');
define('TAGGED_ANALYZER_PATH', 'java -jar C:\\wamp\\www\\moodle\\local\\accessibilitycheck\\checker\\analyzer.jar');

The first one is the path to pdfinfo. If pdfinfo is in system’s path, you can just write pdfinfo, but if not, you must put there the full path.

The second one is the full command line to run the analyzing program in Java. Normally, your Java interpreter should be in system’s path, so you can just write Java; otherwise you must write the full path to it. Then there is the option -jar, which specify to Java that it has to run a program contained in a jar file; this is normally to be left as is. Finally, you must specify the full path to the jar file to be executed, i.e. where you put analyzer.jar.

If you didn’t put iText and bouncycastle jar files in the magic directory jre/lib/ext/ or lib/ext/, then you will have to specify them on the classpath explicitly, for example as follows:

define('TAGGED_ANALYZER_PATH', 'java -cp /path/to/analyzer.jar:/path/to/itextpdf-5.5.0.jar PDFXMLDocumentAnalyzer');

Unless you want to develop further the plugin, you shouldn’t have to modify anything under these two defines. There is currently nothing else to configure or customize.

It doesn’t matter if the plugin is already installed in Moodle or not while modifying the file.

Testing

Quick test, on the command line

To verify that the Java analyzing program works well, you can try to run it. Try it with the example PDF file test-commandline.pdf, for example.

java -jar analyzer.jar test-commandline.pdf

If you see exceptions, then something went wrong. If you are returned to the command prompt without any message, then you are ready for the second test.

Full test

It’s now time to test the plugin in action inside Moodle!

When a perfect PDF is uploaded, that is technically accessible and without errors, the message displayed just congratulates you for having uploaded a good file. Therefore, to see more interesting messages, you should try the plugin with a deliberately inaccessible file. Don’t retry the same file as above (test-commandline.pdf), it doesn’t have any error. Instead, try this test-invalid.pdf file.

Open Moodle in your browser and login with an account that has the right to upload files inside courses: an admin account, or a teacher account. You might create a dummy course for your tests.

  1. Open the course you want to upload files in.
  2. Turn editing mode on.
  3. Click to add a resource or an activity somewhere.
  4. When it’s time to upload files, send test-invalid.pdf or another PDF file that isn’t accessible (most PDF files aren’t fully accessible).
  5. After the file is uploaded, you should see a dialog box saying that your PDF isn’t accessible, what problems were found, and hints on how to solve them.

Possible improvements

This plugin is still in an early stage and there are many possibilities for improvements. Among those are:

  • Error messages are often too long to fit in dialog boxes. It would be nice to open a new page specifically to display accessibility checking reports.
  • There are a lot of programs able to produce PDF files. The plugin only supports a few: Word, PowerPoint, Open Office; it would be nice to have explanations for other less popular programs as well. Unfortunately this would have required a big time investment.
  • Currently, the Matterhorn protocol isn’t complete, only relatively few of its criteria are indeed checked. It would be nice to check more, if possible.

Conclusion

Before developing the plugin, we analyzed a sample of 200 PDF files, and found that only 15 of them contained metadata for accessibility. Among these 15, only 8 to 10 had tagging that made reasonable sense for assistive tools, and only 2 or 3 had no errors. This number is disappointingly low, and was a part of the motivation to write this plugin.

It would be interesting to deploy the plugin in production, and conduct a study to see the impact it will have on the level of accessibility. Unfortunately, people change slowly, and two or three years would probably be needed to conclude something useful out of this experience.

In the meantime, I hope that it will encourage people to make more accessible PDF files.