Adventures in Technology Enhanced Learning @ UoP

Author: Will Maltby

Print-based booklet to accessible online resource


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:

Wellbeing PDF booklet front cover

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,, taken Feb 2019

Faculty vs Central: Perspectives of an Online Course Developer

What’s this about?

I joined the University as an OCD about five years ago, and have worked since then in the central TEL section to provide first-line support for the University’s VLE. Having recently taken a 4-month secondment to the Faculty of Technology as a Senior Online Course Developer (OCD), I thought I’d take a moment to share the experience.


An OCD’s job here in the TEL section is quite varied and ‘bitty’, with a little less focus on big projects (Educational Technologists fulfill that role here). Skill-wise I’ve been using a variety of languages and tools (PHP, Javascript, MySQL etc) and various Office/content creation apps (Flash/Captivate/Articulate and the like).


Where are my units!?

The first thing that struck me was that I’d lost access to all units University wide. Whilst I had no mandate to work on units outside of the Technology faculty, I instantly missed being able to quickly find a given unit and check something out. I found myself having call TEL each and every time I ‘quickly’ needed to jump to a given unit to get something. This probably affected me in particular because I’ve worked on various non-standard Moodle sites across all faculties – but it does make me wonder whether all OCDs should have read access for all units? Wouldn’t it be a good thing if OCDs could see what their counterparts in other faculties are doing? It might help spread best practice (and perhaps even spur some friendly competition).

Hands tied

As a centrally based OCD I’m used to having various problems come my way, typically discover that a systemic problem is affecting other instances across whichever system, and then investigate and resolve. As a faculty OCD the process is simply to report it to central and then sit and wait. Most ironic was that it would have been myself picking these tasks to investigate in TEL. So I found myself being more cautious than I’d hoped with the suggestions and advice I gave to academics.

Missed opportunity

As the secondment was primarily out of necessity more than opportunity due to an expectedly reduced team, we didn’t really get the chance to work on anything major. We also had main exams on which had to take priority. I could see we were critically just one or two people short of a proper OCD team capable of looking after and running what is actually a surprisingly large department’s worth of units. Ultimately we had no real scope for proper project work and due to the focus on exams, we ended up as little more than curious extension to the CAM Office admin team! But this was more a product of the circumstances than the department itself.

Senior role differences

Whilst the actual increase of responsibility of the Senior role was relatively minor, it did entail a different way of thinking – I had always to try and think of the larger picture. It’s certainly a different style of working than writing code – and, with a small team under me, I found I was too frequently flipping between development and managerial work. As a result, this made me worse at both. Ideally, I’d have liked to delegate jobs and allow myself to better focus my time, but circumstances made this difficult.

Job perks

The Tech Admins apparently make the best cakes! I was fortunate enough to be able to not just witness, but both experience and actively participate in ‘Cake Day’:


Overall I appreciated my brief time as a faculty OCD, offering me a fresh perspective on things I’d seen differently from central. It certainly gave me a much better understanding of where Academics are coming from when they’re trying to build various activities in their units. Just because they’ve managed to put a given tool on a site, doesn’t mean it’s necessarily actually what they want!

It’s also made me question whether faculty OCDs should have read-only access across Moodle, so that everyone is aware of what’s going on around the University. To give just one example: our team was shocked when librarians came over and let us know that Technology was woefully, and exclusively, behind on managing our reading lists. This was news to us – no system had been set up to manage reading lists and so none of us had done it.

I’m grateful to have had this opportunity, as I’ve often pondered moving toward a more managerial role but never really wanted to commit to it. So a 4-month secondment was the perfect option.  In the end I’ve found I prefer the nature of the OCD role in central, as it best lends me the variety and flexibility of work that personally I find most rewarding.


© 2024 Tel Tales

Theme by Anders NorénUp ↑