Adventures in Technology Enhanced Learning @ UoP

Category: Accessibility (Page 2 of 2)

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

Accessibility of digital learning content at UoP

On 15 January 2019, following a two-month pilot, the TEL team switched on the Blackboard Ally plug-in across all modules on Moodle. In brief, if a lecturer has uploaded some digital course content to Moodle (typically Word documents, Powerpoint presentations or PDF files) then Ally permits students to download that content in an alternative format (electronic Braille, html, epub, tagged pdf, or mp3). This is great for accessibility, of course, but this is also an inclusive approach: any student, not just one with a particular need, might choose to download a Word document in mp3 format (to listen to on the go) or in epub format (to get the benefit of reflowable text on a e-reader). The TEL team will be providing students with more information about Ally over the coming weeks, but in this post I want to mention a feature of Ally that is of interest to authors of digital course content.

Ally generates an institutional report about the accessibility of course content on the institution’s VLE. So we now know what the most common accessibility issues are for the 38,462 course content files on Moodle. The top five are (drum-roll please):

  1. The document has contrast issues. Just under half of all documents (48%, to be precise) have contrast issues.   
  2. The document contains images without a description. Roughly 43% of all documents commit this accessibility sin.
  3. The document has tables that don’t have any headers. Just over a quarter (26%) of all documents have this issue; I suspect that the documents without this issue are simply those without tables.
  4. The document does not have any headers. This is a problem for 24% of documents.
  5. The document is missing a title. Again, 24% of documents have this problem.

The first four are classed as major accessibility issues; the fifth issue is classed as minor.

At first glance this seems shocking: about half of all documents suffer from a major accessibility issue to do with contrast. When we compare ourselves against other institutions, however, we learn that these issues seem to be common across the HE sector; indeed, we seem to be doing slightly better than many institutions. And the important thing is, now that we know what the issues are, we can start to address them. Over time, we should be able to drastically reduce the number of documents with these common – and easily fixable – problems.

One piece of good news: we have a relatively small number of documents that possess accessibility issues classed as severe. The most common severe issue at Portsmouth – just as it is at other universities – involves scanned PDFs that have not been put through OCR. There might be good, valid reasons why a scanned PDF has been used. But accessibility would certainly improve if authors minimised their use of such files.

Header image taken from link. Retrieved from
(Assessed: 17th January 2019). Thank you to Ally for giving us permission to use their image.

Thinking about accessibility

I’ve been doing a lot of thinking about accessibility and Moodle recently as we move the Moodle Baseline project into the pilot stage. It’s become clear that many of us don’t make our responsibility to create accessible content a top priority when all that’s needed is a small amount of extra time to ensure a vast improvement in the ability of differently abled users to consume your Moodle content. I’m not going to call any specific Moodle sites out here, but some of the most prevalent bad practice that somewhat surprisingly still seems to exist includes using HTML tables for navigation & layout, and using images for headings or navigation.

Both of these issues become problematic to users who use screen readers. Whilst it is true that screen reader support for tables has improved, they should still not be used for navigation or layout. Every time the screen reader box enters a table cell, the screen reader will tell the user which cell they are in. You can easily see how this is not a good user experience if you have to work your way through a four by five table, with a link (or more than one link) in each cell. Using something more appropriate such as an HTML list for this navigation properly give the nav role in the html, as well as a more streamlined experience, a screen reader can also use this information to offer it’s user the option to skip the navigation and go straight to page content, or not. for some more information on this have a look at the W3 Schools page detailing the nav role.

Using an image for heading isn’t automatically a terrible thing. If it’s used in conjunction with either HTML alt text, or if at all possible an ARIA attribute to notify to a screen reader how the image is being used. Using CSS to replace a text link with an image, which will also allow the image to be seen by those browsing visually, but also mean the HTML text link is visible to those with a screen reader It just so happens that Bootstrap 4 has an easy way to do this which everyone can use after the Moodle upgrade in August. Bootstrap also offers ways to totally hide elements in your HTML content from everyone except those using screen readers, so you can really go the extra mile to offer content that’s easier to digest audibly.

There are reasons why you’d need to use a custom navigation, there are also times however that the topic jump list should be more than sufficient for navigating between topics on a Moodle site. If you find that this is almost good enough – but not quite – please talk to us and we’ll try and make it totally good enough for you to use. If you’d like to find out more about accessibility I would heartily recommend the Digital Accessibility MOOC on FutureLearn, it really opened my eyes to accessibility issues I’d never considered – it made me realise what I thought I was doing to enable differently abled people to read my content, wasn’t in fact enough.

I’ll leave you with this from our Moodle content guide which will arrived with the new theme after the upgrade in the summer:

Accessibility for Moodle content means that your content is available to be consumed by all users, regardless of their ability. Creating accessible learning content is the responsibility of us all – It’s not something that should be left until later, or for us to think that it’s the responsibility of someone else.

The Portsmouth Moodle – Accessibility Snapshot

In January 2018 we were lucky enough to host a visit from Alistair McNaught, a JISC subject specialist on accessibility and inclusion. Alistair spent a day at the University as a “mystery shopper”, playing the role of a student with disabilities who was trying to access various digital resources and services. He looked at the full range of services – prospectus, website, Library platforms and Moodle – but here I’ll focus on his observations about the VLE.

The first thing to note is that Alistair had difficulty logging on to a PC in the morning: it took more than ten minutes for the desktop to appear. The student sitting next to him confirmed that, after the initial boot, it often did take a long time before a public PC was in a state that allowed work to take place. Not good for a student with ADHD!

Alistair confirmed that tab order (for keyboard navigation) works well in Moodle and the visual tracking of focus is good. There’s easy navigation with breadcrumb trails and a navigation side panel; this is important because good navigation assists all users, especially assistive technology users. The Moodle accessibility block is available and obvious on all pages, and Equality and Diversity information is easily discoverable. The self-enrol E&D course has lots of very good, easily accessible, generic awareness-raising resources; and there are easy-to-find PDF resources on equality data – these have good reflow and colour change possibilities. All this is good news and it allows us to build on – in Alistair’s words – conscious competence.

However, there are some things we need to think about. For example, some of our third-party resources have accessibility issues; we are to some extent a hostage to fortune in these cases, but at least now we are in a position to raise the points with the suppliers. Another issue was that some of our generic units have poor colour contrast; Alistair pointed us to a tool – the Colour Contrast Analyser from the Paciello group – which will help us identify these problems more readily. And once we are aware of them, it’s easier to fix.

Alistair also took a look (with the consent of the academics involved) at a couple of teaching units from ICJS. He was highly impressed with the pedagogical approach taken in these units, and he praised a number of aspects. A “lovely human [video-based] introduction adds value for many students” – but he added that it “would be even better with transcript or captions”. It was “great to see active use of rich media and a nice visual key to resources”; the “direct links to reading resource and final assessment” were useful; and the “impressive range of resources” were “well organised” and had “clearly scaffolded teaching with explanations and pointers to the purpose of the resources”. Where resources could cause access issues this has been recognised and a genuine attempt made to remedy it with a PDF alternative (however, the PDF had its own accessibility issues and so does the ‘Click here’ link text). Finally, a Useful News and Information block showed “great currency, with tie-in to contemporaneous issues”. So, again, there is a lot of conscious competence on which we can build.

These units had some issues; fortunately, they are easily fixed. For example, hyperlinks need unique and meaningful link text so that assistive technologies that gather page links together can give users meaningful information. If an author writes “Click here to browse an interactive timeline of key events” then the result from assistive technologies might be a long list of “Click here”s – which is entirely uninformative. Much better to write: “Click here to browse an interactive timeline of key events”. Another problem came from an interactive Articulate resource that failed to load; even if it did load, Articulate generally produces output with limited accessibility. And some structures had untitled navigation elements, which would cause problems for some users. (This last issue might be down to an underlying Moodle template issue; Alistair pointed us to another tool – the HTML5 Outliner plugin for Chrome – that will help us investigate this further.)

All in all this was a tremendously useful visit. We know there are areas of good practice we can build on, and there are issues we can fix.  And it truly is worth pursuing this: if we take an inclusive approach to Moodle and the content on it, all learners will benefit.

Feature image title:  Web Accessibility Word Cloud by Jill Wright is licensed by CC-BY 2.0 on Flickr

Newer posts »

© 2024 Tel Tales

Theme by Anders NorénUp ↑