Introduction

As an online course developer I recently had the task of creating an accessible online version of a print-based Wellbeing information booklet which Marketing had produced, which as one might expect, was quite heavy on graphics and styling.

The first page provides a good idea to what the 28 page PDF copy looks like:

What is an accessible document?

An accessible document is both simplified in the literal sense in terms of visual presentation and in a technical one to meet specific criteria for accessibility software. The former involves making sure things like making headings and fonts clear/bold and images have proper alt text to explain what they are. Technical concerns are things like making sure the document has proper metadata, has a logical ordering of text for screen readers, and is properly tagged. These concerns can be addressed using common word processing software, such as in this case, Microsoft Word 2016 and Adobe Acrobat DC.

Checking for accessibility

To check the document, the Blackboard Ally plugin for moodle was used. The original document had a score of just 8%:

However, it should be noted that this number is derived purely from the number of occurrences of problematic instances,  rather than a rating of how readable it is per se. The Ally tool does provide some useful guidance on how to fix the errors, such as explaining what each issue is, what it means, and how to practically fix it.

Converting to alternative formats with Blackboard Ally

A great  key feature, as used on this task, is the ability to automatically attempt to convert the document to an accessible version of your desired format.

The HTML format was exported  in this case, and the result was a fairly good rendition of just the basic text with foreground images kept. However, there were some critical errors in the conversion which meant that more than simply a post editing tidy up was needed. For example, the information from the table cells in this document didn’t export in a structured format and so the information was completely unreadable.

Original (left) versus Ally conversion to HTML:

As a result the document would need some manual re-entering of text to finish it off.

Editing with Word 2016

To begin with, the Ally HTML output was opened in Word 2016 as good starting point. The first job was to just go through and make sure all text had been properly converted. This was the most time consuming part of the whole processed, followed by subsequent proofing.

With that done, it was then down to solve the technical issues using Word’s built in accessibility tools.

This tool checks things such as whether tags are added, and more subtle things like whether a table has a heading row, and/or whether it’s properly marked up as such for screen readers. This is mostly a case of clicking each fault and either automatically fixing it (as in the case of meta tags) or manually fixing (the table headings had been stripped by the Ally conversion and so had to be manually re-entered as heading rows).

Once everything has been checked/ticked off, it’s then a case of exporting it as a PDF document.

At this point the advanced saving options panel was used to make sure the PDF would have the correct accessibility features by adding structure tags:

Now, in an ideal world, this would be the end of the process. However, Word 2016 falls short right at the final step here as for some bizarre reason, it fails to add a title in the metadata. You can certainly add a title in Word, however, it seems to be ignored when converted to PDF. Due to this Adobe Acrobat DC had to be used to finished it off, but this was partly the original intention anyway in order to ‘run it by a 2nd pair of eyes’ so to speak.

Finalising with Adobe DC

To finish off, the outputted PDF was opened with Adobe Acrobat DC which has its own accessibility tools.

This flagged up a few more problems and was able to auto correct them. It also enabled me to add the title metadata and then finally export the finished PDF.

The finished result

A 100% perfect score in Blackboard Ally!

The resultant document should now be 100% compatible with related accessibility assistive software. The image shown here has been properly tagged with alt text to explain what it’s representing, and so is perfectly acceptable in an accessible document.

It’s important to remember that accessible documents do not necessarily have to be pure text. And whilst the focus here is ultimately making visual content accessible for the visually impaired, there’s no harm in adding a little well conforming colour.

Image credit:
Header Banner, https://www.jisc.ac.uk, taken Feb 2019