How to Make a Custom Storyline Player Tab Keyboard Accessible

Questions answered by this guide

• ?How do I make a custom Storyline Player tab accessible by keyboard?
• ?What keyboard shortcut should I use to open custom help in Storyline?
• ?Does Storyline's key-press trigger work for keyboard-only users?
• ?How do I test a custom Player tab with a screen reader?
• ?Where should focus go after custom help content closes?
• ?Can I put a keyboard shortcut trigger on a Storyline slide master?

What you'll learn

• Opening the custom tab with a keyboard shortcut is only the first step, the whole experience needs testing
• Storyline's key-press trigger has historically required the slide to already have focus, not just any keypress, verify this on your own build
• Check your chosen shortcut against Storyline's full current list of built-in shortcuts before using it
• Test keyboard-only access and screen reader access separately, neither one proves the other works

What's inside

Storyline developers and accessibility specialists adding a custom Player tab or navigation help and making it usable without a mouse

1. 01Why keyboard access to custom Player tabs matters
2. 02Understand what you're building
3. 03Create accessible help content
4. 04Add keyboard access
5. 05Test keyboard-only access
6. 06Test with a screen reader
7. 07Check focus behavior
8. 08Common mistakes
9. 09Testing with different assistive technologies
10. 10Quick testing checklist

Why it matters

A custom Player tab or help panel that only opens by clicking with a mouse locks out keyboard-only learners entirely. Adding a keyboard shortcut fixes part of that, but only part. Storyline's own key-press trigger has historically required the slide to already have focus before a key press is recognized, not simply that something was clicked, which means a shortcut that works when you test it one way can behave differently for a learner navigating purely by keyboard. The central thing to hold onto: making a custom Player tab keyboard accessible is not just about opening it with a shortcut. The entire experience, opening, using, and closing, needs to be tested with a keyboard and with a screen reader before you can call it accessible.

When you'll encounter this

• You're building a custom Player tab or in-course help panel meant to be available on every slide.
• You're considering a keyboard shortcut trigger on a slide master so it applies across the whole course.
• A reviewer or scan flags that a custom tab is reachable by mouse but its keyboard access hasn't been confirmed.
• You're deciding whether an older webinar or Community answer's shortcut recommendation still matches how your current Storyline build actually behaves.

Examples

Best practices

• Separate the pieces before you build anything: the custom Player tab itself, the help content it opens, the keyboard method used to reach it, and the focus behavior both when it opens and when it closes. These are five different things to design and test, not one.
• Build the help content the way you'd build any accessible slide: meaningful headings, content that reads in a logical order, real accessible names on any button or link inside it, and a Focus Order that matches what a learner would expect. See the Focus Order Guide and Keyboard Navigation Guide for how to check these directly, this guide doesn't repeat that process.
• Add keyboard access using Storyline's own "When the user presses a key" trigger, placed on a slide master if you want the same shortcut available across every slide that uses it. Verify current behavior on your own Storyline build before relying on it: this trigger has historically required the slide to already have focus, not necessarily a prior click according to Articulate's own clarification, before a key press fires, and a related issue was fixed in Storyline 360 build 3.50.24668.0. Don't assume an older webinar or Community answer describes exactly how your current build behaves, test it.
• Choose the shortcut carefully. Storyline's published courses already use a full set of Ctrl+Alt+ combinations, Z, T, M, C, R, P, comma, period, S, F, and A, for zoom, accessible text, mute, captions, replay, play/pause, previous/next slide, submit, full screen, and background audio, plus Shift+? for its own built-in shortcuts list. Check your chosen combination against the current list before using it, don't invent or assume a combination is free without checking, and note that on a Mac keyboard, Cmd and Option commonly replace Ctrl and Alt.
• Test keyboard-only access on the published course, not just in Storyline Preview: start the course, reach the custom tab or its shortcut using only the keyboard, confirm the help opens, navigate through everything inside it, operate every interactive element, close it, and confirm where focus lands.
• Test with a screen reader separately, NVDA is a reasonable default. Confirm the help is actually announced when it opens, where screen reader focus moves to, whether headings and content make sense read aloud, whether every control has a real accessible name, and what happens when the help closes. Keyboard-only testing and screen reader testing check different things, passing one doesn't confirm the other.
• Check the whole focus path, not just the moment the shortcut fires: shortcut or control, help opens, focus enters the help, the learner navigates the help, help closes, focus returns somewhere logical. A shortcut successfully opening the content proves the shortcut works, nothing more, the rest of the path still needs checking on its own.
• If you can, test with more than one screen reader. Different screen readers can announce the same custom content differently, so confirming behavior in NVDA alone tells you about NVDA, not about every assistive technology a learner might use.

Common mistakes

• Making the custom tab or help reachable only by mouse.
• Choosing a keyboard shortcut that conflicts with one of Storyline's own built-in shortcuts.
• Getting the shortcut working and never testing the content it opens.
• Ignoring Focus Order inside the help content itself.
• Testing only in Storyline Preview instead of the published course.
• Never testing what happens when the help closes, only what happens when it opens.
• Assuming keyboard accessibility proves the same experience works with a screen reader.
• Assuming screen reader testing alone proves every keyboard interaction is correct.

Practical checklist

• Custom Player tab or help has a clear purpose.
• Keyboard users can reach it without a mouse.
• The shortcut doesn't conflict with an existing Storyline shortcut.
• Help content has a logical Focus Order.
• Help content can be navigated without a mouse.
• Every interactive element inside the help is keyboard accessible.
• NVDA testing completed where required.
• Focus behavior when the help opens was checked.
• Focus behavior when the help closes was checked.
• The published course was tested, not just Storyline Preview.
• Any issues found were documented and retested after changes.

Frequently asked questions

Summary

A keyboard shortcut that opens a custom Player tab is a starting point, not proof the tab is accessible. Build the help content with real headings, Focus Order, and accessible names, add keyboard access with Storyline's key-press trigger after verifying how it behaves on your own build, choose a shortcut that doesn't conflict with Storyline's existing ones, and test the complete path, opening, navigating, and closing, with a keyboard and with a screen reader before calling it done.