How Storyline Button Sets Work With Keyboard Navigation

Questions answered by this guide

• ?Why does Tab only reach my first Storyline answer choice?
• ?Is my quiz broken if Tab does not stop on every answer?
• ?How do keyboard users select an answer in a Storyline button set?
• ?What is the difference between a button set and a group in Storyline?
• ?Do Pick Many and Multiple Response questions work the same way as Pick One?
• ?How should I test keyboard navigation on Storyline answer choices?

What you'll learn

• Tab reaching only the first answer usually means the choices are a button set, not a keyboard access failure
• Inside a button set, arrow keys move between choices, Tab moves past the whole set
• Pick Many and Multiple Response questions have a separate, documented arrow-key issue with some screen readers, where Tab is the current workaround
• Custom-built buttons that were never added to a button set behave differently and need their own keyboard test

What's inside

Storyline developers troubleshooting keyboard navigation on quiz answers and button-based interactions

1. 01Short answer
2. 02Why Tab does not stop on every answer
3. 03What a Storyline button set does
4. 04Button set vs. an ordinary group of buttons
5. 05Tab vs. arrow keys
6. 06Pick One and Multiple Choice
7. 07Pick Many and Multiple Response
8. 08Custom buttons and freeform interactions
9. 09When this is actually an accessibility problem
10. 10How to test it
11. 11Common mistakes
12. 12Practical checklist

Why it matters

Tab reaching only the first answer is one of the most common things flagged as broken during an accessibility review, and it is usually not broken at all. Storyline's answer choices are normally set up as a button set, and a button set is designed so Tab enters it once and arrow keys move between the individual choices, the same pattern a native HTML radio group uses. Treating this as a bug and changing the focus order to force Tab onto every choice fights against how the interaction is built and can make the actual keyboard experience worse, not better. The real risk is different: not testing the arrow-key step at all, or assuming a custom-built set of buttons behaves the same way when it was never actually grouped into a button set in the first place.

When you'll encounter this

• You Tab through a quiz slide and keyboard focus lands on the first answer choice, then jumps straight to the next control instead of the second answer.
• An accessibility review or a coworker flags that Tab does not reach every answer choice.
• You are deciding whether to change the Focus Order to force Tab onto every choice.
• You built a custom set of answer buttons by hand, rather than using Storyline's built-in question types, and are not sure how it should behave.

Examples

Best practices

• A Storyline button set is a real, named feature, not just a group of buttons that happen to sit near each other. Right-clicking one or more selected objects and assigning them to a button set (Button Set 1, or a new set) tells Storyline those objects share a single, mutually exclusive selection, choosing one automatically deselects the rest. Almost any object type can be added to a button set, not just buttons, pictures, shapes, and characters can all be included. This is what gives Storyline's answer choices their radio-button-like behavior.
• A button set is not the same thing as an ordinary group of objects. Grouping objects in Storyline (Ctrl+G) is a layout and editing convenience, it lets you move, resize, or copy several objects together. It does not create shared selection behavior or change how Tab and arrow keys move through them. Two buttons that are grouped for editing purposes still behave as two separate, individually tabbable buttons unless they are also assigned to a button set.
• Inside a button set, the keyboard pattern is Tab once to enter, then arrow keys to move between the individual choices, then Tab again to move past the set to the next control, commonly a Submit button. This is consistent with how a native HTML radio button group works, and it is the pattern to test for, not Tab stopping on every choice.
• Multiple Choice (graded) and Pick One (survey) questions ask a learner to choose a single answer from up to 10 choices, and both are built on Storyline's button set behavior, Tab into the set, arrow keys between choices, one answer selected at a time.
• Multiple Response (graded) and Pick Many (survey) questions let a learner choose more than one answer, so they cannot use a strict single-selection button set the same way Pick One does. Keyboard navigation still follows the Tab-then-arrow-keys pattern, but Articulate's own accessibility documentation for Storyline 360 currently lists a real, specific gap here: in pick-many and pick-one question slides, some screen readers re-announce the currently selected choice instead of moving to the next one when the down arrow key is pressed. The documented workaround is to use Tab instead of the arrow keys to move between choices when this happens. This is worth testing directly with the screen reader your learners are most likely to use, and worth mentioning in course instructions if a quiz depends on arrow-key navigation.
• Custom buttons and freeform interactions that were never assigned to a button set do not get this behavior automatically. If a set of answer-like buttons is built by hand with triggers instead of Storyline's question types, each button is just an ordinary, individually tabbable object unless it is deliberately grouped into a button set. Test these the same way you would test any custom interaction, do not assume they behave like a native question slide just because they look like one.

Common mistakes

• Reporting that Tab skipping between answer choices is a keyboard access failure without first testing the arrow keys.
• Manually reordering Focus Order to force Tab onto every individual answer choice in a button set.
• Assuming a custom-built set of answer buttons behaves like a native question slide without checking whether it was actually assigned to a button set.
• Testing only in Storyline Preview instead of the published output, where keyboard behavior should always be confirmed.
• Not testing the arrow-key step at all, and only checking that the first answer is reachable.
• Assuming Pick Many and Pick One behave identically for every screen reader, without testing the specific arrow-key re-announcement issue Articulate has documented.
• Leaving a course with unclear selected-state styling, so even when keyboard navigation works correctly, a learner cannot visually or audibly confirm which answer is currently selected.

Practical checklist

• Tab into the interaction and confirm focus lands on the first answer choice.
• Identify whether the choices are a Storyline button set (mutually exclusive selection, radio-button-like) or a custom set of independent buttons.
• Use arrow keys to move between choices where the interaction is a button set.
• Confirm the Selected state is visually clear on whichever choice is focused or chosen.
• Confirm keyboard focus stays visible at every step, not just on the first choice.
• Use Enter or Space to activate or confirm a choice where the interaction expects it.
• Tab to and test the Submit button separately from the answer choices.
• Test the published course output, not just Storyline Preview.
• Test with a screen reader, and if arrow keys do not move between choices as expected, try Tab and Shift+Tab instead.
• Re-test after any change to the question type, the button set assignment, or the Focus Order.

Frequently asked questions

Summary

Tab reaching only the first Storyline answer choice is usually a sign the choices are a button set, not a keyboard access failure. Inside a button set, Tab enters once and arrow keys move between choices, the same pattern a native radio button group uses. Pick One and Multiple Choice questions follow this cleanly, Pick Many and Multiple Response allow more than one selection and carry a separate, documented arrow-key issue with some screen readers, and custom-built buttons only behave this way if they were actually assigned to a button set. Test with Tab, arrow keys, and Enter or Space on the published output, and only treat this as a real problem if the arrow-key step itself does not work, not because Tab skips between choices.