By Laura Lochen, Instructional Designer, MnDOT

Editor’s note:

eLearning Services within the Minnesota Department of Transportation (MnDOT) is undergoing a significant technical and logistical overhaul. This article shares some of their experiences. The team welcomes hearing from other groups experiencing a similar challenge, and also hopes their story will help others.

eLearning Services within the Minnesota Department of Transportation (MnDOT) has been creating interactive eLearning for close to 20 years. First we worked in Authorware creating interactive CDs. Then we migrated to Flash in about 2004, which allowed us to put our courses on the web for all MnDOT learners to access. Flash was a mature and robust software at the time we started using it. It was fully programmable, so we learned how to strong-arm it into doing all the interactivity we needed. At the time we started working in Flash, we did not consider accessibility. By the time we took on the challenge of making interactive and accessible eLearning, our developers had well-honed programming skills in Flash. It became a matter of designing and coding interactivity, then testing the programming to get it to do what we wanted. Once we created an activity or action, we could keep the programming, and use it over and over. This allowed for quicker and more reliable course builds overall.

In came HTML5, and that required a full-fledged change to our whole system. This was not a slow change with a long-term sunset. This was an immediate stop that left MnDOT with well over 100 eLearning courses that would not play on browsers in two years. Our team was in a bind. How could we move forward while fixing what we had? None of the current eLearning in our LMS (learning management system) was expendable; someone was using it. Fortunately, we were able to hire two full-time temporary people to help us rebuild our library while still moving forward on current projects. So far, we’ve found HTML5 is nowhere near as mature and robust as Flash, and there are some things you simply cannot do. However, we are fully committed to accessibility, and we strive to find workarounds that let us maintain our interactivity and accessibility. We constantly weigh those two, but HTML5 has forced us into some compromises.

Currently, we are working with two course development tools, Lectora Inspire 17, and Storyline 360 version 3.23. Originally, this was in an effort to find one solution. However, due to issues with almost every software we have tried, it is likely we will move forward using both. We also use Captivate 2019 for a few projects.

Some Issues and comparisons:

• Browser compatibility - Flash published a self-contained package that would run the same way on all browsers. HTML5 publishes multiple pages that often run differently on different browsers.
• Screen reader compatibility - We have also found a significant difference in the way that JAWS reads the information on the page vs. NVDA. JAWS compatibility takes up easily 25 percent of our development time, and 70 percent of our accessibility work. All the other accessibility and interactivity can be built into a template. Even when we find a workaround for something, an update to the Storyline or Lectora software will make it function differently, or not at all. Sometimes it feels like a moving target.
• Multiple software products instead of one - Some items were simple in Flash (scale up or scale down pictures, adding video over a stationary background, etc.), but are very complicated in HTML5. Often, it takes multiple software products to reproduce interactivity done previously only in Flash.
• Software accessibility - Every eLearning software company seems to have varying degrees of skill and knowledge about what accessibility really means for usability. They vary significantly from company to company. Often a company claims to work well with screen readers, and we find it does not.

Some solutions that we use:

• For browser compatibility, we are limiting the browsers we work with to Internet Explorer 11 and Chrome. That way we can create templates and reusable activities that will be consistent. As long as the learner knows what browsers are optimal, this is a workable solution.
• We still struggle daily with screen reader compatibility. There are some things a screen reader won’t currently do in HTML5. We never want to limit our designs to satisfy the software inconsistencies. We hope that compatibility will improve as HTML5 gets more use as an eLearning option. While we try to make everything work, there will be some things that will have to wait for the assistive technology (AT) software to catch up. We realize that the AT, as well as our knowledge, is still evolving.
• We use both Lectora and Storyline 360 as our main development software. They seem to give us the best options for interactivity and accessibility. We also use JavaScript and GreenSock to force the software to do what we need and want.
• We hope the larger software companies eventually pick up their game, and take a more serious look at the issues those of us in the public sector are encountering. It’s nice to have “bells and whistles,” but it’s disappointing when we can’t use them to provide our learners with the best learning experiences possible.

As for our team, we are searching for a happy medium, and creating new procedures and templates that we will be able to use going forward. While it feels like we are back at “square one,” it’s also an exciting, engaging, and frustrating task to take on. We do not want to compromise the quality of our product, and the style our customers expect. However, we do need to be as accessible as possible given the tools we have. As we learn more, we can start to build our capacity back to where it was and, hopefully, help others in the process.