Improving accessibility in Articulate Storyline

We always try to develop our eLearning modules in a way that comply with the highest accessibility standards set by the Government (for most of our clients, it is defined in the Accessibility for Ontarians with Disabilities Act or AODA), and this goes beyond just closed captions or making the module accessible via keyboard, as there are so many more things to keep into account, such as the contrast between the background and the foreground, the spacing of text for readability, alternatives to activities that involve using the mouse, and many more (if interested you can refer to the Act).

Recently, we had one of our modules reviewed by one of our clients who are experts on accessibility as it pertains to web objects. For the most part, the feedback they provided was implemented, as it involved changing colours, updating text and audio, which can all be done within the authoring tool (in this case, Articulate Storyline), however, there were some comments that made us go into deep thinking mode.

Most of these comments were about updating very specific HTML tags and attributes, in other words, modify the DOM (Document Object Model) after publishing the eLearning module.

While this is usually fine, for example, if the module was developed directly in HTML, it is unfortunately not the case when the module is developed in Storyline. Why?

Well, for starters, we don’t deal with the DOM directly when we are developing any eLearning module, as we do it through a WYSIWYG editor where we add the text, shapes, colours, etc., on the screen but we don’t hard code any HTML objects.

Additionally, the files that are generated by Storyline when the module is published are, for the most part, JavaScript files that contain all the data, how it is linked, how it is animated, and how it looks in general, but there is really not an HTML page we can edit for any of the slides (our guess is that the published module has a library or framework included that renders the module in real time when the learners are going through it).

So, in conclusion, as much as we would like to improve the accessibility of our modules, there are some very specific modifications that are not possible (especially if those are related to modifying elements in the DOM), and even if we manage to make those modifications, our gut tells us that we might end up unintentionally breaking other parts of the module.