Why I Don’t Use Packaged Authoring Tools

Why I Build Natively in the LMS

When I started my work as a Learning Management System (LMS) Administrator and Instructional Designer, I joined a team that was already committed to building natively in the LMS. While there were still some older packaged courses in the system, the team had moved away from using them. By the time I arrived, the expectation was clear: design directly in the LMS. That approach was my baseline from day one.

But I did have to help maintain and update a few legacy packaged courses as part of our revisions. That experience drove the point home.

• Every update meant republishing and re-uploading.
  
• Tracking data was more complicated.
  
• Accessibility issues were harder to fix.
  

It wasn’t just about meeting formal accessibility guidelines. It was about making the entire process more accessible for everyone involved: learners, designers, and administrators alike. That experience shaped how I work to this day.

Modern LMS platforms give us everything we need to create meaningful, accessible learning experiences without extra layers or barriers.

Inside the LMS, I can:

• Design with semantic structure and consistent navigation.
  
• Embed accessible multimedia and activities that work across devices.
  
• Provide opportunities for reflection and feedback that support real growth.
  
• Iterate quickly without republishing packaged files.

So What's The Issue?‍

Some of the most commonly used packaged authoring tools look polished on the surface, but under the hood? They’re often inaccessible, rigid, and out of sync with what effective learning actually requires. I’ve audited countless self-paced courses built with these tools.

We keep encountering the same issues over and over: clunky navigation, inaccessible interactions, and a huge remediation effort just to meet WCAG 2.2 standards. In some cases these tools are not accessible to build with or in. Even before you add any content, you are already failing to meet basic accessibility requirements.

These tools weren’t built for modern, inclusive learning. Too often, they’re just repackaged slide decks with limited flexibility, especially for learners relying on screen readers, and keyboard navigation.

So Why Do I Skip Packaged Authoring Tools?

Because they slow things down. They’re harder to make accessible. They often prioritize looks over learning, and for me, that’s not good enough.

When I build directly in the LMS, I can design for everyone from the start. That saves time, reduces remediation, and leads to learning that sticks.

You don’t need flashy slides pretending to be learning. You need structure, clarity, accessibility, and space for growth.

But I also know skipping these tools isn’t always an option.

Sometimes you don’t get to choose the technology you’re handed. Contracts, legacy systems, or budget constraints might force you to use a packaged authoring tool even when you know it’s not ideal.

If you can’t avoid it entirely, the question becomes: How do you make it work as well as possible?

When You Can’t Ditch the Authoring Tool: Designing Accessible Learning Anyway

In a perfect world, we’d all have the freedom to choose tools that prioritize accessibility, flexibility, and learner engagement. But that’s not the reality for most instructional designers or Learning and Development (L&D) teams.

Sometimes the tool is already chosen. It’s part of the contract. It’s what the team knows. Or it’s simply what’s available. And too often, it wasn’t built with accessibility in mind.

I see this all the time when auditing courses. The tools look solid on the surface, but underneath, they’re hiding barriers. Navigation that fails with keyboard use, screen reader confusion, inaccessible quizzes, or static content that can’t adapt to learner needs.

So what do you do when you’re stuck with a tool that wasn’t built for inclusive design? You make thoughtful, strategic choices within those constraints.

Keep It Simple

Over designed content is often the biggest source of accessibility problems. Extra animation, gamified interactions, or visual-only feedback might look impressive, but they’re rarely inclusive.

Instead:

• Use clear, consistent layouts
  
• Stick to simple navigation patterns
  
• Avoid overly complex interactions (like drag-and-drops or hotspots) unless you know they’re accessible (most are not). 

Less complexity means better clarity and fewer barriers for all learners.

Design With WCAG in Mind

Don’t rely on the tool’s marketing claims about accessibility. Start with the Web Content Accessibility Guidelines (WCAG) as your foundation.

Build with:

• Proper heading structures (not just bolded or oversized text)
  
• Keyboard-operable activities (check your focus order!)
  
• Descriptive, useful alt text for images (and mark all the objects as decorative)
  
• Provide multiple ways to convey information

Test as You Build

Waiting until the end to test for accessibility leads to rework and missed issues. Test early and often.

Use basic checks like:

• Screen readers (NVDA, JAWS, or VoiceOver)
  
• Keyboard-only navigation
  
• Turning off audio to see if meaning is lost (and don’t forget to disable auto-play!)
  
• Watching for focus indicators and logical tab order
  

These simple steps uncover major issues before you ship the final course.

Use the LMS for What the Tool Can’t Do

Even if your content is built in a packaged file, your LMS can still help create a better, more inclusive experience.

Use the LMS to:

• Host pre-course instructions or context-setting activities
  
• Enable discussions, reflections, and peer feedback
  
• Embed accessible versions of videos, PDFs, or transcripts
  
• Offer branching or adaptive paths based on learner needs
  

Think of the authoring tool as one piece of the learning experience, not the whole picture.

Speak Up and Document What Doesn’t Work

If something is inaccessible and there’s no built-in way to fix it, document it. Share the impact. Suggest alternatives. These conversations move teams toward better tools and smarter decisions. Saying “this interaction isn’t accessible” isn’t complaining. It’s making a design choice that centers equity.  

Compliance ≠ Learning

A linear click-through with a quiz at the end might check a box. But it won’t change behavior. It won’t shift practice.

If you want people to truly learn and apply something new, you need more than just content delivery. You need thoughtful design and tools that support application, discussion, ungraded reflection, and meaningful feedback.

That’s hard to do when you’re boxed into a rigid template.

Bottom Line

You may not get to choose the tool. But you do get to choose how you use it.

Building natively in the LMS is almost always more accessible, adaptable, and sustainable. When that’s not an option, the goal doesn’t change. Design learning that includes everyone. And if you ever get the chance to help your team rethink which tools to use? Start with accessibility. Start with the learner. The rest will follow.

If you want to see this approach in action, I audit courses for accessibility, and I teach a course in D2L Brightspace that models exactly how to do it. I also train teams to get the most out of their tools, even when they are not perfect. Book a call with me to learn more.