Accessible Storyline Projects: Keyboard Navigation and Alt-Text

Articulate has made amazing strides to develop accessibility features in Storyline. Accessibility is becoming must more of a focus in the elearning industry, and Articulate is at the forefront. Each year they make improvements to accessibility features and add new ones, and while many of their accessibility features are unique to Storyline, they are generally as intuitive as they can be made.

You won’t find many surprises in basic accessibility features, and the best practices for making anything accessible also apply in building Storyline projects, like alt-text, closed captions, sufficient contrast, media control, etc. All of the usual accessibility features need to be considered and implemented. And if you’ve made if this far, I assume that you are knowledgeable in the basics of accessibility, so this guide will focus on what’s different in Storyline and how to make use of Storyline’s unique accessibility features.

Storyline will not make your projects accessible for you, nor does it have an accessibility checker like Microsoft Word. So you must make use of the accessibility knowledge you’ve gained so far and be patient as you learn what’s unique about building accessibility into Storyline projects.

At their most simplistic, Storyline courses are just web pages. You can even run a WAVE report on a published and hosted Storyline course, like I did on this sample project featuring Saguaro National Park. However, if you clicked through to view the report, you’ll notice that it only evaluates the slide that’s currently on display. And WAVE basically just freaks out, it’s not a very useful report in this instance. (If you are determined to use WAVE on Storyline, the plugin version for your browser works better, though it’s still buggy!).

The problem is also what’s unique and fun about Storyline: a Storyline project is made up of slides, and each Storyline slide is not linear like a typical web page. When you browse a typical web page, there’s a top, there’s a bottom, and generally the content is read left-to-right. Storyline turns all of that on its head. A developer can make any visual design decisions they like in Storyline, and unlike Word or a web editor, there is no natural hierarchy associated with the visual elements. When no consideration is given to screen reader users, the experience will be chaotic and unusable as keyboard navigation presents the with elements out of the intended order. Worse, decorative elements that don’t add to the learning experience will be presented as well.

As we dive into making Storyline projects accessible, it’s easiest to begin by considering screen reader users and what their needs are. As long as you build in the standard accessibility features you already know and love, it’s only a small step farther to create Storyline projects that are not only keyboard navigable but also perfectly usable with screen reader software.

Focus Order for Keyboard Navigation

In a document or a web page, headings and other formatting elements are what dictate the order in which a screen reader user experiences the content. Screen reader users can browse headings and select the content they wish to read. However, Storyline doesn’t have headings or a hierarchy like documents and web pages. That means that we need to create one, manually.

That brings us to our first accessibility feature unique to Storyline: focus order. Once a slide is finalized, the focus order must be set. Similar to using headings and programming alt-text, you must specify the order in which elements will appear to a screen reader user, and which elements should remain hidden (generally only hide items because they’re decorative, just like situations in which you would leave alt-text blank).

To edit the focus order, select Focus Order on Storyline’s home tab. Once you’re there, rearranging the order of items is fairly intuitive, unless your objects have impossible-to-discern names. Select “create a custom focus order” and get to work. Select an item and use the arrow buttons to move. If the item names in the Focus Order don’t make much sense to you, close the window and visit your Timeline. Rename each object in a way that makes sense so that it’s easily identifiable in the Focus Order window.

Focus Order window in Storyline
Focus Order in Storyline. Good example of why you should name your objects in a way that they can be identified!

Once that’s done, reopen your Focus Order window, consider in which order elements should be presented to a screen reader user and rearrange accordingly. Elements that appear on layers will also appear in the Focus Order list, so if you are surprised by how long the list is, that’s likely the reason why. Take layers into consideration as you consider the best order.

If an item is merely decorative, you can remove it altogether from the list. Just select the object and then the trash can icon. If you make a mistake and need to restore an element, click the Plus and select the missing element.


You expect to add alt-text to images, but in Storyline, you have the ability to add alt-text to objects as well. The process is the same as adding alt-text to images, you can just right-click on an image or object, select Accessibility, and then edit your alt-text.

If you don’t add any alt-text to your objects, the name of the object as shown in the timeline will be read aloud by default. This is one good reason to consistently name your objects in Storyline.

If you are editing the Focus Order, Storyline offers another way to edit alt-text: you can check and add alt-text of both images and objects right there in the Focus Order window. Handy!


The biggest different that comes to my mind in making Storyline projects accessible versus standard web projects is the fact that the keyboard navigation order needs to be set manually by the developer.

It’s also unique to be able to add alt-text to objects in Storyline in addition to images. That makes sense, of course – objects can be used for all sorts of things in Storyline!

Tasks like Focus Order go much faster when all of your images and objects in the timeline have identifiable names, which is always best practice anyways when working in Storyline. Identifiable names also make programming triggers much shorter work!

Above all, consider keyboard navigation and screen reader user experience in your final Storyline projects, and think about downloading a screen reader software and testing it out for yourself.

We’ll cover more Storyline accessibility tips and tricks next time!