Implementing Screen Reader Alerts in Storyline

Last updated: 5/26/2025

Certain eCourse events should be accompanied by an alert so that screen reader users can reliably become aware that the event occurred. For instance:

  • A button is selected or unselected
  • A layer opens or closes
  • A button that was previously disabled becomes enabled
  • An activity within a slide is reset to its initial state
  • An element that was previously hidden appears*
  • Other similar events

These alerts can be provided in the form of a sound effect or in the form of an announcement automatically made by a screen reader.

*Note: separate alerts would likely not be necessary for text or images that become visible as part of synced media, if synced audio describes the text or image at the time it appears.

Sound effect alerts

Sound effect alerts are typically easy to implement, but they tend not to provide as much information as screen reader announcement alerts and thus, are less suited for many situations.

Sound effect alerts may be most appropriate for situations where focus will not be drawn to the event that transpires. For example, consider a slide that starts with its Next button disabled and requires learners to open each layer within the slide before the Next button can be used. When the final layer is opened and the Next button changes states from disabled to normal, you wouldn't want focus going to the Next button — because focus should instead go to the first element in the newly-opened layer — so a sound effect could be used instead to alert screen reader users that an event has occurred. (The technique described further below in the Custom alert section could also be used in a situation like this and may better inform screen reader users.)

Sound effect alerts can typically be implemented using a Play media trigger.

Example of using a variable to track if all layers in a slide have been opened; when they have, the variable is set to true, and that variable change triggers a completion alert audio file to play

Screen reader announcement alerts

Automatic screen reader announcements are a great means for alerting screen reader users to certain eCourse events, like a layer opening or a button being selected.

Set focus trigger

When focus lands on an element through a set focus trigger, screen readers will typically automatically announce that element.

However, be aware that some bugs have been found with certain set focus triggers. Learn more about them, and possible workarounds, in the Set focus bugs section of the Focus order in Storyline page.

Custom alert

This technique can be deployed in situations where a screen reader alert is needed or wanted and none of the other methods described below are suitable.

For example, consider a slide that features a selection-based activity: you may want to provide learners with a button that will reset the activity, such as setting all the selectable elements back to their normal/unselected states and returning focus to the top of the slide or start of the activity. In such a case, it would be appropriate for the reset button to also trigger a screen reader alert, so screen reader users could reliably be made aware that the activity was indeed reset, as intended. (This technique could also be used in the situation described further above, in the sound effect alert example.)

  1. Create a text box outside the slide area, and type into it the desired alert message: for example, "Activity reset"

  2. Set the text box's default state to Hidden
  3. Adjust the text box's Timing so it does not show until end of slide
    • Testing has revealed the Show until end of slide Timing setting to sometimes produce an extra, unnecessary JAWS announcement

  4. Give the text box a Fade entrance animation with a duration of .20s

    • Iterative testing has found that if the duration is too short (e.g., < .15-20s), the post-toggle button will be announced twice, which some may find an inferior screen reader experience, rather than the shape being announced then the post-toggle button being announced once; if the duration is too long, assistive technology users may execute another command before the technique has fully executed, which could cause problems

  5. Give the element that will trigger the alert two additional triggers: 1) a trigger that changes the text box's state to Normal; and 2) a trigger that sets focus on the text box

  6. Give the shape two triggers: 1) a trigger that sets focus on the button when the shape's entrance animation completes; and 2) a trigger that changes the shape's state to hidden when the shape's entrance animation completes
    • That second trigger works to ensure this technique is executed every time a learner toggles the button

Note: As described in the Technique for forcing the appropriate state to be announced section further below, this technique could also be implemented using an alt-tagged shape instead of a text box containing the alert text.

Prevent the user from clicking on the other layers

This layer property will automatically move focus to the element in the layer that is highest in the slide's focus order, and that element should subsequently be automatically announced (though, NVDA has been known to occasionally announce another, random element first, and both JAWS and NVDA may continuing announcing additional content within the newly opened slide until they receive a new user command).

Layer opening

Example of a button opening a layer and hiding itself, with the layer's first element immediately after the button in the focus order

When a layer that does not have the "Prevent the user from clicking on the other layers" layer property assigned to it opens, JAWS and NVDA will typically automatically announce whatever element currently has focus; that will typically be the button that was clicked to open that layer, but if that button is changed to its hidden state as part of the same event that opens they layer — for example, if both actions are triggered by When user clicks events — focus will jump to the next element in the focus order, causing that to be the element that is automatically announced.

Button being toggled

When a button is toggled, such as when it's toggled back and forth between selected and unselected states, it's typically appropriate for screen reader users to be alerted to that in some way, both to confirm the toggle event occurred as intended and to inform the user as to the button's new current state.

NVDA has been observed to announce a button's new state when it's toggled: for example, if focus is on a button that is currently unselected, and an NVDA user presses enter or space to toggle the button into its selected state, NVDA will automatically announce the button's selected state alt text (or button text, if no unique alt text is assigned).

JAWS has been observed to produce different behavior depending on how the user navigates to the button. If a JAWS user tabs focus to a button, it will behave as described above when toggled: that is, the alt text or button text associated with the button's new state will be automatically announced, which is typically the appropriate behavior.

But, if a JAWS user reads to the button using the arrow keys and then toggles it, JAWS has been observed to automatically re-announce the button's old state: for example, if a JAWS user reads to an unselected button and presses enter or space, JAWS may automatically announce the button's unselected state alt text, not the alt text for the selected state into which the button has been toggled. (Though, a subsequent "read current line" command should result in the appropriate button state being read.)

Since this behavior could confuse or inhibit JAWS users and may be considered in tension with WCAG 1.3.1 Info and relationships (A), it's recommended that you employ the technique detailed below to ensure the appropriate alt text is automatically announced.

Technique for forcing the appropriate state to be announced

This technique can be quickly applied to ensure JAWS announces the appropriate button state when a button is toggled. (Note: This technique is a variation on the technique described further above in the Custom alert section.)

  1. Insert a shape somewhere outside the slide area (being outside the slide area will prevent the shape from being detectable through normal assistive technology user engagement)

  2. Set that shape's default state to Hidden
  3. Adjust the shape's Timing so it does not show until end of slide
    • Testing has revealed the Show until end of slide Timing setting to sometimes produce an extra, unnecessary JAWS announcement
  4. Give the shape alt text like "Selection toggled"
    • This alt text will be automatically announced as part of JAWS interacting with the button, so choose alt text that would be appropriate given the interaction, such as how "Selection toggled" is appropriate for a toggle button interaction

  5. Give the shape a Fade entrance animation with a duration of .20s

    • Iterative testing has found that if the duration is too short (e.g., < .15-20s), the post-toggle button will be announced twice, which some may find an inferior screen reader experience, rather than the shape being announced then the post-toggle button being announced once; if the duration is too long, assistive technology users may execute another command before the technique has fully executed, which could cause problems

  6. Give the button two triggers: 1) a trigger that changes the shape's state to Normal when the button is clicked; and 2) a trigger that sets focus on the shape when the button is clicked

  7. Give the shape two triggers: 1) a trigger that sets focus on the button when the shape's entrance animation completes; and 2) a trigger that changes the shape's state to hidden when the shape's entrance animation completes
    • That second trigger works to ensure this technique is executed every time a learner toggles the button

Note: As described in the Custom alert section further above, this technique could also be implemented using a text box containing the alert text instead of an alt-tagged shape.

See also within the Checklist